What happens when customers have different accounts?
This question can be split into a lot of different cases:
- One customer using multiple devices with different Apple/Google accounts.
- One customer using multiple devices with the same Apple/Google account.
- Multiple customers sharing a single Apple/Google account.
- Some more complex combinations of the above.
Our service handles those cases with the concept of receipt ownership.
Receipt ownership
- A receipt is owned by a single customer (applicationUsername)
- A single customer can own multiple receipts.
- When the app sends a receipt validation request: the service sets the receipt owner to this customer (only if applicationUsername is set).
- When the receipt is updated, only its current owner gets the benefits of the new purchase (or subscription renewals).
Change of ownership
When the receipt owner changes, the previous owner(s) don’t loose access to past purchases (which they presented a valid receipt for). However future purchases (or subscription renewal) will be only accessible to the last owner of the receipt.
If past owners opens the app and show a valid receipt containing the new purchases, they’ll gain access to those purchases (and become the new owner).
Example
Here’s a quite complex example. Let’s consider a messaging app requiring a monthly subscription.
On her personal device, Alice is using the AppStore account she shares with her husband Bob: alice+bob@apple.com.
However, Alice and Bob each have a different account on the messaging app (applicationUsernames Alice
and Bob
Alice also has a work device, using a different AppStore account (alice-work@apple.com). She’s logged in the messaging app using the Alice
username (the same as her personal device).
She purchases a subscription plan. A receipt is generated, that will appear on both her personal device, and Bob’s device.
Here what happens.
Device 1 Username: Alice Apple: alice+bob |
Device 2 Username: Bob Apple: alice+bob |
Device 3 Username: Alice Apple: alice-work |
Receipt Owner |
Subscribers on Fovea.Billing |
|
---|---|---|---|---|---|
1 | Purchase Validate Receipt |
Alice | Alice | ||
2 | Open App Validate Receipt |
Bob | Alice, Bob | ||
3 | Open App No Receipt note: the receipt with a purchase is for Apple account alice+bob |
Bob | Alice, Bob | ||
4 | Subscribed period ends. Renewal occurs. | Bob | Bob | ||
5 | Open App No Receipt |
Bob | Bob | ||
6 | Open App Validate Receipt |
Alice | Alice, Bob |
After every subscription period, a past owner is assumed to have lost access to the subscription until it can show a valid receipt.
Note on the Cordova Plugin
The Cordova plugin in itself ignores the concept of application users. It only reports purchases and/or subscriptions for the active store account.
The above only has meaning if you have a back-end server that needs to know which application users can access the features.
Don’t like this business logic?
Using the webhook, you can create your own business logic. You’ll have to maintain your own database table that links applicationUsername to purchases or receipts. Then decide when you want to update those links.
- Store in a database “
purchaseId
(primary key),expiryDate
,applicationUsername
“ - Insert or update an entry in this database when receiving a webhook call.
- Use this database to determine if a user has access to the content.
You can then adjust the policy with some tweaks. For example, do not update the applicationUsername
if a purchase is already in this database, then the subscription wouldn’t be migrated automatically to the other user that logged in from the same device. But in this case, you probably need an interface to allow your users to perform the migration from within your app, maybe with a maximum number of migrations per purchase (add numMigrations
to the above database to keep track).
Initially, I would advise you keep things simple. Maybe just track if (or how many) people are abusing the system, see if it’s worth making the experience more complicated to everyone else. It depends on your type of users.