A restaurant reservation app sells seats for a period of time, not tables.

What does a table booking app actually have to track?

Four things, and only one of them is a booking. Seats, which is just the chairs added up. Covers per sitting, which is how many guests you seat in one turn of the room. Turn time, which is how long you give a party before you want the table back, and which is never a single number because a pair and a party of six do not eat at the same speed. And pacing, which is the cap you put on one time slot. A kitchen does not fail across a whole service. It fails at 7:30pm.

The gap between seats and covers is where the money leaks. A pair seated at a table for four holds two empty chairs for the length of a turn, and you cannot sell them to anybody. Table combinations buy some of it back: two fours that join into an eight mean one booking can be a party of six without a six top sitting empty until it arrives. A system that only stores party size and a time cannot see any of this, which is why a reservation app that is really a form with a time picker on it disappoints the person running the floor within a week.

Then the things that are not reservations and still take seats. Walk-ins, which come out of the same room. A waitlist, which is an ordered queue of people with no table yet and a way to reach them. A no show, which is a booking that neither arrived nor cancelled. A cancellation, which is the same table handed back with ninety minutes notice and nobody to offer it to. Each of those is a state a booking moves through, not a flag, and the fastest route to a mess is one status string that three screens interpret differently.

Most of this is shared with any other service business that sells time. The difference that changes the design is the unit. You are not selling the table, you are selling a seat for a period, so two bookings can both be inside your opening hours, both have a free table, and still be wrong together because they land in the same quarter of an hour. Write the slot cap first. Everything else in the book is a view over it.

Does Apple treat a table reservation as a real world service?

Yes, and the wording is firmer than the word exempt suggests. App Review Guideline 3.1.3(e) is headed Goods and Services Outside of the App and 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." Read on 14 October 2026. That is an instruction, not a permission slip. A meal in your dining room is consumed outside the app, so a deposit, a prepaid menu and a no show fee are card payments. In-app purchase is the wrong rail for them, not the safe one.

The clause next door matters if you sell somebody's time rather than a table. Guideline 3.1.3(d), Person-to-Person Services, covers the purchase of real-time person-to-person services between two individuals, and names tutoring, medical consultations, real estate tours and fitness training. It then says one-to-few and one-to-many real-time services must use in-app purchase. So a private lesson booked through your app sits in 3.1.3(d), and a class of eight does not. A restaurant table does not need that clause at all, because the meal is a physical service and 3.1.3(e) already covers it.

The trap is guideline 3.1.1. To unlock features or functionality within your app you must use in-app purchase, and Apple lists subscriptions, premium content and unlocking a full version as examples. A priority booking membership that only gets a regular a better table on a Friday is a service outside the app. Sell the same membership as early access to the book inside the app, or attach any digital perk the app itself hands over, and it becomes in-app purchase. If that is where you are heading, the walkthrough on adding in-app purchases is the next thing to read, before you price anything.

One more sentence catches people who try to have both. The preamble to 3.1.3 says apps using other purchase methods cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set out in 3.1.1(a) and 3.1.3(a). For a deposit there is nothing to steer towards, because card entry is already the sanctioned route. The clause bites when the same app also sells something digital and you would rather the customer bought it on your website. Gift cards follow the same logic: Apple's rule names digital gift cards, certificates, vouchers and coupons that can be redeemed for digital goods or services, so a card redeemable only for dinner is a different animal from one that also buys something in the app.

Apple, App Store Review Guidelines, sections 3.1.1 and 3.1.3, read 14 October 2026

What does Google Play's payments policy say about the same booking?

The same answer, reached from the other side, in blunter language. The policy says apps that require or accept payment for in-app features, services or digital content must use Google Play's billing system "for those transactions unless Section 3, 8, or 9 applies". Section 3 then opens with the cases where Play billing must not be used, and its first two entries are the purchase or rental of physical goods and the purchase of physical services. Read on 14 October 2026. Note the direction of that sentence. It is a prohibition, not a carve-out you opt into.

The examples Google gives for physical services are worth reading out loud if you are building for a restaurant: transportation services, cleaning services, airfare, gym memberships, food delivery and tickets for live events. Food delivery is on the list by name, and a table with a meal at it is the same kind of purchase. So on Android a booking deposit goes through your own processor, and Play billing is not an option you turned down. It is an option the policy closes.

Two pieces of scope keep this honest. Section 3 turns on what the payment is mainly for, so a single charge that bundles a meal with digital content is not automatically outside Play billing, and the cleanest fix is to stop bundling. And Sections 8 and 9, the alternative billing and outside-app payment link programmes, are about digital purchases in eligible countries and depend on enrolling in a programme. They are not a route a deposit needs, and citing them for a restaurant booking suggests you have read the wrong section.

The practical upshot across both stores is a relief rather than a burden. Your reservation app does not carry two payment implementations, one per platform. It carries one card flow, one processor and one receipt, and the store takes nothing, because what you sold was dinner. The work that remains is consent, timing and telling people what you are about to charge them for.

Google Play Console Help, Payments policy, Sections 2 and 3, read 14 October 2026

How do you take a deposit or a no show fee without a chargeback?

Store policy is the easy half of this. The hard half is consent, and no guideline helps you there. Take the card when the booking is made, not when the party walks in. Put the amount and the cancellation window on the same screen as the button that confirms the table, in words a tired person reads in one pass: a figure, a deadline, and what happens after the deadline. A deposit somebody does not remember agreeing to comes back as a chargeback, and the bank reads your screens, not your intentions.

Separate the authorisation from the charge. A deposit against the bill and a no show fee are two different events that both start at the moment of booking. One is money you intend to hand back as food. The other is money you only take if nobody arrives. Most processors will save a payment method for later use, which is the mechanic a no show fee wants, because it leaves the charge until there is something to charge for. Check what your provider calls it and what it asks of you before a card can be charged with the customer not present.

Then the messages, which are not decoration, because most of the no show problem is a reminder problem. A confirmation at the moment of booking. A reminder the day before with a one tap cancel inside it, so the easiest thing a wavering guest can do is give you the table back. And a waitlist offer that reaches somebody standing in a car park, which needs a channel that works while your app is closed, so push notifications or a text rather than email. Give every waitlist offer an expiry, and never offer one table to two people, or the queue starts lying to everybody in it.

Last, store the terms with the booking rather than in a settings screen. If you move the cancellation window from forty eight hours to twenty four, every booking already in the book was agreed under the old terms, and reading the current setting at the moment you charge quietly rewrites history for people who never saw the new number. The same goes for the deposit amount. Copy it onto the booking row when it is created, and charge what the guest actually agreed to.

Apple, App Store Review Guidelines, guideline 3.1.3(e), read 14 October 2026