Skip to main content

Please introduce a new Restore Behavior that disables transfers completely

H
Forum|alt.badge.img

Hello,

I am using RevenueCat for many years and I am very satisfied with your service. However, I have a new app with a licensing model that does not work with the currently available restore behaviors.

Example use case:

For a cross-platform email app the licensing should not be tied to a device or app store account. It should be tied to the email address. Therefore, the AppUserId is set to the email address. Furthermore, an app store account should be able to buy the license (one time or subscription) for multiple email addresses.

Current state:

RevenueCat does not support multiple AppUserIds for one app store account. It also does not support the prevention of transfers of purchases. The option “Keep with original App User ID” does not work because the new purchase should be added to the current App User ID. Even when never using the restorePurchases() method of the RevenueCat, purchases are transferred when making a purchase. 

Example workflow:
1. User logins to app with email address and RevenueCat AppUserId @firstmail
2. User unlocks @firstmail with a consumable or subscription
3. User logouts and logins with another email address @secondmail
4. User also unlocks @secondmail with a consumable

Wanted behavior, let’s call it “Disable Transfers”:
Revenuecat AppUserId with @firstmail should keep their purchase and @secondmail should get the new purchase. Both Revenuecat AppUserIds should have the entitlement. No transfers at all.

Behavior with “Transfer to new App User ID”:
Revenuecat AppUserId with @firstmail has no purchases because they are transferred to @secondmail. @secondmail has a duplicate purchase.

Behavior with “Transfer if there are no active subscriptions”:
If Revenuecat AppUserId with @firstmail has a subscription, then you get the error RECEIPT_ALREADY_IN_USE, and the user gets charged but the purchase is added to @firstmail. @firstmail has duplicate purchase. Otherwise, the behavior is like “Transfer to new App User ID”.

Behavior with “Keep with original App User ID”:
You get the error RECEIPT_ALREADY_IN_USE, and the user gets charged but the purchase is added to @firstmail. @firstmail has duplicate purchase.

Suggested solution:
Add a transfer behavior “Disable Transfers” that completely disables transfers. New purchases should always be added to the currently logged in AppUserId. The methods restorePurchases() and syncPurchases() should throw an unsupported error if the transfer behavior is set to “Disable Transfers”.

Alternative solution:
Maybe make it an option or default that purchases do not trigger transfers.

Related docs:
https://www.revenuecat.com/docs/projects/restore-behavior
https://www.revenuecat.com/docs/getting-started/restoring-purchases

Related questions:

https://community.revenuecat.com/sdks-51/there-is-already-another-active-subscriber-using-the-same-receipt-5956

 

https://community.revenuecat.com/sdks-51/there-is-already-another-active-subscriber-using-the-same-receipt-receipt-already-in-use-6143

 

    joan-cardona
    RevenueCat Staff
    Forum|alt.badge.img+6

    Hi @hig,

    Thank you for the detailed post!

    This should be possible if you use consumables but not with subscriptions since that’s a limitation from the stores. The App Store does not allow a user (as in an Apple ID) to be subscribed to the same subscription more than once, that’s why our restore behavior doesn’t include the option that you describe. On the other hand, a consumable can be purchased multiple times and be redeemed by the same user over and over. In that case, the restore behavior doesn’t have any effect since essentially you cannot restore a consumable purchase and should all be handled by your backend.

     

    Let me know if this helps clearing things!

    Joan.
    H
    Forum|alt.badge.img
    • hig
    • New Member
    • April 15, 2025

    Hi Joan,

    thanks for your response.

    I understand that this problem probably does not occur if the app only uses consumable IAPs.
    I also know that it is not possible to purchase the same subscription twice. That’s why the app would have multiple seperate subscriptions (groups). Then the user would be able to purchase subscription #1 for  @firstmail and subscription #2 for @secondmail.

    However, the restore behaviors are problematic in the following cases:

    Case 1: App uses consumable IAP for lifetime entitlement and in-app subscriptions
    If an Apple AppStore account subcribed to an in-app subscription for @firstmail. RevenueCat remembers that and transfers the purchases to @secondmail if the same Apple Store account purchases a consumable IAP for @secondmail

    Case 2: App without consumable IAP uses multiple in-app subscription groups
    If an Apple AppStore account subcribed to the in-app subscription group #1 for @firstmail. RevenueCat remembers that and transfers the purchases to @secondmail if the same Apple Store account subcribes to the in-app subscription group #2 for @secondmail. Then @firstmail has no access anymore and @secondmail has two subscriptions.

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settings

    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