Skip to main content

Hi, 

I’m trying to get some clarity around account creation. Currently, a user can create as many accounts as they want in our app (no payment is needed upon account creation). However, we want to only allow a single Apple/Google ID to be associated with one account. For example, if I:

  1. Create two brand new accounts
  2. Login to the first one and subscribe to a paid monthly subscription
  3. Logout and login to the second account

At this point, I would expect that the second account doesn’t have access to the paid monthly subscription that was purchased by account number one. The phone is still logged in with the same Apple/Google ID, so:

  1. Is the second account able to purchase a paid monthly subscription?
  2. If the second account purchased a higher tier than the first account, would it all be associated with one account in RevenueCat, therefore “upgrading” the first account?

We have done some testing in Sandbox mode, and wanted clarity on how this would work in production. One thing to note is that each of the accounts that are created would have a different AppUserID, so I’m not sure if we would need to enable Transfer Purchases, to handle this case? Or if our app needs to prevent a user from subscribing if the underlying Apple/Google ID is already associated with a subscription?

 

Thanks!

 

 

Is the second account able to purchase a paid monthly subscription?

No, the stores do not allow the same device account to own duplicate subscriptions. 

 

If the second account purchased a higher tier than the first account, would it all be associated with one account in RevenueCat, therefore “upgrading” the first account?

Correct, the upgrade would be coming from the same device account so would get applied to the same App User ID in RevenueCat. However, the restore behavior provides you some control over what RevenueCat should do:

  • With “Transfer”, the second App User ID that just purchase would get the receipt moved to them, and the first App User ID that purchased would lose access. This is the recommended behavior since it always gives the App User ID that just purchased or restored access to the subscription - which is what most customers expect.
  • With the “Block restore” option, the upgrade would still go through, but a “receipt already in use error” would be returned to the second App User ID, and the upgrade stays on the first App User ID’s account. This is usually not recommended unless you have your own support resources around to help customers with account recovery. 

That makes sense. Thank you for clarifying @ryan! Is there anyways to test the “Block restore” behaviour on sandbox? I saw in the docs that there is a bit of a unique behaviour for sandbox, to prevent having to create a new sandbox tester account each time. If it isn’t possible, is there a recommended testing flow?

Hey @Lee Howorko,

 

Whatever restore behavior is set in the dashboard will apply to both sandbox and production transactions, so there actually wouldn’t be a way to test changing from one behavior to another. The good news is your app code shouldn’t need to change at all when switching behaviors, but if you go with “Block restores” then I’d make sure you’re handing the “Receipt already in use” error specifically since that will be the error returned if a restore is blocked.

 

If you do need to test, a new behavior and your app is already live, you may need to set up a new test app in RevenueCat to create a new API key and copy your setup over.

 

 I saw in the docs that there is a bit of a unique behaviour for sandbox, to prevent having to create a new sandbox tester account each time. If it isn’t possible, is there a recommended testing flow?

Thanks for pointing this out. The docs here are actually incorrect (just fixed, looks like we missed the update on that page) and the sandbox behavior is now the same as production. We made this change when the configurable restore behavior was rolled out. 

Is the second account able to purchase a paid monthly subscription?

No, the stores do not allow the same device account to own duplicate subscriptions. 


Hi @ryan, I got some problems regarding this one. I am not sure if the best practise is replying here or creating a new topic.

Lately I received multiple users who already have an active subscription from Google Play, then signed out and created a new account and from what I understand they won’t be allowed to subscribe with the same billing account.

However, I received a webhook call from RevenueCat that they subscribed successfully in the new account with a $0 bill.


This is the webhook call back I have received from RC:

"presented_offering_id": "plus","price": 0,"price_in_purchased_currency": 0,…"transaction_id": "GPA.3333-***

 

And both records has a unique transaction id under the same Google Play account, here’s records:


I am not sure what’s happening, it’s the third times in the last 2 weeks.

Please advise.
 

P.S. I am adding a price check on the webhook function, rejecting new subscriptions with price=0, but not sure any side effects and the user still receive a “successfully subscribed” message on the frontend, so from the user’s angle it will be confusing.

Thank you.

 

@Kev it probably makes sense to start a new topic if needed since it seems unrelated.

A follow-up question I would have is what was the event type that was sent by RevenueCat? And could you share the event UUID? 

It looks like you’ve already confirmed the transactions exist in Google Play which is good, and the $0 price is appearing there as well so it seems that’s correct.

 

P.S. I am adding a price check on the webhook function, rejecting new subscriptions with price=0, but not sure any side effects and the user still receive a “successfully subscribed” message on the frontend, so from the user’s angle it will be confusing.

I would advise against this. There are edge cases where price may not be known at the time of the transaction (e.g. Google API issues) and it would attempted to be backfilled later. You shouldn’t block a customer from accessing content because the price=0. The price you see from RevenueCat is technically an estimate, and it’s not the source-of-truth on whether a customer should have access to content or not.

@ryan I have created a new topic.

 

Is the second account able to purchase a paid monthly subscription?

No, the stores do not allow the same device account to own duplicate subscriptions. 

 

If the second account purchased a higher tier than the first account, would it all be associated with one account in RevenueCat, therefore “upgrading” the first account?

Correct, the upgrade would be coming from the same device account so would get applied to the same App User ID in RevenueCat. However, the restore behavior provides you some control over what RevenueCat should do:

  • With “Transfer”, the second App User ID that just purchase would get the receipt moved to them, and the first App User ID that purchased would lose access. This is the recommended behavior since it always gives the App User ID that just purchased or restored access to the subscription - which is what most customers expect.
  • With the “Block restore” option, the upgrade would still go through, but a “receipt already in use error” would be returned to the second App User ID, and the upgrade stays on the first App User ID’s account. This is usually not recommended unless you have your own support resources around to help customers with account recovery. 

Hey, I can understand the logic for subscription.

But if it’s not subscription and it’s one time product which are consumable, I prevents transfer, (in ios) and login with account A to purchase then login with account to purchase, two products belongs to account A both.
It’s ridiculous, it mean app user id is useless!!

And in android, it’s totally different, two products belongs account A and account B separately. I suppose android is the expected!

Reply


Terms & ConditionsCookie settings