How to secure non-consumable in-app purchases when user logs inHow to restore a Consumable In app Purchases?Restore button for iOS non-consumable in-app purchaseConsumable vs. non-consumable in iOSHow to make a non-consumable product available for multiple purchases through iOS in app purchasing?Is iOS in-app consumable purchase actually required to be restored?Handling non-consumable in-app purchases when a user can log in and out of the appSyncing a consumable in-app purchase with a serverPurchase non-consumable in app feature multiple timesiOS Non-consumable IAP with custom user accounts management - multiple purchasesHow is the right way to restore Inapppurchases of non-consumable products in combination with server?
I recently started my machine learning PhD and I have absolutely no idea what I'm doing
Why would you put your input amplifier in front of your filtering for and ECG signal?
Divisor Rich and Poor Numbers
Pedaling at different gear ratios on flat terrain: what's the point?
A person lacking money who shows off a lot
Do high-wing aircraft represent more difficult engineering challenges than low-wing aircraft?
Write electromagnetic field tensor in terms of four-vector potential
Solenoid fastest possible release - for how long should reversed polarity be applied?
Why use a retrograde orbit?
Why aren't satellites disintegrated even though they orbit earth within their Roche Limits?
Cannot remove door knob -- totally inaccessible!
When did Britain learn about American independence?
Why do academics prefer Mac/Linux?
Deleting the same lines from a list
Non-African Click Languages
How do Ctrl+C and Ctrl+V work?
When the match time is called, does the current turn end immediately?
Is it standard to have the first week's pay indefinitely withheld?
How to deal with the extreme reverberation in big cathedrals when playing the pipe organs?
Find the area of the rectangle
Why can't I share a one use code with anyone else?
Does a non-singular matrix have a large minor with disjoint rows and columns and full rank?
What color to choose as "danger" if the main color of my app is red
Would life always name the light from their sun "white"
How to secure non-consumable in-app purchases when user logs in
How to restore a Consumable In app Purchases?Restore button for iOS non-consumable in-app purchaseConsumable vs. non-consumable in iOSHow to make a non-consumable product available for multiple purchases through iOS in app purchasing?Is iOS in-app consumable purchase actually required to be restored?Handling non-consumable in-app purchases when a user can log in and out of the appSyncing a consumable in-app purchase with a serverPurchase non-consumable in app feature multiple timesiOS Non-consumable IAP with custom user accounts management - multiple purchasesHow is the right way to restore Inapppurchases of non-consumable products in combination with server?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
In one of my apps, users can unlock the full version through non-consumable in-app purchase. In the next update, I am introducing an ability to log in to our app so that their progress can be synced across their devices.
Now comes the problem - when the user logs in, I will transfer the information about their purchase to our server. However, what happens if a user logs out from our app, and then their friend logs in? The device is still connected to the App Store using the original Apple ID, and they can restore the purchase which will now be associated with their friend's account.
As you can see, theoretically users can allow all their friends to unlock our app for free unless we find a way of uniquely associating each purchase with a particular user on our servers.
I am sure this is a common issue, so how does it usually get tackled? We need to secure purchases originating from iOS and Android.
P.S. The syncing is done via Firestore.
android ios google-cloud-firestore 
in-app-purchase asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
add a comment |
In one of my apps, users can unlock the full version through non-consumable in-app purchase. In the next update, I am introducing an ability to log in to our app so that their progress can be synced across their devices.
Now comes the problem - when the user logs in, I will transfer the information about their purchase to our server. However, what happens if a user logs out from our app, and then their friend logs in? The device is still connected to the App Store using the original Apple ID, and they can restore the purchase which will now be associated with their friend's account.
As you can see, theoretically users can allow all their friends to unlock our app for free unless we find a way of uniquely associating each purchase with a particular user on our servers.
I am sure this is a common issue, so how does it usually get tackled? We need to secure purchases originating from iOS and Android.
P.S. The syncing is done via Firestore.
android ios google-cloud-firestore in-app-purchase asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
add a comment |
In one of my apps, users can unlock the full version through non-consumable in-app purchase. In the next update, I am introducing an ability to log in to our app so that their progress can be synced across their devices.
Now comes the problem - when the user logs in, I will transfer the information about their purchase to our server. However, what happens if a user logs out from our app, and then their friend logs in? The device is still connected to the App Store using the original Apple ID, and they can restore the purchase which will now be associated with their friend's account.
As you can see, theoretically users can allow all their friends to unlock our app for free unless we find a way of uniquely associating each purchase with a particular user on our servers.
I am sure this is a common issue, so how does it usually get tackled? We need to secure purchases originating from iOS and Android.
P.S. The syncing is done via Firestore.
android ios google-cloud-firestore in-app-purchase asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
In one of my apps, users can unlock the full version through non-consumable in-app purchase. In the next update, I am introducing an ability to log in to our app so that their progress can be synced across their devices.
Now comes the problem - when the user logs in, I will transfer the information about their purchase to our server. However, what happens if a user logs out from our app, and then their friend logs in? The device is still connected to the App Store using the original Apple ID, and they can restore the purchase which will now be associated with their friend's account.
As you can see, theoretically users can allow all their friends to unlock our app for free unless we find a way of uniquely associating each purchase with a particular user on our servers.
I am sure this is a common issue, so how does it usually get tackled? We need to secure purchases originating from iOS and Android.
P.S. The syncing is done via Firestore.
android ios google-cloud-firestore in-app-purchase android ios google-cloud-firestore in-app-purchase asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
asked Mar 23 at 16:13
Andriy GordiychukAndriy Gordiychuk
4,28011444
4,28011444
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There is no "official" guidance on this from either of the App Stores. What we do at RevenueCat is save the receipt file against a user Id, then whenever a new purchase (or restore) comes in check if the receipt file is already saved to another userId. We can then return an error that this receipt is already in use by another account.
If you look at some of the big subscriptions apps (Netflix, Spotify, HBO, etc.) you'll notice they don't even have a "Restore Purchases" button. You can get away with this if you require an account sign-in since purchases can be restored by signing into your account. However, unless you have engineering and customer support teams like Netflix, a "Restore Purchases" button is generally a good idea as it can save you from edge cases - just check if the receipt is already on file for another account before "unlocking" access.
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55315753%2fhow-to-secure-non-consumable-in-app-purchases-when-user-logs-in%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is no "official" guidance on this from either of the App Stores. What we do at RevenueCat is save the receipt file against a user Id, then whenever a new purchase (or restore) comes in check if the receipt file is already saved to another userId. We can then return an error that this receipt is already in use by another account.
If you look at some of the big subscriptions apps (Netflix, Spotify, HBO, etc.) you'll notice they don't even have a "Restore Purchases" button. You can get away with this if you require an account sign-in since purchases can be restored by signing into your account. However, unless you have engineering and customer support teams like Netflix, a "Restore Purchases" button is generally a good idea as it can save you from edge cases - just check if the receipt is already on file for another account before "unlocking" access.
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
add a comment |
There is no "official" guidance on this from either of the App Stores. What we do at RevenueCat is save the receipt file against a user Id, then whenever a new purchase (or restore) comes in check if the receipt file is already saved to another userId. We can then return an error that this receipt is already in use by another account.
If you look at some of the big subscriptions apps (Netflix, Spotify, HBO, etc.) you'll notice they don't even have a "Restore Purchases" button. You can get away with this if you require an account sign-in since purchases can be restored by signing into your account. However, unless you have engineering and customer support teams like Netflix, a "Restore Purchases" button is generally a good idea as it can save you from edge cases - just check if the receipt is already on file for another account before "unlocking" access.
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
add a comment |
There is no "official" guidance on this from either of the App Stores. What we do at RevenueCat is save the receipt file against a user Id, then whenever a new purchase (or restore) comes in check if the receipt file is already saved to another userId. We can then return an error that this receipt is already in use by another account.
If you look at some of the big subscriptions apps (Netflix, Spotify, HBO, etc.) you'll notice they don't even have a "Restore Purchases" button. You can get away with this if you require an account sign-in since purchases can be restored by signing into your account. However, unless you have engineering and customer support teams like Netflix, a "Restore Purchases" button is generally a good idea as it can save you from edge cases - just check if the receipt is already on file for another account before "unlocking" access.
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
There is no "official" guidance on this from either of the App Stores. What we do at RevenueCat is save the receipt file against a user Id, then whenever a new purchase (or restore) comes in check if the receipt file is already saved to another userId. We can then return an error that this receipt is already in use by another account.
If you look at some of the big subscriptions apps (Netflix, Spotify, HBO, etc.) you'll notice they don't even have a "Restore Purchases" button. You can get away with this if you require an account sign-in since purchases can be restored by signing into your account. However, unless you have engineering and customer support teams like Netflix, a "Restore Purchases" button is generally a good idea as it can save you from edge cases - just check if the receipt is already on file for another account before "unlocking" access.
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
answered Mar 25 at 16:24
enc_lifeenc_life
1,9601815
1,9601815
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
add a comment |
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
Do you store the whole file or just the originalTransactionID? I thought that ID will be sufficient.
– Andriy Gordiychuk
May 4 at 16:49
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
The originalTransactionID is sufficient for this use-case. Probably worth storing the entire receipt file, you may want it for something else down the road.
– enc_life
May 6 at 16:57
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55315753%2fhow-to-secure-non-consumable-in-app-purchases-when-user-logs-in%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
