I wrote a script for paypal IPN because I want to update the database after the payment. I'm not even talking about the script content, because it seems that the script is not called at all !
I decided to simplify and to only write one thing in the script: send me an email.
When I pay the subscription on paypal sandbox, I'm redirected to the return URL I inserted in my button, but it seems that the notify url is not called, as I don't receive the mail I'm supposed to receive...
Any idea why ?
At first I thought it was I was on a local server. But now I'm on a live serveur, and it's the same thing.
May I have your help ?
Thank you
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.
I have a site that offers services to paid members.
When a member subscribes, he goes to Paypal, pays the subscription and then Paypal calls my ipn script which takes care of updating the database and sending a message to the member.
Everything is working fine, but some time ago, I started receiving some messages from Paypal:
"Please check your server that handles PayPal Instant Payment Notifications (IPN).
IPNs sent to the following URL(s) are failing:
http://domain.com/ipnhandler.php
If you do not recognize this URL, you may be using a service provider that is
using IPN on your behalf. Please contact your service provider with the above
information. If this problem continues, IPNs may be disabled for your account."
I found it strange, because at the same time, people went on subscribing, and the database was updated everytime. So I found strange to receive a message from Paypal saying that the URL was failing... How could it be failing, while the script was working fine?!
Then, one day, the database stopped from being updated. It started in early december, and since then, people pay their subscription but nothing happens. I had a look at the ipn history in my Paypal account, and I can see that Paypal called the script once (only once) for each payment, but the script returned nothing (http response is empptty). And on my side, I had a look at my log file, and there's nothing in it.
In my ipn script, the first thing I do is logging the call in the log file. But it's desperatingly empty since december...
Is there anyone who could help me with this issue? It's very upsetting because I have to register eveything manually... And everything was working fine, so I don't understand why it's not wirking anymre as I didn't change anything in the script neither in Paypal setup.
Please, I really need your help!!!
Thanks
The IPN script will need to load completely in order to return a 200 OK response from your server back to PayPal. What tends to happen is you could have an error happening near the end of the script after everything else has run, so while it seems like the script completed because you see emails/database updates, etc, it actually did not complete successfully.
Any time I have something going wrong with my IPN stuff I follow the steps in this guide on testing PayPal IPN and I'm able to track down the problem. I would recommend you follow those steps to find your problem.
I have developed one regular paypal form along with IPN script(in PHP).
When I make the payment using sandbox, everything works fine and flawlessly !
But when the form goes live, it doesn't even call the IPN.
Please note that the live payment is made through paypal.co.uk.. and Form submits data to paypal.com.
So, I think this is happening due to paypal.co.uk.
Is it so ?
Is there any solution for this ?
No. Your IPN script is likely still configured to verify the IPN data at https://www.sandbox.paypal.com/ instead of https://www.paypal.com/, which will cause it to fail, which in turn will cause the script not to get executed.
You can review individual IPN messages to were sent for your account in History > IPN History on your PayPal account overview as well.
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.