Subscriptions with Paypal IPN - paypal

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.

Related

Order of IPN returns when setting up subscriptions

Gidday
I'm setting up several subscribe buttons on my site, each without a free trial period, so the initial two IPNs, subscr_signup and subscr_payment are sent about the same time. I'm using the custom field in the IPN to hold the user's membership ID from my site (subscription is separate from signing up for an account).
I've read that Paypal doesn't always send those two IPNs them in that order.
Initially I was going to use the subscr_signup IPN to populate the member's subscription details, but I'm wondering, am I better off using the subscr_payment IPN to do that ie check if a sub has been set up, and if not set one up, otherwise just check the subscr_payment details against the database?
The payment IPN doesn't have the recurring field, but I don't need it, as all subscriptions are recurring on my site, and I can determine the type of subscription from the amount paid.
Or, would it be better if I set it up as a 1 day free trial, so the IPNs definitely come separately?
Thanks for your time and help.
Either way should work. Another option that some merchants have done, is written all of the information to their database and set up the account before sending the buyer over to PayPal to sign up and make the payment. Then the merchants would rely on the IPN to actually activate the IPN or activate it beyond it's free trial period. You could also set up a script to check your system periodically to see if there are any profiles that are deactivated and should be removed from your system, or that never paid.

Paypal IPN expiration

As I receive an IPN from PayPal, I would not like to process it immediately, but, instead, queue the message and then process it with a scheduler.
Therefore, there's a point that worries me - if I queue a message and only process it (including the '_notify-validate' verification), let's say, 12 hours later, will I be able to do it?
Thanks in advance.
You can't schedule a delay with PayPal for when we send out the IPN post and if you don't reply back to PayPal within a few seconds we'll reattempt to send the post later.
It is possible to not reply to, like, the first six IPN posts for a payment but doing that will eventually start to trigger an e-mail telling you that the posts are not being replied to right away. It may possibly lead to IPN being disabled on your account.

Paypal subscription next payment date

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.

Missing IPN Notification

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.

Testing Paypal subscription IPN

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