Checkout some common subscriptions testing scenarios to help you thoroughly test your subscription integration before taking it live. You should also make use of our general testing doc, particularly its list of test credit card numbers.
Testing trial periods
A common need is to test how your integration handles trial periods without waiting a full trial period to see the results. The solution is rather simple: create a new subscription with a
trial_end value only a few minutes in the future.
Using this approach, you won’t see a
customer.subscription.trial_will_end event notification (which occurs three days before a trial ends), but in all other ways the logic is the same as a subscription with a longer trial period.
Testing webhook notifications
Proper use of subscriptions relies heavily on using webhooks. You can test webhooks by triggering fake event notifications via the Dashboard. However, when you do so, the received event contains only fake data that doesn’t correlate to real or test subscription information.
Using fake event notifications may suffice but the most reliable way to test webhook notifications is to create actual test subscriptions and handle the corresponding events.
Testing payment failures
We’ve identified specific test credit card numbers to trigger payment failures, and these are usable on subscriptions as well. (As subscriptions are fundamentally just scheduled payments.)
One catch to be aware of is that if a subscription requires an immediate payment and that payment fails, the subscription is not created. In order to test how a payment failure affects an active subscription, attach the 4000 0000 0000 0341 credit card to a customer as the payment source but use a trial period, if only of a few minutes. Depending upon your subscription settings, you still have to wait a day to see the first retry attempt. If desired, you can use that day to update the customer’s payment source to a working test card to see what happens with a successful retry.