Skip to main content
Question

Can Android BillingClient API be used to identify past users

  • 20 November 2023
  • 7 replies
  • 88 views

I have been able to identify previous paid users in the iOS version of my Capacitor App using AppTransaction.shared in a  Capacitor plugin I wrote. It works well. I able to keep my previous paid users free and offer subscriptions to new users only.

In Android, I understand one can query past purchases using BillingClient.queryPurchases()? Is it possible using the Revenucat Capacitor Purchase Plugin to access this value with Revenuecat?  Currently I identify new users using Firebase Remote Config and “first_user” date, but this is not always accurate when a user updates their device or deletes the App.

 

7 replies

sharif
Rank
Userlevel 5
Badge +9

Hey @michael-sozanski,

Unfortunately BillingClient doesn’t have an equivalent API for StoreKit’s originalApplicationVersion or originalPurchaseDate. RevenueCat tries to abstract away the underlying details of the device APIs so we don’t expose a BillingClient instance. However, we do expose originalApplicationVersion and originalPurchaseDate so you don’t have to use AppTransaction if that’s all you need from StoreKit. Those properties are null on Android since no equivalent exists there.

Sharif
M
Badge +6

Thanks for clarifying. Unfortunately, getting originalApplicationVersion and originalPurchaseDate thru Revenuecat didn’t work consistantly for me when users had deleted and reinstalled the App or moved it to a new device. Using AppTransaction.shared with my plugin allows me to access the version earlier in the startup process and works when a user deletes, reinstalls etc.

Maybe I am missing something in Revenuecat.

sharif
Rank
Userlevel 5
Badge +9

@michael-sozanski it depends on the testing flow you’re doing, but those values require RevenueCat to have the receipt on our servers. If you delete and reinstall the app then you’ll likely have a new user record in RevenueCat without the receipt, so those values won’t be filled in. Only after calling syncPurchases, restorePurchases, making a purchase, or logging in will those values be filled in again. It sounds like AppTransaction is reading the receipt locally which is why that works. We do expose a local receipt parser that can be used for this but unfortunately it’s not available on React Native yet. I’d say go ahead and continue using AppTransaction if it works for your use case.

Sharif
M
Badge +6

Thanks. AppTransaction.shared is working pretty well so far. I will look at the local receipt parser (not using React, just javascript and Capacitor).

Interesting issue came up when using Revenuecats originalApplicationVersion. A user is showing an originalApplicationVersion of “6” but the App has never been above v3.1.1 and a 6 is not present in any version ever released. All versions are X.Y.Z, never a single number. 

sharif
Rank
Userlevel 5
Badge +9

@michael-sozanski Apple has changed the name of the property in their new StoreKit API but this property stands for the build version, not the version you see in the store. So 6 is the build number. More info here: https://developer.apple.com/documentation/storekit/apptransaction/3954447-originalappversion If you don’t want to use the build number, you can check the original purchase date instead: https://www.revenuecat.com/reference/subscribers#:~:text=that%20user%20installed.-,original_purchase_date,-Only%20available%20on

Sharif
M
Badge +6

Yes, I knew it was the build number and I deal with that in my plugin. I just convert them to X.Y format in my AppTransaction.shared plugin code to compare versions based on X.Y only. If my build is 2.9.98 and I’m comparing to build 3.0.1, I convert and just compare 3.0 and 2.9 to avoid problems. (My subscription version is > 3.0)

There is no single build number 6 in any of my build versions But Apple does allow a 1 digit CFBundleVersion:

From Apple Developer Site:

You can also abbreviate the build version by using only one or two integers, where missing integers in the format are interpreted as zeros. For example, 0 specifies 0.0.0, 10 specifies 10.0.0, and 10.5 specifies 10.5.0.

 

So a 6 shouldn't be seen, it should be 6.0.0 I’m assuming.  An unsolved mystery. 

sharif
Rank
Userlevel 5
Badge +9

Hello,

In that case I can take a quick peek at the receipt for you? I can check if the receipt contains that unexpected version number or if it’s something else, just open a support ticket so we don’t share sensitive user info here. 

Sharif

Reply


Terms & ConditionsCookie settings