Guideline 3.1.3, Other Purchase Methods

A 3.1.3 rejection means your app pointed a customer at a way to pay that is not in-app purchase, and Apple does not accept that you qualify for one of the exceptions. Sometimes the app genuinely does not qualify. Sometimes it does, and you never told anyone which exception you were relying on.

Before anything else: this is the fastest-moving area of the guidelines. Court orders and legislation in the US, the EU and Japan have changed what a link-out may do, and the answer differs by storefront. Check the guideline text and the entitlement pages on the day you submit, including this one.

How it is usually worded

The header is Guideline 3.1.3 - Business - Payments - Other Purchase Methods, sometimes with a sub-letter such as 3.1.3(a) or 3.1.3(b). The body tends to read like:

• "Your app includes a link to an external website for purchasing content or services."
• "Your app does not qualify for the reader app exception."
• "Your app unlocks content or features purchased outside the app without offering in-app purchase."

What 3.1.3 is, versus 3.1.1

3.1.1 is the rule: digital content and services used inside your app are sold through in-app purchase.

3.1.3 is the list of exceptions to that rule, plus the anti-steering conditions attached to them. If you have been rejected under 3.1.3 you are being told your case is not on that list, or that you took an exception further than it goes.

The exceptions, as the guideline sets them out :

• "Reader" apps: apps whose function is letting people consume content or subscriptions bought elsewhere: magazines, newspapers, books, audio, music, video. They may let customers access what they already bought, but they may not sell it in the app outside IAP.
• Multiplatform services: an app that is part of a service running on other platforms may let customers access content, subscriptions or features they acquired elsewhere. For consumable items in multiplatform games, the same items must also be purchasable as in-app purchases in the app.
• Enterprise services: services sold to organisations rather than to the individual using the app.
• Person-to-person experiences: one-to-one real-time services such as tutoring, medical consultations or personal training may be paid for outside IAP. One-to-few and one-to-many, a class, a webinar, a recorded course, must use in-app purchase.
• Goods and services consumed outside the app: physical goods, real-world services, and anything delivered offline must not use IAP.
• Free stand-alone apps: a free companion app to a paid web tool (cloud storage, email, web hosting, business software) does not need IAP, provided the app neither sells anything nor points customers at where to buy.

Two entitlements sit alongside these, and both must be applied for and granted before you rely on them: the External Link Account Entitlement, which lets a qualifying reader app include a link to its own site for account creation and management, and the StoreKit External Purchase Link Entitlement, which permits external purchase links in specific storefronts under specific conditions.

Why it triggers

• A Manage subscription or Upgrade button that opens a web page showing prices.
• A sign-up screen telling customers to create their account on your website, with no entitlement granted for that link.
• Claiming reader status while the app does more than let people consume content: creating, collaborating, publishing, or selling anything.
• A multiplatform game selling gems on the web that customers cannot also buy as an in-app purchase in the app.
• A course, cohort or group session sold outside IAP under the person-to-person exception. Group means IAP.
• Copy that compares prices: "cheaper on our website", "save 30% at example.com", even where the link itself is permitted.
• Support articles or a help centre inside a WebView that happen to contain a buy button.
• An entitlement you were granted for one storefront being used everywhere.

That last two are worth dwelling on. Reviewers open the help section, and they use the storefront they are in.

How to fix it, in order

1. Decide which exception you are claiming, in one sentence. If you cannot name it, you do not have one, and the answer is IAP.
2. Match the app to the exception, not the other way round. A reader app that also lets people create content is not a reader app. Trim the app or drop the claim.
3. Take out the pricing and the steering. Prices, promotions, "subscribe on the web", comparison copy, and any deep link into your checkout, including inside WebViews, help centres, onboarding emails rendered in-app, and screenshots.
4. Add IAP as the in-app path. For multiplatform services this is not optional for consumables: the same items must be purchasable in the app.
5. Apply for the entitlement if you qualify, and wait for it. Shipping the link first and arguing later is how a 3.1.3 becomes a 5.6 conversation about repeated violations.
6. Check per storefront. Build the link-out behind a flag keyed to storefront, so a permission granted in one region does not appear in another.
7. Tell the reviewer in App Review notes which exception applies, which entitlement you hold, and where in the app the relevant screen is. Reviewers do not go hunting for context you did not supply.

What to send back

Reader app, entitlement held:

Thank you for the review. This app is a reader app under 3.1.3(a): it provides access to [content type] that customers have already purchased on our website, and sells nothing in the app. The single account link is covered by the External Link Account Entitlement granted to this account on [date]. We have removed the pricing reference from the onboarding screen and the help article that contained a purchase link.

Multiplatform service:

Thank you. Our service runs on web, Android and iOS, and customers may access subscriptions purchased on other platforms under 3.1.3(b). This build adds in-app purchase for every consumable available elsewhere, at parity, and we have removed the copy comparing web pricing. Reviewer steps to reach the purchase screen are in the notes.

The honest part

We cannot tell you what your storefront permits this month, and neither can anyone writing a blog post about it. What holds across versions is the shape: sell in-app unless you fit a named exception, never steer, and get the entitlement before you ship the link.

Source: Apple, App Store Review Guidelines, 3.1.3 (https://developer.apple.com/app-store/review/guidelines/#other-purchase-methods)

Related: apple-guideline-3-1-1-in-app-purchase, apple-guideline-2-3-accurate-metadata, apple-guideline-5-6-developer-code-of-conduct