• Community
  • Get Help
  • SDKs
  • Purchases not restoring automatically on Android when calling configure with another app user id
Solved

Purchases not restoring automatically on Android when calling configure with another app user id

  • 7 December 2023
  • 4 replies
  • 134 views
R
Badge +3

I am working on preparing an Android app to properly support the `Transfer to new App User ID` behavior. Up until now, the project on RevenueCat was blocking transfers.

 

The app offers access to content based on a subscription, and the users require an account to purchase any subscription.

 

While reading the documentation, I noticed this section that mentions the following auto-transfer behavior:

So I made the following changes - as instructed by the docs here - , to make sure the existing subscription tied to the Google Play account doesn’t transfer to an anonymous user id:

  • Only call `configure` or `login` on the SDK when the user is logged in the app (has a user id)
  • Never call `logout` on the SDK

However, the problem that I noticed is that when I log in to another in-app account, the auto transfer behavior that is mentioned on the doc snippet shown at the beginning is not happening. Is that section of the documentation outdated or am I missing something?

Here is an example scenario that I ran in sandbox mode:

  1. Create an in-app account (account1@example.com) and subscribe
  2. Log out
  3. Create another in-app account and log in (account2@example.com)

Expected result (based on the docs): The existing subscription should be automatically transferred to account2@example.com

Actual result: No TRANSFER webhook is present when I monitor the latest webhooks sent in RevenueCat dashboard, thus the subscription is not transferred automatically. Also, I tried force stopping and restarting the app, but the subscription did not transfer in this case either.

However, if I call `Purchases.sharedInstance.restorePurchasesWith` when account2@example.com is logged in, the subscription is transferred properly to the new account.

 

I don’t mind this, I actually think it’s better this way, but I still don’t understand why that behavior mentioned in the docs is not happening in my tests. What I want to get is a clarification, because I don’t want to release the app like this and then be caught off guard when in Prod, that behavior starts happening to users. 

 

Thank you!

icon

Best answer by Ryan Glanz 12 December 2023, 23:30

View original

4 replies

R
Badge +3

Extra clarification: I am on Android SDK v6.9.5 - I am not on the latest version because of this issue

Not sure if this matters but I thought I’d mention it.

Ryan Glanz
Rank
Userlevel 3
Badge +8

Hi Radu,

It looks like we shipped a change recently to not transfer the purchase immediately on configure. So I will go update those docs.

If you did want them to transfer right away, you could use syncPurchases, which is the programmatic-safe version of restorePurchases.

K

Hi @Ryan Glanz just wanted to check, as the docs still mention that purchases are transferred upon configure/login on android. Can you confirm if this is the case or not in the latest SDK version as of 20th march 2024?

 

Thanks!

R
Badge +3

I would really appreciate some more info on this behavior. @Ryan Glanz 

First, the documentation states that “Due to platform limitations, purchases will be transferred as soon as you call configure if a user's purchases are already associated with another app user ID.”

The docs still say this, even though @Ryan Glanz confirmed that the docs will be updated to reflect the new behavior.

“Due to platform limitations” --> Based on the wording from the docs, I always assumed this is something that is outside of RevenueCat’s control.

Then, I understood from Ryan’s comment that the RevenueCat team shipped a change so that the purchase will not transfer automatically when configure is called.

 

Was this behavior change accidental? Is it something that will remain in place in the future?

 

This is not an insignificant change and can have serious implications in our projects, that’s why I need more info.

 

Our server was built to support only one subscription per account. We could end up with 2 parallel subscriptions in some cases because of this, leading to unwanted behavior. Let’s take a real-life scenario into account, for example:

  • Sister has an app account with a Stripe subscription that grants premium access in our platform (website and iOS / Android apps) (Stripe is not handled by RevenueCat in our project, we use Stripe directly).
  • Brother has another app account with a Google Play subscription (same premium rights granted as above) created though his Android device (managed by RevenueCat).
  • The siblings are going on a road trip. The sister’s Android device runs out of battery and borrows the brother’s phone to use her own app account on it until she can recharge her phone. As soon as she logs out of the brother’s app account on his device and logs into her app account, because the brother’s subscription is a Google Play one, RevenueCat will transfer the brother’s Google Play subscription automatically when configure is called, to her app account, at least according to the current documentation.
  • This will trigger a situation on our backend where the sister’s account will receive the TRANSFER webhook event, for her brother’s Google Play subscription, over her Stripe subscription. Of course, we can ignore this request on our backend if there is already a subscription on the sister’s app account, but now that means that RevenueCat is desynchronized from our backend. Future webhooks of the brother’s subscription (for RENEWAL for example), will be sent to her sister’s user ID, until he signs back to his account from his device, so that his subscription is restored automatically (if that auto-transfer behavior is still valid by the time he signs back in).

 

Just to make it clear again, this auto transfer behavior is not currently happening on the RevenueCat SDK version we’re using (v6.9.5), and I’d like to receive some assurance from RevenueCat that this will continue to be the case in the future, or at least have a warning in the SDK changelogs if that auto-transfer behavior will be re-enabled in the future, so that we know what we’re getting into when updating the SDK.

Reply


Terms & ConditionsCookie settings