Rejection decoder › Guideline 3.1.1
Guideline 3.1.1 rejection: In-App Purchase
Guideline 3.1.1 says, in short, that digital features or content used inside an iOS app are generally sold through Apple's In-App Purchase. A Stripe checkout, an "Upgrade on our website" button or a pricing page inside the app is the usual trigger.
Apple decides. This page is our own reading of the App Review Guidelines as of September 2026, not Apple's wording, and following it does not guarantee approval. The current text at developer.apple.com is the authority.
What Apple's message says
In our own words, a 3.1.1 message says the app unlocks or sells digital content or features (premium plans, credits, subscriptions to the app itself) with a payment method other than In-App Purchase, or directs users to one. Apple often lists each place it found, so one rejection can carry several 3.1.1 citations.
Apple may also read other things as ways around In-App Purchase: an invite or promo code field that seems to unlock paid features, or a sign-up flow where a business registers and pays elsewhere. If that code only joins an existing team and unlocks nothing, say so plainly.
Rules on linking to outside payment differ by storefront and changed for the United States in 2025. Read the current text of 3.1.1 and 3.1.3 before relying on any exception; Apple's wording is the authority.
Why AI-built apps hit it
Web-first builders make Stripe the default way to charge. When the web app is wrapped with Capacitor, the same pricing page, checkout redirect and "Manage billing" link come along into the iOS app. Typical findings:
- A paywall or trial-ended screen that opens a Stripe Checkout page.
- Prices and an "Upgrade" button shown inside the app, even if the button opens Safari.
- An invite or promo code field that appears to unlock paid plans.
We have seen a founder choose web-only payments on purpose to keep things simple, then get three 3.1.1 citations in one rejection for exactly that. The fix was to sell subscriptions through In-App Purchase on iPhone and iPad and keep web checkout on the website only.
How to fix it, step by step
- Decide what you sell. Digital features or content used in the app generally need In-App Purchase. Physical goods and real-world services (deliveries, bookings, in-person sessions) can use your own payments.
- Pick one path for iOS. Either add In-App Purchase (StoreKit directly, or a billing service such as RevenueCat) or remove every price, purchase button and payment link from the iOS build. Hiding them only on iOS is a common approach for wrapped apps.
- If you add In-App Purchase: create the products in App Store Connect, attach them to this version, make sure the Paid Apps agreement is active, and match product IDs exactly in your billing setup.
- Handle codes honestly. If a code field only joins an existing team, explain that in App Review notes.
- Show subscription terms on the purchase screen: plan name, length, price, and working Terms of Use and Privacy Policy links (Guideline 3.1.2).
- Test a sandbox purchase on a device, give the reviewer a demo account that can reach the paywall, then upload a new build.
What to reply in the Resolution Center
Fill in the brackets and delete anything you did not do. Answer every 3.1.1 citation Apple listed, in the same order. If you sell physical goods or in-person services, say which, and that they are consumed outside the app.
Hello, Thank you. Regarding Guideline 3.1.1: in build [version] we [removed the external purchase button and pricing from the iOS app / added In-App Purchase for (products)]. [If relevant: "The invite code field joins an existing team account and does not unlock any paid features."] The purchase screen is reached by [path]. The demo account in App Review Information [is on the free plan / has an expired subscription] so the purchase flow can be tested. Best regards, [Your name]
Related guidelines
- Guideline 2.1: App completeness and Information Needed if the reviewer could not reach or load the in-app purchases (2.1(b)).
- Guideline 4.2: Minimum functionality if the web pricing page is one sign the app is a wrapped website.
- Guideline 2.3: Accurate metadata if the description still mentions web pricing.
Questions
Can I use Stripe in my iOS app?
For physical goods and real-world services, generally yes. For digital features or content used inside the app, Apple generally requires In-App Purchase. Rules on linking out differ by storefront and changed in the United States in 2025, so check the current guideline text for your case.
Can I just hide the payment button on iOS?
Many wrapped apps do exactly that: no prices, purchase buttons or payment links in the iOS build, with paid plans sold only on the website. Users who already paid can still sign in. Apple decides whether a specific app qualifies.
Do in-app purchase products need to be submitted with the app?
First-time in-app purchases are reviewed together with an app version. Attach them to the version before submitting, and check they are still attached if you pull the build from review.
Stuck on this rejection?
Paste the full message into the free rejection decoder to see every cited guideline explained, with a reply draft. It runs in your browser and nothing is uploaded.
Or order a rejection fix, $99: we read the full message, find the cause, fix it in your project, upload a new build and draft the reply for your approval. Target turnaround 72 hours from access. Apple still makes the final decision, and its review time is separate.