What is expected behavior for syncing google play/apple store auto-renewing subscriptions with internal account?

Question

We're currently implementing the auto-renewing subscriptions for Google (we started with non-renewing for Apple and implemented already deduplication and validation process on server-side) and the main question right now is the following case:

1. A user has Google account A in Google Play and Internal account A in into the application
2. The user buys auto-renewing subscriptions. (It's now tied to Internal Account A)
3. He signs out from Internal A and signs into Internal B

So the question would be what the expected state should be for Internal B? Basically, the play market (therefore Google BillingClient) will have information about subscription because it tied to Google account, but we expect the subscription to be in effect only for 1 internal account (and it will be because of deduplication process anyway). But in this case, the user has a strange situation when the subscription is already bought previously (when he was logged in with Account A), but not in effect and therefore he can't buy for Internal Account B.

I was trying to find the answer under the following link, but looks like they don't really have a good description of such cases: https://developer.android.com/google/play/billing/billing_subscriptions

It seems to me that we should just provide some UX for this situation, smth like: 'Looks like you've got the subscription, but you're in wrong account'. But would appreciate if anybody can answer this question of what Google/Apple review team expects in this case.

Answer 1

If you look at other big subscription apps, like Netflix or Spotify, you can get some UI ideas of how they manage this. If Internal Account A subscribes on iOS, then logs in on Android, you can show in the UI that the subscription is billed and managed through iTunes.

In the situation you described, if Internal Account B logs in, then the expected UI would be in the "non-subscribed" state. There are a couple edge cases to think about:

1. If Internal Account B tries to purchase a subscription from a device that's already purchased it, there will be an error that the subscription is already active.

2. Make sure Internal Account B can't restore purchases for a receipt that was bought by Internal Account A.

At RevenueCat, we store the receipt file and original transaction Id on the user record that made the original purchase, that way we can detect if a different user is trying to restore the same purchase (by the original transaction Id).

As far as policies. The only official policy is that users need a way to restore a previously purchased subscription. If they can do a restore by simply logging into Internal Account, then that is sufficient. How you want to handle the case of "app store account sharing" is up to you. Like most things with mobile subscriptions, it's a tradeoff of development complexity vs. risk.

Answer 2

I do not believe Apple has an actual "policy" regarding the proper behavior for subscriptions. I would not expect them to fail you unless you did something pretty egregious regarding subscriptions.

To an extent, this is understandable because of the various nuances, it does become implementation dependent upon the app on how they want to handle things.

I highly doubt they test for this situation. This would require not only too much time testing your app but also more intimate knowledge on how your app works. I would also theorize Google is similar in practice.