Solved

Eligibility of introductory offers


Badge +1

Hi guys,

I complete setup for product and introductory offers for it on AppStore connect. Now I check eligibility for new user (by checkTrialOrIntroductoryPriceEligibility), and completion block return dictionary with eligibility statuses and associated products. My problem is that status for all products is “Not eligible for trial or introductory price.” Why SDK return wrong status?

icon

Best answer by cody 21 July 2021, 17:09

View original

36 replies

Userlevel 1
Badge

@cody I am attempting to implement checkTrialOrIntroductoryPriceEligibility in our app using RC and just wanted to check this statement:

 

The checkTrialOrIntroductoryPriceEligibility method takes the existing receipt on your device and checks the transactions to determine if the user is eligible or not for the product ID in question. If there’s no receipt available, this method will return ‘unknown’.

 

Does that mean that it’s likely all new users will get an “unknown” eligibility response? (I am testing with a new sandbox account and get “unknown” but wanted to check if this is also the case for real-world production users)

Thanks in advance!

Badge +3

Confirmed - `checkTrialOrIntroductoryPriceEligibility` is what you need.

Would be good if this were documented in the official guides, probably under “Displaying Products”. Until finding this thread, found it confusing on how to determine if user should see free trial paywall, or regular paid paywall. 

Userlevel 6
Badge +8

Hey @Dmitry!

The checkTrialOrIntroductoryPriceEligibility method takes the existing receipt on your device and checks the transactions to determine if the user is eligible or not for the product ID in question. If there’s no receipt available, this method will return ‘unknown’. If there’s an error parsing the local receipt, we’ll ask the backend for eligibility information, which will do its best to return a value based on the information in the user’s receipt. Debug logs will help to provide any relevant information about this method and potential errors.

If the method is returning ‘ineligible’, the method has likely found previous transactions from the user’s receipt either on-device or from the backend that indicate the user is ineligible for the introductory price. If you’re testing this method in sandbox, I’d recommend creating a new sandbox user and/or trying a fresh installation.

Generally, you should handle each of these cases, and inform your users based on the information you have available. Even if our method returns unknown or ineligible, Apple’s payment sheet will ultimately display the introductory price if the user is eligible for it and the user will confirm the terms of the purchase during the checkout.

Userlevel 1
Badge +1

I couldn't find `checkTrialOrIntroductoryPriceEligibility` and have eventually found out that it has been renamed to `checkTrialOrIntroDiscountEligibility` as of Purchases 4.0.0 as seen here, in case it helps someone visiting this thread.

Userlevel 1
Badge +1

I have found the same behaviour as @Marco Muratore: testing in the sandbox, a user is considered non-eligible for free trial for any of the products if they have subscribed before, even after resetting eligibility in the iPhone Settings.

I tried the following and none of it served to reset the eligibility of the user for a free trial:
- delete the user in RevenueCat's sandbox dashboard
- reinstall the app from scratch
- log out the sandbox user and log in again

If I start the flow, then the system prompts tell me that the user has the free trial, but the response from RevenueCat is always non-eligible.

The only thing that worked to have a user eligible for free trial was to create a new test user in the sandbox in App Store Connect. Once I subscribed with this new sandbox user, I couldn't reset their eligibility again.

So as of these tests, it would look like once a sandbox users is used to subscribe once, then they are "burnt" and can't be used to test the full subscription scenarios. Is this intended behaviour? Is there a way to reset a test user eligibility for a free trial?

Userlevel 1
Badge

@skuske I asked my question above in a support ticket and got a helpful answer from Michael at Developer Support.

The receipt not being available is most commonly seen in Sandbox and is not usually an issue in production. So this case of not having a receipt generated causing the eligibility to be off would be less common to see in production. In production, a receipt is generated when a user downloads the app and is saved against the Apple account.

 

So it seems that most, if not all, users on production will have a receipt and therefore return “eligible” or “ineligible”.

 

If there is no receipt for any reason, the method will always return “unknown”.

Userlevel 5
Badge +8

Hey, sorry for the delay. 

 

For iOS: 

 

Eligibility works on a per-product basis, so I’d recommend not trying to have a single `isEligibleForTrial` boolean if you intend to display multiple products. Instead, you should think about it as “is eligible for a free trial of the monthly option” vs “is eligible of a free trial for the annual option”. 

There’s some extra nuance (I’ll go into it in a bit), but in general terms, you should just rely on the value that RevenueCat returns without doing any further computation. We’ll take care of de-duplication such that a user doesn’t get two free trials (one for annual and one for monthly). 

 

The gnarly details: 

Eligibility is actually performed on a per-subscription group basis, technically. This means that if your monthly and your annual options are in the same subscription group, and a user uses the free trial for one of them, they won’t be able to use another free trial for the other product (or for the same product). 

If products are set up to be in different subscription groups in App Store Connect, and each of them have a free trial, then yes, the user will be able to use a free trial more than once. But even if that was the case, you shouldn’t do any further computation, since ultimately it’s iOS that decides whether to grant the user a free trial or not.

So even if your logic says that the user already redeemed a free trial for another product in a different subscription group and you show a price, iOS will still automatically apply a free trial if the user is eligible.

 

My advice is to simply rely on the value that RevenueCat provides, and make sure to tie it to each product (so if you have a purchase button, for example, change the copy to “start free trial” for example if the eligibility for the currently-selected product was “eligible”. 

 

For Android: 

 

Your Android logic looks fine (I think you can skip the price == 0 check, but I also don’t think it’ll hurt). We do have a section dedicated to testing this on Android in our guide that might be helpful here: https://www.revenuecat.com/blog/engineering/the-ultimate-guide-to-android-subscription-testing/#free-trials

 

You should also be mindful of the setting in Google Play for who is eligible for a free trial from there. 

 

Hope this helps! 

Userlevel 5
Badge +8

@Jonah thanks for reporting! We already have a fix in place, which will go out very soon. In the meantime, one way to work around this is to configure the SDK to use StoreKit 1. 

 

Purchases.configure(with:

    Configuration.Builder(withAPIKey: Constants.apiKey)

        .with(appUserID: "<app_user_id>")

        .with(usesStoreKit2IfAvailable: false)

        .build()

)

Userlevel 5
Badge +8

@lucksp agreed! Sadly eligibility is ultimately managed by the OS, so we can’t do much on our side to make it better. 

 

However, for testing, here’s my advice: 

  • TestFlight for intro eligibility is… well, annoying, I’d use either Sandbox or StoreKit Configuration files. 
  • If you’re testing on Sandbox, you can either create multiple sandbox accounts and switch between them (that’s what I do), or use a single one, but then go into App Store Connect, find the sandbox user (Users and Accounts → Sandbox), then click Edit on the top right, select the user and click Clear Purchase History. This can take a while to take effect, though (from 1 hr to 24 hrs!). You can also access a similar option through the device in Settings → App Store → Sandbox Account. 
  • If you’re testing with StoreKit Configuration files, you can actually reset eligibility very easily! You just go to Xcode → Manage transactions → delete them all. This deletes the history for the user as the app sees it… But you’ll need to also use a new appUserID in RevenueCat since sadly we don’t have a way to know that you deleted the history for the user. If you’re using anonymous IDs, a fresh install does the trick. This is the easiest way to test, but it requires a bit more setup at first. 

Hope this helps! 

Userlevel 5
Badge +8

@manuel-becker even though I don’t have an ETA, I’ve taken note to let you know the minute we have a beta for Capacitor 

Badge +3

@manuel-becker even though I don’t have an ETA, I’ve taken note to let you know the minute we have a beta for Capacitor 

So nice of you, thank you. I still have to get it done asap because I would love to be part of the next RC “Roast my Paywall” series but mostly because users are asking a lot for trials and not having them results in lots of 1 star ratings although the app gives away so much for free already. But that’s simply how the “app store game” works I guess ;-)

I would still love to know though because I would probably at least use it for some time to do AB testing with it. Thank you again for being so responsive here. This makes all the difference for developers like me and I highly appreciate it!

Userlevel 5
Badge +8

@Bilance you should be able to get eligibility information by following the steps outlined here: 

Note that the reply refers to purchaserInfo, however, on Flutter v4 or higher, the object is called customerInfo. The steps should otherwise remain the same. 

Userlevel 5
Badge +8

@manuel-becker sorry for the lack of an update. 

 

We didn’t end up adding this new API, since on Android since the introduction of BillingClient 5, the answer to whether your user is eligible for an intro offer is: yes, as long as they can see them. 

 

This means that anything you get through getOfferings, the user is eligible for on Android. This is a different story from iOS. 

 

I’m thinking of ways to make this behavior more standardized across the board, although there are technical limitations that make that a bit tricky. 

 

For the time being, I’d advise: 

  • on iOS, use the API for intro eligibility
  • on Android, you can look for the `freePhase` on the PricingPhases within SubscriptionOption, if there’s one there it means the user is eligible for a free trial

 

Badge +3

@Andy No worries, you don’t have to be sorry. Anything helps and any hint is highly appreciated, especially with something like that which probably affects all RC’s users which are developing not natively.

That definitely sounds like a big step forward in terms of not having to sync purchases first. I don’t know yet how to get SubscriptionOption but I will deep dive the Capacitor documentation and hopefully find out. This should also prevent users from simply creating a new account and using the next free trial again because it’s iOS and Android which decides about the eligibility, right?

Thank you so much as always for all your efforts and for doing such a fantastic job, I appreciate it a lot.

Badge +3

@Andy Awesome, this helps a lot and I highly appreciate you taking the time to help. So for iOS the check right now asks for multiple product ids which is why I did the additional check afterwards because I wanted to get a single boolean result first to show a trial button directly on the products feature. When I understand you correctly it probably doesn’t even matter to add the second product id for the case when they are in one subscription group, right?

I will definitely check the subscription testing guide tomorrow, thank you very much.

Userlevel 5
Badge +8

If they’re in the same subscription group, and they both have free trials, then the value will be the same for the two. 

 

I forgot to mention, but if you happen to be on React-Native, we’re currently in beta with our own Paywalls, which take care of the intro eligibility handing automatically for you (along with other goodies like remotely making changes and A/B pricing experiments)

 

Here’s more info if you’re interested!

https://github.com/RevenueCat/react-native-purchases/releases/tag/7.4.0-beta.2

And if you’re on a different javascript-based SDK like Cordova / Capacitor, we’re going to work on adding support for those soon, although I don’t have an ETA just yet. 

Badge +6

this is confusing for testing...it would be nice if on TestFlight, the sandbox users would have a reset eligibility to verify the intro offers are available.

Badge +3

Hi @cody, we implemented checkTrialOrIntroductoryPriceEligibility

Some of our testers use TestFlight and tested purchases in the past, so they reset eligibility for intro pricing from App Store settings but the result remains “Not eligible for trial or introductory price.”.

We can confirm the intro (in this case a trial) was available by trying to proceed to the payment and checking the purchase confirmation page.

Is it possible that there is a bug regarding this specific case?

Thanks

Badge +3

@Andy Great to know, so the check is for my usecase redundant but still fine for me. I feel it’s so hard to find info about details like that.

Yeah I saw the release of the Paywall feature and immediately was super hyped and wanted to use it (especially because of the AB testing and saving me a lot of time) but then I recognized that it’s not available yet for Capacitor. ;-)

Badge +3

I may have found a bug.

 

I have a product that has no introductory offer set up on Connect. However, `checkTrialOrIntroductoryPriceEligibility` is returning `eligible`.

 

Do note, I have other product id’s in the same subscription group that do have trials. 

 

Happening in both sandbox and production. Latest iOS sdk. 

Badge +3

@Jonah thanks for reporting! We already have a fix in place, which will go out very soon. In the meantime, one way to work around this is to configure the SDK to use StoreKit 1. 

 

Purchases.configure(with:

    Configuration.Builder(withAPIKey: Constants.apiKey)

        .with(appUserID: "<app_user_id>")

        .with(usesStoreKit2IfAvailable: false)

        .build()

)

Thanks for the quick reply. Ok will give that a shot!

Userlevel 5
Badge +8

@manuel-becker happy to help! Don’t hesitate to reach out again if there’s anything else we can help with

Badge +3

Hi @Andy  - I’m now on latest iOS SDK (4.12.0). I’m using a SKProduct that has a free trial. `checkTrialOrIntroDiscountEligibility` is returning elligible, however. `package.storeProduct.discounts` is empty. 

 

Is this expected?

Badge +3

.

Badge

@skuske I asked my question above in a support ticket and got a helpful answer from Michael at Developer Support.

The receipt not being available is most commonly seen in Sandbox and is not usually an issue in production. So this case of not having a receipt generated causing the eligibility to be off would be less common to see in production. In production, a receipt is generated when a user downloads the app and is saved against the Apple account.

 

So it seems that most, if not all, users on production will have a receipt and therefore return “eligible” or “ineligible”.

 

If there is no receipt for any reason, the method will always return “unknown”.

I’ll just go with this and hope for the best. Thank you! 

Reply