Solved

Upgrade and trial not working properly with Android

  • 29 August 2022
  • 3 replies
  • 255 views
V
Badge +4

I'm currently using the revenucat webhook to manage the subscriptions (iOS works just fine) and while testing the Android purchase flow, I've been struggling with the following issues:

  • The trial webhook is not being received as the documentation says, it's just coming as a normal initial purchase, it does not have the property  "period_type": "TRIAL" but has the "period_type": "NORMAL" instead. 

This is making really hard to identify when a user is trialing or already has trialed.

I created the offer just as the documentation explains:

 

  • The other problem I've been facing is that a user is not doing an upgrade but another new subscription purchase is happening instead, why is this happening? example situation:
  1. Starts with a premium trial
  2. Decides to downgrade to a basic plan
  • Subscription should change to basic (even that the change is not being applied immediately, the plan should be changed (probably in the end of the trial with a renewal) and at least one PRODUCT_CHANGE event should be triggered. Why is this not happening? 

I'm already passing the oldSKU as a second param to the purchasePackage method.

const currentSubscription = await ApplePurchaseApi.getSubscriptionDetails()
const oldProductId = currentSubscription.activeSubscriptions[0]
// console.log(oldProductId)
// console.log(currentSubscription)
Purchases.purchasePackage(revenuePackage, {oldSKU: oldProductId})

Anyone to help?

 

Kind regards,

icon

Best answer by Jens 30 August 2022, 14:33

View original

3 replies

Jens
Rank
Userlevel 5
Badge +7

Hey @Vitor Guimaraes, I’ve looked into this briefly, and there are a few observations / questions. Firstly, these are all sandbox transactions and sandbox has all kinds of weirdnesses, especially due to the accelerated renewal rates. I can see that for those instances where we didn’t send a webhook with period_type TRIAL, the transaction also wasn’t a trial, but rather a renewal or re-subscription. 

There are a few things you can do to double check:

  • Firstly, when testing trials, make sure you are using new test Play Store accounts, since each test account is only eligible for one trial. 
  • Secondly, if you haven’t, I would recommend setting up Google server notifications with RevenueCat, so that we get a timely notification anytime something happens with the subscription. Especially with the accelerated renewal cycle in Sandbox, we might otherwise skip over periods

If these don’t resolve your issues, I would recommend reaching out directly to our support team so we can investigate more closely. 

V
Badge +4

hey @Jens thanks for your fast reply. About the trial, everything is fine and it was exactly the reason I was not getting the period_type = "TRIAL".

But I still not confident about publishing the app with this duplicate subscription behavior that is happening instead of the upgrade… Is there anything else I could check about it?

Kind regards,

 

Jens
Rank
Userlevel 5
Badge +7

Hey, I saw that you created a support ticket too, so I will respond with the same answer in both cases. I looked through your events and found exactly one instance where you were trying what you outlined here (downgrading). However, in reality, you didn’t actually downgrade, but create a new subscription, and here is why:

The original subscription was created on 2022-08-22T14:17:10.185+00:00. You attempted the downgrade on 2022-08-22T15:25:30.401+00:00. However: The original subscription was a monthly subscription. When sandbox testing on Google Play, monthly subscriptions renew every 5 minutes for a maximum of six times (see here). This means they are cancelled after 30 minutes. For that reason, the original subscription had already automatically been cancelled by Google by the time you attempted the downgrade.

For that reason, you received a new INITIAL_PURCHASE event for the new subscription (and also, we sent a CANCELLATION event for the original subscription on 2022-08-22T15:22:29.341+00:00. Please note that this event was quite a bit delayed, this is due to the fact that we don’t refresh receipts frequently enough to capture all of these accelerated renewals in a timely manner; this would improve if you set up Google server-to-server notifications as mentioned in my previous message).

Reply


Terms & ConditionsCookie settings