A tip for a real world service does not go through in-app purchase, and Apple says it must not.
Tipping in an app means charging a card. If the thing being tipped for happens off the phone, a haircut, a class, a delivery, a dog walk, the gratuity rides on the same card payment as the service. App Store Review Guideline 3.1.3(e) is not vague about it: 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. Google Play's payments policy says the same thing from the other side. Physical services and peer to peer payments are both cases where its billing system must not be used. Both read on 14 October 2026. The mechanics of taking the money are the same as adding payments to any booking flow.
So permission is not your problem. What follows is the part that is: which rail each kind of tip belongs on, what the preset buttons should say, who the money belongs to the moment it lands, and the one place where a tip genuinely does have to go through the store.
Start hereThe short version
One question decides the rail: where is it consumed.
Both stores sort payments by where the thing being paid for is used, not by what you call it. A tip attached to something that happens in the world travels on a card, and the store billing systems are closed to it. A tip attached to something that happens inside the app is in-app content, and the store billing systems are the only way to take it. There is no third option and no way to choose.
That makes almost every booking app simple. The haircut happens in a chair, the class happens in a room, the delivery arrives at a door. Card, every time. The cases worth slowing down for are the ones where the service moved onto the screen, which is a live class streamed in the app, a video consultation with a group, or a tip that buys the customer something.
Does a tip have to go through in-app purchase?
Not for a service given in person, and the wording is stronger than an exemption. Guideline 3.1.3(e), headed Goods and Services Outside of the App, says you must use purchase methods other than in-app purchase for physical goods or services consumed outside the app, and names Apple Pay or traditional credit card entry as the examples. Read that twice, because people get it backwards. In-app purchase is not an option you are being let off. It is closed.
The guidelines do mention tipping, exactly once, and it is in the other direction. Guideline 3.1.1 says apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app. That sentence is about a reader tipping a writer and a viewer tipping a streamer. It is permissive, not mandatory, and it has nothing to do with a salon. If you went looking for the word tip and stopped at the first hit, you read the wrong clause.
One clause nearby is worth knowing because it catches people with group bookings. Guideline 3.1.3(d) covers real time person to person services between two individuals, naming tutoring, medical consultations, real estate tours and fitness training, and allows payment methods other than in-app purchase for them. Then it closes the door: one to few and one to many real time services must use in-app purchase. A one to one video session is a card. The same trainer teaching eight people live in your app is store billing, and so is the tip. If you are building a class schedule app, sort the in-person classes from the streamed ones before you write a line of payment code.
Google Play arrives at the same place with a different list. Its payments policy says its billing system must not be used where payment is primarily for the purchase of physical services, and gives transportation, cleaning, airfare, gym memberships, food delivery and tickets for live events as examples. The same sentence rules out peer to peer payments. Note that Google puts fitness in both lists, as an in-app subscription service that must use Play billing and as a gym membership that must not. The resolution is the same test as Apple's: a workout streamed to the phone is in-app, a gym you walk into is not.
What should the tip buttons on the screen say?
Three presets and a no tip option, all four the same size. The real decision is the middle preset, because that is the one most people press, and the two either side exist mostly to make it look reasonable. Decide it by looking at your own price list rather than by copying a coffee shop.
Percentages and flat amounts fail in opposite directions. Percentages scale with the ticket, so they read sensibly in the middle of your price list and badly at both ends. Twenty percent of a small ticket is pocket change, and twenty percent of a long appointment is a number nobody taps. Flat amounts are clear on a small bill and insulting on a large one. If your prices spread widely, percentages usually win, and if everything you sell costs roughly the same, flat amounts are easier to read. Tick through the planner below with your own typical ticket and the choice tends to make itself.
Set your presets
What your tip buttons would actually charge
Pick a typical ticket. The middle button is the one most people tap, so that is the number you are really choosing.
15, 18 and 20 percent
$5.70 then $6.84 then $7.60
Middle button pays $44.84 in total.
18, 20 and 25 percent
$6.84 then $7.60 then $9.50
Middle button pays $45.60 in total.
Flat amounts, no percentage
$2.00 then $5.00 then $10.00
Middle button is 13.2 percent of this ticket.
Percentages hold up on a mid sized ticket and fall apart at both ends. Flat amounts do the opposite. Nothing here is a rule, it is arithmetic you should see before you pick.
Two details are not style questions. The first is the total. Guideline 4.9 requires apps using Apple Pay to provide all material purchase information to the user prior to sale of any good or service, so the screen that takes the tip has to show the service, the tip and the sum before anybody confirms. The second is the opt out. Guideline 3.2.1(vii) rests on a tip being a completely optional choice by the giver, and a no tip option hidden as a small grey link is not that. Same row, same size, same tap target.
Timing beats wording. A tip asked for at booking is a tip asked for before the work has happened, and it suppresses both the amount and the booking. Hold the card at booking for the service, mark the appointment complete, then prompt on the receipt. That means the amount you finally charge is not the amount you first authorised, which is a question for whoever processes your cards before it is a question for your app. Ask them what they allow before you design the flow around it.
Who does the tip money belong to once it lands?
Whoever your screen said it was for, and the guidelines hold you to that. Guideline 3.2.1(vii) allows apps to let individual users give a monetary gift to another individual without in-app purchase, provided the gift is a completely optional choice by the giver and 100 percent of the funds go to the receiver of the gift. It then adds that a gift connected at any point to receiving digital content or services must use in-app purchase. So the clean case is a tip your app passes through untouched to one named person.
The moment the business keeps a share, that clause stops describing what you built. Nothing breaks, because a tip on a service consumed outside the app is still covered by 3.1.3(e), which is the rule you were relying on anyway. What has to change is the copy. If the shop takes a cut, or the tip is pooled across the team at the end of the week, the screen cannot say the money goes to Maria. Say it goes to the team, or say it is shared, and say it where the customer taps rather than in a policy page nobody opens.
Store the tip as its own amount in its own column from the first commit. Every question you will be asked later needs the two numbers apart: how much of yesterday went to staff, what the card fees were against the service alone, what to refund when an appointment goes wrong, what a stylist is owed. Folding the tip into the service price is a ten second shortcut that makes all of that unanswerable without rebuilding the data. The same discipline runs through the rest of app monetisation, where the number you can report on is worth more than the number you collected.
Payroll and tax are the part to stop guessing about. How a tip is treated depends on your country, on whether the person receiving it is an employee or self employed, and on whether the money passed through your business account on the way. Those answers are not in any store guideline and they are not something an app builder can tell you. Get them from an accountant in your jurisdiction, and build the reporting your app needs once you know what you are reporting.
What breaks when a tip turns out to be wrong?
Refunds, first and most often. A customer who wants the service refunded usually wants the tip back too, and a customer who fat fingered a 25 percent button wants only the tip back. Both are partial refunds, and both are easy if the tip is a separate amount and painful if it is not. Build the receipt as three lines, service, tip and total, and build the refund screen to let someone refund either line on its own.
Second is the mismatch between what you authorised and what you charged. If the tip arrives after the appointment, the final amount is higher than the one the customer approved at booking. Whether you can do that, and by how much, is set by your payment processor and the card networks, not by your app. Find out the rule before you build, because the alternative is discovering it through declined charges on real customers.
Third is the staff list. A tip pointed at a person needs that person to still exist in your data when the money is counted. Staff leave, change names, cover each other and get double booked. Record the tip against the appointment and the staff identifier, not against a display name you later edit, or your end of month report will hand money to a row that is no longer there.
Last, and easiest to get wrong on purpose, is the zero. A customer who tips nothing is a normal outcome, not an error. Do not make them tap twice, do not show a confirmation asking if they are sure, and do not grey the button out. Beyond the guideline wording, this is the sort of detail reviewers do notice, and it is the sort customers remember. The behaviour that keeps you out of trouble and the behaviour that keeps people booking happen to be the same behaviour.
The same tip, sorted by two rulebooks
| The case | App Store | Google Play | Same outcome on both |
|---|---|---|---|
| Tip for a service given in person | Card or Apple Pay, guideline 3.1.3(e) | Card, a physical service is a must not use case | Yes |
| Tip on a live group class streamed in the app | In-app purchase, one to many real time, guideline 3.1.3(d) | Play billing, Google lists fitness among in-app subscriptions | Yes |
| Tip where all of it reaches one named person | No in-app purchase, guideline 3.2.1(vii) | Card, peer to peer payments are a must not use case | Yes |
| Tip the business keeps a share of | 3.2.1(vii) stops fitting, 3.1.3(e) still covers it | Unchanged, it is still payment for a physical service | No |
| Tip that unlocks something inside the app | In-app purchase currencies, guideline 3.1.1 | Play billing, it is in-app content | Yes |
| Total shown before the card is charged | Required with Apple Pay, guideline 4.9 | Its pricing rule governs the Play billing screen only | No |
Guideline numbers from Apple's App Store Review Guidelines and the Google Play payments policy, both read on 14 October 2026. Guideline numbering moves between revisions, so check the number before you quote it in a review note.
Where this lands if a builder generated your app
The rules do not soften because an AI wrote the code. You are still the one who picks the rail, writes the copy next to the tip button and presses submit. Guideline 4.2.6 is why the last part is yours: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. Nobody can submit the salon app on the salon's behalf.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync, so the payment code is 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 and there is no free tier. Ask it for a salon booking app with card payments and a tip step and you get a working flow in an afternoon.
Be specific in the prompt about the two things that are decisions rather than code. Name your presets, and say whether the tip is pooled or goes to one person, because that sentence determines both the data model and the wording the customer reads. The honest limit: no builder can tell you how tips are taxed where you live, and no builder presses submit for you.
Questions people ask about tipping in an app
For a service that happens in the real world, you have to. App Store Review Guideline 3.1.3(e), Goods and Services Outside of the App, says that 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. Checked on 14 October 2026. Google Play's payments policy lists physical services and peer to peer payments among the cases where Play billing must not be used. So a haircut, a class you attend, a delivery or a dog walk all take a card, and the tip rides on the same charge.
Describe the booking, then decide the tip
Pick your three presets, write one sentence about who the money reaches, and keep the tip in its own column. That is the whole design, and it takes longer to decide than to build.
Start building