Skip to main content

Hello,

 

I have a question regarding expired subscriptions: When a user resubscribes, a RENEWAL event is send.

In our system, we want to track subscriptions individually, meaning every new subscription would be reflected in a new subscription object on our side. Currently we try to use the original_transaction_id as some kind of external id of a subscription.

As far as I can tell, RevenueCat doesn’t really have a concept of “individual” subscriptions, RevenueCat really only cares about the current subscription status of a user and (I guess) there will always be only one single INITIAL_PURCHASE event, right? Meaning if a user buys a subscription, then cancels and then resubscribes two years later, it would still be a “renewal”.

Are there any best practices for handling each subscription individually?

 

Thanks so far!

 

 

Hey @AlexRegier!

If a user re-subscribes to a product in the same subscription group (even after it expired), it’s considered a renewal because that’s how Apple treats the subscription in their receipts. If a user were to subscribe to a different product in a different subscription group, the original_transaction_id would be different and it would be considered a new subscription. To clarify - it’s not that RevenueCat doesn’t have a sense of individual subscriptions, it’s that Apple always links these types of purchases back to the initial purchase.

You can keep also track of different subscriptions/events with the differentiation between original_transaction_id and transaction_id in our webhooks: https://docs.revenuecat.com/docs/webhooks#subscription-lifecycle-events-fields

transaction_id String Transaction identifier from Apple/Amazon/Google/Stripe.  
original_transaction_id String transaction_id of the original transaction in the subscription from Apple/Amazon/Google/Stripe.

Understood!

You mentioned iTunes, but is this the case for google play as well?

 

The transaction_id will obviously change for every renewal transaction. And just looking at the original_transaction_id would not help in my case, because that ID will be same if a user resubscribes at a later point.

So I guess I would need a workaround by looking at the expiration date BEFORE a renewal to determine if it’s a new subscription or not :disappointed_relieved:. That makes things more complicated :/ 

 

 

Hey @AlexRegier!

Regarding Google Play, (unlike Apple) if a subscription has already expired and a new subscription is purchased, then a new subscription token should be generated, and would be identified with a new transaction ID.

Hey @cody 

Okay, that’s good to know! Thanks so far!

It would be really cool to have some kind of unified behavior across the stores through the RevenueCat API/Webhooks tough! Is there something planned in that regards?

Reply


Terms & ConditionsCookie settings