Downgrading using prorationMode: DEFERRED still doesn't work
Closed this issue · 7 comments
- I have updated Purchases SDK to the latest version
- I have read the Contribution Guidelines
- I have searched the Community
- I have read docs.revenuecat.com
- I have searched for existing Github issues
Describe the bug
A clear and concise description of what the bug is. The more detail you can provide the faster our team will be able to triage and resolve the issue.
Do not remove any of the steps from the template below. If a step is not applicable to your issue, please leave that step empty.
- Environment
- Platform: Android
- SDK version: 2.4.0
- OS + version: Android 12.0
- XCode/Android Studio version: Android Studio Bumblebee
- Framework (Cordova, Ionic, Ionic Native, etc): Cordova
- Framework version: 11.0.0
- How widespread is the issue. Percentage of devices affected. (Unkown)
- Debug logs that reproduce the issue
- Steps to reproduce, with a description of expected vs. actual behavior
- Make initial purchase with purchasePackage on android
- After that do downgrade by passing oldSku and DEFFERRED as the prorationMode
- The purchasePackage returns success but webhook with BILLING_ERROR is received as cancelation reason
- No INITIAL_PURCHASE event is received from the webhook
As the title says downgrade using DEFFERRED prorationMode still doesn't work, after the fix for this issue #65 now the purchasePackage it succeeds but the webhook sends this:
First a webhook with type: "CANCELLATION" is received which is ok as the user decided to cancel and the subscription would expire later, but in the same data I see this:
cancel_reason: "BILLING_ERROR"
When i was purchasing the package (downgrading with prorationMode: DEFERRED) the downgrade went through it didn't return any errors.
Normally after that I've received another webhook with:
type: "EXPIRATION"
but it also said that the expiration reason was because of billing error:
expiration_reason: "BILLING_ERROR"
After that I didn't receive any webhook that a INITIAL_PURCHASE was done.
- Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)
Additional context
Add any other context about the problem here.
Purchasing, Upgrading and Downgrading are basic flows of the IAP and also having DEFERRED mode where the next downgraded subscription starts only after the current expires its a very common flow.
Is this because of:
If so why was #65 fixed if DEFERRED or any other prorationMode apart from IMMEDIATE_WITH_TIME_PRORATION isn't supported in RevenueCat?
As I said DEFERRED is as common as IMMEDIATE_WITH_TIME_PRORATION is, so supporting it's a must.
Hey @angjelkom, thanks for such a detailed report! I've sent this ticket to the support team and will report back here once I have more info...
This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!
hey @angjelkom sorry for the bot. Still working with the support team on this for you..
@angjelkom, it sounds like we don't support the DEFERRED proration mode, which is why you're not receiving the proper webhooks. I can see the confusion around our support, given that we shipped a fix for this scenario... I'm gathering more information on why we don't support it and will report back here when I have more info.
@beylmk I understand, but supporting upgrade and downgrade it's a standard feature of the In-app purchase, it's not some unique platform feature, and downgrading a subscription by canceling and only subscribing to the downgraded subscription after the canceled subscription expires it's a very common option (which is what the DEFERRED proration mode stands for), in fact most of the apps with in-app purchase have such downgrade options, so not having this supported after 4 years it's a bit surprising and disappointing.
Hopefully at some point in future will be supported.
Hey @angjelkom -- I totally understand the frustration here. I believe we defaulted to the IMMEDIATE_WITH_TIME_PRORATION because we can't detect the proration mode on the server-side, and it was the most common. But I don't see why we can't pass that info from the SDK. I've created a ticket to investigate supporting this, and will keep you posted here on any progress.
And just to clarify -- the purchase will go through and the user will be charged as expected. We just currently won't trigger proper webhooks or report revenue correctly in any proration mode besides IMMEDIATE_WITH_TIME_PRORATION. I understand that's a crucial part of the flow as well, but just wanted to be clear...
This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!