Testing

If you are using enhanced subscription recovery, you can use the subscription-recovery test API to manually force subscriptions into different states (active, in-grace period, on-hold, passively canceled, and recovered). This helps expedite the testing of your enhanced subscription recovery integration.

Prerequisites

Making subscription-recovery test API calls requires a beta app, test user account, and transaction validation method (push notifications or API calls). Complete the following steps so that you can generate new subscriptions, and receive and verify state changes:

1. Create a beta version of your app.
2. Create a test user and link it to your beta app.
3. (Recommended) Integrate Roku Pay push notifications in your backend system. This enables you to receive and verify subscription state changes in near real-time. Otherwise, you can verify changes by pulling transaction data via Roku Pay validate-transaction API calls.
4. Enable Enhanced Subscription Recovery in the Developer Dashboard for your beta app.

Once you have successfully tested Enhanced Subscription Recovery with the beta version of your app, you can publish the updated production version of your app and then enable Enhanced Subscription Recovery for it.

You must publish the updated version of your production app before enabling Enhanced Subscription Recovery for it. If you do not do this, customers will be unable to purchase a subscription for your app until the on-hold period has elapsed.

Testing subscription recovery

To move subscriptions into different states and verify your subscription recovery integration, follow these steps:

1. Purchase a new subscription to your beta app with the test user account. You cannot run subscription recovery testing on existing subscriptions.

   Do not use free trial products for testing subscription recovery. This is because canceling a free trial moves the subscription directly into the on-hold state where it can no longer be moved into a different state.

2. Record the transaction ID generated by the purchase of the new subscription. You will need to pass this in the subsequent subscription-recovery test API calls.

3. Make subscription-recovery test API calls in chronological order of the subscription lifecycle (failing to follow the listed order may trigger unexpected notifications and block the subscriptions):

   a. active

   b. in-grace

   c. on-hold

   d. passively canceled

   e. recovered (from in-grace or on-hold states)

4. Use Roku Pay push notifications or Roku Pay validate-transaction API calls to verify that your back-end system is receiving and processing subscription state changes.

5. Void transactions before starting another subscription test with the same user and product. Do not reuse already-tested subscriptions; testing must be done on new signups.

Limit calls to less than 10 requests per minute (RPM). Developers exceeding this limit may lose access to the test APIs.

Subscription recovery test API methods

The subscription-recovery test API includes a set of POST methods for changing the state of subscriptions. Changes in the subscription state may take 10–30 minutes.