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.
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.
I have a question about Paypal IPN, I was wondering when does the IPN activate and send it's message to my website.
I currently have my website that has a buy button. When the client buy the service, he is directed to paypal. Once he pay the service, nothing happen. In order for me to receive the IPN notification, the user has to click "Return to merchant website" or whatever the link is, then I receive the IPN notification.
Is it normal, does it work like that for everyone?
Cause right now, most people when they are done with the payment, just close the website and I don't receive any notification.
Thanks for any help !
Your question leaves a lot of missing information so I will go through each option for you:
Read here about how to setup a sandbox account if you don't already have one: https://developer.paypal.com/docs/classic/lifecycle/sb_create-accounts/
Bare in mind that your sandbox account is entirely separate in every way from your live paypal account. All settings will need to be checked and customised as needed.
Set up your IPN URL on your sandbox account Here: https://www.sandbox.paypal.com/uk/cgi-bin/webscr?cmd=_profile-ipn-notify
Once set up, you then need to download and set your code (PHP or something else) to the listener (referenced in the above sandbox profile link). You can find IPN code examples here: https://github.com/paypal/ipn-code-samples
When that's all set you need to set your listener to using the sandbox mode and then log in to your live account and then run the IPN simulator from here: https://developer.paypal.com/developer/ipnSimulator/
Paypal will send messages to your IPN listener and you need to do something with the messages, typically output them into some sort of log file. Any issues, you can read Paypals feedback and IPN data/delivery information here https://www.sandbox.paypal.com/uk/cgi-bin/webscr?cmd=_display-ipns-history&nav=0.3.4 [Found from History->ipnHistory on the Paypal menu] and it should list them out. You can resend any failed or queued or undelivered messages.
Paypal is a terribly documented and terribly structured system for coding with. I hate it. Use Stripe.
I love bullet points.
Paypal claims they will try and resend failed/queued IPNs 16 times over 5 days. I have yet to see this, you need to resend them manually (at least, sandbox ones)
Please remember all the settings and changes you have made to your Sandbox account will need to be also made to your live account before you make your payment system live!
Solution
My return_URL is the location of my IPN.php file which take care of the data sent and received. My problem is that the IPN is only firing when I click the "Return to merchant website" and not when the payment is actually completed
What you have done, from reading your comments, is set your IPN page to being your return from paypal page, this is NOT the way IPN is supposed to work, the IPN page should never be visited by the customer, only ever by Paypal.
Read through my anwser (points 2,3,4) and set up your IPN web link as I have described above, your return_url value should be a basic page to say to the customer "transaction complete". The IPN page is defined on your paypal accounts (sandbox and live) as I stated above.
This will fix your problem.
We're running WPMUdev's Memberships plugin, which requires that the default IPN lister URL be set in one's PayPal profile (because even though the subscribe buttons include notify_url, without a default IPN listener set, apparently there's no way to get recurring payment cancellation messages) — and that all works just fine.
Trouble is, PayPal can't tell the difference between buttons generated by this plugin and manually generated buttons (eg one-off donation), and tries to send IPN messages to the plugin's listener, which gets completely confused because the expected metadata isn't sent with it. PayPal then retries the IPN until its limit is reached.
Is there some way to use notify_url (or some other HTML variable) to disable IPN messages for a specific button? Or will I have to write a null IPN listener that simply acknowledges IPN messages and drops them on the floor?
What #EdSF said is what I would recommend.
Setup an IPN listener that does nothing but return a 200 OK back to PayPal. It doesn't have to actually do anything.
Then set that URL as the value of notify_url in the button that you want to "disable".
This will way you won't end up with loops of IPNs from PayPal trying to hit a bogus URL that doesn't exist.
In the scenario I've described, it's evident that providing a null notify_url doesn't work (the default IPN listener URL is still used) therefore (unless a more experienced PayPal developer can indicate otherwise), and as #Andrew Angell said, it will be necessary to provide an IPN listener that simply acknowledges the IPN message (and maybe logs it, if desired).
Note that, as described in PayPal's documentation, it is not sufficient simply to reply with an HTTP 200 response; PayPal will continue to retry IPNs until the limit is exceeded or the configured listener responds with the appropriate positive acknowledgement described in that link.
There are any number of IPN listener templates available on the web, so that is one option, however here's another that has only just occurred to me:
There are one or two IPN multiplexor scripts floating around, for example, this one, though I haven't yet tried it so can't speak to its quality or suitability. But I'd guess that using a pre-existing multiplexor script would be the sensible thing to do because a) it deals with the problem I presented in my OP, and b) it provides a ready-made mechanism for dealing with other applications that make use of IPN, should the need arise.
I am building an IPN extension for a website, but the service provider for the cart used at the moment has the option Notify_URL set (in the paypal submission form) for its own internal handling (which is somewhat flawed). If an IPN URL is set on the PayPal sellers profile, will both be used, or only one?
There appears to be some confusion on this subject. Some are claiming that both will work. They claim it should notify both in this situation. Though it appears that with subscription based payments, PayPal will only use the IPN URL set in your PayPal profile.
However, on the official PayPal documentation:
You can specify an IPN listener for a specific payment; this is the
only way to receive IPNs associated with Adaptive Payments. In this
case, PayPal sends the IPN message to the listener specified in the
notification URL for a specific button or API operation instead of the
listener specified in your Profile.
Which seems to suggest that the notify_url will override the profile settings. I would assume that it would be better to follow the PayPal documentation then something that may be working even though it isn't intended to.
Source: PayPal Documentation
It's also worth noting that if you disable IPNs in your PayPal account, neither will work.
I think the documentation may have changed since this was last answered. I was also curious what was given precedence: notify_url or your profile's IPN url. From the docs:
Optionally, you can override the URL to specify another listener for specific payments.
Here the wording is slightly confusing, but it seems that even if you have IPN turned off in your profile, if you pass a notify_url value in with the payment, it will still be sent. Bold added by me:
The IPN message will always be sent to your notification URL unless receiving IPN messages has been disabled. 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.
I have seen this work first hand, which is why I investigated it more to make sure it was working correctly. My IPN History told me "your IPN notifications are turned off," prompting me with a link to turn it on. However, below that was a history. The reason was because I was passing in my desired notify_url with the transaction.
So #johnmadrak's statement, "It's also worth noting that if you disable IPNs in your PayPal account, neither will work," is actually not true. Even if you've turned the setting off in your profile, passing in a notify_url still works.
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.