Guideline 3.1.3(e) is not permission to use another payment method. It is an instruction to use one.
Apple's words are these: “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.” Read on 17 October 2026, from a guidelines page Apple stamps Last Updated: October 16, 2026. The section that sub-item lives in opens by saying its apps “may use purchase methods other than in-app purchase”, so the heading hands you a choice and the sub-item takes it away. If you sell deliveries, repairs, haircuts or a seat in a hall, routing the money through in-app purchase is the mistake and not the cautious option. Most people hit this while adding payments.
Below: the exact words of 3.1.3(e) and 3.1.3(d), what guideline 3.1.5 is actually about, and the place Google's rule reads differently from Apple's even though it lands in the same spot. Every quote carries the date it was read.
Start hereThe short version
A section called Other Purchase Methods is mostly full of musts.
Guideline 3.1.3 has seven sub-items, lettered (a) to (g). Four of the seven contain the word must, and we counted them in the text on 17 October 2026: (c), (d), (e) and (g). In three of those four the must points at in-app purchase. Consumer, single user and family sales must use it, under (c). One-to-few and one-to-many real-time services must use it, under (d). Digital purchases consumed in the app, including paying to boost your own post, must use it, under (g). Only (e) points the other way.
The sentence that orders you off in-app purchase appears exactly once in the whole document. We searched the full guidelines text for the phrase “must use purchase methods other than” on 17 October 2026 and found one hit, in 3.1.3(e). So this is not one of a family of escape hatches. It is a single sentence, with a narrow trigger, inside a section whose other rules mostly pull the opposite way.
That is why the same sentence gets repeated wrongly in two ways. People read the section heading and remember a menu of exemptions, then design a store that takes card payments for digital unlocks, or a class booking app that charges a card for a one-to-many session. Both get rejected, and for opposite reasons. The number on the rejection notice is the fastest way to tell which mistake you made, so it is worth knowing which number covers what before you build the checkout.
Does 3.1.3(e) permit another payment method, or require one?
It requires one. The sub-item is titled Goods and Services Outside of the App, and the operative clause is a single sentence with must in it. The test it applies is not whether the thing you sell is physical. It is where the thing gets consumed. A delivered parcel, a plumber's visit, a haircut and a ticket to a room full of chairs are all consumed away from the phone, and all land in (e). Apple names two acceptable rails, Apple Pay and traditional credit card entry, and introduces them with the words such as, so the pair is an illustration rather than a closed list.
The word people reach for here is exemption, and it is not Apple's word. We read the whole App Store Review Guidelines page on 17 October 2026 and searched it: exemption appears zero times, and exempt appears once, in guideline 1.1.1, in a sentence about professional political satirists. The guidelines also put no percentage anywhere inside 3.1.3. There is no commission figure in that section at all, which matters because the reason most people care about the rule is the fee, and the rule itself never mentions one.
One thing the text does not resolve. The opening sentence of 3.1.3 says apps in the section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, with exceptions for apps on the United States storefront and for the cases set out in 3.1.1(a) and 3.1.3(a). An app whose only paid thing falls under (e) has no in-app purchase to steer anybody away from, because (e) forbids in-app purchase for that sale in the first place. We could not find anywhere on the guidelines page that explains how those two sentences sit together, and that is not the same as saying no explanation exists elsewhere in Apple's documentation. Build the checkout plainly, without a sales pitch about where the money goes, and the question stops mattering.
Apple, App Store Review Guidelines, Last Updated October 16, 2026, read 17 October 2026
Which rule catches you
Pick what you are selling
Every line below maps to a guideline number and to a direction. Two of them forbid in-app purchase, three require it, and three leave the choice with you.
3.1.3(e), Goods and Services Outside of the App
Apple Pay or card entry. In-app purchase is the wrong answer here.
Read off the guidelines on 17 October 2026. A reviewer looks at your actual app, not at this box.
What does 3.1.3(d) say about one to one versus one to many?
It cuts the same business in half. Sub-item (d) is titled Person-to-Person Services and reads: “If your app enables the purchase of real-time person-to-person services between two individuals (for example tutoring students, medical consultations, real estate tours, or fitness training), you may use purchase methods other than in-app purchase to collect those payments. One-to-few and one-to-many real-time services must use in-app purchase.” Two sentences, two opposite rails, and the only thing that changes between them is how many people are on the other end of it.
That makes a group class the awkward case, because a live class is a real-time service and so sits in the second sentence. A yoga teacher with private clients and a Tuesday group is therefore running two rails inside one app, and the only honest way to build that is to pick the rail per product rather than per app.
There is a seam between (d) and (e) that the text does not close. Two of Apple's own examples in (d), real estate tours and fitness training, are services performed in the world rather than on the phone, which is exactly the trigger (e) describes. For an in-person one to one booking, (d) says you may use another method and (e) says you must. We read the whole guidelines page on 17 October 2026 and could not find anything on it that says which sub-item governs when both describe the same sale, and that is not the same as saying nothing elsewhere in Apple's documentation does. The two readings agree on what is safe, though: another payment method satisfies the may and obeys the must, so an in-person session priced outside in-app purchase is the answer that works under either.
How many people make a class? Apple does not say on this page. We searched the whole guidelines text on 17 October 2026: the terms one-to-few and one-to-many each occur exactly once on it, both in the sentence quoted above, and neither is defined. No participant number appears. We could not find a definition anywhere on the page, which is not proof that none exists elsewhere in Apple's documentation, so plan for the cautious reading. One more boundary is worth marking. A live session consumed inside the app is not consumed outside the app, so (e) does not reach it, and a recorded class sold afterwards is digital content and goes back to 3.1.1. Guessing at this boundary is a common entry on the list of why apps get rejected.
What is guideline 3.1.5 actually about?
Cryptocurrencies. That is the whole heading, and the sub-item has five parts. Wallets may store virtual currency, provided they are offered by developers enrolled as an organization. Mining is not allowed unless the processing happens off device, with cloud mining as the example. Exchanges may facilitate transactions or transmissions of cryptocurrency on an approved exchange, only in countries or regions where the app holds the licensing to run one. Initial coin offerings, cryptocurrency futures trading and other crypto-securities trading must come from established banks, securities firms, futures commission merchants or other approved financial institutions. And crypto apps may not offer currency for completing tasks such as downloading other apps or posting to social networks.
None of that is about real world goods or services, and none of it sets a payment rail for anything other than crypto. If you have been handed 3.1.5 as the number that lets a booking app take card payments, the number is wrong. The sequence runs 3.1.1 in-app purchase, 3.1.2 subscriptions, 3.1.3 other purchase methods, 3.1.4 hardware-specific content, then 3.1.5 cryptocurrencies, so a misremembered 3.1.3 lands two doors down. Checked 17 October 2026.
Guideline 3.1.1 is worth reading alongside it, because it carries the sharpest illustration of where in-app purchase ends. Digital gift cards, certificates, vouchers and coupons redeemable for digital goods can only be sold in your app using in-app purchase. Physical gift cards sold within an app and then mailed to customers may use other payment methods. Same product name, two rails, decided entirely by whether something arrives in the post. None of this changes what the store costs you to be in, which is a separate sum covered in what it costs to publish an app.
Apple, App Store Review Guidelines, sections 3.1.1 to 3.1.5, read 17 October 2026
Does Google Play read the same sale the same way?
It lands in nearly the same place and gets there by a different route. Google's Payments policy opens by saying its billing system is required for developers offering in-app purchases of digital goods and services distributed on Google Play. Then it publishes a list headed purchases that are not supported by Google Play's billing system: purchases or rentals of physical goods, with groceries, clothing, home appliances and electronics as the examples; purchases of physical services, with transportation, airfare, gym memberships and food delivery; and payment of a credit card or utility bill. Read 17 October 2026. That page carries no last-updated date of its own.
Not supported is a different kind of sentence from you must. Apple writes a rule addressed to you. Google describes what its system does and does not handle. The practical outcome for a shop is the same, which is why the difference gets flattened in retellings, but it changes how you argue a case. There is nothing to appeal about an unsupported product type. There is something to discuss when a rule is addressed to you and your sale sits on its edge.
Google's version of the person to person carve-out also carries a test Apple's does not. A 1:1 online paid service is free of Play's billing system if the service is between two individuals and is not available for replay afterwards, meaning the session is not recorded and cannot be accessed again in any Play-distributed app. Education and hobby classes, health coaching and specialist advisory services are the named examples. Record the session for later and you lose the carve-out on Google. Apple's payments section says nothing about it: we searched guidelines 3.1.1 to 3.1.5 on 17 October 2026 and the words record, recorded and replay appear in none of them. Those two shapes have to be reconciled before you choose which payment layer to use.
Google Play Console Help, understanding Google Play's Payments policy, read 17 October 2026
The same sale, as each store writes it down
Six sales, and what each store's own documentation says about the rail. The last column asks whether a single implementation satisfies both. Where it says no, you are building two code paths.
| The sale | App Store, guideline 3.1 | Google Play, Payments policy | One build satisfies both |
|---|---|---|---|
| Physical goods posted to the buyer | 3.1.3(e), you must use another method | Listed as not supported by Play billing | Yes |
| A service performed away from the phone | 3.1.3(e) if it is consumed outside the app | Listed under physical services | Yes |
| A live session between two people | 3.1.3(d), you may use another method | Not required, if the session cannot be replayed | No |
| A live class for a group | Must use in-app purchase | A digital service, so Play billing applies | Yes |
| Pointing at your own checkout inside the app | Restricted, with named exceptions | Restricted, with named exceptions | Yes |
| A fee reduction for using your own rail | No | Service fee reduced by 4% in India and South Korea | No |
Where this lands if a builder generated your app
The rule attaches to the sale, not to who wrote the code. An agent can wire a card sheet or a store product in minutes, which means the decision about which one belongs there is now the slow part, and it is yours. Ask for a paywall in a shop app and you may get the rail that gets the app rejected, because a paywall is the default shape of a request about taking money. Say what is being sold and where it is consumed, and the right rail follows from that sentence.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so the checkout is ordinary code you can read and change. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, with no free tier. It does not submit to the App Store for you, because guideline 4.2.6 requires apps created from an app generation service to be submitted by the provider of the app's content, and that is you.
The honest limit is that no builder can read your business for you. A reviewer opening your app decides what you are selling from what they see on the screen, and a card form on a screen full of digital unlocks is a rejection whatever the code says underneath. Write the product list first, mark each line with where it gets consumed and how many people are on the other end of it, then let that list pick the rails. That is a twenty minute job and it is the whole of this problem.
Questions people ask about 3.1.3(e)
It requires a payment method other than in-app purchase. The guideline reads: 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. The verb is must, not may. The two examples Apple gives are Apple Pay and traditional credit card entry, so a card form or a payment sheet both fit. Read on 17 October 2026, from a guidelines page stamped Last Updated October 16, 2026.
List what you sell, then pick the rail per line
Write down every paid thing in the app with two notes beside it: where it is consumed, and how many people receive it at once. Those two notes answer the guideline question for every line on the list, and they take an afternoon less than an appeal does.
Start building