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.
Related
I am updating my Paypal Integration from good old NVP to the new Script.
With the old ExpressCheckout, returnURL's where handed over from my backend server through paypal for success or failure. These URL's could carry a random parameter and thus protect against someone faking the paypal responses (as I could verify that these responses carry the same parameter as given to paypal at order creation time from my server).
The current Javascript from Paypal just calls a onApprove() method and its up to me to tell this approval to my server.
As there are no returnURL's handed over anymore, there is also no way to protect the callback from being faked. Someone inspecting my (clientside javascript) code or observing the traffic from the browser can just handcraft that call and tell my server that paypal successfully authorized.
Is my reasoning wrong?
Is there any other way to prevent this scenario?
PayPal has explicitly stated that their IPN service should not be relied on during the user checkout process. I believe the idea here is that IPN should be a tracking mechanism to keep our back end data in sync with PayPal's data. What I want to do is to use express checkout but enforce an "IPN" to hit my server, and for my server to appropriately respond, before anything is finalized.
I can then ensure that I only give out content to users once they've paid, and that if a user does pay for a piece of content they do not have to refresh or wait for the IPN to come in. One of the problems with doing this using a return url and query string, is that i have a single page website on the firefox phone. The phone gets data from our API web service. So i need this endpoint to be hit regardless of the return url.
I know there are some more features with PayPal advanced developer, at a fee. I'm fine with that if that's the case, but i just want to know my options first.
As the name implies, IPN is instant. There are rare occasions where it may be slightly delayed, but that doesn't happen often, especially on the live servers.
You can build your IPN listener to do whatever you need as far as updating a database, generating custom email notifications, hitting 3rd party web services, etc. and those actions will be triggered in real-time.
You just need to get your listener created and configured in the PayPal IPN settings, or you can also pass the IPN URL in the NotifyURL parameter of your Express Checkout API calls.
If you happen to be using WordPress you may be interested in my PayPal IPN for WordPress plugin. It gets you up-and-running with IPN very quickly, and then you can hook into the plugin to trigger your own functions based on different IPN types or payment statuses.
Extra Info from Comments
As mentioned, IPN is a post-transaction thing. What you could do, though, is setup Auth and Capture on your checkout system. When the order comes through you would run it as an Authorization, and when you're ready to "finalize" you would run the capture.
You would get an IPN for both the authorization and the capture. So, one thing you could do, if it suits you, would be to run the order as an Authorization, and then within your IPN script, go ahead and run the capture. That way you could do whatever checks you want to do and only capture if they pass.
In passing cases, the capture would take place "almost" instantly when the order takes place. Cases where it doesn't pass, you could either void the Auth or let it sit there in a pending state.
Using the PayPal permissions API can you receive notifications from payments made after a customer clicks on a payment button, proceeds to PayPal, and then pays?
I notice they have IPN, but will this work with the permissions API?
Thanks!
You can include NotifyURL in your API requests to set a URL for IPN to POST data to. It's not something that technically "works with the permissions API" but any transaction that is made would indeed trigger the IPN.
If you're building an app for 3rd parties to use, though, and you're passing NotifyURL in your API requests, that will override any IPN configuration each individual merchant using your tool might have setup on their own. This can cause frustration for such users because then their own IPN solution doesn't get hit when they take payments through your app.
If you're going to do that I recommend setting up a way for your users to enter their own IPN URL in your app settings, and then if they have a value, forward the POSTed data to their URL when PayPal sends it to yours. That way both IPN scripts will get hit and process the data accordingly.
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 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.