The Infrastructure Is Ready — The Business Case Is Not
App-to-web checkout has moved from theory to production. RevenueCat now ships a full web billing product suite — Web SDK, purchase links, hosted paywalls, redemption flows, and entitlement sync across RevenueCat Billing, Paddle, and Stripe. The tooling is real. The regulatory path exists in the US following the Epic v. Apple ruling. The promise is straightforward: route users to a web payment flow, avoid platform fees, improve margin.
Yet the honest assessment from teams operating this infrastructure at scale is the opposite of what social narratives suggest: most subscription apps should not adopt app-to-web checkout. Not because it is impossible or non-compliant, but because the financial upside is overstated and the operational side effects are understated.
The core issue is conversion friction. Every additional step between intent and payment degrades outcomes. Sending a user out of an app, into a browser, through another authentication context, into a billing form, then back via deep link or redemption flow introduces more abandonment points, more attribution gaps, and more opportunities for the user to defer the decision. Even well-designed flows hurt conversion-rate. If you measure only completed payer margin, web checkout looks attractive. If you measure paywall visitor to activated subscriber, the picture deteriorates quickly. For most subscription apps, the second metric is the one that matters.
The second issue is retention opacity. App store subscription management is clunky, but users understand where to go. The moment billing fragments across Apple, Google, Stripe, Paddle, and web portals, some customers lose clarity on how to cancel. This can superficially improve retention metrics — not because the product experience improved, but because voluntary churn becomes harder. One internal experiment saw 6% fewer paying customers when web checkout was introduced, but 170% more subscribers set to renew on web. Those subscribers are not renewing because web payment improved their experience. They are renewing because they forgot to opt out.
The third issue is dispute exposure. App stores absorb chargebacks, tax complexity, billing descriptor confusion, and payment recovery friction. Once payment moves to the web, the app owner inherits that exposure. Tax handling, lifecycle comms, cancellation UX, and support all become more consequential. Merchant-of-record services like Stripe Managed Payments or Paddle mitigate some of this, but they do not eliminate the conversion-rate-optimization-cro or support complexity. They just shift one painful category of operational burden off the plate.
The fourth issue is net margin compression. Payment processors charge 2.9% plus 30 cents per transaction in the US. Stripe Billing adds 0.7% of volume. Tax tooling and managed payment services add further fees. For a weekly $5 subscription, effective processing fees approach 9%. If the app qualifies for Apple's Small Business Program and pays 15%, the supposed 12-point margin improvement collapses once processor fees, billing software, engineering time, experimentation cost, support load, and revenue leakage from lower conversion are included. In some businesses the math still works. In many, it does not.
The fifth issue is permanent complexity. If an app-to-web experiment runs for three months and the team decides it was a mistake, the web-billed users do not disappear. The app still must support renewals, cancellations, billing questions, subscription state reconciliation, and infrastructure maintenance. The experiment becomes a durable second billing stack. This is an organizational decision, not a technical one. It requires product, growth, engineering, support, lifecycle marketing, finance, ops, legal, and analytics alignment. That is significant machinery to spin up in order to maybe improve unit economics.
When App-to-Web Actually Makes Sense
There are real cases where app-to-web is rational. If an app has a large US user base, high lifetime-value per paying user, strong paid acquisition economics, robust experimentation infrastructure, and enough support capacity to absorb billing fragmentation, the trade-off can work. If the app already operates a serious web business or if the category naturally supports account-based behavior and cross-platform usage, users may tolerate the extra checkout friction better than they would in a lightweight impulse-purchase app.
The right approach is to treat app-to-web as a constrained experiment with a proper hypothesis. Pick a narrow, eligible segment. Measure full-funnel conversion, not just net revenue on completed purchases. Track refunds, disputes, support tickets, cancellation confusion, and cohort quality. Check back one month, three months, twelve months after the experiment ends. Assume support burden will be higher than the first spreadsheet suggests. Assume billing fragmentation will last longer than the experiment does. Assume fee savings will compress after including everything. If the economics still work after all of that, there is a real business case. Most teams will conclude that app-to-web can work, but not well enough to justify everything that comes with it.
Smarter Paywall Logic Delivers Cleaner Wins
While app-to-web checkout generates complexity, paywall personalization infrastructure is delivering tangible conversion improvements without the billing fragmentation.
RevenueCat's new Paywall Rules feature enables dynamic customization of paywall component visibility based on user behavior and custom variables — without requiring app releases. Developers can now show or hide components conditionally: display a trial timeline only when a trial is available, swap package options based on custom variables, tailor messaging for promotional offers. Rules are evaluated at runtime based on offer type (intro, promo, multiphase), package identifier, or custom variables. A single paywall can now handle multiple scenarios that previously required maintaining separate paywall variants.
This approach improves conversion-rate by reducing context and increasing relevance, but it does so within the existing billing stack. There is no payment flow fragmentation, no second support burden, no dispute exposure shift. The complexity remains in the presentation layer, not in the operational layer.
A related case study illustrates the strategic tension between hard paywalls and freemium models. One growth advisor worked with a client to implement a multi-step paywall: the product is free, but users are offered a seven-day trial of the premium version. After the trial, they are prompted to subscribe to maintain maximum value. Combined with pricing and packaging optimizations, this shift resulted in a 75% increase in LTV per user. The business moved from excluding users with a hard paywall to growing more quickly through organic acquisition. The key distinction is that this approach expanded the top of the funnel while keeping the billing experience intact. Conversion improved through better product positioning and trial mechanics, not by fragmenting payment infrastructure.
Unified Revenue Tracking Solves a Different Blind Spot
For apps monetizing through a mix of ads and in-app purchases, understanding total revenue has historically required stitching together dashboards, exporting CSVs, and building custom pipelines. The result is a blind spot in decision-making: teams make slow decisions based on incomplete LTV metrics and guesswork.
RevenueCat's new In-App Ad Revenue Tracking feature addresses this by ingesting ad revenue events in real time alongside purchase data. Ad revenue now flows into the main Revenue Chart. Realized lifetime-value incorporates ad revenue, giving a complete picture of cohort value. A dedicated Ads section tracks ARPDAU (Ad Users), Ad Monetized Users, Ad Impressions, Fill Rate, Ad RPM, CTR, and eCPM. The Customer Details page includes a dedicated Ads tab showing individual user profiles with Total Ad Revenue, Impressions, Clicks, Fill Rate, CTR, eCPM, and impression timestamps.
Integration is straightforward. For Google AdMob, replace standard loading calls with the RevenueCat SDK's loadAndTrack methods. For other mediation platforms that provide impression-level revenue data — AppLovin MAX, ironSource, Unity Ads — call RevenueCat's AdTracker methods in ad SDK callbacks. It is the same reliable RevenueCat SDK under the hood. Because RevenueCat uses real-time SDK data and mediation platforms use post-processed, fraud-filtered data, slight discrepancies are expected and documented.
This feature does not replace mediation platforms or MMPs. It adds subscription context to ad data. Fast-follows will include blended ARPDAU across all users. Future updates will introduce predicted LTV with ads and analytics showing how ad exposure impacts subscription conversion and churn. For apps monetizing with ads, this consolidates the full revenue picture in one place without introducing billing fragmentation.
The Pattern: Reduce Friction, Avoid Fragmentation
The common thread across these developments is that the highest-leverage improvements in app-store-optimization-aso and monetization come from reducing friction and avoiding fragmentation, not from chasing marginal fee savings at the cost of operational complexity.
Dynamic paywall logic improves conversion by increasing relevance without introducing billing fragmentation. Multi-step paywalls expand the top of the funnel by lowering the entry barrier while keeping the payment experience intact. Unified ad revenue tracking provides complete LTV visibility without requiring teams to operate multiple billing stacks.
App-to-web checkout, by contrast, trades a simple problem for a messier one. The infrastructure is production-ready. The regulatory environment has opened in the US. The tooling exists. But for most subscription apps, the financial upside is smaller than it appears, and the operational burden is larger. The relevant question is not "Can I avoid app store fees?" The question is: "Am I capable of operating a better billing business than Apple or Google for this segment of users?" For most teams, the honest answer is no.
The lesson for practitioners is to prioritize interventions that improve conversion and retention through better product positioning, smarter presentation logic, and cleaner data — before introducing billing fragmentation that creates permanent complexity.