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.
Related
I'm developing a merchant website and I'm working with Paypal right now.
I found that using IPN and the auto return do the job I want.
I'm using NGROK to expose my localhost and everything works fine. However, when I take a look at NGROK terminal I see that PayPal is actually sending datas to my auto-return page first and THEN after something like 3 seconds sending the rest to my IPN file.
I did think that the right data processing was IPN then SUCCESS... Am I wrong? Is that because I'm using NGROK or localhost? Or maybe PayPal Sandbox?
It sounds like you're mixing up PDT and IPN.
PDT = Payment Data Transfer. This is meant for use with Auto-Return, and the payment data gets sent back to your return URL so you can display it on screen. Database updates, email notifications, etc. should NOT be taking place here because there is no guarantee the user will make it back to the return URL even with Auto-Return enabled.
IPN = Instant Payment Notification. This is meant for post-transaction processing and is where you should handle db updates, email notifications, and anything else you need to make sure happens every time a transaction occurs. IPN also allows you to process things like e-check updates, refunds, customer disputes, etc. where no browser interaction was taking place at the time.
You can use both together, but the PDT URL and IPN URL should be different from each other. The PDT URL would be your return / thank you page, and again you would only display data here for the user's reference. The IPN URL would be a separate script that acts as a listener only.
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 have a SAAS web application that works through a subscription fee. If the subscription is valid everything works fine, otherwise the app goes in read-only mode until the customer renew the subscription. I've developed the payment flow with the PayPal API.
The problem is that PayPal Documentation says this:
"Although PayPal usually processes IPN messages immediately, IPN is not synchronized with actions on your website. Internet connectivity is not always 100% reliable and IPN messages can be lost or delayed. The IPN service automatically resends messages until the listener acknowledges them. The service resends messages for up to 4 days.
Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
Unfortunately this is exactly my case: when customers renew the subscription I need to immediately activate the app so I placed all the logic right in the "notify callback" where I have to create the order, send a confirmation email, update some session variables... but I if there's a delay from PayPal IPN this is a problem!
In these days I did some test in Sandbox mode and in several cases I got an answer from IPN even 4 hours after the successful payment! This is unacceptable for my app!
Finally the question: what's the best solution for my case? It makes sense to move the application activation from "notify callback" to "success callback"? There may be problems?
Thanks
Don't use IPN for this; it's a poor fit & not designed to be inserted into synchronous user experience flows. It works fine as a way to initiate offline fulfillment, but can delay your customers if they are actively waiting for access.
You don't specify which PayPal product you are using, but each product should provide a way to immediately give you feedback that the payment has been completed. For example with Express Checkout or any API-based payment you can take action (activate/re-activate a subscription) when you receive the successful API response (the DoEC API in the case of Express Checkout).
With web-only/non-API products you can take action when the customer redirects to your return_url, using PDT to securely get information about the transaction if you need that (it can include an IPN-style key that you post back to PayPal to verify, exactly as you do with an IPN).
If you are concerned about the edge cases of someone closing their browser before it can redirect to you, or some other sort of dropped connection or programming error, you can also check & activate/fulfill upon receipt of an IPN to catch any fallout. So all customers that complete a normal payment flow are activated immediately; if they do something wonky (or your code breaks, or whatever) then the activation still happens, albeit potentially delayed by a few seconds or minutes.
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.
I have finished designing a program, and am ready to create a commerce system. Ideally, I would like to use Paypal to handle all the transactions for me, how ever I want this to be done on my own website, and have the information securely sent over to Paypal. I understand how to do this entire process, how ever I do not understand where I would add code to have my server generate a serial code and store it alongside customer information in a database.
The Paypal API isn't very helpful, so I am wondering if there is a variable passed back to the merchant website by PayPal, via a POST or similar, that can be checked to verify that a payment was accepted, and then react depending upon that status.
I understand that I can have it send the user back to the merchant website, but I would like it to generate a page along the lines of...
Thank you for your purchase (NAME)! A copy of your serial for (LICENSE_COUNT) licenses has been sent to your e-mail at (EMAIL).
And then have a script run to automatically generate the serial, send it to the user, and save it in a database.
Any language is acceptable.
Are you working with Payments Standard or Express Checkout?
If you're using Payments Standard you would need to use PDT + Auto-Return to get data back to your page for display. That said, I wouldn't rely on it to deliver the necessary details to your user because they're not always guaranteed to make it back there even with Auto-Return enabled.
Instant Payment Notification (IPN) is recommend for this sort of thing. It will POST transaction data to a listener script you have on your server. This happens separate from the checkout system itself. You can automate tasks like updating your database, hitting 3rd party web services, sending email notifications, etc. from within this script. It also allows you to handle e-checks correctly (only delivery the e-goods when the payment clears.)
If you're using Express Checkout you can handle this within the checkout flow rather than using IPN if you want to because the user is always guaranteed to make it back to your site. That said, if you're accepting e-checks you'd still want to use IPN instead. If you've disabled e-checks then this would work just fine.