Solved

Subscription Renewal with Block Restores

  • 11 January 2022
  • 1 reply
  • 123 views
S
Badge +1

Hey,

We are looking into the available ‘Restore Behavior’ configurations from RevenueCat, and I believe based on our business requirements we need to use the ‘Block Purchases’ option. Our app requires an account to make a subscription purchase, and requires the user to be logged into that account to use any subscription entitled features.

 

One concern we have is how the ‘Block Purchases’ configuration behaves when a subscription renewal occurs. The ‘Restore Transactions’ behaviour makes sense, as this would require the customer to log into the account that initially made the subscription purchase. But what happens if the logged in user at the time of renewal is different than the logged in user who initiated the subscription?

 

We are currently still configured to ‘Alias (legacy)’, but from our initial testing it seems like a subscription renewal is applied to the currently logged in RevenueCat user. In the customer history for this account, they do not have a ‘started subscription’ event, just a ‘Renewed their subscription of _ for _’ event. Does this behaviour hold true when 'Restore Behavior' is configured as 'Block Purchases'?

 

Example scenario (all occurs on one device, one App Store account):

  1. User is logged into Account A and purchases a 1-month recurring subscription.
  2. Prior to the subscription renewal, the User logs out of Account A and logs into Account B
  3. The 1-month subscription renews.
    1. In RevenueCat, this updates the entitlements for Account A to no longer have an active entitlement (expired), and adds the entitlement Account B.
 
Will 'Block Purchases' also require that subscription renewals occur on the same RevenueCat account? Or is that functionality limited to the 'Restore Transactions' function logic?
 
If 'Block Purchases' does not require that subscription renewals occur on the same RevenueCat account, what would be the ideal way we handle this? It seems like that the user would be stuck using Account B until the next subscription renewal (since they cannot transfer the purchase when ‘Block Purchases’ is configured)?
icon

Best answer by jazmine 24 January 2022, 21:32

View original

1 reply

jazmine
Rank
Userlevel 3
Badge +7

Hey @Stephen Heaps , 

 

I am going to split up your questions and answer them individually.

But what happens if the logged in user at the time of renewal is different than the logged in user who initiated the subscription?

The renewal will occur on the account that initiated the purchase. The only exception to this would be an account that is aliased together or if an account was transferred to another account ( which would only occur if you have transfer purchases as your restore behavior). 

We are currently still configured to ‘Alias (legacy)’, but from our initial testing it seems like a subscription renewal is applied to the currently logged in RevenueCat user. In the customer history for this account, they do not have a ‘started subscription’ event, just a ‘Renewed their subscription of _ for _’ event. Does this behaviour hold true when 'Restore Behavior' is configured as 'Block Purchases'?

That behavior is likely a combination of a sandbox quirk and having Alias as your restore behavior. If you have your restore behavior configured to ‘Block Purchases’ the receipt will never be transferred or merged with another user. So the renewal will always show up on the account that initiated the purchase. 

 

Example scenario (all occurs on one device, one App Store account):

  1. User is logged into Account A and purchases a 1-month recurring subscription.
  2. Prior to the subscription renewal, the User logs out of Account A and logs into Account B
  3. The 1-month subscription renews.
    1. In RevenueCat, this updates the entitlements for Account A to no longer have an active entitlement (expired), and adds the entitlement Account B.

 

Will 'Block Purchases' also require that subscription renewals occur on the same RevenueCat account? Or is that functionality limited to the 'Restore Transactions' function logic?

In the scenario you described the if you have ‘Block Purchases’ the subscription renewal will only occur on account A, even if restore transactions if called. 

 

If 'Block Purchases' does not require that subscription renewals occur on the same RevenueCat account, what would be the ideal way we handle this? It seems like that the user would be stuck using Account B until the next subscription renewal (since they cannot transfer the purchase when ‘Block Purchases’ is configured)?

Yes you are correct when ‘Block purchases’ is configured the user will be stuck using account B. If you want users to be able to transfer purchases from one account to another when Restore transactions is called Transfer Purchases might be a better fit. 

 

 

 

 

 

 

Reply


Terms & ConditionsCookie settings