Skip to main content
Solved

Confirming behaviour of expiration_at_ms on the PRODUCT_CHANGE event

  • 28 October 2021
  • 1 reply
  • 245 views

Forum|alt.badge.img+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?

Best answer by Joel B

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.

View original
Did this post help you find an answer to your question?

1 reply

Forum|alt.badge.img+1
  • Author
  • Helper
  • 2 replies
  • Answer
  • November 2, 2021

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.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings