App Store & Google Play Rejection: Stripe vs In-App Purchase, Explained for iOS and Android

The Rejection Every App Developer Eventually Sees

If you've landed here, you've probably just received a message like this from Apple:

Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app requires users to make a purchase or subscribe using payment mechanisms other than in-app purchase, which is not appropriate for the App Store. Specifically, your app features an external payment system (Stripe) to unlock digital content or features.

Or, if you're publishing on Android, its close cousin from Google Play:

Policy Violation: In-App Billing Requirement
Apps that sell digital goods or services must use Google Play's billing system.

These are two versions of the exact same problem. Both Apple and Google require that digital purchases made inside an app go through their own native billing system — not Stripe, not PayPal, not a website checkout. It's one of the most common rejection reasons on both stores, and it catches teams off guard constantly, especially those who built one shared payment flow with Stripe because it was faster, cheaper per transaction, or already working on the web.

What the Two Policies Actually Say

On iOS, Guideline 3.1.1 requires that any feature or functionality unlocked in the app — subscriptions, in-app currency, premium content, extra levels, or a full version upgrade — go through Apple's In-App Purchase (IAP) system, built on the StoreKit framework.

On Android, Google Play's Payments policy requires the same category of purchase digital items, subscription services, app functionality or content, cloud software to go through the Google Play Billing Library. Even just linking users to a website for payment, without processing it inside the app, is treated as a violation.

Neither platform is flexible about this for the standard case. Apps are not allowed to use their own payment mechanisms, license keys, QR codes, or third-party processors for that category of purchase, on either store.

Digital Goods vs. Physical Goods: The Line That Matters on Both Platforms

The single most important distinction identical on iOS and Android is whether what you're selling is digital (consumed inside the app) or physical/real-world (consumed outside the app). Get this classification right and the rest of the fix is straightforward.

If your app mixes both types for example, a fitness app selling branded merchandise and a premium subscription you need both payment paths running side by side, kept clearly separate: digital purchases through native billing, physical goods through Stripe or another processor.

Why Both Platforms Are So Strict About This

Beyond the commission angle, both companies frame this as a consistency and trust issue: users expect a familiar purchase flow biometric confirmation, a receipt tied to their account, purchases automatically restorable across devices. A custom Stripe checkout breaks that consistency on either platform, and both review teams treat an external payment form for digital content as a policy violation regardless of how well it's built.

It's worth knowing that this landscape has been shifting recent antitrust rulings have opened narrow exceptions, particularly for apps on U.S. storefronts, where external payment links are now permitted in limited circumstances on both platforms. But outside those specific carve-outs, and in most regions globally, the core rule still applies: digital goods sold inside the app go through native billing.

How to Actually Fix It On Both Platforms

1. 1. Identify the exact flagged purchase. The rejection message usually names the specific product a subscription, an upgrade, a specific plan. Start there, not with your entire payment system.
2. 2. Confirm it's genuinely digital. If it unlocks something inside the app, it needs native billing on that platform. If it results in something delivered or used outside the app, it can likely stay on Stripe.
3. 3. Set up matching products in both consoles. Create in-app purchase products in App Store Connect (consumable, non-consumable, or subscription) and equivalent products in the Google Play Console.
4. 4. Implement the native billing framework on each platform. StoreKit for iOS, the Play Billing Library for Android so the transaction runs through each platform's own system, not a web checkout.
5. 5. Remove the external payment trigger for that content. Any button, link, or flow that lets a user pay outside the app for that specific digital item needs to go, on both platforms.
6. 6. Resubmit with a clear note. Explain plainly what changed for example, that the flagged subscription now runs entirely through native billing.

The Easier Way: One Payment Layer for Both Platforms

Implementing raw StoreKit and Play Billing correctly handling receipt validation, subscription renewal states, restoring purchases across devices, and keeping entitlements in sync with your backend is one of the more error-prone parts of mobile development, and doing it twice, once per platform, doubles the work. This is exactly why many teams don't build it from scratch and instead integrate a purchase infrastructure layer like RevenueCat, which sits on top of both Apple's In-App Purchase and Google Play Billing at once, handling receipt validation, subscription status, entitlements, and analytics from a single dashboard cutting weeks off implementation time on iOS and Android alike, and reducing the chance of a repeat rejection from a subtle billing mistake on either store.

Stuck on an in-app purchase rejection on iOS, Android, or both or need RevenueCat / payment gateway integration done right the first time?
Our development team handles the full fix across both platforms correctly classifying digital vs. physical goods, implementing StoreKit and Play Billing (or RevenueCat), and getting your resubmission approved.
Book a free call with our developer team →

A Few Things to Double-Check Before Resubmitting

• Old IAP or Play Billing products left in a pending or unresolved state in App Store Connect or Play Console can sometimes confuse reviewers even if they're not connected to your current build check and clean these up on both platforms.
• External links or buttons pointing to a website checkout for digital content need to be fully removed on both iOS and Android, not just visually hidden.
• Mixed digital/physical apps should keep the two payment paths clearly separate in both the code and the UI, so reviewers on either store can immediately tell which purchase uses which system.
• Your response to the review team matters a short, specific explanation of exactly what changed tends to move review along faster than a long justification of why the original approach should have been fine.

The Bottom Line

A Guideline 3.1.1 or Google Play Billing rejection isn't usually a sign that something is fundamentally wrong with your app it's almost always a payment-routing issue: digital content sold through the wrong channel, on one platform or both. The fix is well understood and predictable once you correctly separate digital goods from physical ones and route the digital side through each platform's native billing system, ideally with a tool like RevenueCat handling the underlying complexity across iOS and Android so you can focus on the product instead of receipt validation edge cases.