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!