I was wondering if someone could help me figure out where this could be coming from.
Here is a successfull transaction:
Response received: HttpResponse{body='Status=OK
RedirectURL=https://www.furnitureclinic.co.uk/orderSuccessful?VendorTxCode=fclinic-170720105629-212955392
', statusCode=200, statusMessage='OK'}
And here a failed transaction:
Response received: HttpResponse{body='email sentStatus=OK
RedirectURL=https://www.handbagclinic.co.uk/Checkout?VendorTxCode=fclinic-170720105715-107422623
', statusCode=200, statusMessage='OK'}
As you can see in the failed transaction, after body=, it says email sentStatus=OK rather than just Status=OK.
This causing payments to Sage to fail.
I would just like to know, at which point in the payment process does this response get sent, and what could possibly be causing this to happen.
I have looked through the entire Notification URL file and no mention of "email sent" ever shows up.
This is the last step of a Server transaction - Sage Pay will call back to you with the Notification post, which it looks like you are getting, and you respond with the 'OK' message and a redirect URL (to send the consumer's browser off to wherever).
However, if you are sending all that through, it's as if you are telling Sage Pay to reject the transaction.
I recommend setting up a simple script on your NotificationURL, which just replies (to the notification POST) with:
Status=OK
statusMessage=Fine
RedirectURL=<wherever>
And then re-introduce the complexity of signature checking etc. afterwards...
Related
I encountered the following problem twice in the last month with PayPal IPN in live mode.
I receive an incoming IPN as usual, and all the data are correct. Then I append cmd=_notify-validate& and send the input to PayPal to verify it. The documentation says to expect VERIFIED or INVALID as response.
Instead those two times I got
<HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>
An error occurred while processing your request.<p>
Reference #…
</BODY></HTML>
with HTTP status 503. My script of course dismisses the IPN, but how should I handle this?
Normally, if the listener fails, PayPal retries to notify in an increasing interval. But I don’t receive any additional IPNs. I could save the request and verify it later on my own, but for how long does this work? I assume I have to verify it instantenously, otherwise PayPal will forget about it.
Can anybody recommend a good way of handling this?
I am having some problem regarding Paypal IPN not getting fired on one of my server. Below is the scenario.
1) I have two sites site A(old) is on server X and site B(new) on server Y.Both the sites having identical Paypal express checkout form submission and IPN code.
2) Site A is running smoothly with paypal express checkout form submission and IPN is get fired correctly.
3) But with Site B, though our form gets submitted correctly and payment is successful, IPN is not getting fired.
More information :
I checked Paypal`s business A/c for any of functionality that may needed to add IP/domain where IPN is located.
I have also checked with Paypal support where they says that from 25 March 2014 they have told to add Paypal`s API related IP address to our servers firewalls. We had done with adding those IP address but still this is not working.
URL : https://ppmts.custhelp.com/app/answers/detail/a_id/14/related/1/session/L2F2LzEvdGltZS8xNDAxMTcyODkwL3NpZC9VbENEUWhWbA%3D%3D
Hope following information is sufficient for you. Please suggest if any one of us have some solution to overcome.
Thanks in advance.
Unfortunately, there's not much issue specific information for me to work with, so lets make this an IPN Troubleshooting Guide for future reference :)
Check the IPN feature status for the given account -
https://www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-ipn-notify (login to your account first, then follow the link to be taken to the IPN Settings)
Alternative:
Login to PayPal.com
Open Profile --> My Selling Preferences
Find the "Instant payment notifications" option
There are four states IPN can be in:
Enabled --> If you're prompted to choose your settings, IPN is
enabled and IPNs will be sent if a notify URL is passed in the
checkout request.
Enabled with Default URL Set --> If a "Notification URL" is displayed and "Message delivery" is set to enabled, the default URL will be used every time you do not specify a different IPN URL in the checkout request (e.g. eBay transactions will be sent to the default URL because eBay's Express Checkout Integration does not pass a notify URL)
Disabled --> You never set the default URL, but IPN URL passed in your transactions has been throwing too many errors. You should see the empty Address field and the option "Do not receive IPN messages (Disabled)" being checked.
Disabled with Default URL Set --> a default IPN URL was configured at some point in time, but due to failures on the default URL or on the dynamic URLs, the IPN feature has been disabled. You will see the URL and "Message Delivery = Disabled"
Why does PayPal disable IPN delivery?
PayPal expects your server to respond with a HTTP-200 OK message. If we receive a different response code, a retry mechanism is set in motion.
The IPN message is sent a total of 16 times with increasing time frames between each attempt. If the errors for one URL reach a certain threshold, IPN is disabled automatically. You will receive an e-mail message to the main e-mail address listed on the PayPal Account, that warns you of an impending deactivation
If IPN is enabled, check the status of the last IPN messages under https://www.paypal.com/cgi-bin/webscr?cmd=%5fdisplay%2dipns%2dhistory&nav=0%2e3%2e4
It'll show you the last HTTP Response Codes your server is sending back and you can filter for failed / retrying messages.
Check http://en.wikipedia.org/wiki/List_of_HTTP_status_codes to see what the status means.
If there is not HTTP Response code, there's a connection issue on a lower level.
Most frequently caused by:
Firewalls
SSL Connectivity Problems (try using HTTP)
Black Hole Routing
If you feel that everything is configured correctly, check out https://ppmts.custhelp.com/app/answers/detail/a_id/733
If the IPN messages are marked as "SENT" (HTTP 200 Received), the next step in IPN processing is posting the data back to PayPal for validation. You can either enable logging within the script (dump the HTTP request and response in a file on the server) - or you can contact PayPal MTS ( https://www.paypal.com/mts ) and ask what's visible on the PayPal Side.
A good test to check the connectivity to paypal is to run the following command on the webserver itself:
curl -d "cmd=_notify-validate" -v https://www.paypal.com/cgi-bin/webscr
If you see that the POST has reached PayPal, but PayPal responds with INVALID for all messages:
Check your code, https://github.com/paypal/ipn-code-samples is a good source of samples
If PayPal responds with INVALID to some messages, you're likely running into an encoding issue. You'd best set your Character Encoding settings under https://www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-language-encoding - set them to UTF8 for the best results.
If PayPal Responds with VERIFIED, but your script doesn't continue processing after validating the payment, make sure you run a TRIM() (or the equivalents in the language being used) to remove whitespace, line feeds and CRLF
What happens afterwards is up to the IPN script you may run into errors while connecting to a database, parsing the IPN message for certain data or some coding errors.
In short: If the IPN message has been received, posted back and verified, everything else happens in your own code on your server and you'd have to start digging through log files (or make sure logs are being created, that's always a good idea) to find out what's going on. If the problem is reproducible, it is always a good idea to check what happens with one of the sample scripts (which include logging)
Hope this helps tackling IPN issues head on - any questions regarding IPN? Contact paypal.com/mts if you want to investigate what's happening on the paypal side.
I'm going to implement the IPN protocol in my website, using php.
Paypal documentation note that the protocol goes as follows:
The user clicks the button.
Paypal posts my IPN listener an IPN message.
My listener has to send an empty HTTP 200 OK response.
My listener has to send the message gotten from paypal (with a preceding string) back to paypal.
Paypal sends my listener a "VERIFIED" or "INVALID" response.
Can anyone explain why the protocol demands this [3] step?
Why can't it be fulfilled just with the [4]th step?
Also, I noticed that in another chapter of paypal documantation, they skip this [3]rd step themselves (see their implementation). So I wonder, is it really necessary??
The 200 OK response will happen automatically as long as your IPN script completes successfully. This let's the PayPal server that it did indeed complete.
If PayPal's IPN server gets something other than 200 OK back from your web server it will assume your script failed and will place that IPN in a que to be re-sent. It will resend after 30 seconds, then 60 seconds, then 120 seconds, etc. until it gets that 200 OK.
This is why sometimes people end up with duplicate IPN's. If you've got something at the very bottom of your script, for example, that's failing, but all of your email notifications, database updates, etc. actually did work prior to that point, you'd end up seeing those things happen again and again because PayPal kept re-sending the IPN. This can be very messy, of course, so you want to make sure that's not happening.
Again, though, the response code gets sent back to PayPal from your web server automatically. It's not something you actually have to do within your code.
We are using opencart-1.5.6 and installed authorize.net(AIM) and PayPal as the payment gateway.But while we checkout using authorize.net, the card is processed and cash is deducted from credit card successfully, but the page is not redirecting to the confirmation page.Mail is sent successfully to admin and also purchase status is also set as completed.But the page still stuck in showing a please wait message.
System is working in the sandbox mode and issue happens when its live.
I would greatly appreciate if you can help.
As SankarV is recommending, exploring the response for the confirm AJAX request is the best bet - there might be no direct error in console, but since AJAX response contains invalid JSON due to possible PHP errors being printed out, the redirect to a success page could not be performed. So again, explore the AJAX response for the confirm request and come back with anything suspicious within it.
And though some entry_company might not take place in the checkout, since it is echoed somewhere while not instantiated, the PHP Notice is raised thus making the JSON response invalid...
I just moved my server to a new host, and obviously changed the DNS for my paypal ipn page.
For some reason paypal keeps hitting my page about every 30 seconds with the same transactions over and over again.
So of course its verified then stored in the database as duplicate records.
Has anyone had this problem? Or know how to fix?
Make sure that your browser is returning 200 OK status to paypal.
Either way, you should store IPN tracking IDs (ipn_track_id) in your database and check for duplicates. This is the only guaranteed way to solve your problem.
According to PayPal's IPN documntation:
Your listener must respond to each message, whether or not you intend
to do anything with it. If you do not respond, PayPal assumes that the
message was not received and resends the message. PayPal continues to
resend the message periodically until your listener sends the
correct message back, although the interval between resent
messages increases each time. The message can be resent for up to four
days.
This resend algorithm can lead to situations in which PayPal
resends the IPN message while you are sending back the original
message. In this case, you should send your response again, to cover
the possibility that PayPal did not actually receive your response the
first time. You should also ensure that you do not process the
transaction associated with the message twice.
IMPORTANT: PayPal
expects to receive a response to an IPN message within 30 seconds.
Your listener should not perform time-consuming operations, such as
creating a process, before responding to the IPN message.
So a) is your script properly responding and b) is the notify_url parameter from your transaction different with your DNS change?