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.
Related
We have created a small app to help users manage certain PayPal orders, but the IPN doesn't seem to work as expected. I found this at the note at the bottom of the following URL:
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNSetup/
"Even though you have not enabled receiving IPN messages in your Profile or
you have reset your preference by turning off IPN messages, PayPal still
sends IPN messages to the notification URL you specify for a specific
payment."
Based on this we instructed our beta testers not to worry about enabling IPN in their account, since we specify the notification URL for the user's transaction via the notify_url field in the button code. But then no IPN is sent.
Next we instructed our beta testers to enable IPN, and since doing so requires you to enter a notification URL and users don't want transaction data for EVERY transaction posted to our system, and we don't want that either, we instructed them to enter a "fake" URL and disable sending messages to that URL in their account. Based on the note at the link above we figured this should work too, but it doesn't. No IPN is sent, although you can now see the message in the IPN history.
So I'm a little stumped here. The way I see it, we only have 2 options, and neither seems ideal ...
Instruct our users to enable IPN and hard-code our IPN notification URL into their profile settings. This means if they're already using IPN for something else they can't do this, and even if they can it means that data for EVERY transaction they do will hit our system and neither the user nor we want that.
Instruct our users to enter a "bogus" notification URL in their account, and leave messages to that URL enabled, since we'll override this with our own notify_url setting. This would work, however it will cause PayPal to attempt to send messages to an invalid notification URL for any transactions NOT processed through our system. I assume PayPal doesn't want this, and it could possibly lead to the user losing IPN access in the future due to constant IPN errors, etc.
Anyone have any ideas for me? Thanks!
In experience, as you're finding, you do need IPN enabled in order for the IPNs to be sent, but then if you specify notify_url it will override the URL in the profile.
Instead of setting up a bogus URL, though, you could put any actual script there. Just make it a script that does absolutely nothing. That way IPNs that get sent here will "do nothing" other than send a 200 OK back to PayPal's server showing that the IPN was received successfully.
If they're already using their own IPN solution and the data needs to go through both then you'll have to setup an IPN forwarder. You can daisy-chain IPN URLs to that a bunch of them get hit with the same data if you need to.
Personally, I like to have some sort of a catch-all IPN setup in my profile that saves any IPNs it gets to my database for logging purposes. Then, again, the notify URL can be used to override this if necessary.
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.
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.
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.