Skip to main content

Can I be confident that the transaction ID sent to the webhook will always be the same for the lifetime of a subscription, or do I need to use the original_transaction_id value?

Since I’ll be creating a record in my DB for each new subscription, I want to make sure that I’m not creating duplicate records if a new transaction ID is created for existing subscriptions For example when it renews, or if the same Android user logs in as another user in my app. In the second case, I’d like to be able to reassociate that subscription to the current user.

I’m migrating to RevenueCat from an existing system that integrated directly with Apple/Google stores. Both Apple and Google require you to keep a reference to the original (or previous) transaction/token since these will change over the lifetime of the subscription. I’m hoping that RevenueCat takes care of that headache so I can just use a single ID for the lifetime of a subscription.

Hey @Jeremy,

I’d recommend relying on the original_transaction_id value. Depending on the store, the transaction id will act differently. For Apple, they will generate an entirely new transaction id for each subsequent renewal. For Google, they generate a new transaction id that increments from the original. Stripe is the only store that won’t generate a unique transaction ID for each renewal.

For the lifetime of the subscription, you can rely on the original_transaction_id - this would only change in the case of a product change. 

Reply


Terms & ConditionsCookie settings