Solved

Eligibility of introductory offers



Show first post

36 replies

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

@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()

)

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 +4

Shall we use TrialOrIntroPriceEligibilityChecker’s checkEligibility function to check for trial eligibility for iOS 14 +
Edit: Okey found checkTrialOrIntroDiscountEligibility

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 3
Badge +7

HI @atineoSE ,

 

Unfortunately I don’t know of another way to consistently test user eligibility except for creating a new sandbox user each time. That is usually our solution to this issue.   

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 +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.

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 +5

@cody If the user has never purchased anything, will there be a receipt available to parse?

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.

Reply