I have PayPal PDT (Payment Data Transfer) enabled on my PayPal account, and I have auto-return turned on, pointing to a "Complete_Paypal_Order" page on my site.
When a customer makes a purchase, and they pay using PayPal's site, they are sent to a page which will redirect them back to my site within 10 seconds. If the customer waits for the redirect, the GET request to my site contains the transaction id, just as it is supposed to.
If, however, the customer clicks the link on PayPal's redirect page that says "If you are not redirected within 10 seconds, click here," the transaction id is not passed to my site. Instead, the get request looks like: "http://.../Complete_Paypal_Order?merchant_return_link=click+here&form_charset=UTF-8", no matter what the customer ordered. This happens in both sandbox and live PayPal sites.
Has anyone run across this before, and if so, do you know of a solution?
Also, just to be clear, I am aware of some of the drawbacks of PDT, but suffice to say that, for various reasons, changing to IPN or API calls is not an option for the site at this time. So, please don't suggest "just use IPN" or "just use ExpressCheckout API calls."
Related questions (as yet unanswered):
Paypal PDT - unable to get transaction ID.
Paypal PDT AutoReturn
Related
2
I have PayPal PDT (Payment Data Transfer) enabled on my PayPal account, and I have auto-return turned on, pointing to a "Complete_Paypal_Order" page on my site.
When a customer makes a purchase, and they pay using PayPal's site, they are sent to a page which will redirect them back to my site within 10 seconds. If the customer waits for the redirect, the GET request to my site contains the transaction id, just as it is supposed to.
If, however, the customer clicks the link on PayPal's redirect page that says "If you are not redirected within 10 seconds, click here," the transaction id is not passed to my site.
Has anyone run across this before, and if so, do you know of a solution?
Also, just to be clear, I am aware of some of the drawbacks of PDT, but suffice to say that, for various reasons, changing to IPN or API calls is not an option for the site at this time. So, please don't suggest "just use IPN" or "just use ExpressCheckout API calls."
A very rough history of PayPal integrations (forgive me if my dates are off by several years)
PDT: Circa 2002.
IPN: Circa 2004?
Express Checkout: Circa 2006?
I won't tell you to just use something else, but I will tell you this about PDT: It is a terrible choice, completely undependable for payment confirmation purposes, and suitable for extra informational purposes only. Basically, you can use it to display some transaction details if and when if the buyer does return to your site, since in many cases they may not return at all in such an API-less integration. For example, if they pay as a guest and PayPal is legally obligated to show them a receipt and they just close their browser treating that as the final confirmation.
Anyway, have you looked in the POST (not GET) for the PDT data?
As far was what you should be using, if you really can't implement an API, a client-side JS integration is at least somewhat more reliable: https://developer.paypal.com/demo/checkout/#/pattern/client
(But, something like the Express Checkout you mentioned (using current v2/checkout/orders API for 2 routes of 'Set Up Transaction' and 'Capture Transaction', documented here, and the server demo pattern paired with those 2 routes -- will of course be most ideal, whenever it does become an option for you)
I maintain a PayPal integration which uses PayPal HTML Buttons and confirms payment using IPNs. This system has been in production for more than 5 years.
The system sets the cancel_return variable to a unique URL for each order. If this URL gets hit (i.e. if the customer cancels at paypal and gets sent to this URL), it first checks the session, to ensure the user hitting the URL is the same one who initiated the order, then cancels the order.
I noticed that several recent transactions have been cancelled even though the transactions at PayPal were successful.
The logs showed that customers are hitting the cancel_return URL - in some cases just after the IPN has been received, and in one case just before the IPN was received.
I found at least one way to reproduce this behaviour:
initiate the order on my site
complete the payment at paypal
return to merchant
use the back button to return to paypal
I then get a message that says "Your payment was completed. To continue shopping, please return to the merchant." One button is provided: "Return to merchant name".
Clicking this button takes the user to the cancel_return URL!!
PayPal's documentation for cancel_return says
A URL to which PayPal redirects the buyers' browsers if they cancel checkout before completing their payments. For example, specify a URL on your website that displays a "Payment Canceled" page.
Default — PayPal redirects the browser to a PayPal webpage.
My question is whether this is an intentional change by PayPal -- if so I expect it will break many sites -- or if this is a bug. I couldn't find a bug report at PayPal.
Yes, they changed the meaning of cancel_url, though they are not acknowledging this as a bug or an intentional change. This is definitely a bug in my opinion (as documented in the question above).
In addition to the steps above (reproducing using the back button), I found a customer click-trail in my server logs where the customer was sent to the cancel_url, without using the back button, soon after PayPal sent the IPN confirming their successful payment. I confirmed that the customer did not want to cancel and did nothing to intentionally cancel their order. Unfortunately I could not find a way to reproduce.
I registered at www.paypal-techsupport.com and submitted a ticket about this issue. After several exchanges, the end result I got was:
This is the information that I received from our engineer.
Its an expected behavior when the customer click on the back button, it will bring back to the cancel_url.
We would suggest you to do some modification so that the order is not being cancel when the customer go to the cancel_url.
With poor customer support like this, I will not be recommending PayPal to any of my clients in the future.
You can post it here and the PayPal folks can pick it up.....
https://www.paypal-community.com/t5/Merchant-Technical-Support/ct-p/mts
I have a site where my users can create invoices. I would like to offer my users the ability to have their invoices paid by their clients via PayPal. Each user on my site has their own paypal account.
I would like to use PDT so that the status of the invoice is updated to paid immediately after a payment is made via paypal. However, it would appear that this is not possible, because PDT requires that Auto Return is enabled (https://www.paypal.com/pdt) in the paypal account. Given that I don't have control of all my clients' paypal accounts (and I can't ask all of them to enable Auto Return), this doesn't seem to be feasible.
However, looking further into Standard Payments (https://cms.paypal.com/uk/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_formbasics), I can create a form variable called return (see Setting The Return URL on Individual Transactions). Does this mean that PDT data will be returned when using this method?
What you want is Instant Payment Notification (IPN). It is very similar to PDT except that it will be triggered regardless of whether Auto Return is enabled and whether or not the user actually makes it back to the site (which isn't guaranteed even with Auto-Return enabled).
The IPN system will POST transaction data to a listener on your web server in real-time. This can be used to update your own database, send email notifications, hit 3rd party web services, or anything else you'd like to automate.
IPN happens "behind the scenes". It's server-to-server communication, so it's not something that you'll see happening in the browser. It will do exactly what you're wanting, though.
After adding stuff in shopping cart, clicking some Pay Now with PayPal button, and successful PayPal payment (PP or CC), it is logically possible that a user stays on PayPal website, if for example the Auto Return option isn't activated (or it is but it doesn't work because the user is a guest user without PP account)
The user can return to the site by clicking a link, but doesn't have to. My question is: if he doesn't, how will the site owner be aware that the user paid so that he can now send the items by post? That the site owner gets informed of being paid seems elemental to me, so I find incomprehensible that such elemental thing be left to some obscure Auto-Return option.
Please can somebody explain this to me?
This is a common challenge with any redirected payment gateway, and it's the reason most (if not all) of them implement some sort of asynchronous notification that a payment has been completed. In PayPal, this is the Instant Payment Notification (IPN). You must setup on your site either a generic IPN listener that you link to from your PayPal account profile settings or you can create a more targeted IPN listener specifically for your transactions and use the NOTIFYURL (or related) parameter in the form or API request you use to redirect to PayPal to send IPNs to that listener.
In my integrations, I never perform any order update or transaction logging when the customer returns from the site, preferring instead to wait for the IPN that I can validate and ensure came from PayPal as opposed to a spoofed return from someone trying to hack my checkout process.
For more information, see the IPN documentation: https://www.x.com/developers/paypal/documentation-tools/ipn/integration-guide/IPNIntro
Paypal provide IPN for this purpose through which we paypal send request asynchronous to your site and you can perform whichever action you want
I think the point may have been missed here. Or a problem does exist. If the purchaser uses CC, even if you have IPN set up and it works, but if the purchaser uses CC and does not click a button on the last page, which is not presented when using PP account, it is possible for the funds to go through, but no IPN, and so your website is unaware of the purchase. This last page, is an extra page that CC user gets after the page with the Pay button on it.
In this state, you can even go into IPN history, and the IPN is there, says it is sent, but it hasn't been. It does not get sent until after the purchaser clicks the button on the extra page and then they are taken to the auto return page.
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/