A cancellation policy is two rules and one piece of plumbing.

What should a cancellation window actually be?

As long as it takes you to refill the slot, and not an hour longer. That is the whole calculation, and there is no published standard to borrow instead. A barber with a standing waiting list might refill a four o'clock in minutes, so a short window costs almost nothing and makes customers feel fairly treated. A clinic booking six weeks out cannot refill a Tuesday morning on Monday night, so its window runs in days. If you pick a window longer than your refill time, you are charging people for an empty chair you were always going to fill, and they will notice.

Store it as a number of hours before the slot starts, never as a clock time. Hours before start survives a customer in another timezone, a slot that moves when you reschedule it, and the two weekends a year when daylight saving shifts the local clock under you. Every comparison then becomes one subtraction against the slot's start, in a single timezone you own, and you can print the deadline in the customer's own local time without ever storing it that way.

Decide what happens exactly on the boundary before anybody argues about it. A cancellation that lands one minute late is the single most common complaint in this part of a booking app, so write the rule down as a comparison you can read out: a cancellation is free when the slot starts more than the window away from now. Then add a grace period you never advertise, a quarter of an hour or so, and let it absorb slow typing, flaky signal and clocks that disagree. Nobody complains about a fee that silently did not happen.

The one feature that reduces late cancellations more than any fee is a reminder that arrives while cancelling is still free. Send it a few hours before the window closes rather than the night before the appointment, and put the cancel action in the message itself. That turns your fee into something people can avoid, which is the point of having one. A booking app without push notifications collects more fees and keeps fewer customers.

Does a late cancellation fee have to go through in-app purchase?

No, and on iOS it is not allowed to. Guideline 3.1.3(e), Goods and Services Outside of the App, 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. An appointment with a dentist, a dog groom and a table for two are all consumed outside the app, so the deposit, the late fee and the no-show fee all travel by card. This is a must, not a may.

Now the part worth being honest about. Apple's guidelines say nothing at all about charging for a service that was never delivered. Read the document on 14 October 2026 and the words no-show, cancellation, deposit and never delivered do not appear in it. There is no guideline that permits a no-show fee and none that forbids one, because that is not what the guidelines are for. They decide the route the money takes. Whether you are entitled to keep a fee for an appointment that did not happen is a contract and consumer law question in the country your customer sits in, and the answer is not the same everywhere. If somebody tells you Apple approves of no-show fees, they are describing a document that does not exist.

Two neighbouring rules decide the edge cases. Guideline 3.1.3(d), Person-to-Person Services, allows a purchase method other than in-app purchase for the purchase of real-time person-to-person services between two individuals, naming tutoring students, medical consultations, real estate tours and fitness training. The sentence after it is the trap: one-to-few and one-to-many real-time services must use in-app purchase. A private lesson held over video can go on a card. The same trainer streaming to eight people cannot. And guideline 3.1.1 still owns anything that unlocks features inside the app, so a paid membership that happens to waive your cancellation fees puts two separate payment systems in one product.

One more line in the same section catches people who read only the subsection that suits them. The preamble to 3.1.3 says that apps in that section 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 forth in 3.1.1(a) and 3.1.3(a). It does not undo the requirement in 3.1.3(e), which tells you outright to collect real-world service payments by other means. It does mean that steering copy about avoiding store billing belongs nowhere near a screen where in-app purchase would otherwise apply.

Apple, App Store Review Guidelines, read 14 October 2026

How do you charge a card when the customer is not there?

In two steps, and the first one happens weeks before you need it. Stripe's Setup Intents API, in its own words, lets you save a customer's payment details without an initial payment, and the documentation names this exact situation: one-time payments with a final amount determined later, often after the customer receives your service. So at booking you create a SetupIntent, collect the card, and keep the resulting payment method against the customer. Nothing is charged. The booking screen stays free, which is usually what the owner wanted anyway.

Then the slot passes and nobody came. You create a PaymentIntent with the amount, the currency, the saved payment method, the customer, and two flags that do the work: off_session set to true, which tells Stripe the customer is not in your checkout flow to respond to any authentication requests, and confirm set to true, which confirms the payment immediately. Stripe is explicit about what off_session buys you and what it costs. It will request exemptions using information from a previous on-session transaction, and if the conditions for an exemption are not met, the PaymentIntent might throw an error.

That error is the failure path you have to build, and it is the reason this is not a normal payment. When the attempt fails, the request comes back with a 402 status and the PaymentIntent sits on requires_payment_method. Stripe's instruction is to notify the customer to return to your application to complete the payment, by email or an in-app notification. If the decline code is authentication_required, you take the declined PaymentIntent's client secret and hand it to confirmPayment so the customer can authenticate the charge themselves. Which means the honest version of a no-show fee includes a screen where somebody who already did not turn up is asked to approve a payment. Price that reality in before you promise an owner their fees collect themselves.

Three smaller details that cost an afternoon each. Strong customer authentication rules require you to authenticate the customer up front if you intend to collect payments from them again later, and Stripe warns that a customer who never authenticated initially may have future payments declined and be asked for extra authentication, so the save step is not optional paperwork. Stripe also notes that when you save a payment method without an initial payment, Radar does not act on the SetupIntent by default, which you turn on in the Radar settings. And card-present transactions, meaning card details taken through Stripe Terminal at the counter, use a different process for saving the payment method entirely.

All of that assumes you are holding cards yourself. If the app also sells a membership, you are running store billing and a card processor side by side, and the two have different refund rules, different receipts and different places to look when a number disagrees. That is a decision worth making deliberately rather than by accident, and which payment layer to use lays the two out side by side.

Stripe, save a customer's payment method without making a payment, read 14 October 2026

What has to be on the screen before you take the booking?

Stripe puts this duty on you in plain terms, and it is worth reading as a product spec rather than legal boilerplate. You are responsible for your own compliance with the laws, regulations and network rules that apply when you save a customer's payment details. You add terms to your app that state how you plan to save those details, and you let customers opt in. The line that decides your screen design is this one: when you save a payment method, you can only use it for the specific usage you included in your terms. Save a card for a deposit and then quietly charge a no-show fee on it, and you are outside the usage you described.

Stripe lists four things the terms have to include before you charge somebody who is offline. The customer's agreement to your initiating a payment, or a series of payments, on their behalf for specified transactions. The anticipated timing and frequency of those payments. How you determine the amount. And your cancellation policy, if the payment method is for a subscription service. It also tells you to keep a record of the customer's written agreement to those terms, and suggests an explicit control to collect consent, offering a save my payment method for future use checkbox as the example. A tick box that is already ticked is not consent you would want to defend.

Translated into a booking confirm screen, that is four lines and one control. The window, in words, with the actual deadline in the customer's own local time. The fee, as a number, not as a percentage of something they have to work out. When you take it, so after the window shuts or after the slot passes. The sentence that says you are keeping the card to do it. Then the checkbox, unticked. Repeat all five in the confirmation message, because that is the thing people still have in their pocket three weeks later when they are deciding whether to be annoyed with you. If you take the deposit with Apple Pay, guideline 4.9 also requires you to provide all material purchase information to the user prior to sale of any good or service.

The last thing to build is the override, and it is the one nobody specs. Give the owner a button that waives a fee in one tap, with a note field, because often enough the right answer is to let it go: a funeral, a hospital, a first-time regular. A policy you can bend on purpose keeps people. Running that waiver through the same ledger you use for a loyalty card app means the goodwill shows up in the same place as the revenue, where the owner can see what the kindness cost and whether it worked.

Stripe, compliance requirements for saving payment details, read 14 October 2026