Solved

Confirming behaviour of expiration_at_ms on the PRODUCT_CHANGE event

  • 28 October 2021
  • 1 reply
  • 151 views

Badge +1

I’m looking to confirm some of the behaviour around the expiration_at_ms field on the PRODUCT_CHANGE event.

When we receive a PRODUCT_CHANGE event (which could be an upgrade, downgrade, or crossgrade), I understand that the expiration_at_ms will be the expiration of the old product.  (The docs here make that clear: https://docs.revenuecat.com/docs/managing-subscriptions#considerations).  What I’m less certain about is how it behaves for the different stores.

Suppose we had the following situation: a monthly subscription was purchased Nov. 1, and is set to renew on Dec. 1.  If a product change was triggered on Nov. 15th, Are the following assumptions correct?

When on the Play Store:

  • Performing a downgrade: downgrades are delayed until the next renewal, so expiration_at_ms should be Dec. 1.
  • Performing an upgrade: should be immediate, so expiration_at_ms should be Nov. 15th
  • Performing a crossgrade: should be immediate, so expiration_at_ms should be Nov. 15th.=

When on the App Store:

  • Performing a downgrade: downgrades are delayed, so expiration_at_ms should be Dec. 1
  • Performing an upgrade: upgrades are immediate, so expiration_at_ms should be Nov. 15th
  • Performing a crossgrade: if the new subscription is also monthly, expiration_at_ms should be Nov. 15th, as the existing subscription should immediately be expired.

Does this sound about right?

icon

Best answer by Joel B 2 November 2021, 15:36

View original

1 reply

Badge +1

Alright, a bit more info here in case anyone else comes across this.  It turns out the Android web hooks come in immediately for a downgrade, so the expiration_at_ms ends up being basically the date/time when the PRODUCT_CHANGE web hook comes in.  So in the above example, for the first bullet point, expiration_at_ms ends up being Nov. 15th, NOT Dec. 1.

Reply