1 store account, multiple app user id with different subscription plans

Hey ​@himanshu-gupta-59b473 - the behavior you're experiencing is actually working as designed for the Keep with original App User ID Restore Behavior, but it's exposing a fundamental mismatch between your use case and what this setting was built for.

The "Keep with original App User ID" setting assumes one App User ID equals one Store account (on the device). When you have multiple app users sharing the same Store account (same Apple ID or Google account), the behavior can indeed get to that state:

Case 1 (Same product): User B tries to buy Product X that User A already owns. RevenueCat sees the product already exists on the receipt owned by User A and blocks it with RECEIPT_ALREADY_IN_USE. This works as intended and as you described.

Case 2 (Different product): User B tries to buy Product Y. The App Store doesn't know about User A vs User B, it just sees a valid purchase request for a valid App Store Account and allows it. As the purchase completes, Product Y gets added to the Store receipt, then the SDK posts that receipt to RevenueCat. Our backend sees the receipt is owned by User A, applies your "Keep with original App User ID" setting, and assigns Product Y to User A. User B is the one “getting charged” but no entitlements given.

On this other behavior of Transfer if there are no active subscriptions we note this:

This is especially relevant on iOS, where a receipt contains all purchases associated with a given Apple Account, so in the case of using the behavior "Keep with original App User ID", the customer would be able to start a new subscription on the store, but they would not be able to gain access because RevenueCat would associate that new subscription with the original App User ID (since it is on the same Apple receipt).

The different Store tie receipts to Store accounts, not app accounts, that’s why you can't reliably detect this before purchase. RevenueCat only sees the receipt after the Store completes the transaction and by that point the user has already been charged. We will then only decide whether to transfer the entitlements or keep them with the original owner.

To try and prevent this however, you could check when a user logs into your app if their device's Store account is already linked to a different user by comparing the logged-in user's ID to customerInfo.originalAppUserId (SDK reference here) and if they don't match, that means the Store account belongs to someone else.

At that point, you should:

1. show a message explaining the conflict
2. disable purchase buttons in your app (or alert somehow)
3. direct them to sign out of their Apple ID/Google Account on the device and sign in with a different Store account

This prevents the "different product" scenario because the user can't even attempt a purchase until they've switched to a separate Store account. Once they sign in with a fresh Store account (one with no existing RevenueCat receipt), the check will pass and they can purchase normally.

Would this work for you? It’s a bit more involved, but could work to catch these cases and “block accordingly”.

Another alternative would be to change your restore behavior. If forcing separate Store accounts is not applicable, you could consider:

1. "Transfer to new App User ID" - User B would get the subscription, but User A would lose access
2. "Transfer if there are no active subscriptions" - Prevents transfers while subscriptions are active, but allows new users after churn (after the subscription expire). This reduces (but doesn't eliminate) the "different product" problem.

Hope this helps, but let me know how it goes!

​@guilherme Isn’t the originalAppUserId is the id which revenueCat generates when it is initalised ?
We login to revenuCat using custom id of our system.
As per revenueCat document, when a User A logs in, a originalAppUserId is created with the alias as custom id and when User B tries to log in on the same device then again for them a new originalAppUserId will be created with User B custom id as alias.

So how comparing originalAppUserId will help here ? Or am i missing something here ?

Could you please clarify this ?

Hey ​@himanshu-gupta-59b473 , 

Apologies for the confusion here. You are correct, that after a Purchases.logIn('userB_67890'), User B's customerInfo.originalAppUserId reflects their own customer record, and not User A's. Since there's no trace of User A in User B's CustomerInfo, that comparison wouldn't catch the conflict. 

After looking into this more carefully, a better approach for your case would be to call a receipt restore, which with your “Keep with original App User ID” behavior should throw an error that the receipt is associated with another user (in your case, User A). We have 2 methods that can do this:

• restorePurchases()

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.)

• 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).

Since restorePurchases() can trigger an OS authentication flow, is recommended to be a user started flow and not to be called programmatically. You can still do a check without requiring the user interaction with  syncPurchasesForResult() (SDK reference here) right after your authentication flow.

For context, syncPurchases is similar to restorePurchases as hit the same backend endpoint for the receipt, and with "Keep with original App User ID" configured, if the Store receipt is already owned by a different subscriber, it will return a RECEIPT_ALREADY_IN_USE_ERROR.

You can then catch that and block User B from purchasing from that point onwards. Something like this should do:

try {
  await Purchases.logIn('userB_67890');
  await Purchases.syncPurchasesForResult();
  // No error = Store account is free or belongs to this user
} catch (e) {
  if (e.code === PURCHASES_ERROR_CODE.RECEIPT_ALREADY_IN_USE_ERROR) {
    // Store account already linked to a different user - block purchases
    showWarning("This Store account has an active subscription linked to another account.");
  }
}

One thing to keep in mind is that syncPurchases is a heavier operation (it posts the full receipt and can trigger migrations), so I wouldn't recommend calling it systematically throughout your app. But calling it once right after your login/auth flow to check for this specific conflict should be fine and would cover your edge case.

Would this work for your setup? Could you give it a try and let me know?