5

I have an Android app offering auto-renewing subscriptions via In-App Billing, using https://developer.android.com/google/play/billing/billing_library.html.

I'm using a lightly modified BillingManager.java from https://github.com/googlesamples/android-play-billing/ to help with purchase management.

Previously, prior to release (around 4-8 weeks ago), whenever a subscription trial ended and the subscription auto-renewed, I would continue to receive a corresponding Purchase object in the purchases lists upon querying purchases:

PurchasesResult subscriptionResult = mBillingClient.queryPurchases(SkuType.SUBS);
List<Purchase> list = purchasesResult.getPurchasesList();

(see queryPurchases here)

The OrderID had an incremented counter value appended according to the number of renewals that had occurred since the original order (as described under Subscription Order Numbers here).

In the last few days, it seems that whenever a customer's subscription converts to paid from trial, or renews subsequently, queryPurchases returns zero Purchases thereafter. I expect to receive one Purchase object for users with an active subscription (and was getting this during testing a while back - I have the data in my db to confirm it.)

As a result, the app no longer calls our backend server to update the subscription validity and users are denied access to functionality for which they have been charged - not great.

I can view the customer's order (with incremented OrderID) on Google Play Console and the subscription shows as valid (and is not cancelled) and a purchase token is available and can be validated.

Does anyone have any idea why would queryPurchases would stop returning a valid Purchase after the first renewal? (The Purchase is returned as expected prior to the renewal date.)

I'm using the current billing client library, as follows:

implementation 'com.android.billingclient:billing:1.0'

(As a workaround, I can fix this on the back-end by periodically rechecking all submitted purchase tokens, but I'd much prefer to do it on demand triggered by the app, which was working fine previously.)

stephent
  • 1,355
  • 15
  • 29
  • Were you able to solve this problem? I am seeing the same thing using testing account. I wonder if this is only a problem in testing. – Xi Wei Jan 10 '19 at 10:15
  • @XiWei no, I never found a solution to this. It's a problem in production. My workaround is to run a task on my backend server that periodically revalidates and updates the subscriptions. (Not ideal at all.) – stephent Jan 10 '19 at 18:10
  • I am just about to switch to the new library (from the old "v3") and am worried about problems like this. This seems like a huge problem. If I understand this correctly, old subscriptions that have renewed at least once are no longer returned with queryPurchases? – Flyview Jan 22 '19 at 19:04
  • @Flyview - correct, that's the problem I was seeing. I haven't delved back into it for a few months now - my server is doing its thing in the meantime... – stephent Jan 24 '19 at 21:38
  • @StephenT I finished switching over to BillingManager implementation in my own app and haven't had a problem with this so far, using the test subscriptions that automatically renew. They showed up in queryPurchases() response up until they were automatically or manually canceled. Will update here if things change or I start seeing issues. – Flyview Jan 27 '19 at 19:38
  • I also found a similar issue and one thing I have noticed is that it returns the purchase when you cancel the subscription but not after it renews. – Kartik Garasia May 03 '20 at 09:40

0 Answers0