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.
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
We are using SpiceLogic's BuyNowButton control with dedicated IPN_Notified event handler. Our payment processing logic requires buyer's redirection back to shopper site and we are interested to do it from IPN_Notified event handler after all verification there pass. We have noticed that Server.Transfer doesn't work there (gets suppressed) if you try to run it from inside event handler. Response.Redirect works as expected but raises non-braking exception "Thread was being aborted". Our question is: "Is there any known bad in redirecting buyer from IPN_Notified that way? Will it work in real PayPal environment as it works in our dev environment now?"
IPN happens completely separate from the checkout experience. A redirect will not work there because it's an entirely separate server session / communication. It's not anything happening in the browser.
It sounds like you must be working with PayPal Standard, so if you want the user to be returned to a specific page on your site after checking out with PayPal you can look into setting up Auto-Return in the PayPal account. Even with that enabled, though, there is no guarantee the user will make it back to your site because they could simply close the browser before it redirects.
If you want to guarantee the user always gets back to your site you should move to using the Express Checkout APIs instead of PayPal Standard. It will require more coding skill and working with web services, but it will give you much more freedom to do exactly what you want to do with your user experience.
In the SpiceLogic PayPal Control, the IPN_Notified event is completely a service type event, which is triggered by the PayPal IPN Notification service. The consumer of this event is a backend service from PayPal, not your customer. Your customer will never be redirected anywhere whatever you perform in your IPN_Notified event.
When PayPal IPN service calls your IPN URL, the IPN_Notified event is fired from your SpiceLogic PayPal control. But, PayPal does not care about that. PayPal simply calls that IPN Url and Post transaction data and then returns. So, if you issue a Response. Redirect, it will do nothing to PayPal IPN service. Response. Redirect is an instruction for the Browser, but PayPal IPN service is not a browser which will redirect.
If you want your user to redirect or convey a message, you need to use the PayPal_Returned event from the SpiceLogic PayPal Control.
In order to understand better the IPN and event workflow, please check these images.
I'm currently trying to implement a mechanism whereby i can return a customer to a success page containing an activated PIN allowing access to a piece of software. The process is a straight forward PIN purchase without any kind of user accounts or login system involved.
I have the payment buttons and IPN script in place and working fine, but this only allows me to email the PIN after a successful payment via the IPN script, since of course the two sessions are completely separate to maintain security.
My problem with this is that i can't be sure the customer has access to the same email they used to pay with via Paypal. I had the idea of asking the user to enter which email they would like the PIN sent to prior to the Paypal redirection and then sending it as a custom value.. but then came visions of a mammoth backlog of support emails where users have entered the wrong email. I would really like to be able to redirect to a success page containing the PIN.
Thanks in advance.
I would recommend using the Express Checkout API. The payer experience is very similar to standard payment buttons, however, the user is always guaranteed to return back to your site, so you can display whatever you want on your final page.
That documentation can be a little scary, but it's really just a matter of utilizing 3 API calls.
SetExpressCheckout - This is used to setup a new transaction and will return a token that you'll append to the end of a redirect URL to PayPal. The user is sent to PayPal, they login and agree to pay, and are then sent back the ReturnURL that you specify in this request.
GetExpressCheckoutDetails - Now back on your site/application, you use this API to obtain information about the buyer like their shipping address, address status, payer status, payer ID, etc. You will need the Payer ID for the final API call.
DoExpressCheckoutPayment - This is very similar to the SetExpressCheckout request, but no transaction is completed until this call is completed. Only then does the money move.
Again, those final calls are done on your site so you can use the API response data to update your database and display details on the final page however you want to.
Keep in mind that payments could still be pending for one reason or another, so you'll want to check the status (returned in the DECP response) and display appropriate information on the final page.
IPN's will still be triggered with Express Checkout so you can adjust the IPN script to handle pending payments or anything else you may want to automate outside the checkout flow.
If you happen to be working with PHP my class library for PayPal will make these calls very quick and easy for you.
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.
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.