I am running a marketplace for video games. When a buyer buys an item they can directly pay the seller through Paypal by setting the 'business' variable to the Paypal account of the seller in the link that will send the buyer over to Paypal to complete the purchase.
While this works most of the times, there are downsides to this approach as the website fully depends on receiving the IPN of the transaction. In very rare cases, Paypal fails to send the IPN (server logs show that there was no such request to the listener script – even hours later).
Is there a way to integrate a direct payment from buyer to seller where the website immediately gets feedback that the purchase has been completed (via JS-API or similar), so the website does not only depend on the IPNs?
I have seen a few similar questions on StackOverflow, but the solutions mentioned in answers have been deprecated as far as I can see (Adaptive Payments are no longer supported for new projects).
Integrate PayPal checkout with a server-side pattern. Here is the front-end UI: https://developer.paypal.com/demo/checkout/#/pattern/server , which will call two routes on your server.
Those routes will in turn call the PayPal API to 'Set Up Transaction and 'Capture Transaction', respectively: https://developer.paypal.com/docs/checkout/reference/server-integration/
The above has no dependency on asynchronous IPN or webhooks.
Since the buyer will be paying the seller and not your account, you can use the custom 'payee' object to specify this: https://developer.paypal.com/docs/checkout/integration-features/custom-payee/
Related
I have tested a PayPal IPN on sandbox. It works without issue. I tested it using the demo PayPal account. Now I have moved live I cannot test with a PayPal account, as I only have one. So I tried using a card. The payment is successfully made. However, the IPN is empty.
I don't have any PHP errors for the IPN call. The IPN URL defined in Notifications -> Payment Notifications on my live account is correct.
The payment is made using PayPal Smart Checkout: https://developer.paypal.com/docs/checkout/#how-the-buttons-work
Does PayPal not use IPNs when buying by card?
What do you need IPN for? That is a very old service.
Use a server-side integration for the PayPal Checkout. Here's the UI: https://developer.paypal.com/demo/checkout/#/pattern/server
You'll need two corresponding routes on your server, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here: https://developer.paypal.com/docs/checkout/reference/server-integration/
I would like to be able to test our integration with PayPal. We have sandbox accounts set up, etc, and I can even create payments. However, I'd like to be able to also issue refunds, query for refunds, and all the other APIs, all via integration tests and without human or even browser involvement. The difficult part seems to be that, of course, the PayPal flow requires someone to interact with a PayPal URL and approve the purchase.
Some more detail : We use the standard e-commerce flow on our site. User shows up, puts a product in a cart, proceeds to buy flow, selects a payment method, in this case PayPal. Of course, in PayPal's case, we create the Payment in PayPal and then simply show the embedded popup of palpal's flow where the user logs into their PayPal account and approves the purchase. PayPal does all this work. We simply get the response that 'yes, the purchase has been approved'.
So.. in an integration test environment, we can create the Payment entity in PayPal but.. how do we, in a sandbox environment integration test, get that payment approved? Is there a developer API available on the sandbox environment that says 'hey, this PayPal user approves this payment' or 'hey, this PayPal user rejects this payment', so that in test code we can simulate the buyer's flow. Or is there a way to set up a sandbox account to just 'auto approve' purchases or 'auto reject' purchases, simply for a test environment?
Yes, you can do anything in the sandbox that you can do on the live servers. This is a very broad question, though, so it's tough to answer.
For example, if you want to process payments without the need for any browser flow you'll need to have a billing agreement setup or a Pro transaction so you can run reference transactions. This would involve Express Checkout APIs and/or Payments Pro APIs, and reference transactions APIs. Depending on whether you're using Classic or REST, though, the API calls would be different.
In any case, once a transaction exists in the PayPal sandbox system you could then use the API to refund it. Same thing, though...you'd either be using REST APIs or Classic.
If you can provide more specifics in your question I can update this answer to be more specific as well.
I new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
We are using Paypal recurring billing service (using Express Checkout) at our website for monthly subscription.
Since we have an Australian account so we are not able use the DPRP (Direct Payment Recurring Payment) service offered by Paypal because it seems, DPRP service is limited
to only few countries (US, UK and Canada).
In Express checkout payment details are received at Paypal Website. So we do not have any information, whether the payment failed, user pressed the Back button in browser or He/She intentionally clicked the cancel payment.
After speaking to Paypal support team we get know that there could be multiple possible reason for Payment failure, and seller has to contact Paypal by themself. So we can
not provide any troubleshooting for that at our website.
So we want to know, Is there any possible solution to avoid this or atleast can we diffrentiate between the user for whom payment failed and who intentionally moved to
our website back without doing payment because this way we are not only unable to followup with them but also loosing a part of the customer base, interested in our service.
Any help in this is Appreciated.
Thanks
You should implement the Pay Pal IPN (Instant Payment Notification).
You configure the IPN url address on your PayPal merchant account settings. This page is simple HTML page with server-side programming that is listening for requests coming from PayPal.
There's no need to do something extra in the checkout process for making IPN work. Once you set this up, it will automatically work.
Every time something happens with a transaction in your merchant account, e.g. transaction completed/failed/canceled, PayPal will send an HTTP Post to your IPN listener URL.
Here you can get all the relevant information about the transaction, like the payer ID, the payment status. With this information you can decide what to do with your customer's order.
I have downloaded sample code from paypal to allow me to use parallel payments via their sandbox accounts. When I run parallel.php, I get redirected to paypal's sandbox login page.
How am I supposed to know "server side" that the payment has been made successfully, so I can update my database records?
I believe you have to work with PayPals IPN system. This will basically send a confirmation to your server that tells you it has gone through.
https://www.paypal.com/ipn
Paypal lets you register a notification url which is part of the IPN (instant payment notification IIRC) system. So if someone pays by a delayed payment (such as a bank transfer) the transaction will update days later. You need to have an application (web page) on your server that can be called by Paypal with transaction details to update a payment.
You'll need to create an initial transaction record in your system when paypal redirects back to you so refer to their documentation for that. I'd also recommend looking at either OSCommerce or Zen cart for an idea of how they do it as they support the same kind of thing.