Restoring Purchases

Re-sync purchased transactions from Apple, Google, or Amazon

Restoring purchases is a mechanism by which your user can restore their in-app purchases, reactivating any content that had previously been purchased from the same store account (Apple, Google, or Amazon).

It is recommended that all apps have some way for users to trigger the restorePurchases method, even if you require all customers to create accounts.

Purchases.shared.restorePurchases { customerInfo, error in
    //... check customerInfo to see if entitlement is now active
}
[[RCPurchases sharedPurchases] restorePurchasesWithCompletion:^(RCCustomerInfo *customerInfo, NSError *error) {
    //... check customerInfo to see if entitlement is now active
}];
Purchases.sharedInstance.restorePurchases(::showError) { customerInfo ->
    //... check customerInfo to see if entitlement is now active
}
Purchases.getSharedInstance().restorePurchases(new ReceiveCustomerInfoCallback() {
    @Override
    public void onReceived(@android.support.annotation.Nullable CustomerInfo customerInfo, @android.support.annotation.Nullable PurchasesError error) {
    //... check customerInfo to see if entitlement is now active    
  }
});
try {
  PurchaserInfo restoredInfo = await Purchases.restoreTransactions();
  // ... check restored purchaserInfo to see if entitlement is now active
} on PlatformException catch (e) {
  // Error restoring purchases
}
try {
  const restore = await Purchases.restorePurchases();
  // ... check restored purchaserInfo to see if entitlement is now active
} catch (e) {

}
Purchases.restoreTransactions(
  info => {
    //... check customerInfo to see if entitlement is now active
  },
  error => {
    // Error restoring purchases
  }
);
var purchases = GetComponent<Purchases>();
purchases.RestorePurchases((info, error) =>
{
    //... check purchaserInfo to see if entitlement is now active
});

The restorePurchases method should not be triggered programmatically, since it may cause OS level sign-in prompts to appear, and should only be called from some user interaction (e.g. tapping a "Restore" button).

Restore Behavior

If an identified App User ID tries to restore transactions that are already associated with a different identified App User ID in RevenueCat, you can configure how RevenueCat should respond by changing the Restore Behavior dropdown in Project Settings > General in the dashboard.

509509

Note that the restore behavior set here will affect all apps under the project. Also note that Alias (legacy) will only be available for legacy projects with Alias behavior already enabled, not new projects.

📘

Restore behavior also applies to making purchases

The configured restore behavior will also apply if an identified App User ID makes a new purchase and the device receipt is already associated with a different identified App User ID in RevenueCat.

Transfer Purchases

Default ✅

The default behavior is to transfer purchases between identified App User IDs if needed. This ensures that the customer restoring gets access to any purchased content, but only one customer at a time can have access. For example, if UserA buys a subscription, then UserB logs into your app on the same device and restores transactions, UserB would now have access to the subscription and it would be revoked from UserA.

If an identified App User ID restores and the owner of the receipt is anonymous, the anonymous identifiers will be merged (aliased) into the same customer profile in RevenueCat and treated as the same customer going forward. If an anonymous ID restores and the owner of the receipt is an identified App User ID, we will resort to the specified restore behavior and transfer the receipt to the anonymous user.

Google Play on Android

Due to platform limitations, purchases will be transferred as soon as you call configure if a user's purchases are already associated with another app user ID.

This may cause unexpected transfers of purchases between app user IDs, especially for apps with optional logins or users with multiple devices. To prevent this behavior, you should wait to call configure until you have the appropriate app user ID for your customer.

Block Restores

Use with caution 🚧

Returns an error if the App User ID attempting to restore purchases is different from the original App User ID that made the purchase. This requires customers to sign in with their original App User ID, and is only allowed for apps that require every customer to create an account before purchasing.

Alias

Legacy ✅

The legacy behavior is to merge (alias) any App User IDs that restore the same underlying subscription and treat them as the same subscriber moving forward. This applies to both anonymous and identified App user IDs. You can continue to use this legacy behavior as long as you'd like, but you cannot re-enable the alias behavior if you switch to Transfer Purchases or Block Restores.

Example usage

My app...

Restore Behavior

Does not have any login mechanism and only relies on RevenueCat anonymous App User IDs.

Transfer purchases. Required to allow customers to restore transactions after uninstalling / reinstalling your app.

Has an optional login mechanism and / or allows customers to purchase before creating an account in my app.

Transfer purchases. Required to make sure customers that purchase without an account can restore transactions.

Requires all customers to create an account before purchasing.

Transfer purchases. Recommended to help customers restore transactions even if they forget previous account information.

Requires all customers to create an account before purchasing, and has strict business logic that requires purchases to only ever be associated with a single App User ID.

Block restores. Will make sure that transactions never get transferred between accounts. Your support team should be prepared to guide customers through an account recovery process if needed.

Next Steps


Did this page help you?