I have a web site thats been operating for months, if not years. It takes payments via PayPal. IPNs are used to track the payment status against an order.
If the paypal account owner issues a refund, the IPN from that is tracked, and the order updated with the amount refunded.
Now: The problem: This was all working in February 2015. But since then I have made 4 refunds (buy logging into the PayPal website and refunding). Each one was days apart. In each case they were partial refunds.
In all cases the monies have reached the recipient, and logged transactions IDs etc in PayPal.
The first one, I never received the IPN.
The second one I did received the IPN (and decided the first one must have been a glitch, unusal though it would seem)
However the third and fourth also have not generated an IPN that I received.
From looking at the Apache logs, there appears to not have been even an attempt from notify.paypal.com that Apache received.
So I am much puzzled, have googled around but not found anything. Can anyone suggest what I have missed that have caused these IPNs to stop?
Perhaps I should add that I continue to receive all the payment notification IPNs just fine. It seems to be just the refunds that I miss.
I thought at one time there was a flag about IPNs in settings, but I can't see it anywhere in the new web interface.
Regards
Monathan
Related
I'm currently using PayPal's adaptive payment system to process purchases on my e-commerce platform.
This has been working successfully for the past 5 years. Last week, there was a situation where my platform's system did not record IPN responses from PayPal. This was an intermittent issue. Lets say, 5 transactions were made in a day - 3 were recorded and 2 weren't. Note that there was no code change done in recent times. I also tried resending IPN messages from PayPal's IPN history page, but to no success.
On contacting PayPal, I was asked to check my IPN listener, which again had no issues. I'm quite puzzled as to what might be causing these issues.
In the last 24 hours, all the transactions stopped receiving IPN messages. On checking PayPal's IPN history page to retry sending IPN messages, I could not find any of the messages for the transactions that happened today. I am unable to process confirmation numbers for my customers without the IPN message from PayPal.
Any insights to this issue would be greatly appreciated.
This may not be the silver bullet answer you're looking for but I'm in a similar position as you. We've only been intermittently receiving IPN messages from Adaptive Payments for the past few days. Other IPN messages seem unaffected. Last night we received a number of IPN messages from transactions as far back as 5 days ago and as of today everything appears to be normal. I have no idea what was wrong and so I'm not ready to call it "fixed", but I'm hopeful.
The only action I've taken (besides spending the past two days manually confirming payments), was opening a ticket at paypal-support.com. I can't say for certain if that had any effect as they have yet to tell me if they've taken any action, only asked for more details.
As a side note, I can't find any service status pages for Adaptive Payments. Presumably this is because it's a limited release product, however it's slightly frustrating as we do depend on it until PayPal offers a better alternative for chained payments to multiple endpoints.
I'm using paypal adaptive payments to make transaction via paypal. Although few of transactions are taking more than 6 hours too receive IPN.
I've gone through forum posts and their documentation, I came through - https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/
"Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
The callback is taking more than 6 hours is way too much. any suggestions ?
I've built several custom carts. On average, I see the PayPal IPN come back within 2 minutes at the longest, and usually recurring payments take longer than single payments because they send two IPN messages, not just one, on the initial setup. I usually take the 'custom' property and put a unique identifier that I have permanently cookied. So, even though I may see an initial IPN come in on a recurring payment, I wait for the one that says that txn_type is subscr_payment and also that payment_status is Completed. You can't really trust a subscription payment as being paid unless you see that second message. And if it's a single payment, then I look for txn_type to be web_accept and payment_status to Completed.
The way I handle things is to redirect the customer to PayPal to purchase using the form button technique. The customer pays and then gets redirected (thanks to the form hidden vars I created initially) back to my own custom cart URL that I specify. I call that URL the payment-confirmation script. I display a message with a progress bar to please wait while their payment is being confirmed with PayPal. I hold them there 10 seconds and then redirect to the receipt. It is on the receipt where I check the database to see if my IPN script has already processed this order. If not, then I redirect them back to the payment-confirmation script again for another 10 second progress bar delay. My receipt uses a session cookie to ensure I never send them into a loop more than one time to the payment-confirmation script. So, the customer waits another 10 seconds and then comes back to the receipt page, where I test again, reading my permanent cookie on the 'custom' property that I saved, versus the 'custom' property that comes in from the IPN that I use as the order key in the database. Usually within the first or second 10 second delay, the IPN has come in and I can proceed. However, if the IPN has still not come in, then I redirect to a friendly error message saying that their payment cannot be confirmed and to call our call center to remedy the issue. Our call center techs then see the delay problem in PayPal, back the other transaction out, and sell to the customer over the phone manually, instead.
We have been running IPN payments for around 15 months now, and for all that time we have around 10% missed IPN notification (there is no record of PayPal attempting to contact our website to notify it of the IPN, Paypal IPN history gets always http200.
Now we are hitting around 5 missed notification per 30 orders/day. We have tried to set up manually url listener in account settings and after that we are getting hundreds notifications from ebay sales) and also passing url method was used - nothing helped. Any idea how to diagnose the problem?
Thanks in advance
Although it is possible some situations don't trigger IPN, IPN actually covers a lot of things. I'd recommend getting in contact with paypal merchant technical services (or with paypal customer support, and they will transfer you to technical) as soon as possible, and ask them to see if there's anything wrong on either side. You would need to prepare the related transaction is within 28 days whose IPN is missing, because IPN only remains in the history for 28 days.
I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).
Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).
However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.
Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.
Does that mean that a user must have/create a PayPal account to pay?
Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?
Could anyone who's gone through this kindly shed some light?
The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.
With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.
Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.
One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.
Edit
One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.
PayPal's PDT system sends order confirmations to merchant sites that use PayPal Payments Standard and lets them authenticate this information. Such sites can then display this data locally in an "order confirmation" page.
When to Use PDT?
IPN provides the same capabilities described above. So, when should you choose PDT instead of IPN?
With PDT, your site is notified immediately when a customer completes payment. With IPN, however, there is a material lag between the time a customer completes payment and the time your site receives notification of this event.
So, use PDT if your site includes a feature that requires immediate payment notification.
For example, consider a digital music store. With PDT, this store can let customers download their purchases right away since PDT sends order confirmations immediately. With IPN, such immediate order fulfillment is not possible.
Advantages of IPN
PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Another advantage of IPN is that it sends many types of notifications, while PDT sends just order confirmations. So, using IPN, your site can receive, for example, chargeback notifications as well as order confirmations.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will receive two order confirmations for each sale. As a result, you must be careful to take action (say, ship a product) on just one copy of a given confirmation message.
Documentation Here
Re 1. PDT is meant to use with Auto Return for Website Payments feature. Auto Return redirects to PDT site after paying money to seller. Unfortunately it's not possible to use that feature along with PayPal Account Optional - used to enable Credit Card payment. Here is note from PayPal: 'If you have turned on Auto Return and have chosen to turn on PayPal Account Optional for new users, a new user will not be automatically directed back to your website, but will be given the option to return.'. User will have an option to go back to your site(PDT step) or stay on PayPal site. To sum it up when paying by Credit Card user can skip PDT step if user will not click 'return to store link'.
Re 2. It is up to you what paying options do you want to allow. If you want to allow paying without a PayPal Account you can enable Account Optional. If you want to allow only users with PayPal accounts disable that feature. There might be more options.
Re 3. In your case you need to trigger action after successful purchase. Recommended way would be to implement IPN. PDT doesn't work for all cases and doesn't guarantee message delivery. Here is link to doc covering that topic PDT vs IPN.
This is an old question, but my simple answer would be - Why not use both PDT and IPN? They will work fine for card transactions.
PDT can provide the immediate transaction status to your website, where you can quickly check the payment success or failure status and provide the user with appropriate message.
Meanwhile, you can await the full verification from IPN in the background. Once received, you can use this to further update your DB and process the order.
You can follow this step-by-step guide which I found to be very clear and helpful - and it's still valid in 2018.
https://www.codexworld.com/paypal-standard-payment-gateway-integration-php/
I'd like to test paypal subscription IPNs, both the ones received when a subscription is created, and the ones sent later with the next payment (such as monthly if the subscription is $x per month).
However I'd prefer not to wait a month or a day to receive the second IPN. Is there a way to have an IPN sent quicker, such as hourly, using paypal or their sandbox?
On the documentation it says you can only specify years, months, days, and weeks as the subscription period.
PayPal's developer support and documentation is an embarrassment to them. But this particular limitation isn't as debilitating as it seems at first blush.
For testing, define your recurring payment to not have a free trial. When you create a new subscription, your server will receive two IPN messages in quick succession, one to create the subscription and the second to apply a payment. That's basically all you need to test.
If you have a free trial, you'll get basically the same pair of messages, just with a trial period between them. :)
The first message ("create subscription") will look something like this. Note the 'txn_type' -- that's the key bit of information for disambiguating the two messages:
{
"txn_type"=>"subscr_signup",
"subscr_id"=>"unique_id",
"verify_sign"=>"random_gibberish",
"item_number"=>"your_subscription_name"
"subscr_date"=>"14:32:23 Feb 15, 2010 PST",
"btn_id"=>"1111111",
"item_name"=>"Your Subscription Description",
"recurring"=>"1",
"period1"=>"1 M",
# This example is from a "free trial" IPN notification-- if you don't have a
# free trial defined, there will only be 'period1' fields, and they'll
# have the data that appears here in the 'period3' fields.
"amount1"=>"0.00",
"mc_amount1"=>"0.00",
"period3"=>"1 M",
"amount3"=>"34.95",
"mc_amount3"=>"34.95",
"mc_currency"=>"USD",
"payer_status"=>"verified",
"payer_id"=>"payer_unique_id",
"first_name"=>"Test",
"last_name"=>"User",
"payer_email"=>"test_xxxx#example.com",
"residence_country"=>"US",
"business"=>"seller_xxxxxxx#example.com",
"receiver_email"=>"seller_xxxxxxx#example.com",
"reattempt"=>"1",
"charset"=>"windows-1252","notify_version"=>"2.9","test_ipn"=>"1",
}
The second message is the more interesting one in this case. It will essentially be the exact same message you'll get later when the recurring payment is applied. It looks something like this:
{
"txn_type"=>"subscr_payment",
"subscr_id"=>"unique_id",
"verify_sign"=>"random_gibberish",
"txn_id"=>"payment_unique_id",
"payment_status"=>"Completed",
"payment_date"=>"12:45:33 Feb 16, 2010 PST",
"item_number"=>"your_subscription_name"
"subscr_date"=>"14:32:23 Feb 15, 2010 PST",
"custom"=>"data-you-sent-in-a-custom-field",
"id"=>"1",
"payment_gross"=>"34.95",
"mc_currency"=>"USD",
"payment_type"=>"instant",
"payment_fee"=>"1.31",
"payer_status"=>"verified",
"mc_fee"=>"1.31",
"mc_gross"=>"34.95",
"btn_id"=>"1111111",
"payer_id"=>"payer_unique_id",
"first_name"=>"Test",
"last_name"=>"User",
"payer_email"=>"test_xxxx#example.com",
"residence_country"=>"US",
"receiver_id"=>"your_merchant_id",
"business"=>"seller_xxxxxxx#example.com",
"receiver_email"=>"seller_xxxxxxx#example.com",
"protection_eligibility"=>"Ineligible",
"transaction_subject"=>"",
"charset"=>"windows-1252","notify_version"=>"2.9","test_ipn"=>"1",
}
So you can do almost all of your testing without waiting a day. By the time you think you've got it nailed down, you'll be receiving lots of subscription IPN messages the next day.
In addition, here is a link to PayPal's documentation for further reference.
It's possible to resend test IPNs, so you should only need to 'buy' one subscription for testing.
Once you've bought one subscription, here's what to do:
Log into your PayPal sandbox seller account.
Select 'Profile' => 'My Selling Preferences'.
Select 'Instant Payment Notification Preferences' from the third column.
Confirm that IPN is enabled and that the URL is correct.
Click the link to the IPN History page.
Scroll down, tick one or more IPNs and click 'Resend'.
After you confirm, the selected IPN(s) will now be resent to the URL you have specified. You can repeat an unlimited number of times with the same IPN(s).
The excellent answer by #dondo covers the rest.
It used to be that the period specified in days would be treated by the test server as minutes so you'd be called every 3 minutes when specified 'd3'. I think they removed this and I'm not aware of any replacement feature to test subscriptions.
Hey I just wanted to throw a shout out to Neil because that is exactly what I was looking for and I don't have enough reputation to reply or upvote..
Believe it or not paypal still doesn't make it easy to do subscription testing with ipn files :/
So, just because I didn't see it on here and the OP kind of sounded like they were under the impression to only expect two possible responses from papal --
if anyone else is having issues, here are some other txn_type that hit my ipn while doing testing:
//when paypal subscription profile is created for the subscriber
subscr_signup
//payment made for a given billing cycle
subscr_payment
//when subscription fails
subscr_failed
//user cancels subscription - not
subscr_cancel
//end of term - paypal is "done" with that subscriber
subscr_eot
//why I was looking for this thread to begin with lol
recurring_payment_suspended_due_to_max_failed_payment
that last one hit my ipn this morning against every last one of my test subscribers. when I was looking up what that meant, I found that the following are also possible to get:
recurring_payment_profile_created
recurring_payment_profile_cancel
recurring_payment_profile_modify
recurring_payment
recurring_payment_skipped
recurring_payment_failed
I don't know what I did to get that because subscriptions and recurring payments are technically different in PayPal's eyes (subscriptions can possibly never terminate but recurring payments have a cap on the total payments someone can make for any "subscription") but their documentation isn't always straight forward, either, so I dunno. That I'm still working on figuring out as this was a subscription button generated by a sandbox merchant account but whatever.
Happy headaches :)
UPDATE:
I figured out my problem just now - so just so it sounds like I know what I'm doing I'll explain...
I think paypal's subscription sandbox environment is slowly dying. I noticed the other day when I'm messing around in sandbox.paypal.com that I get "Fatal Failure" a lot of times. Refreshing the page seems to correct this most times, although sometimes i have to refresh a few times for the screen to come back.
I am getting the same response from them hitting my IPN file, which explains why every subscription I had got suspended today. Thanks to Neil I was able to resend the IPN response and I captured it into a text file (lol) and then I hit the ipn file reading in the response and throw it back at paypal (its really more complicated than that I'm just making it sound easy).
In any case by refreshing the page I can initiate the paypal handshake more or less on demand and when I do, it's 50/50 - sometimes I get VERIFIED, and sometimes I get Fatal Failure - just like when I try to do much of anything in their sandbox site (Fatal Failure).
Below is an example of part of a failed response I get from them... I get a 200 so I believe hitting their server isn't the issue with connectivity, but I am starting to see a pattern with "Fatal Failure" here and this points to more their end than mine
HTTP/1.1 200 OK
Date: Tue, 29 Sep 2015 02:41:00 GMT
Server: Apache
Fatal Failure
you can also manually create IPN from their sandbox:
https://developer.paypal.com/cgi-bin/devscr?cmd=_ipn-link-session