I'm about to integrate Paypal Express Checkout in an online food ordering system. My current view of the flow is the following:
SetExpressCheckout is called, and the customer is redirected to Paypal with the token.
Once the customer has approved the payment, he is redirected to a waiting page, while the order is being sent to the restaurant.
Upon reception of the restaurant response, the following happens:
If the order is approved, DoExpressCheckoutPayment is called and the payment is completed;
If the order is rejected, the payment never completes.
That makes me wonder, is it ever possible that DoExpressCheckoutPayment fails, and the funds cannot be taken for any reason? Because in my case, that would be too late to cancel the order which has already been sent to the restaurant.
Should I use PAYMENTACTION=Authorization instead, and then capture/void the authorization? As the funds can be held for 3 days, while I just need a few minutes for decision, that looks a bit overkill.
Yes, a DoExpressCheckoutPayment API call can certainly fail.
What you should do is set PAYMENTACTION=Authorization in your SetExpressCheckout and DoExpressCheckoutPayment API call, and - once the restaurant has acknowledged the order - call the DoCapture API to capture the funds from the authorization.
Funds are honoured for 3 days, and an authorization is available up to 29 days.
Also; design to fail. Keep a fallback. Just in case the DoCapture does fail. It shouldn't, but you never know. So double-check that 'PAYMENTSTATUS' is 'Completed' and 'TRANSACTIONID' is not empty in the DoCapture API response.
Related
I'am having troubles about how to handle the paypal recurrent payment system.
I followed every instruction in the website, but once i create the profile, paypal puts it in pending, making me doubt about the reliability of the service itself.
I tried to look over the internet but i didn't really get how this should work...
i made the first call with SetExpressCheckout in order to create the request, when the token is returned, i send the token to the paypal page, the user confirms the payment, then i call the CreateRecurringPaymentsProfile method to confirm the operation (passing PAYERID and TOKEN and setting the AMT value for the first payment and the PROFILESTARTDATE as now +1 month for the future payments)
Now when i try to read the response from the last call (or if i go to the buyer/seller paypal account) i see that the payment is in pending and i have to wait an undefined amount of time before this payment is activated.
Now the real question is: can i trust the fact that even if the payment is in pending, i'll receive the payment and so i can set set the user as member or i have to check and wait until the status is 'active' with the GetRecurringPaymentsProfileDetails method?
PS: i'm doing this in the sandbox version, maybe the official version is a bit faster and more reliable?
Thank you!
In Sandbox as in Live when you call CreateRecurringPaymentsProfile you will also get the response in which it will give you the status of the profile (ActiveProfile or PendingProfile). When the status is in Penidng it means that the system is in process of creating the recurring payment profile. You can then check your IPN messages for an update. It is normal but obviously if you notice that all the profiles you create get into Pending and never activate then there could be a bug but should not be the case. In here is the PayPal technical guide for this API: https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/
We are building a new website for a take-away service and are integrating with PayPal Express (Using the NVP API). As orders are dispatched the same evening eCheck payments have been disabled.
The process we're going to follow is as below:
User places order with PayPal and when using DoExpressCheckoutPayment the action used is Authorization
The takeaway confirms the order and a DoCapture request is made setting the complete type to COMPLETE
It is my understanding that at this point, so long as the response status indicates it has COMPLETED that the funds are guaranteed. In fact, apart from very rare scenarios, it should usually be guaranteed at the point of Authorization.
Therefore I do not see the requirement for the IPN? There are no further notifications to be received with a given transaction. I could see the benefit it we were taking eChecks but when that's disabled does it offer anything?
IPN is an optional "messaging service". Your checkout/purchase flow doesn't have any "dependency" (shouldn't as PayPal puts it).
IPN is an asynchronous message service, meaning that IPNs are not synchronized with actions on your website...
...
The IPN message service is not a real-time service. As a result, your listener may not receive an IPN message for many seconds after an event occurs. As a result, your checkout flow should not depend upon receiving an IPN message to complete. If it does, your checkout flow will be slow during periods of heavy system load and complicated, since it must handle retries.
It's been some time for me, but you are correct about IPN being very helpful if/when you support eCheck - re: notified when Paypal has cleared the check/funds (if memory serves, 1 - 3 business/banking days).
Hth...
When using the classic PayPal API, what happens to an express checkout transaction in which DoExpressCheckoutPayment does not get called?
For example, if a user is sent to the PayPal site via a successful call to SetExpressCheckout, signs in and completes the sale on the PayPal and is sent back to my site via the ReturnURL field. At that point, what happens if the DoExpressCheckoutPaymet method is not called? Is there still a transaction waiting to be processed?
The token would still be available for a little while yes, but the transaction is never complete until DECP is called. You could circle back around and use the same token, though, or you could go through SetExpressCheckout again to obtain a new token.
Again, though, there is no actual transaction until DECP is completed successfully (unless you're working with recurring payments, in which case you may skip to CreateRecurringPaymentsProfile).
I have a website with two payment processors:
The other processor have an API call to invalidate a token, so if the user still didn't submit his payment info and I revoked his pending payment token -> he'll get an error.
There's a scenario where a (crazy) user can pay using both payment gateways:
1. The user starts a request to paypal
2. The user starts a request to other processor
3. He completes the payment with other processor
4. He then completes the payment with paypal
As I can see it, only revoking the paypal token can solve this condition.
If so - does anyone know how to do it programmatically?
Note: Any situation where two transactions are completed successfully is unacceptable (so refund/cancel and similar is not a solution)
I'm assuming you're using the (popular) express checkout API, and that the situation you're describing is AFTER you've issued a SetExpressCheckout but BEFORE you issued the DoExpressCheckoutPayment.
In that case, as you already redirected the shopper to the PayPal site, it's out of your hands and there's no API to revoke the token. However, there's a simple solution to your case. Even if the shopper approved the transaction at PayPal, you can still ignore the redirect and NOT issue a DoExpressCheckoutPayment request. In this case, the captured funds from his account (which you never got), will be returned to him 3 hours after the initial SetExpressCheckout was issues.
Don't forget to issue a proper notification to the user.
I am using PayPal with NVP API (using PHP) for express checkout. I am creating an invoice record in the database before redirecting the user to Paypal. In case the user doesn't return to my site after processing, I am using IPN to confirm the purchase and then update the invoice record that the payment is confirmed. I am still in the sandbox mode and trying to figure out how I will tie the transaction started with NVP to the confirmation I get with IPN.
I need to verify if the "PAYMENTREQUEST_n_INVNUM" sent in the NVP will come back as "invoice" in the IPN post.
It appears I cannot actually test this until I am live since the Sandbox IPN does not seem to be active with NVP initiated sandbox transactions - is this correct?
Thanks for your help.
You can test this in Sandbox. But if you're using "PayPal NVP", I assume you're using PayPal Express Checkout and calling the SetExpressCheckout and DoExpressCheckoutPayment API's.
If that's the case, you don't really need IPN, because a transaction will only be completed as soon as you call DoExpressCheckoutPayment.
In other words, buyers will always be redirected to the RETURNURL you specified in SetExpressCheckout, and the transaction is completed (or not) when you call DoExpressCheckoutPayment on this return page.
To get the invoice number, you could call GetExpressCheckoutDetails and supply the TOKEN you retrieved earlier (it's also appended to the GET of the RETURNURL).
Finally, check PAYMENTSTATUS=Completed in the DoExpressCheckoutPayment API response to see whether the transaction has completed or not.
Thank you Robert for the clarity on the process - especially useraction=commit.
I finally realized that I could turn on IPN in the Sandbox for my test seller and test NVP with IPN together. I was able to verify that PAYMENTREQUEST_0_INVNUM matches the 'INVOICE' parameter in the IPN POST.
I will use the custom field to pass customer email from my system in case they use a different email to log into paypal with, therefore allowing me to have email/invoice number pair for confirmation.