RevenueCat supports app-to-web checkout — here’s why you shouldn’t use it

There is a version of this post that would probably perform better on social. It would say app-to-web is finally here, the economics are obvious, the app stores have been weakened, and every subscription app should rush to move checkout to the browser

I do not think that version would be very helpful

The honest version is simpler: yes, we support app-to-web checkout. We support it today with RevenueCat Billing / Web Billing, we support it with Paddle, we support Stripe Billing as a web billing system that can sync into RevenueCat, and we support Stripe Managed Payments in private beta

The other honest part is the one fewer people want to say out loud: most apps probably should not do app-to-web checkout

Not because it is impossible. Not because it is non-compliant in every case. Not because the tooling is not real. But because the financial upside is often overstated, while the operational, conversion, support, and retention side effects are understated. If you’re a large app with meaningful leverage, sophisticated lifecycle marketing, strong experimentation capabilities, and enough margin pressure to justify the work, app-to-web can make sense. If you are not, there is a good chance you are trading a simple problem for a much messier one

First, what we actually support today

If you strip away the noise and just look at the platform, RevenueCat Web is now a real product category for us. It includes a Web SDK, Web Purchase Links, a Web Purchase Button to link out from in-app paywalls, Web Paywalls, Web Funnels for web-to-app flows, and Redemption Links that help tie an anonymous web purchase back to the correct app user

The app-to-web flow we promote is straightforward in concept. A user starts on a paywall in your app, taps through to a web checkout, completes the purchase there, then comes back to the app via deep link or redemption flow and gets access unlocked. We keep entitlements in sync across app and web once the purchase is recognized

That sounds clean on a diagram because, to be fair, it is fairly clean on a diagram

In practice, the capability picture depends heavily on which billing engine you choose

Billing optionWhat we support todayImportant caveat

RevenueCat Billing / Web BillingOur own web billing engine with Web SDK and Web Purchase Links support, plus hosted purchase flows, subscription lifecycle handling, and customer management portal supportIt uses Stripe as the payment processor underneath, but is a separate RevenueCat billing engine. Some limitations still apply, including localization gaps in some surfaces and country-specific billing-data limitations

Paddle BillingWe support importing Paddle purchases and support Paddle across Web SDK, Web Purchase Links, Web Paywalls, Web Funnels, and Redemption LinksPaddle-specific operational constraints still exist; for example, our Paddle integration does not currently support Paddle’s abandoned cart emails

Stripe BillingWe support importing external purchases from Stripe Billing and syncing entitlements back to the app Very soon, we’ll also support Web SDK, WPLs, Funnels, and Redemption LinksThe main caveat is “which Stripe path are you actually choosing?.” Stripe Billing, Stripe Checkout, and Stripe Managed Payments solve slightly different problems, so teams should be precise about the implementation path they want

Stripe Managed PaymentsWe support this through the Stripe Billing integration, with Stripe acting as merchant-of-record for eligible transactionsIt is currently a private beta / invite-only feature

That is the part I want to be very clear about, because ‘supports app-to-web’ can mean a few different things depending on what people hear. We do not just mean ‘you can hack a link into a button’. We mean there is now an actual product set for hosted web checkout, redemption, and entitlement sync. But it also does not mean every billing provider has identical maturity, identical feature coverage, or identical rollout status

There is another important nuance here. In the US, iOS developers are now permitted to guide users to web-based payment flows without additional Apple fees or restrictive design requirements following the Epic v. Apple ruling from early 2025. That’s in the US and on iOS only. For other platforms and other markets, app-to-web is sometimes possible, but always comes with additional fees, and reporting requirements. That means app-to-web is not a blanket ‘turn this on everywhere’ strategy. You need to make sure you control exactly who sees it and where

So why should most people not use app-to-web?

When people say ‘app-to-web’, what they often mean is ‘save 15% or 30% on store fees’. And what they often forget is that the fee is not the only thing that dictates how much money you take home at the end of the day

The first issue is the most obvious one:

• Conversion usually gets worse

Every additional step between intent and payment hurts. Sending someone out of an app, into a browser or hosted checkout, through another authentication context, into a billing form, then back into the app is simply more fragile than native in-app purchase. Even if the flow is well designed, you are introducing context switching, more points of abandonment, more places for attribution to break, and more opportunities for a user to decide they’ll do it later. You might recover margin on the users who complete checkout, but if enough of them fail to complete it, the math stops looking clever

This is one of those areas where teams can accidentally fool themselves. If you only look at completed payer margin, web checkout looks great. If you look at paywall visitor to activated subscriber, it can look much worse. And for most subscription apps, the second number is the one that matters

The second issue is more uncomfortable because it can make your retention chart look better for the wrong reason:

• People are often less aware of how to cancel web subscriptions

That can create the appearance of stronger retention or lower churn, but in many cases what you are really seeing is lower customer clarity. App store subscription management is not perfect, but users broadly understand where to go. The moment you split billing systems, some of your customers now manage on Apple, some on Google, some in Stripe, some in Paddle, some in RevenueCat Billing-backed web flows. That can absolutely reduce voluntary churn. It can also absolutely increase frustration, support load, refund requests, chargebacks, and a long tail of unhappy users who feel like billing became harder the moment they gave you money

In May of 2025, we launched a (much publicized) in-app purchase vs. web checkout experiment with an app we own. That experiment saw 6% fewer paying customers when we added web checkout. That same experiment currently has 2.7x (+170%!) more subscribers set to renew on web

Those subscribers aren’t set to renew because, by paying on the web, they enjoy the app much more than they would if they paid via in-app purchase. They’re set to renew because they’ve forgotten to opt out of renewal

And that brings us to the third issue:

• Chargebacks and disputes tend to become more material when you own more of the payment experience

App stores absorb a lot of mess for you. Once you move payment to the web, you get more control, but you also inherit more exposure. Tax handling, billing descriptor clarity, payment recovery behavior, lifecycle comms, cancellation UX, and support all become more consequential. Paddle and Stripe Managed Payments can help with the merchant-of-record and tax side for eligible flows, which is precisely why they exist, but that does not magically remove the conversion or support complexity of app-to-web. It just moves one painful category of operational burden off your plate

The fourth issue is the one small teams underestimate most:

• The savings are often not that dramatic once you include all costs

We do not charge extra for RevenueCat Web itself, but the payment rails still do. In the US you pay 2.9% + 30¢ for Stripe processing, plus optional Stripe Tax fees where relevant. For Stripe Billing, our docs cite the same transaction fee plus Stripe Billing fees of 0.7% of volume, again before any tax tooling you may need. So say you’re selling a weekly subscription of $5 — you’d effectively pay Stripe close to 9%. Add the fee for Managed Payments, and you’re getting awfully close to the 15% most developers pay

If you are on Apple’s Small Business Program and paying that 15%, that is where the simplistic ‘save 12 percentage points’ narrative starts to fall apart. Between processor fees, billing software fees, tax tooling, engineering time, experimentation time, support cost, revenue leakage from lower conversion, dispute loss, and the long tail of operating multiple billing systems, your net improvement can get very small very quickly. In some businesses it will still be worth it. In many, it will not

And even if it works in a narrow segment, the fifth issue remains:

• You are creating permanent complexity, not a temporary experiment

This is the part that almost nobody models properly

If you run an app-to-web experiment for three months and decide it was a bad idea, your web-billed users do not politely disappear. You still have to support them. You still have to honor their renewals, manage their cancellations, answer their billing questions, reconcile their subscription state, and maintain enough infrastructure so their access remains correct. Congratulations: your test is now a durable second billing stack

The app stores are opinionated, expensive, and frustrating. They are also operationally simple in ways people stop appreciating once they leave them

The hidden cost is organizational, not technical

Most discussions about app-to-web are framed as product or finance decisions. In reality, they are company decisions

You need product and growth to redesign the purchase journey. You need engineering to build routing, redemption, instrumentation, and edge-case handling. You need support to answer “Where do I cancel?” forever. You need lifecycle marketing to own the web renewal and churn experience. You need finance and ops to reason about taxes, disputes, reconciliations, and payout differences. You need legal or policy confidence on where you can and cannot show external payment paths. And you need analytics clean enough to tell whether the whole thing actually worked

That is a lot of machinery to spin up in order to maybe improve unit economics

This is why I think the average team should be much more conservative than the current conversation implies. 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 a lot of teams, the honest answer is no

When app-to-web probably does make sense

All this being said, there are real cases where I would absolutely consider using app-to-web

If you have a large US user base, high average revenue per paying user, meaningful paid acquisition economics, strong experimentation infrastructure, and enough support capacity to absorb billing fragmentation, then app-to-web can be rational. If you already have a serious web business, or if the web is strategically important beyond payments, it becomes even more attractive. If your app 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

Likewise, if merchant-of-record complexity is the blocker, the fact that Stripe Managed Payments now exists, is genuinely interesting. If you want the most integrated RevenueCat-native route, RevenueCat Billing / Web Billing is what we support most directly today. If Paddle fits your tax and merchant-of-record preferences better, our Paddle path is a very capable option

If this topic is top of mind for you, on Tuesday April 28 (the day before Stripe Sessions) we’re co-hosting The Web for Apps Opportunity in downtown San Francisco:

A full day event that includes talks by RevenueCat and Stripe on how, where, and when to use web payments for your app. ​The afternoon concludes with a private executive dinner at 54 Mint

Apply to attend here

So this is not me saying never do app-to-web. It is me saying do it for the right reasons, with open eyes

My actual recommendation

If you are curious about app-to-web, do not start by trying to replace in-app purchases broadly. Start by treating it like 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, 3 months, 12 months after the experiment ends. Assume your support burden will be higher than the first spreadsheet suggests. Assume that billing fragmentation will last longer than the experiment does. Assume fee savings will compress after you include everything

And if, after all of that, the economics still work out, great. You probably have a real business case

But most teams will arrive at a less exciting and more useful conclusion: app-to-web can work, but not well enough to justify everything that comes with it