Skip to main content

I’m running into a bit of an edge case where my app might allow duplicate subscriptions to occur:

Our app is iOS only. For experimentation with pricing, I have 2 subscription groups setup in App Store Connect:

  • Group A = has monthly/bi-monthly/yearly products at default prices
  • Group B = has monthly/bi-monthly/yearly products at experimental prices

Each of these groups is put into an Offering, and an Experiment is setup to compare these 2 offerings.

(I understand that I must use 2 subscription groups here, or users could manually cross-grade to the cheaper group)

Our app does not use any anonymous App User IDs -- users must create an account before purchasing. We are using the “Transfer to new App User ID” behavior for purchases with multiple App User IDs.

Starting with a fresh iOS Sandbox tester ID:

  • Create account (App User ID) UA
  • RevenueCat SDK logIn() with App User ID = UA
  • Experiment drives user UA into Offering A
  • User UA purchases a Monthly subscription from Group A at Price A

After this, the account user logs out (but we do not call RevenueCat SDK logout, so as not to create an anonymous user). Then, while still using the same iOS Sandbox account:

  • Create account (App User ID) UB
  • RevenueCat SDK logIn() with App User ID = UB
  • Experiment drives user UB into Offering B

Now, at this point, there is a brief period (~1 minute?) after the RevenueCat `logIn()` where it appears that RC has not yet transferred the purchases from UserA to UserB. During that time, UserB purchases a Monthly subscription from Group B at Price B.

Then, moments later, I get a customerInfo callback that has all of the subscription transfers from UserA to UserB. At this point in time, UserB now owns redundant subscriptions, one from each subscription group… which is bad.

 

Does this all sound like a correct setup for the “two pricing tiers experiment” I describe above?

If so, the core problem seems to be that delay between `logIn()` and getting the purchases transferred… how can I avoid that?

Is there some other way to prevent purchasing across the two subscription groups?

Thank you for the response @cody ! I hope I can ask a couple of follow-up questions? :)

 

1.

I had considered inserting `syncPurchases` into the login flow, but this post (

) led me to believe that would be incorrect, specifically:

> You should not call this programmatically on every app launch for every user. This can increase latency in your app and can unintentionally alias users together.

Is there a downside to using `syncPurchases` in the scenario that I describe above? (i.e. we don’t use anonymous users)

 

2.

In the Unity SDK, the `syncPurchases` function lacks a completion callback. How can I know when the `syncPurchases` process has completed? (I don’t want to expose purchasing options to the user until I’ve fully established their subscription status)

 

Hey @Frank Hickman!

Just calling `logIn` won’t transfer subscriptions, which might be what’s causing the delay here. It sounds like once a renewal occurs and we detect the transaction in the transaction queue, we re-sync the purchases and that’s when the transfer happens.

To force a transfer right away, you should call `syncPurchases` right after logging in - that should trigger the transfer immediately.

I should also mention: this is a Unity app, and we are using the RevenueCat Unity SDK

Reply


Terms & ConditionsCookie settings