[SOLVED] Testing DEFERRED Proration Mode

Google Play Billing provides various Proration Modes via the BillingFlowParams.ProrationMode API to help developers implement an upgrade and downgrade experience.

One of the most frustrating Proration Modes to work with is DEFERRED. Here’s how Google defines this mode:

Replacement takes effect when the old plan expires, and the new price will be charged at the same time.

Typically, app developers use DEFERRED for the downgrade use case.

Practically speaking, this mode will wait before making the product the user is downgrading take effect until after the current (the future old plan) plan expires.

For example, if your current plan has a monthly bill term, the new plan will take effect when the current plan is set to renew within the next up to 31 days.

Similarly, if the current plan is an annual bill term, it may be quite a while until the DEFERRED plan takes effect. If the user downgrades, the same day they bought an annual plan, the new plan won’t take effect for 365 days!

Testing the DEFERRED Proration Mode can be a bit tricky. Let’s dig into this a bit further.

Testing DEFERRED Proration Mode

Here’s what you need to know to successful test and have confidence in your DEFERRED implementation:

Testing via a Device Development Build has limits

Development builds will trigger the downgrade flow, and you will get the confirmation email from Google.

However, the deferred product will not replace the current plan at the end of the current plan’s bill term. In fact, it will be “stuck” in limbo where the current plan will be active, despite not renewing and an expiration time in the past, and the new plan will not be active.

You can get out of this state by cancelling the current plan manually via Play Store > Payment & subscriptions > Subscriptions. Doing so will throw an error in the Play Store app, but the cancel will expire the current plan and the deferral.

Conduct End-to-End Testing via a Test Track build

Fortunately, a signed build distributed via a Test Track, including Internal, will allow you to conduct end-to-end testing of DEFERRED plan changes.

If you have any problems testing this scenario via a Test Track build, be sure you are setup for successful IAP & subscription testing:

  1. Only active products can be bought - Make sure the in-app purchase or subscription product is active in Play Console.
  2. Add Google accounts to the Test Track - Add approved testers to the internal, alpha, or beta test tracks. Testers added to the list, must also join the test via the link surfaced in the test section in your Play Console.
  3. Add Google accounts to Setup > License Testing - This allows testers to make purchases using test credit cards to avoid actual charges.
  4. Check the Google Play Account on Device - the Play app allows you to sign in to multiple accounts. Make sure the one added in step 3 and 4 above is the active account signed in before attempting the test purchase.

Practical Considerations

Testing the DEFERRED Proration Mode is tricky and so can be providing customer support to users who have triggered this duration mode (likely via a downgrade).

Here are some real world considerations you need to know about Google Play DEFERRED plan changes:

  1. Play Billing doesn’t surface DEFERRED transactions - You will not have a Purchase Token or Order number until the plan takes effect.
  2. End Users don’t have visibility into DEFERRED transactions via the Play Store app - End users will only know about the plan change via the Google Play plan change sheet at the time of the change and the confirmation email from Google Play. The plan change is not surfaced in the Play Store > Payments & subscriptions > Subscriptions.
  3. Trying to upgrade back to the original plan, while a DEFERRED is pending will result in an error - The Play Store sheet will raise an error that says: “We are unable to change your subscription plan.”
  4. Trying to initiate a DEFERRED sku change to the plan that is already DEFERRED will result in an error - The Play Store sheet will raise an error that says: “We are unable to change your subscription plan.”
  5. Play Billing can get confused - If you see the Play Store sheet with DF-DFERH-01, you’re in a funky state. You can try again, cancel your subscription and try again, or delete your test app build and try again.

Google Play Billing Made Easy

Make your life easier by simplifying your Play Billing implementation with Nami.
Here’s what we have to offer:

  • A proven Play Billing implementation covering all tricky edge cases -- including upgrade/downgrade logic plus DEFERRED Proration Mode handling
  • An easy to adopt SDK, no server-side code is required
  • Built-in native paywall templates, A/B testing, and analytics
  • Our generous free tier provides reasonable limits and lots of features not found in homegrown implementations.

Now you can focus on building a great app experience, not hassling with Play Billing infrastructure. Get started for free here.