My understanding of the Paypal IPN mechanism is that my website should send over a message that includes:
a URL to go to if the USER completes the Paypal payment process
a URL to go to if the user hits CANCEL instead
a URL to go to once the payment has been checked for validity (after the user completes it).
But this doesn't makes sense.
I have an asp.net site.
I give the user a payment page. He enters how many widgets he wants to pay for.
Then it routes him to PayPal.
Lets say he completes all the steps to pay me.
So now he is sent to my website again, at the URL in #1, which tells him that the payment should be verified within 5 minutes.
But then, a few milliseconds later, according to my (probably wrong) understanding, he should be sent to the URL in #3. This URL is a blank page, since all it does is execute code that stores the successful invoice in a database.
When I actually try it, he is sent to URL #1, but there is no indication that he is sent to URL #3. No invoice is stored, no blank page appears either.
I am using the sandbox, not the real site. Also, all my pages are protected by a password, but that doesn't block URL #1 (since the user is logged in), so my guess is it should not block URL #3.
Any help is appreciated.
My understanding of the Paypal IPN mechanism is that my website should send over a message that includes:
a URL to go to if the USER completes the Paypal payment process
Correct.
a URL to go to if the user hits CANCEL instead
Correct.
a URL to go to once the payment has been checked for validity (after the user completes it).
Incorrect. That's a URL for PayPal to POST to, independently of the current browser session, when the payment is completed. That is your IPN handler.
But this doesn't makes sense.
Agreed. It isn't correct either.
When I actually try it, he is sent to URL #1, but there is no indication that he is sent to URL #3. No invoice is stored, no blank page appears either.
He isn't. PayPal tries to POST an IPN to that URL. You're supposed to have something listening there to process the transaction. There are further requirements of that IPN handler such as validation, duplicate handling, etc, which you need to familiarize yourself with.
Related
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 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.
I have implemented PayPal payments using PDT. I realize a combination of PDT and IPN is recommended, however for my purposes PDT is sufficient.
I am able to direct user to PayPal, collect payment and then conduct an action (updating account credits for the user in the database) when the user returns to my site. The URL shows an address like:
http://www.domain.com/process_pdt?tx=45138128VH922173V&st=Completed&amt=1.99&cc=USD&cm=&item_number=
So far so good. The problem I have is refreshing the browser with this URL causes the user's account to get credited again without redirecting the user to PayPal to collect payment a second time.
I have read that I should add the transaction id (tx in URL above) to the user table and check to ensure this tx id has not already been used. If it has, I should display an error message. Is this the only way to go about this, i.e. by storing each tx id in the user table and then checking for the id's existence each time the process_pdt URL above is called by the user (legitimately or fraudulently)?
Ah, yes: this is indeed the only way to go. As a simple sanity check you may want to do a redirect from the process page to a URL that does not include the txn_id (that way a casual refresh won't cause the problem, but if they use their back button it will still happen) but you must verify that the txn_id is only used once yourself.
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.