I have a SAAS web application that works through a subscription fee. If the subscription is valid everything works fine, otherwise the app goes in read-only mode until the customer renew the subscription. I've developed the payment flow with the PayPal API.
The problem is that PayPal Documentation says this:
"Although PayPal usually processes IPN messages immediately, IPN is not synchronized with actions on your website. Internet connectivity is not always 100% reliable and IPN messages can be lost or delayed. The IPN service automatically resends messages until the listener acknowledges them. The service resends messages for up to 4 days.
Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
Unfortunately this is exactly my case: when customers renew the subscription I need to immediately activate the app so I placed all the logic right in the "notify callback" where I have to create the order, send a confirmation email, update some session variables... but I if there's a delay from PayPal IPN this is a problem!
In these days I did some test in Sandbox mode and in several cases I got an answer from IPN even 4 hours after the successful payment! This is unacceptable for my app!
Finally the question: what's the best solution for my case? It makes sense to move the application activation from "notify callback" to "success callback"? There may be problems?
Thanks
Don't use IPN for this; it's a poor fit & not designed to be inserted into synchronous user experience flows. It works fine as a way to initiate offline fulfillment, but can delay your customers if they are actively waiting for access.
You don't specify which PayPal product you are using, but each product should provide a way to immediately give you feedback that the payment has been completed. For example with Express Checkout or any API-based payment you can take action (activate/re-activate a subscription) when you receive the successful API response (the DoEC API in the case of Express Checkout).
With web-only/non-API products you can take action when the customer redirects to your return_url, using PDT to securely get information about the transaction if you need that (it can include an IPN-style key that you post back to PayPal to verify, exactly as you do with an IPN).
If you are concerned about the edge cases of someone closing their browser before it can redirect to you, or some other sort of dropped connection or programming error, you can also check & activate/fulfill upon receipt of an IPN to catch any fallout. So all customers that complete a normal payment flow are activated immediately; if they do something wonky (or your code breaks, or whatever) then the activation still happens, albeit potentially delayed by a few seconds or minutes.
Related
I have an e-commerce platform where customers are paying for the product. What we did for tracking customers details is auto-returning to our site with PDT (Payment Data Transfer). But recently we saw that some customers are closing the browser after completing their payment. So they are not auto redirected back to us. And we can't do further procedures. So what should we do in this scenario? How can we solve it?
An automatic return from an API-less Payments Standard integration is not guaranteed. Sometimes, notably in the case of a guest checkout, PayPal must show a receipt, and so the customer must manually click to return. Or the network connection could be interrupted, or their browser could crash. So relying on PDT to trigger business logic is a very bad idea.
Alternatives:
Wait for an asynchronous webhook: https://developer.paypal.com/docs/integration/direct/webhooks/ -- or similarly (older solution), an asynchronous IPN: https://developer.paypal.com/docs/classic/products/instant-payment-notification/
Change from Payments Standard to a synchronous API-based server side integration, such as the one shown in this skeleton demo: https://developer.paypal.com/demo/checkout/#/pattern/server . With this, the capture occurs from your server (after the browser executes the fetch command or redirect back to your server), so you get an immediate API response when your server does that API call to PayPal to capture the payment.
I am using PayPal REST API to programmatically transfer amount from one PayPal account to other. Suppose my C#.NET program has initiated transfer via PayPal REST API but got disconnected before receiving any response. How to know whether the initiated transfer has either succeeded or not, later when connectivity is available? So that, I can either confirm transfer or can initiate retry.
Or
How should I manage this?
You can use the Instant Payment Notifications to get a notification every time something processes.
Instant Payment Notification (IPN) is a message service that automatically notifies merchants of events related to PayPal transactions.
The IPN isn't always timely, you may want to only fall back on this in the case that you get disconnected. I just checked on my last 50 IPN entries, and the log times for them varied from 10 seconds to 5 minutes (averaged 2 minutes) following the transaction on my web server.
To use the IPN, you just need to setup a URL to accept the notifications and that's where you can do any logic needed / save IPN details to the database.
See also:
IPN Getting Started
IPN Integration Guide
Enabling IPN Messaging on your PayPal Account
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...
I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).
Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).
However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.
Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.
Does that mean that a user must have/create a PayPal account to pay?
Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?
Could anyone who's gone through this kindly shed some light?
The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.
With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.
Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.
One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.
Edit
One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.
PayPal's PDT system sends order confirmations to merchant sites that use PayPal Payments Standard and lets them authenticate this information. Such sites can then display this data locally in an "order confirmation" page.
When to Use PDT?
IPN provides the same capabilities described above. So, when should you choose PDT instead of IPN?
With PDT, your site is notified immediately when a customer completes payment. With IPN, however, there is a material lag between the time a customer completes payment and the time your site receives notification of this event.
So, use PDT if your site includes a feature that requires immediate payment notification.
For example, consider a digital music store. With PDT, this store can let customers download their purchases right away since PDT sends order confirmations immediately. With IPN, such immediate order fulfillment is not possible.
Advantages of IPN
PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Another advantage of IPN is that it sends many types of notifications, while PDT sends just order confirmations. So, using IPN, your site can receive, for example, chargeback notifications as well as order confirmations.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will receive two order confirmations for each sale. As a result, you must be careful to take action (say, ship a product) on just one copy of a given confirmation message.
Documentation Here
Re 1. PDT is meant to use with Auto Return for Website Payments feature. Auto Return redirects to PDT site after paying money to seller. Unfortunately it's not possible to use that feature along with PayPal Account Optional - used to enable Credit Card payment. Here is note from PayPal: 'If you have turned on Auto Return and have chosen to turn on PayPal Account Optional for new users, a new user will not be automatically directed back to your website, but will be given the option to return.'. User will have an option to go back to your site(PDT step) or stay on PayPal site. To sum it up when paying by Credit Card user can skip PDT step if user will not click 'return to store link'.
Re 2. It is up to you what paying options do you want to allow. If you want to allow paying without a PayPal Account you can enable Account Optional. If you want to allow only users with PayPal accounts disable that feature. There might be more options.
Re 3. In your case you need to trigger action after successful purchase. Recommended way would be to implement IPN. PDT doesn't work for all cases and doesn't guarantee message delivery. Here is link to doc covering that topic PDT vs IPN.
This is an old question, but my simple answer would be - Why not use both PDT and IPN? They will work fine for card transactions.
PDT can provide the immediate transaction status to your website, where you can quickly check the payment success or failure status and provide the user with appropriate message.
Meanwhile, you can await the full verification from IPN in the background. Once received, you can use this to further update your DB and process the order.
You can follow this step-by-step guide which I found to be very clear and helpful - and it's still valid in 2018.
https://www.codexworld.com/paypal-standard-payment-gateway-integration-php/
For my membership site, I've got the IPN handler done. My question is one of site "flow".
Here's how it goes:
User -> Landing -> SignUp -> Verify -> PayPal -> ThankYou
So here's the problem (which could just all be in my head). Let's say you've signed up and verified your account. Then you click the "Subscribe!" link and are sent to paypal - where you complete payment and get sent to the "Thank You" page.
What if the IPN doesn't arrive back to my site quickly? The subscribe link will still be there, and users may click it again thinking they've not subscribed (even though they have, it's just taking time).
If I combat this by updating their profile to say... "Activating..." when they click the "Subscribe" link, and they don't complete the PayPal process... it could be forever saying "Activating...".
Just curious, as this is my first time integrating PayPal:
How do you handle the state between the time the user clicks the subscribe link and it takes for the IPN process to complete?
Have you ever had any issues with IPN's not arriving quickly?
Your question suggests that the connection to the remote server is asynchronous (ajax)?
It's probably easier to write it in a synchronous manner, so the IPN is guaranteed to return. If it doesn't, it means that:
a) The user closed the browser after being redirected to the remote server;
b) The remote server did not respond.
Good payment gateways will redirect the user back to your site if they click maybe the "Cancel" button, but a return is never guaranteed, so you need to handle it correctly.
I would have a separate table to log the transactions for a given user; that is:
one user, many transactions
Some payment gateways allow you to define as callback to your server when a transaction is completed. That is, the connection is initiated by the gateway -- it does not run the browser, as the user can close the tab/window -- where it does a post to your callback URL, and then you update the status of the transaction.
I'm not sure if PayPal does allow for such things, but so far, I've never had issues with PayPal because I've always written it in a synchronous manner.
Of course, if asynchronous is required, then your ajax function has to have a timeout/error handler -- I recommend jQuery, of course.
I've never had any issue with IPN not arriving quickly, but then again I have never really had a huge website with a lot of users. I also didn't make any significant changes to a user account until I received the IPN.
I made a paid registration for one of my websites using the paypal API. A user would fill out their username, password, etc. and I would pass the variables to the paypal API. The data wouldn't be acted on until I did receive the IPN.
You could always associate a timestamp with a pending payment if you feel the status "Activating..." is important within a user profile. A pending payment could timeout after 10 minutes.