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
Related
I have a strange problem, I'm trying to figure out.
I'm using PHP and REST API.
This is the scenario:
1) Users press the checkout button
2) Payment is approved
3) Payment is executed
4) User is redirected to the completed purchase page
5) Few seconds later, Cancel URL of the transaction is called (like when users clicks on Cancel and return to merchant button, instead of approving the payment).
Out of about 100 transactions I had 3 wich manifested this way on all 3 the payment was actually made, and the funds where available. I have checked the server access log files and 2 of them were using ios 9.3.1 and one was an ios 9.2.1. How is this possible?
My guess is that they somehow hit the back button and then the cancel button, can this be the case?
My cancel URL contains a script which sets the order status to canceled, should I adjust the script to only set the status to canceled if the order wasn't previously executed.
Can anybody still cancel the payment AFTER I have executed the payment?
I think you should "trust" the IPN message sent by PayPal rather than the ok/cancel return url.
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/
The ok/cancel url should only be used to display the information to the user
Let PayPal know your IPN endpoint (the script which will receive the IPN GET/POST message). Once your script get called, update the database accordingly
Doing this way the user would not be able to screw up the transaction, you are guarantee to receive 1 IPN message, either it is an "transaction ok" or a "transaction error" message
Your issue seems to be similar to the question posted here.
From user2090027's response which was marked as answer
"We can overcome this by checking/maintaining the no of responses which we get after the payments are made on paypal.
We can maintain this using cookies on client end or on server using sessions or something else similar."
Hope this helps.
This is an old question but having built a PayPal integration myself I thought I'd add some info about why it happens.
If the user ends up on your "return" page after completing their payment and hits the back button, they'll get a PayPal page like this:
If they click "Return to merchant", they'll be sent to your /cancel URL. So if you get one of these and the payment has already gone through, you can show them the payment confirmation page.
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 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
I'm implementing a simple Buy Now button and I'm using IPN (not PDT) to verify the transaction.
A thing that bugs me is that I don't understand how come only after I set the notify_url field to the button I also get the transaction variables to the success URL, as GET params. It would seem normal to be the other way around.
Since the user could or could not choose to "return to the merchant's website" there's not way I should rely on that data. It does however seem to be identical to the one sent to the notify URL.
Some clarification would help. Thanks!
I know what you mean, after the user has finished paying and chooses to return to the sellers website (button in paypal page) they are redirected to your thankyou page.
I don't think it used to do this back in 2009 but now paypal will issue the redirect with all sorts of parameters in the url query string.
I'm just ignoring this information and relying on the backend IPN post which is verifiable by paypal
In my previous experience with IPN, I defined the location of the notify URL in the control panel. Once the payment is processed, PayPal sends a POST notification to this URL independent of any user behavior.
In any case, even if you define the notify_url parameter in the button, I believe PayPal will still send the payment notification seperate from the user behavior - they spawn a new process to send the data. As to why they are using a GET rather than a POST, that is odd behavior. However, in your IPN script you should still have logic that verifies the call with PayPal before you continue processing.
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.