How to Avoid App Store Fees Without Getting Your App Rejected

There are two legitimate ways to avoid app store fees. Apple's Small Business Program cuts commission from 30% to 15% for developers under $1,000,000 in annual App Store proceeds, and routing payment through an external checkout removes Apple's cut entirely, but only when that checkout is surfaced the way Guideline 3.2.1 actually allows, not through any convenient webview.

Why Apple and Google Take Up to 30 Percent of Every Transaction

Apple and Google built in-app purchases as a toll on every transaction, not a fee for a specific service. Any app that sells digital goods, subscriptions, or membership access through Apple's or Google's payment system hands over 30% of that revenue by default, a rate that has stayed largely unchanged since the App Store launched in 2008. For a subscription or donation-based app, that is not a rounding error. It is the difference between a sustainable model and one that quietly bleeds out.

This is what people mean by the Apple 30 percent cut in practice: it applies whether the transaction is a $2 tip or a $200 annual membership, and it applies again every time that subscription renews. Google Play mirrors the same structure on Android, though both platforms now offer a reduced 15% tier for smaller developers. For a founder weighing native in-app purchase against building something else, the commission is rarely the only cost, but it is usually the first one that shows up on a spreadsheet.

This matters more, not less, for African founders right now. Africa's mobile payments market is forecast to reach US$198.8 billion in 2026, growing at roughly 22% a year, according to a 2026 market report from Research and Markets distributed via GlobeNewswire. As more commerce and giving moves onto phones, the architecture decision of who processes a payment, and who takes a cut of it, stops being a technical footnote and becomes a real line item in a business plan.

The Real Trade-off: External Checkouts Are Legal, but Not Automatically Compliant

Sending a user to a payment page outside the App Store is allowed under Apple's own rules, but how you do it decides whether the app gets approved or rejected. App Store Guideline 3.2.1 is the specific rule at issue: it permits certain apps to link out to external purchasing, but the link has to be presented as what it is, a clear exit from the app, not a disguised checkout wrapped in an in-app browser that behaves like a native payment sheet. Apple has rejected apps for the second pattern even when the first would have sailed through review.

This is the part most generic guides skip. Apple's Small Business Program is the cleanest legitimate discount available: it cuts the standard 30% commission to 15% for any developer or organisation with under $1,000,000 USD in prior-year App Store proceeds, applied automatically once you enrol. That covers most independent apps and small non-profits outright, and it requires no architecture change at all. The external-checkout route only makes sense once volume or margin makes even 15% too costly to absorb, and once you are prepared to build and maintain the compliance and engineering work that native in-app purchase would otherwise have handled for you.

We saw this trade-off directly on a membership app we built for a non-profit community organisation. The organisation could not afford to lose 15 to 30% of every donor contribution to standard in-app purchase commission, so instead of native IAP, the app opened an external checkout through a third-party payment processor, structured the way Guideline 3.2.1 requires rather than as a disguised in-app payment screen. The harder problem was technical, not legal: an externally processed payment does not automatically tell the app it succeeded. We solved it with a webhook listener built into the backend, the same underlying pattern we've covered in confirming a payment with a webhook instead of a client-side callback, so the member's status updated the moment they returned to the app, with no manual refresh.

What to Ask Your Developer Before You Try This

Building a compliant external checkout is worth the engineering investment for subscription apps, membership organisations deciding whether to build or buy their app, and donation-based non-profits with enough volume that even a 15% commission adds up to real money over a year. It is usually not worth it for an app with occasional, low-value purchases, where the cost of building and maintaining a compliant checkout and reconciliation system will exceed whatever commission you save.

Before committing to it, ask a developer three things: how exactly the external checkout will be surfaced so it satisfies Guideline 3.2.1 rather than risking rejection, who owns the webhook reliability and retry logic if the payment processor's callback fails or arrives late, and how refunds and disputes get reconciled between the external processor and the app's own records. This is exactly the kind of custom backend and payment architecture we scope in our custom software development work, because the parts that go wrong are rarely the checkout page itself, they are the handoff back into the app.

Avoiding app store fees is a legitimate, well-documented option, not a loophole, but it only works when the compliance detail is right and the engineering behind the handoff is solid. Founders running small or early-stage apps are usually better off simply enrolling in the Small Business Program and keeping native in-app purchase. Founders running a subscription, donation, or membership app with meaningful volume have a real case for building a compliant external checkout instead, provided they budget for the webhook and reconciliation work it requires, not just the checkout page itself. Get the architecture right once and it holds as the organisation scales; get it wrong and it either fails compliance review or fails the member silently at the worst moment.

Questions about avoiding app store fees

Can you legally avoid Apple's 30% in-app purchase fee?

Yes. Apple's Small Business Program reduces the commission from 30% to 15% for developers with under $1,000,000 in prior year App Store proceeds, and apps that process payment through a compliant external checkout instead of native in-app purchase pay no Apple commission on those transactions at all.

Does Apple allow a webview or in-app link straight to an external payment page?

Not automatically. Guideline 3.2.1 permits linking to an external checkout only when that link is presented as a genuine exit from the app, not disguised inside a webview that behaves like a native payment screen. Apple has rejected apps for the second pattern even when the first would have been approved.

What is Apple's Reader app exemption, and does it apply to every app?

No. The Reader exemption lets apps like news, magazine, and streaming services link out to an external site to manage an account or subscription without triggering in-app purchase rules. It does not extend automatically to donation, membership, or general commerce apps, which fall under separate guidelines.

Do non-profits still pay Apple's commission on in-app donations?

Not if approved. Apple states that approved non-profit organisations pay no fee on donations processed through Apple Pay inside their app. Organisations that are not part of that program can still avoid the standard cut, but only by collecting funds through a channel entirely outside the app itself.

How does Google Play's in-app billing fee compare to Apple's?

It is nearly identical. Google Play charges the same headline 30% rate as Apple, reduced to 15% for a developer's first $1 million in annual revenue under its own small business tier. Google has generally allowed more flexibility for linking out to external payment pages, though both platforms' rules keep shifting.

What changed for external payment links after the Epic v. Apple ruling?

The ruling required Apple to allow US apps to include links, buttons, or other calls to action pointing users to purchasing options outside the App Store, something Apple had previously blocked outright. Apple still sets conditions on how those links can be presented, and the exact rules vary by region.

What payment gateways do South African apps use for donations or payments processed outside the app store?

South African developers typically route external checkouts through local payment gateway infrastructure rather than global defaults, since local providers handle EFT, card rails, and Rand settlement more reliably. The right choice depends on transaction volume, currency mix, and whether the app also serves users elsewhere in Africa.

How do you make an externally processed payment feel "native" in the app afterward?

With a webhook. In a non-profit membership app we built, the mobile app passed a hidden user ID into the external checkout URL, and when payment cleared, the payment processor fired a webhook back to the backend, which matched that ID and upgraded the member's status the moment they returned to the app.