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.
Related
I've just uploaded the PayPal APIs to test my scripts, and so far, they seem to be working properly (all in sandbox mode). Payments are processed, and the transaction details are returned, but for some reason, the transactions are not being recorded on the PayPal dashboard.
I tried the IPN simulator, using the sample script from GitHub, but keep getting this error:
IPN was not sent, and the handshake was not verified.
The script works; at the very least, it writes a log file when called from any browser. But not when called from PayPal's IPN simulator.
Could really use some pointers in the right direction. TIA.
If you are HERE, then yes you "should" see them, however that dashboard is not very reliable. This is why I asked for clarity on 'what' dashboard you're looking at and posted the URL of sandbox.paypal.com.
If you're able to ping your IPN listener but PayPal is uanble to, try defining and enabling the IPN URL in the sandbox account and see what happens. From there you'll notice an IPN history link where you can see the status of the IPN call from that transction. If it failed, it will give you the error and you can troubleshoot from there.
Hope this helps
I have Integrated Paypal using php. I know there is return url ,that means when payment is received it will return to the url for our website.My Question is if payment is received and due to internet problem it does not return to our web page, how do I know that payment is received from a particular user?
If there is a network issue and PayPal cannot issue the IPN message, then according to their documentation, they will retry 15 times up to 4 days.
The IPN message service does not assume that your listener will receive all IPN messages. Because the Internet is not 100% reliable, IPNs can get lost or be delayed. To address these issues, the IPN message service includes a retry mechanism that re-sends a message at various intervals until your listener acknowledges receipt. An IPN message may be present up to four days after the original was sent. The maximum number of retries is 15.
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/
This item below might help. Instant Payment Notification should work, but in the case of a network failure, if the payment reached PayPal but the purchaser did not get back to your site to complete a purchase, then you should still receive an email from PayPal telling you that you have received a payment.
using paypal button - can my webpage tell if paypal transaction was successful or not?
You get a confirmation email with their name and email address - be aware that occasionally this may not be the user's current, most active email address. You can also log in to your PayPal dashboard to see all details as well, of course.
You can look up your payment details from the email and compare them to your own user records in your database. If the email they use for PayPal is not the same as the one they registered on your site with, you can still look up their name from the email - in practice it seems to happen extremely rarely that payments have such a problem in my personal experience
I set up a script which emails my users with a passcode to get to the online product they bought which is emailed to them so they can submit that later along with their email address. This is the first thing that happens on return to my script so at least if the site fails to respond properly they can get to what they bought later.
The script uses PHPMailer and cc's me with their passcode so I have it available to re-send to them if they write with a complaint. It doesn't help if the PayPal return for Instant Payment Notification fails completely but the other answers cover that very fully and detail the PayPal repeat attempt process well.
Instant Payment Notification scripts can be downloaded from PayPal for modification by yourself as per the article linked to above.
To be perfectly honest, this is one of PayPal Standard's largest holes. IPN is a POST callback (as is PDT) and they check to make sure they get a 200 response or else they retry (and you can use the IPN history in your PayPal account to resend missing IPNs). But this method still relies on you getting the callback in a timely manner and it's not foolproof. Worse, you need to verify the IPN call and that introduces yet another point of failure in calling PayPal to make sure they did indeed send you the IPN you got.
There's a couple of ways to deal with this
Audit your account regularly. This is a good idea in general, but for a small website this shouldn't be terribly hard. Match your invoices up to your PayPal payments. Obviously this doesn't scale well so...
Switch to Payments Pro. There's more hurdles to this (like more PCI compliance, SSL certificate, etc) but the major advantage is that the API is far less susceptible to the whims of the Internet and only involves one call for credit cards (you can ignore the IPN because the API tells you everything you need to know). The worst that can happen is you send a payment API call and fail to get a response. This is exceptionally rare as PayPal makes sure their API is 99.9% reliable (IPN relies on your server being reliable). Speaking from experience, Payments Pro has far fewer issues than IPN does.
In your application, you should have a status field for orders. If you haven't received the ipn, you wouldn't change the status to Paid.
After that, if you receive an email from Paypal that someone has paid, check the order number, and change the status manually.
how do I know that payment is received from a particular user?
Paypal will send an email both user and you.
Paypal offers 2 solutions for your problem.
PayPal IPN - it notifies the server with a POST request to a specific URL, whena transaction has been successful, declined, aborted by user and so on. Paypal provide an IPN Simulator (the worst simulator ever) in order to test its functionality. you may give it a try at : https://developer.paypal.com/developer/ipnSimulator/
Paypal WebHooks - The webhooks are the "New Kid in the Block",they are basically "user-defined HTTP callbacks that receive events for the subscribed event types. Webhooks are asynchronous, the order is not guaranteed, and idempotency may lead to the same event being sent more than once." as stated in the Paypal documentation.
You can read more about it on : https://developer.paypal.com/docs/integration/direct/rest-webhooks-overview/
For any further help, comment below and I shall try to help.
Cheers,
You have to use notify_url for this purpose
<input type="hidden" name="notify_url" value="https://domain-name.com/ipn.php">
I am kind of a newbie when it comes to online CC processing integration. I am in the Sandbox at Authorize.NET trying to configure my server to process SIM orders where the payment page form resides on the Authorize.net servers and processes the order. By default it looks like the confirmation is on their sites, and e-mails can be configured to be sent to the buyer and the seller. That is all working in the Sandbox. However, I am trying to capture some of the order and processing information on my server using the relay response. My processing page is accessible on my server, although I must say that I have .htaccess limited intermittently because it is still in development. I turn that off when I am testing.
The error that I am getting is:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
I can't tell if they are POSTING data to my page or not, and I'm not really clear on what goes on the response page and how to parse the response. I am using the PHP SDK provided by Authorize.NET. The rest seems to be working. I am getting e-mails for the buyer and the seller and the order is proccessed but I'm not capturing the information on our server. What I would like to do is bypass their confirmation page, receive the relay response, create a custom confirmation and capture some of the data for our database. I'll keep digging because I made a fair amount of progress just reading the docs. This one is particularly useful.
Thanks.
I figured it out. There was an error on the page giving a "500" error. I have to say, it is a little strange the way they have it set up. They are POSTING to my page, where I am capturing the POST data, writing stuff to a database, and then creating a custom confirmation message, although it must be via a header redirect because it shows up on their server (their domain is in the address bar). It all works, but apparently, any SESSION variable values are not available to my script in that case?
All of the following is in the PayPal sandbox:
I have a PayPal subscription/recurring payment setup which uses a IPN listener as the last step to create or update a user's subscription in my website DB. However, when I received the POST data from paypal and send it back for verification, the only response I receive is "INVALID".
I know that my code sends the POST data back to PayPal correctly, because I get a "VERIFIED" response when I mimic a correct POST to my listener by hardcoding the POST data string with the "IPN Message" value as seen on the PayPal's IPN History page.
So my code that sends the POST data back to PayPal for final verification works, and my IPN listener is receiving the POST variables for the transaction. There is just a difference the POST-data string my IPN listener creates to send back to PayPal and the POST-data string that PayPal expects to receive.
PayPal states that the IPN listener must send back the POST data it receives with the same values, order, and encoding that PayPal sent it in.
I think the problem is an encoding issue because in the PayPal POST to my listener, "charset" has the value "windows-1252" which should be "UTF-8". However, "form_charset" has the correct value of "UTF-8".
I have set the encoding to UTF-8 on both input fields on my seller PayPal profile, and have a hidden input in the initial PayPal form/button with the name "charset" and value "UTF-8". Please tell me if there is another way to set the encoding that I have missed.
Part of the POST data string that PayPal claims to be sending includes "¬ify_version=3.8" followed by more variables. When I manually insert this string to test my code, the "¬" gets converted to "¬" when printed to the page which to my understanding means that the character encoding being used is "windows-1252" because "¬" is in the windows-1252 character set, but "¬" is not in the UTF-8 character set, so if UTF-8 was being used, the "¬" would not be converted like this.
How can I get PayPal to actually POST data to my IPN listener with UTF-8 character encoding? Keep in mind that this is a recurring payment so some aspects may be different.
I don't think the issue is on my end, as I have tried different methods, different ways of encoding/decoding the posted data, external libraries, cUrl/sockets, SSL on with different versions, different headers, restarting the server, recreating the purchase, etc.
So Paypal is sending me the wrong POST data or I am forming the post string incorrectly. The latter is possible, but I have tried every method I could find for forming the post string and none worked.
I have been working on this problem for days to no avail, so any help or pointers would be very appreciated.
PS:
a few notes which may or may not be relevant:
This subscription system was created a few months ago and only stopped working inexplicably at some point in the last few weeks. No relevant code was changed around that time AFAIK.
The first day I started debugging this issue, the seller account for the sandbox had completely incorrect data, it was listed as a personal account when it should have been a business account, which meant none of the IPN settings were available. The next day the same account inexplicably worked and showed up as a business account as it should have in the the first place. I'm not aware of any action on my part causing this change. Maybe PayPal sending the wrong character encoding is a similar issue? Some caching system on a cron job? I'm just speculating at this point, I really have no clue.
Relating to my last point, logging into the seller sandbox account has been very unreliable. Sometimes I attempt to log back in after a session timeout and receive an error code which would only make sense in the context of registering a new account. Other times logging in just doesn't work, the result being that a fraction of the times I try logging in after a session timeout, I have to clear my cookies for logging back in to work.
Here's a tldr;
Based on Miles's Experience, it seems there was a bug in PayPal Sandbox that meant the charset settings had no effect.
I've found that this bug has been solved.
To change the charset in your PayPal settings
Log in to your merchant account
Click Profile
Under Selling Preferences click Language Encoding
Press the "More Options" button
Select your site's encoding and leave the use same settings button on yes
Save your settings.
The solution ended up being to use both a IPN Listener and PDT, just make sure both scripts check to verify that the transaction hasn't already been received, so that transactions aren't received more than once.
So just keep track of paypal transactions in a database and check that database in the IPN listener and PDT script.
so I got a guy to code this IPN feature for my website.
Basically a user pays thought the main site then it forwards the ipn stuff to another server and that server sends ipn payment to paypal. For some reason it keeps saying "retrying" under the paypal IPN history. Is paypal blocking this and does the payment have to be made from the same server? Thanks hopefully this makes sense!
IPN does not happen until after any transaction has occurred, so what you're saying here doesn't really make sense. There's no way IPN would be sending any payment to PayPal. PayPal simply POSTs transaction data to your IPN URL after the transaction has taken place.
That said, if you're seeing "retrying" in your IPN History that means your IPN script is not completing successfully, and as such, is not returning a 200 result code back to PayPal's server. You need to troubleshoot your IPN script to figure out what's failing and get it fixed.
Your web server logs should provide the information you need. If you look there you should see a log of when your IPN URL was hit and it should also provide the result including any errors that were generated from the request to that script.
I like to create a simple HTML form with the action set to my IPN URL and then include hidden fields that match the fields/values that I would expect to get from IPN. This way you can load that in a browser and submit it directly so that you can see the result on screen which can help with troubleshooting and debugging.
Keep in mind that when testing that way, though, the data is not coming from PayPal's servers, so it will not verify. You'll need to make sure your script is setup to handle this accordingly for testing purposes.