On this page (12 sections)
Freshness notice — read before acting
Payment rules change often and vary by storefront (the United States, the European Union, Japan, South Korea and other regions have had different requirements at different times). Confirm the current guideline text and any regional entitlement programme for your storefronts before making decisions. This page is orientation, not a substitute for the guideline.
The structure of 3.1
| Section | Topic | In short |
|---|---|---|
| 3.1.1 | In-App Purchase | Digital content, features and subscriptions unlocked within the app generally must use In-App Purchase; no steering to external purchase unless a permitted mechanism applies |
| 3.1.2 | Subscriptions | Auto-renewable subscription terms, disclosure, trials, restore |
| 3.1.3 | Other Purchase Methods | Exceptions: physical goods and services, reader apps, multiplatform services, enterprise services, person-to-person services, and others |
| 3.1.4 | Hardware-specific content | Content unlocked by approved physical products |
| 3.1.5 | Cryptocurrencies | Specific rules for wallets, exchanges and mining |
| 3.1.6 | Apple Pay | Requirements when Apple Pay is used |
Digital features and content vs physical goods and services
- Digital — premium features, subscriptions to app functionality, coins, levels, filters, content unlocks, digital courses consumed in the app. Generally In-App Purchase.
- Physical goods and services consumed outside the app — food delivery, ride hailing, retail purchases, hotel bookings, physical event tickets. Generally must not use In-App Purchase; use your own payment processing.
- Mixed apps must separate the two flows cleanly. Using the “physical” exception for a digital product is a classic 3.1.1 rejection.
The 3.1.3 exceptions
- Reader apps — apps whose primary purpose is to provide access to previously purchased content (magazines, books, audio, video). Specific rules on account creation and external links apply.
- Multiplatform services — content or subscriptions purchased elsewhere may be accessed in the app, provided the same items are also available as In-App Purchases.
- Enterprise services — sold directly to organisations for their employees or students.
- Person-to-person services — real-time one-to-one services between two people (with a distinction for one-to-few and one-to-many).
- Companion apps for hardware or services purchased outside the app, under 3.1.4 and related clauses.
Each exception has conditions. Reading the clause for your case is the single most useful step before responding.
Region and storefront differences
Rules on external purchase links, alternative payment processing and “steering” have diverged by storefront following regulatory action in several jurisdictions. Some storefronts have entitlement programmes with their own eligibility, disclosure and commission rules; others do not. An implementation that is permitted in one storefront can be a 3.1.1 violation in another.
Do not assume worldwide uniformity
Advice that says “all digital payments must use IAP everywhere” or “you can now link out anywhere” is wrong in both directions. Decide per storefront, using the current guideline and any programme you are enrolled in.
Subscription configuration — 3.1.2
- Price, billing period and renewal terms visible before purchase
- Trial length and what happens when it ends disclosed clearly
- Restore Purchases available and working
- Subscription groups and upgrade / downgrade paths configured correctly in App Store Connect
- Terms of use and privacy policy linked where required
StoreKit and technical issues
Many 3.1 rejections are technical: products that do not load (not submitted with the version, wrong identifiers, sandbox misconfiguration), purchase flows that hang, restore that does nothing, receipts not validated, or entitlement not applied after purchase. These fail review as 2.1 or 3.1 depending on wording — 2.1 requires in-app purchases to be complete, up to date, visible to the reviewer and functional, so a product the reviewer cannot reach is a review problem as well as a technical one. Test the full purchase and restore cycle on a device with a sandbox account before submitting.
Reviewability
The reviewer must be able to see and test the purchase. Submit the IAP products with the build, describe in the notes where they are, and if the review account already has entitlements, say so. If purchases require a real-world action (a subscription bought on the web for a multiplatform service), explain and provide a review account that already has it.
External link vs external purchase
Where a storefront permits it, there is a difference between linking to an external site for purchase and completing a purchase in-app through an alternative processor. Each has its own entitlement, disclosure sheet and design rules. Implementing one under the rules of the other is a rejection.
No hiding payment flows during review
Disabling an external payment path while the app is in review and enabling it afterwards is deception under 2.3.1 and can lead to account termination. If a flow is not compliant for a storefront, remove it for that storefront. Do not switch it off for the reviewer.
Resubmission checklist
- Every item sold is classified: digital in-app, physical / outside-app, or a named 3.1.3 exception
- Digital items use In-App Purchase unless a permitted mechanism for that storefront applies and is implemented as specified
- Subscription terms, trials and restore comply with 3.1.2
- Products submitted with the version; purchase and restore tested in sandbox
- Review notes explain where purchases are and how the review account is entitled
- No behaviour that changes after review
Products not appearing at all?
If the rejection was caused by the reviewer being unable to complete a purchase — or if products simply do not load in the app, in sandbox or in TestFlight — that is a configuration, StoreKit or server problem rather than a rules problem. Work through in-app purchases not showing or failing first, because a build whose paywall is empty will be rejected again whatever the rules say.
What we can implement
StoreKit purchase and subscription flows, receipt and entitlement handling, restore purchases, product configuration in App Store Connect, separation of digital and physical flows, storefront-aware feature configuration, and — where a storefront permits and you are eligible — external link or purchase implementations that follow the programme rules.