Why App Store revenue looks lower than Stripe revenue

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Your App Store number looks smaller than your Stripe number for a simple reason: they're not measuring the same thing. Apple and Google report "proceeds" — your revenue after their platform commission is already deducted — while Stripe typically reports the full charge amount before its own, much smaller processing fee. Put a store payout next to a Stripe gross figure and you're comparing net to gross, which will always make mobile look like it's underperforming even when it isn't.

The core mechanic: net vs. gross

When someone subscribes through your iOS or Android app, Apple or Google collects the full price, keeps a commission, and pays you the rest. That remainder is what shows up in App Store Connect or the Play Console — it's already net of the platform's cut. There is no separate line item for "Apple's fee" in your payout; it's baked into the number before you ever see it.

Stripe works differently. When a customer pays $9.99 on your website, Stripe usually shows you the $9.99 charge as the gross transaction, then deducts its processing fee (commonly around 2.9% + 30¢, though you should always check the current published rate on Stripe's pricing page) either as a separate line in your payout or in your accounting feed. The number founders eyeball in the Stripe dashboard is closer to the sticker price than to the take-home amount.

So the "15-30% lower" gap most solo founders notice isn't a mobile performance problem. It's an apples-to-oranges problem: one channel's headline number is post-commission, the other's is pre-fee.

The commission rates behind the gap

These are publicly documented platform terms, not estimates:

• Standard commission: Apple and Google both take up to 30% of the transaction on their standard tier.
• Small Business Program (Apple) / equivalent reduced tiers (Google): developers earning under a published revenue threshold can qualify for a 15% rate instead of 30%. Check the current threshold and terms on Apple's or Google's developer sites, since they're occasionally revised.
• Subscriptions after year one: both stores drop the commission to 15% on a given subscriber's payments once that subscriber has been active for more than a year, regardless of program enrollment.
• Stripe's processing fee: roughly 2.9% + 30¢ per transaction for standard card payments in the US, again worth confirming against Stripe's current published pricing since it varies by country and payment method.

The gap between a 30% platform commission and a ~3% payment processing fee is the entire story. Nothing else needs to be invented to explain why store proceeds and Stripe gross diverge by double digits.

Why you can't compare proceeds to gross directly

Imagine two customers, each paying $9.99/month for the same product — one through your iOS app, one through your website checkout. If you look at "money that hit my bank account" for both, the App Store customer will appear to be worth roughly 70-85% of the Stripe customer, purely from where the commission was deducted. Nothing about that customer's value, engagement, or lifetime is actually different.

The trap is subtle because both numbers are technically "correct" — they're just correct answers to different questions. App Store proceeds answer "what did I get paid?" Stripe gross answers "what did the customer pay?" If you plot both series on the same revenue chart without adjusting for this, every month will show mobile revenue lagging web revenue by whatever the effective commission rate happens to be, and you'll draw the wrong conclusion about which channel is actually growing.

Here's what that looks like on a single $9.99/month price point, side by side:

Same price, same product, three very different "what you keep" numbers — none of them wrong, all of them describing a different stage of the money's journey.

How RevenueCat normalizes this

RevenueCat sits on top of App Store Connect and Play Console data and can report both gross revenue (the customer's charge, before Apple or Google's cut) and proceeds/net revenue (what you're actually paid) as separate metrics. That distinction matters because it lets you choose your basis deliberately instead of accidentally mixing the two. If you pull "revenue" from RevenueCat without checking which figure you're looking at, you can just as easily recreate the same mismatch when you bring it in next to Stripe.

This is exactly the kind of normalization problem that motivated building SoleOS's connectors for Stripe, RevenueCat, and the app stores — pulling both gross and net figures from each source so you can pick one convention and apply it everywhere, rather than eyeballing three dashboards that each default to a different basis.

How to compare apples-to-apples

Pick one of two conventions and stick to it across every channel:

1. Gross-of-fees, everywhere. Track what the customer paid — the sticker price times renewals — for both mobile and web. For mobile, this means using RevenueCat's or the store's gross revenue field, not the proceeds/payout figure. For Stripe, this is usually already what you see by default. This convention is best for comparing top-line growth and channel mix, since it isolates customer-facing pricing decisions from platform economics.

2. Net-of-fees, everywhere. Track what actually lands in your bank account after every cut — Apple/Google's commission on one side, Stripe's processing fee on the other. This convention is best for cash flow, runway, and profitability, since it's the number that actually funds your business.

What you should never do is mix them: gross from Stripe next to net (proceeds) from the App Store. That comparison is arithmetically guaranteed to make mobile look worse, independent of how mobile is actually doing.

The practical upshot for solo founders

If you're running a portfolio of apps across web and mobile, decide your convention once, label your dashboards accordingly, and don't re-litigate it every month when App Store proceeds look "off." A founder tracking MRR growth probably wants gross-of-fees so a $9.99 subscriber counts the same whether they came through Stripe or the App Store. A founder watching cash runway wants net-of-fees, because that's the number the bank statement agrees with. For more on setting that convention up once and keeping it consistent, see how to track revenue as a solo founder.

This guide was published by SoleOS, which unifies Stripe, RevenueCat, and app-store revenue into one view and lets you pick gross or net as your default basis. You don't need SoleOS or any tool for this, though — if you run one product on one channel, a spreadsheet with a single "commission %" column applied consistently will get you the same clean comparison.

Frequently asked questions

Is Apple "hiding" 15-30% of my revenue?

No. The money isn't hidden — it's disclosed in every developer agreement and shown as a commission line in App Store Connect's financial reports. What trips people up is that the headline proceeds number in the dashboard is already net of that commission, so if you compare it to a gross figure from elsewhere, it looks like a discrepancy rather than an expected deduction.

Does the 15% rate apply automatically after a year?

For subscriptions, yes — both Apple and Google reduce the commission to 15% on a given subscriber's billing once that subscriber has been continuously subscribed for more than one year, independent of the Small Business Program. The Small Business Program is a separate, revenue-threshold-based enrollment that can qualify you for 15% from day one. Check each platform's current developer terms for the exact mechanics, since thresholds and rules are occasionally updated.

Should I report gross or net revenue to myself (and to investors)?

Most founders track gross-of-fees for growth metrics like MRR and use net-of-fees for cash planning. If you have investors or advisors, tell them which basis you're using and hold it steady — a metric that quietly switches basis month to month will produce misleading trend lines even if every individual number was accurate.

Does this affect merchant-of-record platforms too?

Yes, in principle — any payment processor that takes a cut before remitting funds to you creates the same gross-vs-net question, just usually at a much smaller percentage than app store commissions. If you're weighing a merchant-of-record setup for your web checkout, see merchant of record for indie SaaS for how those fee structures compare to running Stripe directly.

Where do I see both numbers without doing the math by hand?

RevenueCat's dashboard exposes both gross and proceeds fields per app, which is a good starting point. If you want the mobile and web numbers reconciled side by side on a single basis, that's the specific gap SoleOS's metrics view is built to close — though for a single app on a single platform, RevenueCat's own reporting is usually enough on its own.