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 {
  CustomerInfo customerInfo = await Purchases.restorePurchases();
  // ... 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.)

🚧

Programmatically trigger a restore, by calling syncPurchases instead

If you are trying to restore a purchase programmatically, use syncPurchases instead. This will not cause OS level sign-in prompts to appear.

syncPurchases

syncPurchases is a method we provide in our SDK which allows you to programmatically trigger a restore. This method, much like restorePurchases, reactivates any content that had previously been purchased from the same store account (Apple, Google, or Amazon).

syncPurchases considerations

• syncPurchases is usually used for migrating subscriptions
• Since this method simulates restoring a purchase, there is a risk of transferring/aliasing an anonymous user

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.

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. And finally, if an anonymous ID restores and the owner of the receipt is also anonymous, the anonymous identifiers will be merged (aliased).

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

Next Steps

• Make sure all purchases are being linked to the correct user Id
• If you're ready to test, start with our guides on sandbox testing