Testing Paypal subscription IPN

Question

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.

Answer 1

you can also manually create IPN from their sandbox:

https://developer.paypal.com/cgi-bin/devscr?cmd=_ipn-link-session

Answer 2

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:

1. Log into your PayPal sandbox seller account.
2. Select 'Profile' => 'My Selling Preferences'.
3. Select 'Instant Payment Notification Preferences' from the third column.
4. Confirm that IPN is enabled and that the URL is correct.
5. Click the link to the IPN History page.
6. 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.

Answer 3

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.

Answer 4

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"=>"[e-mail]",
  "residence_country"=>"US",

  "business"=>"[e-mail]",
  "receiver_email"=>"[e-mail]",

  "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"=>"[e-mail]",
  "residence_country"=>"US",

  "receiver_id"=>"your_merchant_id",
  "business"=>"[e-mail]",
  "receiver_email"=>"[e-mail]",

  "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.

Answer 5

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