ClearedToShip
Scan with GitHub

Run a free ShipCheck before you resubmit. Paste a public GitHub link or upload a zip, no account needed. ShipCheck reads allowlisted project files and names each issue with the guideline, a short label, how serious it is, and how many places. Its 3.1.1 check looks for a Stripe card form or payment sheet in an iOS project that has no In-App Purchase library. A fix is $9, or 3 for $19, paid first. Run a free ShipCheck

It can't see your App Store Connect products, which storefronts you sell in, or whether a web checkout link is set up the way Apple allows. A clean scan isn't App Review approval.

Guideline 3.1.1: Apple rejected my app for using Stripe

If your app was built from a web app, or an AI tool wired up payments for you, there's a good chance it shipped with Stripe. Stripe is easy to add, it's what most web tutorials use, and it works fine in a simulator. Then App Review sends back a 3.1.1 rejection.

The short version: if someone pays to unlock something they use inside your iOS app, Apple wants that sale to go through In-App Purchase. There are real exceptions, and the US storefront rules changed in 2025, so the right fix depends on what you sell and where.

What Apple's rule says

From Apple's App Store Review Guidelines, 3.1.1 In-App Purchase (page marked "Last Updated: October 16, 2026", fetched Nov 12, 2026):

If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.

So a "Go Pro" screen with a Stripe card form, a Stripe payment sheet for a monthly plan, or a license key you email after a web purchase are all the kind of thing 3.1.1 is about.

The same section also covers 2 things AI-built apps often miss:

Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.

Digital gift cards, certificates, vouchers, and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase.

When Stripe is fine

Apple's 3.1.3 lists apps that "may use purchase methods other than in-app purchase." The one most people need is 3.1.3(e):

If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.

Note the "must". If you sell physical goods, or a service people use in the real world, Apple doesn't want In-App Purchase there at all.

What you're sellingWhat Apple's guidelines say to use
Premium features, a subscription, AI credits, extra levels, a full unlock used in the appIn-App Purchase (3.1.1)
Physical goods, or services used outside the app (a ride, a haircut, a delivery)Something other than In-App Purchase, like Stripe or Apple Pay (3.1.3(e))
Real-time 1-on-1 services between 2 people (tutoring, a medical consult, fitness training)Can use other methods. 1-to-few and 1-to-many must use In-App Purchase (3.1.3(d))
Content or subscriptions bought somewhere else, used in your appAllowed if the same items are also sold as In-App Purchase in the app (3.1.3(b))
Sold only to organizations for their staff or studentsCan skip In-App Purchase. Consumer, single user, or family sales can't (3.1.3(c))

There are more cases in 3.1.3 (reader apps, free companion apps for a paid web tool, ad campaign management). Read the full 3.1.3 section if one of those sounds like you.

A common trap: AI credits. If a user buys credits to run prompts, images, or videos inside your app, that's a digital unlock used in the app. It isn't a "service consumed outside the app" just because the work runs on your server.

What changed on the US storefront

In May 2025 Apple changed its guidelines after a US court ruling in the Epic v. Apple case. The current 3.1.1(a) text says:

Developers may apply for entitlements to provide a link in their app to a permitted destination in order to purchase digital content or services. These entitlements are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps.

And the StoreKit External Purchase Link section ends:

In all other storefronts, except for the United States storefront, where this prohibition does not apply, apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.

What that means in practice:

  • On the US storefront, your app can have a button or link that sends people to a web checkout (for example a Stripe Checkout page) without a special entitlement.
  • Everywhere else, that kind of button or link isn't allowed unless you hold an entitlement Apple offers in that region.
  • A link out isn't the same as taking the card inside the app. The US change is about buttons, links, and calls to action. A Stripe card form or payment sheet that charges for a digital unlock inside the iOS app is still the 3.1.1 problem.

Stripe's own in-app purchases doc (fetched Nov 12, 2026) matches this split. For iOS it says, "US only: If you sell digital products, content, and subscriptions in the US, you can redirect customers to an external payment page using Stripe Checkout," and "If you sell physical goods, you can accept payments using in-app payments."

Rules like this can change again. Re-read Apple's current 3.1 text before you ship a link-out flow.

How to fix it

1. Find every place the app takes money

Search the project for Stripe and checkout code: @stripe/stripe-react-native, flutter_stripe, CardField, initPaymentSheet, presentPaymentSheet, links to checkout.stripe.com or buy.stripe.com, and any "Upgrade", "Pro", or "Buy credits" screen. AI tools often add a payment screen in more than 1 place.

2. Sort each one: digital or physical

Use the table above. Physical goods and real-world services can stay on Stripe. Anything that unlocks something in the app moves to In-App Purchase.

3. Add In-App Purchase for the digital parts

You need the products set up in App Store Connect and a library in the app.

For Expo apps, Expo's in-app purchases guide lists react-native-purchases (RevenueCat) and expo-iap, and notes that "In-app purchase libraries require configuring custom native code. Native code is not configurable when using Expo Go." You'll need a development build to test. Native Swift apps use StoreKit directly.

Then:

  • Add a Restore Purchases button. The 3.1.1 text above asks for a restore mechanism.
  • Make sure credits bought with In-App Purchase don't expire.
  • Make sure the product IDs your paywall loads are the ones attached to this app in App Store Connect, and that the products are submitted with the build. A paywall that loads nothing can get rejected too.
  • If you also sell a subscription for auto-renewing access, it falls under 3.1.2 as well. Apple's 3.1.2(c) says: "Before asking a customer to subscribe, you should clearly describe what the user will get for the price."

4. Decide about a web checkout link

If you want to keep a Stripe Checkout link for US users, keep it as a link or button that leaves the app, and only show it on the US storefront. Apple's text doesn't allow it in other storefronts without an entitlement. If you're not sure, ship In-App Purchase only and add the link later.

Don't hide the Stripe screen from reviewers with a flag or a remote config switch. Apple's guidelines treat hidden or undocumented features as their own problem, and it puts your developer account at risk.

5. Rebuild and resubmit

Removing a payment flow or adding In-App Purchase is a code change, so it needs a new build.

How to reply to App Review

Keep it short and specific. For example:

Thanks for the review. In build 15 we removed the Stripe payment sheet for the Pro plan. Pro is now sold only through In-App Purchase (product ID com.example.app.pro.monthly), and Restore Purchases is on the paywall and in Settings. Stripe is still used only for physical orders shipped to the customer, which we understand falls under 3.1.3(e).

(That's a template. Use your real build number, product IDs, and what you actually changed.)

If you think the rejection is wrong, for example you only sell physical goods, say that plainly and point to 3.1.3(e). Apple's App Review page says you can appeal to the App Review Board, and asks you to "Provide specific reasons why you believe your app complies with the App Review Guidelines" and to "Submit only one appeal per submission that didn't pass review."

What about Google Play?

Google has its own rules. Its Payments policy covers when Google Play's billing system is required, and Stripe's doc says that for Android apps, "US only: You can process payments directly in-app with a third-party payment processor like Stripe." Check Google's current policy for your countries before you reuse the same Stripe flow on Android.

When ShipCheck helps vs when it doesn't

ShipCheck helps when the problem is in your project files. Its 3.1.1 check flags a Stripe card form or payment sheet in an iOS project with no In-App Purchase library, and marks it as a blocker when the code also looks like it sells a premium or subscription feature.

It can't:

  • See your App Store Connect products, agreements, or prices.
  • Tell which storefronts you sell in, or whether a US-only link-out is shown only in the US.
  • Judge whether something you sell counts as physical, a person-to-person service, or a reader app. That's your call against Apple's text.
  • Catch every link to a web checkout. A plain URL opened from a button may not be flagged.

Run a free ShipCheck

FAQ

Can I use Stripe for digital subscriptions on iOS? Not inside the app. On the US storefront you can link out to a web checkout. Everywhere else, Apple's 3.1.1(a) text says buttons and links to other purchase methods aren't allowed without an entitlement.

I sell physical products. Do I need In-App Purchase? No. Apple's 3.1.3(e) says physical goods and services consumed outside the app must use other payment methods, "such as Apple Pay or traditional credit card entry."

Users bought a plan on my website. Can they use it in the app? Apple's 3.1.3(b) allows that "provided those items are also available as in-app purchases within the app."

Do I need a new build? Yes, if you're removing or adding payment code. Product setup in App Store Connect alone doesn't need one, but the app still has to load and sell those products.

Related guides