App stores charge 15–30%. Stripe charges roughly 3%. That gap is real, and so is the catch. Here's what developers actually pay when selling digital goods through Stripe, Apple, and Google, and where the choice between them actually exists.
On a $10/month subscription with 10,000 subscribers, the difference between 30% and 3% is roughly $27,000 per month. That's the number that makes developers look twice at Stripe. The gap is real. The question is whether a given developer is in a position to capture it.
Most mobile developers aren't. Not entirely. Where that line sits, and what the math looks like on each side, is what the scenarios section below works through.
Stripe's base fee for card transactions: 2.9% + $0.30. On a $10 subscription, that's $0.59 per transaction. For recurring billing, Stripe Billing adds 0.5% (Starter plan, volumes under $80k/month). The effective fee per $10 subscription: roughly $0.64.
That's not the final number for every developer. The charges that apply to digital goods sold internationally:
For a US developer billing a German subscriber in EUR, the effective Stripe rate on a $10 subscription runs closer to 6.5%. Still well below 15%, but not the headline 3%.
Stripe publishes all of these rates. There are no revenue share arrangements, no annual fees, no per-seat pricing. The total is the sum of the applicable modifiers.
This is the part most comparisons skip.
For in-app purchases and subscriptions that unlock content or features inside an iOS or Android app, Apple and Google require their own billing systems. Using Stripe for in-app content violates store policies. This covers the majority of consumer mobile apps.
Apple relaxed some of its anti-steering rules in the US after the Epic v. Apple litigation, allowing developers to link to external purchase pages. That's a link out, not a native checkout. Conversion drops, the rules are still contested, and building a core billing strategy around the loophole carries real operational risk.
Where Stripe is a legitimate option:
Spotify built the hybrid model at scale. The in-app subscription is priced higher to absorb Apple's commission; the web subscription is priced lower to convert price-sensitive users outside the store. New iOS subscribers who subscribe through the app pay more than subscribers who found the web checkout first. The economics are the same product, two different price points, deliberately set.
Running a hybrid checkout has real costs: a checkout page to build and maintain, lower conversion than a native paywall, ongoing questions about platform parity as policies shift. At small scale, the engineering rarely pencils out. At $500k+ ARR in web-eligible subscriptions, the math changes significantly.
Same product: $10/month subscription, 10,000 active subscribers, $1.2M gross annual revenue.
App Store at 30%
Apple takes $360,000. Developer keeps $840,000.
App Store at 15% (Small Business Program or post-year-one subscribers)
Apple takes $180,000. Developer keeps $1,020,000.
Stripe, US subscribers, web subscription
Stripe takes roughly $77,000 (2.9% + $0.30 + 0.5% Billing). Developer keeps approximately $1,123,000.
The gap between the 15% App Store tier and Stripe is around $103,000/year on $1.2M revenue. That gap funds meaningful engineering investment in a web checkout. It also explains why any subscription app operating above a certain scale runs both channels.
One friction Stripe doesn't handle by default: digital services tax.
App stores collect and remit tax on your behalf. Stripe doesn't, unless you turn on Stripe Tax.
Physical goods have relatively clear tax rules. Digital goods sold cross-border trigger specific obligations: EU VAT (via OSS), UK VAT, Australian GST, and an expanding set of national digital services taxes. A developer selling a $9.99 subscription to a French buyer owes 20% VAT on that transaction. Many don't find out until they receive a compliance notice.
Stripe Tax automates calculation, collection, and reporting for an additional 0.5% per transaction. For developers selling direct to consumers in multiple jurisdictions, it's effectively mandatory. Factor it into the Stripe cost column before running the comparison.
Tools like Mirava help teams understand what comparable apps charge in a given market before these cost layers enter the calculation: the market rate, the headroom to price given the effective margin after fees and tax, and how the competitive set is positioned.
Want the pricing picture before you set a number?
Mirava shows what apps like yours are charging across your key markets, before you commit to a tier structure. Try Mirava →
No. Apple requires all purchases that unlock content or features inside an iOS app to use Apple's billing system. Using Stripe for in-app content violates App Store Review Guidelines. Stripe is available only for purchases that happen outside the app: web checkouts, desktop billing, and SaaS subscriptions where the mobile app is a companion client.
One-time purchases: 2.9% + $0.30 per transaction (standard US rate). Recurring subscriptions via Stripe Billing: the same transaction fee plus 0.5% on the Starter plan (under $80k/month volume). Both rates increase with international cards (+1.5%) and currency conversion (+1%).
Google Play charges 15% on the first $1M of annual developer earnings, then 30% above that. Stripe charges roughly 3–4% depending on transaction size and modifiers. On a $10/month subscription, Google Play takes $1.50 at 15%; Stripe takes approximately $0.64. The same constraint applies: Stripe is not available for in-app content purchased through an Android app.
Not by default. Stripe Tax (0.5% per transaction) automates VAT calculation, collection, and reporting for digital goods across the EU, UK, and other applicable jurisdictions. Without it, the developer is responsible for determining and remitting the correct rate per country. App stores handle this on your behalf, which is one real operational advantage of in-app billing for developers without a dedicated finance function.
At low revenue, the engineering cost outweighs the fee savings. The inflection point varies, but $500k+ in web-eligible ARR is a reasonable threshold to start the analysis. The strongest candidates: SaaS tools with a mobile companion app, productivity apps with a desktop-first use case, and consumer apps with a meaningful portion of price-sensitive users who would convert on web but not at a higher in-app price.
App store commissions are the cost of using the distribution and billing infrastructure Apple and Google built. For most consumer apps, that trade makes sense. The useful question is how much subscription volume could realistically move through a web checkout, and whether the margin recaptured justifies building and maintaining one. Spotify and Netflix run both. Below a certain scale, 15% is just the cost of shipping on iOS. Worth understanding, not worth rebuilding around.
