I've been running a 'Buy Now' button on my website for several months now, and a couple weeks back I observed a purchase that had went through where no IPN was sent to my website from PayPal. Later purchases that day succeeded.
Observations
PayPal had sent me an email notification that the purchase was successful, it also recorded this transaction in my account's payment log. This is normal.
The IPN History had no record of any IPN entries for that transaction; there is no record of PayPal attempting to contact my website to notify it of the IPN. This is not normal.
I have not modified the 'Buy Now' whatsoever in the past six months, and there is only one 'Buy Now' button connected to PayPal. Furthermore, this was the only payment that day that had failed to show up in the IPN History.
I've read (I forget the article) that this isn't all that uncommon (happens a few times a year for popular sellers). I don't know, however, what the solution is. I contacted PayPal support a week ago, and they have not gotten back to me.
I find that if the purchaser uses Credit Card option to pay, and they go through the payment page, the very last page has another button. Some purchasers don't click that very last button. The result is that the payment happens, but the IPN to your notify_url does not trigger.
This problem does not happen if the purchaser uses their paypal account to purchase.
I am looking for a solution to this.
Sometimes IPN can be delayed for various reasons, but it will usually post at some point.
I know just last week (or maybe the week before) the IPN servers were down so there were literally millions of IPN's that were qued up in the system and took a long time for them to get all caught up.
Usually, though, IPN works great and is pretty much real-time.
Related
1 month ago I setup 3 payment buttons in my sandbox account, every button with a different IPN page.
Everything worked ok then. Now when I wanted to test again, I didn't received any ipn message. The page is not called.
Going in my paypal account on Instant Payment Notification (IPN) history page I see that all messages are queued, but not sent.
Is this a bug from paypal? did they changed something in the last month and I need to modyfy?
This could be due to the upgrade of certificates. This began happening in June/July, it caused a few errors for myself as well.
https://devblog.paypal.com/paypal-ssl-certificate-changes/
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
How can I get the next payment date from the IPN notification from Paypal. Is there a parameter there relevant? I found "next_payment_date" but it's not clear.
Right now, I'm just calculating it myself.
Calculating it yourself is good, because PayPal some times skips sending an IPN. It doesn't happen often, I've done tens of thousands of transactions and I've only seen this less than 5 times.
PayPal should send a subscr_eot when the subscription stops.
If you're on the standard payment, you'll never see next_payment_date
https://www.x.com/developers/paypal/forums/ipn/pdt/nextpaymentdate-will-not-show
Also, if you accept echeques (payments via bank account), the payment won't always happen on that date, some times a week or more afterwards.
I am thinking about using PayPal to take subscription payments for a website but have a question relating to the process of cancelling and failed payments.
Initial process:
Click subscribe/buy now button
Log into PayPal or enter card details
Review, click confirm
Completion page (with PDT)
3 months and 2 days later and the user logs into PayPal to cancel their subscription (within PayPal instead of using my website).
How is that process or information passed back to my website for cancelled or failed subscription?
I haven't found anything in FAQ, Help or How to and Louise was useless. I hope that someone here can help me...
Manually, I assume we're expected to log in review History and update the website accordingly (every couple of days).
Many thanks,
Simon
You would set up an IPN listener in your PayPal Profile. Once a subscription or recurring payments is charged, skipped, suspended or cancelled, you'll receive an appropriate IPN message at your IPN listener URL.
For IPN sample code and documentation, take a look at https://www.paypal.com/ipn, and for the individual IPN variables, take a look at https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_IPNandPDTVariables
I am adding subscriptions to a site using Paypal IPN which works very well, I can successfully create a new subscription and verify it. The subscription has a two week free trial. The guide was unfortunately a little vague on subscription statuses.
At the moment, the users account gets subscribed status once subscr_signup or subscr_payment is received and gets removed when either subscr_cancel or subscr_failed is received. I believe this is correct but it's best to make sure.
Also what is subscr_eot? the IPN guide describes it as "subscription’s end-of-term." Does this get triggered after the trial period is over?
subscr_eot is sent when a user's last paid interval has expired. subscr_cancel is sent as soon as the use cancels the subscription - for example:
User signs up on day 1 for a subscription which is billed once a month.
subscr_signup is sent immediately, subscr_payment is sent as soon as payment goes through (usually immediately as well).
On day 13, the user cancels. subscr_cancel is immediately sent, although the user has technically paid through to day 30. Cancelling at this point is up to you.
On day 30, subscr_eot is sent - the user has cancelled, and this is the day which his last payment paid until.
Not much changes with trial subscriptions - if a user cancels before a trial subscription is up, subscr_cancel is sent immediately, and subscr_eot is sent at the end of the trial.
Also, one interesting detail is how subscr_eot works with subscr_failed.
It looks like subscr_eot comes after the FINAL subscr_failed. So if in your account you set it to automatically retry failed payments 3 times, then it should go like this:
first failed payment => subscr_failed
second failed payment => subscr_failed
third failed payment => subscr_failed and subscr_eot
so basically in your code you can set subscr_failed to trigger an email like
hi user,
please take moment to check
your payment info, you may need to
update the credit card expiration
date, etc. You still have access,
we'll try again in a few days.
And setup subscr_eot to actually turn their subscription off and trigger an email like
Sorry, we still havent' gotten payment
and have taken your profile down. You
can still reactivate it by logging in and updating your payment info
Basically this is the "nice" way of doing it so customers have a grace period, and their account isn't shut off unexpectedly just because of an expired credit card or something like that.
The thread posted by Chris has been updated recently.
Sometime in 2010, PayPal stopped using subscr_eot when a user cancelled their account. After a number of complaints, they reinstated this, but took 6 months to do so. All this means is that you can once again handle your subscription notifications as described by Peter in the accepted answer.
From a PayPal representative:
subscr_cancel means the profile is
canceled and there will not be future
payments. However, if the buyer has
already paid for the current billing
cycle as they are charged up-front,
then you can use the subscr_eot to
terminate the profile.
Still unsure what happens in the event of multiple failed payment attempts, however. PayPal documentation at the moment is terrible.
It depends on the account if it is new or not whether subscr_eot gets sent, which is kinda beyond me?
I haven't found the proper way to manage subscriptions yet. Calculating the dates on the server could go wrong very fast if there is a delay in payment.