Skip to main content
Solved

Upgrading through a workflow-backed paywall creates a second Play subscription instead of replacing the old one

  • August 19, 2026
  • 3 replies
  • 26 views

Forum|alt.badge.img

If your Paywalls v2 paywall is served through a workflow, the dashboard's play_store_product_change_mode setting gets silently dropped. WorkflowScreenMapper rebuilds the paywall's component data from the workflow payload and hardcodes productChangeConfig to null, so ProductChangeCalculator never runs and the purchase goes out with no oldProductId.

End result: an existing subscriber who taps a different tier doesn't get upgraded — they end up with two concurrent Google Play subscriptions, both billed, with no error or warning anywhere. onPurchaseCompleted fires like nothing went wrong.

Filed with full repro steps, logs, and the disassembly behind the root cause here:
👉 https://github.com/RevenueCat/purchases-android/issues/4002

Posting here too because we couldn't find any dashboard or API way to opt an offering out of the workflow path, and setPurchaseLogic is rejected under the default purchasesAreCompletedBy = REVENUECAT (SDK logs a warning and ignores it). If anyone has found a supported workaround short of taking over billing entirely with MY_APP, we'd love to hear it.

Related earlier thread with the same symptom class — an RC engineer confirmed there that paywall-driven plan changes were "not working as expected with Paywalls v2" (not workflow-specific, but the same category of breakage):
https://community.revenuecat.com/sdks-51/subscription-product-change-issue-6244

Best answer by matt-heaney

Hey ​@Dion Chang,

 

As an update on the above, the team has identified the issue and deployed a fix. This is included in version 10.18.0 of the Android SDK, which is available now (release notes: here)

 

Please can I ask you to update to this version in your app and confirm if this resolves the issue?

 

If you see any further issues, or if you have any additional questions about this fix, please let me know!

 

Thanks,

3 replies

matt-heaney
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • August 19, 2026

Hey ​@Dion Chang,

Thank you for the post. Matt from RevenueCat here!

I’ve raised this internally, and the team is currently investigating this. I’ll keep you fully in the loop with the investigation and any next steps.

Thanks again for raising this!


matt-heaney
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • Answer
  • August 20, 2026

Hey ​@Dion Chang,

 

As an update on the above, the team has identified the issue and deployed a fix. This is included in version 10.18.0 of the Android SDK, which is available now (release notes: here)

 

Please can I ask you to update to this version in your app and confirm if this resolves the issue?

 

If you see any further issues, or if you have any additional questions about this fix, please let me know!

 

Thanks,


Forum|alt.badge.img
  • Author
  • New Member
  • August 20, 2026

Hey @matt-heaney,

Confirming per your ask: we updated to 10.18.0 and verified it — an upgrade purchase now correctly logs Detected upgrade, and the parallel-subscription issue is gone on our end. We've since moved to 10.18.1 as well, no regressions there either. Thanks for turning this around so fast.

For context on our side: we caught this during our own license/subscription-flow testing, not from a live incident, so it hadn't seriously affected our users yet.

One thing I'd like to flag back to the team, separate from our own case: this failure mode is completely silent — no error, no crash, onPurchaseCompleted fires like nothing's wrong. We only caught it because we happened to be testing that exact upgrade path. I'd guess most teams on workflow-backed paywalls wouldn't notice until a user complained about being double-charged, and we have no way to know how many others hit this before 10.18.0. Given that, I'd strongly encourage RevenueCat to proactively reach out to affected developers rather than leaving it as a release note someone might scroll past — a dashboard banner, targeted email, whatever actually reaches people. A silent billing bug feels like it deserves an active heads-up.

Thanks again for the fix — closing this out on our end. 🙏