How much notice does a late cancellation fee need?

Neither Apple nor Stripe sets a window, so this is your policy and your country's law, not a platform rule. What the platforms do require is that the window you pick is written down before you charge. Stripe asks your terms to state the anticipated timing and frequency of payments and how you determine the amount. In practice the window is a business decision about how long it takes you to resell the slot, and the app's job is to store the version of the policy each booking was made under, because changing the fee next month must not change what last month's customer agreed to.

Do I need the customer's permission to keep their card on file?

Yes, and Stripe is specific about what permission means. Its documentation tells you to add terms to your website or app stating how you plan to save payment method details and to let customers opt in, and says that when you save a payment method you can only use it for the specific usage included in your terms. To charge someone who is offline it also wants their agreement to you initiating payments on their behalf, the anticipated timing and frequency, how the amount is determined, and your cancellation policy if the method is for a subscription. It adds that you should keep a record of the customer's written agreement.

Does Apple take a cut of a no show fee?

Apple's commission applies to in-app purchase. A no show fee for a service consumed outside the app does not go through in-app purchase at all, because guideline 3.1.3(e) requires another method, so the money never touches Apple's billing. The costs you do pay are your payment processor's, on both the original booking and the fee. One consequence catches people out: because the charge is yours, the refund, the chargeback and the customer argument are yours too. Apple will not be mediating any of it.

Can I charge a no show fee for a group class?

The guidelines do not settle this one, and pretending otherwise is how a binary gets rejected. Guideline 3.1.3(d) says one-to-few and one-to-many real-time services must use in-app purchase, so a seat in a twelve person class is sold through Apple. A fee for missing that class is not unlocking anything inside the app, which points away from in-app purchase, but the seat it relates to was an in-app purchase. If group classes are your business, ask App Review for a ruling before you build the flow rather than after your first rejection.

What does the app need to store so a disputed fee holds up?

Four records, and the fee is the least important of them. The version of the cancellation policy the booking was made under, stored as text rather than a link to a page you will later edit. The consent event, with who agreed, when, and to which version. The appointment's own state, including who marked it as a no show and when. And the charge attempt with its decline code, because an authentication failure is a different conversation from an empty account. Stripe's instruction to keep a record of the customer's written agreement is the one that decides a chargeback.

Articles · GuidesUpdated October 2026

A no show fee is a real world charge, so it never goes through in-app purchase.

Q: What happens if the saved card declines when I charge the no show fee?

Stripe documents the path. When an off session payment attempt fails, the request fails with a 402 HTTP status code and the PaymentIntent status is requires_payment_method. Stripe says you must notify your customer to return to your application to complete the payment, for example by sending an email or an in-app notification. If the decline code is authentication_required, you take the declined PaymentIntent's client secret and call confirmPayment so the customer can authenticate. That means your booking record needs a fee pending state, and your app needs a screen the customer can land on from a push.

A no show fee is money you take from a customer who booked a slot and did not turn up. In an iOS app you collect it on a saved card or with Apple Pay, not through in-app purchase, and that is not a preference. Apple's App Review Guideline 3.1.3(e) 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. A haircut is consumed outside the app. So is a dental check, a lane at the pool and a table for four. Most of this work sits inside a booking app for business.

One warning before the detail. The hard part of a no show fee is not the charge. It is the consent you collected weeks earlier, the record that proves it, and the screen you show when the bank asks for authentication and the customer is nowhere near their phone.

Start here

The short version

Collect it like a card payment, not like a purchase in the app.

A no show fee is a charge against a card you saved earlier, taken after the slot has passed. Apple requires it to go outside in-app purchase, because the service was consumed in the real world. Stripe gives you the two calls that make it work: save the card with no payment at booking time, then charge it when the customer is offline and the appointment has been marked as missed.

The failure modes are not technical. They are a consent record you cannot produce, a card that was never authenticated at booking so the bank declines the later charge, and no screen for the customer who now wants to argue. Build those three and the fee mostly collects itself. Skip them and you have written a feature that generates refunds.

Does a no show fee have to go through in-app purchase?

No, and the wording goes further than that. People go looking for an exemption. What Apple actually writes is an instruction. Guideline 3.1.3(e), Goods and Services Outside of the App: 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. Must, not may. Billing a missed haircut through in-app purchase is the rejection, not the cautious option.

The line Apple draws is about where the thing is consumed, not about who is paying or how annoyed they are. Guideline 3.1.1 says that to unlock features or functionality within your app you must use in-app purchase, and it names subscriptions, in-game currencies, game levels, access to premium content and unlocking a full version. A haircut is not a feature of your app. Neither is a table, a dental check or a lane at the pool. The appointment happens in a room, and the money for a missed appointment follows the room.

One neighbouring rule matters if you sell time rather than slots. Guideline 3.1.3(d), Person-to-Person Services, says that if your app enables the purchase of real-time person-to-person services between two individuals, and it names tutoring students, medical consultations, real estate tours and fitness training, you may use purchase methods other than in-app purchase. The same paragraph then closes a door: one-to-few and one-to-many real-time services must use in-app purchase. A one to one coaching call is yours to bill. A twelve person online class is Apple's.

And one case the guidelines do not settle. If a seat in a group class was sold through in-app purchase, nothing Apple publishes says which rail a fee for missing that class belongs on. It unlocks nothing in the app, which points away from in-app purchase, but the seat itself was an in-app purchase. If that is your business, ask App Review before you build the flow. A wrong guess is a rejected binary, not a warning.

Last thing, because it wastes people a morning. Guideline 3.1.5 is about cryptocurrencies: wallets, mining, exchanges and coin offerings. It has nothing to do with real world services. If somebody points you at 3.1.5 for a no show fee, they have the wrong number, and the one you want is 3.1.3(e).

Apple, App Review Guidelines, section 3.1, read 14 October 2026

How do you charge a card after the customer has left?

In two steps, weeks apart. Step one saves the card while the customer is in front of you. Step two charges it when they are not. Stripe calls the second one an off session payment, meaning a payment that happens without the direct involvement of the customer, using payment information you collected earlier.

Step one is a SetupIntent. Stripe's own description is that the Setup Intents API lets you save a customer's payment details without an initial payment, which is exactly what a booking screen needs. The appointment is confirmed, the card is collected and verified, and nothing is taken. Strong Customer Authentication is why this step is not optional. Stripe states that SCA regulation requires you to authenticate your customer up front if you intend to collect payments from them again in the future, and that if the customer never authenticated initially, their bank might decline future payments and ask for additional authentication. Skip the authentication at booking and you have built a fee you cannot collect.

Step two is a PaymentIntent, created on your server the moment somebody marks the appointment as a no show. Stripe documents the parameters. Set off_session to true, which tells Stripe the customer is not in your checkout flow to respond to any authentication requests. Set confirm to true, so the charge runs as the intent is created. Set payment_method to the saved method's id. And identify the person, with either the customer id or the customer configured account id, depending on how your integration represents people. Stripe also notes that when a partner such as a card issuer asks for authentication, it will request an exemption using information from an earlier on session transaction, and that the intent might throw an error if the conditions for exemption are not met.

Then the part nobody builds until the first complaint. When the attempt fails, the request fails with a 402 and the PaymentIntent's status is requires_payment_method. Stripe says you must notify your customer to return to your application to complete the payment, for example by sending an email or an in-app notification. If the decline code is authentication_required, you take the declined PaymentIntent's client secret and call confirmPayment so the customer can authenticate. In app terms that is a push, a screen and a fee pending state on the booking. Most of adding payments to a booking app is this unhappy path, not the happy one.

If you have not picked the plumbing yet, decide which payment layer to use before you write the booking screen. A store billing layer is built for subscriptions and unlocks inside the app. It cannot save a card and charge it a week later for a service that happened in a room, which is the entire job here.

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

What has to be in your terms before you charge it?

Stripe is blunt about this, and it is the part a booking app skips. Its documentation says you are responsible for your own compliance with applicable laws, regulations and network rules when saving a customer's payment details, and tells you to add terms to your website or app that state how you plan to save payment method details and allow customers to opt in. Then the sentence that decides whether your fee is collectable: when you save a payment method, you can only use it for the specific usage you have included in your terms.

So the terms have to name the fee. A card saved for convenience cannot be charged for a penalty nobody mentioned. Stripe lists four things your terms must include before you charge a customer who is offline. Their 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 then adds the line that decides disputes: keep a record of your customer's written agreement to these terms.

Consent has to be a real action, taken for this purpose. Stripe gives the example directly: a save my payment method for future use tick box, used to collect consent explicitly for that specific use. A box that arrives pre-ticked, or a sentence in a footer nobody opened, is neither explicit nor a record. Store the version of the policy the customer agreed to, and the moment they agreed, on the booking row itself. Six months later that row is the whole of your evidence.

Stripe, compliance when saving payment details, read 14 October 2026

Check yours

Can you charge that card yet?

Tick what your terms and your booking screen already do. Every item below is something Stripe documents as a requirement for charging a customer who is offline.

Still open before an off session charge:

Terms say they agree to you starting the payment

Stripe lists the customer's agreement to your initiating a payment, or a series of payments, on their behalf for specified transactions.

Terms say when and how often you may charge

Stripe asks for the anticipated timing and frequency of payments. For a no show fee that is: once, after a missed slot.

Terms say how the amount is worked out

Stripe asks how you determine the payment amount. A flat fee, a percentage of the booking, or the deposit already held.

The terms name the no show fee itself

Stripe says a saved payment method can only be used for the specific usage included in your terms. Convenience is not a penalty.

The customer opted in with a tick box

Stripe's own example is a save my payment method for future use checkbox, collected explicitly for that use.

You kept a dated record of that agreement

Stripe says to keep a record of your customer's written agreement to these terms. A single boolean column is not a record.

The card was authenticated while they were present

Stripe says SCA requires you to authenticate the customer up front if you intend to collect again later, or their bank might decline.

Stripe's requirements, not legal advice. Your card network and your country may ask for more.

What does the app have to store and show?

Four records, and the fee is the least interesting of them. The first is the policy the customer agreed to, stored as text with a version, not as a link to a page you will later edit. If you raise the fee next month, the booking made last month is still governed by the old wording, and you need to be able to show which one applied.

The second is the consent event: who agreed, when, to which version, and what they actually ticked. A boolean column named accepted_terms is not a record. A row with a timestamp and a policy version is.

The third is the appointment's own state, and this is where most booking apps are thin. Booked, confirmed, cancelled inside the window, cancelled late, no show, waived. A no show is a state a human sets, usually a receptionist, usually twenty minutes after the slot began. The app has to let them set it, and let them undo it, because they will. The fourth is the charge attempt with its outcome, and not just succeeded or failed. Store the decline code, because an authentication problem is a different conversation from an empty account.

Two screens pay for themselves. One is a staff screen with a single button that waives the fee and asks why, because the alternative is a refund, and a refund costs you the processing fee and twenty minutes. The other is a customer screen that explains the charge after it lands, shows the policy they agreed to and the date they agreed to it, and offers a way to reply. Most arguments about a no show fee are not about the money. They are about being charged by something that never explained itself.

The same fee, a different rail depending on what was booked

The amount is identical in every row below. What changes is the rail Apple allows, and whether you had to put a card on file in advance to be able to use it. Guideline numbers are from the App Review Guidelines as they read on 14 October 2026.

What was booked	Guideline that covers it	Rail Apple allows	Needs a card on file
A missed salon or clinic appointment	3.1.3(e), goods and services outside of the app	Anything but in-app purchase: Apple Pay or card entry	Yes
A deposit taken when the booking is made	3.1.3(e), goods and services outside of the app	Anything but in-app purchase	No
A one to one consultation billed afterwards	3.1.3(d), person-to-person services	Anything but in-app purchase, Apple says you may	Yes
A seat in a one to many live class	3.1.3(d), person-to-person services	In-app purchase, Apple says must	No
A membership that unlocks content in the app	3.1.1, in-app purchase	In-app purchase	No

Where this lands if a builder generated your app

Nothing about the payment rail changes because an AI wrote the code. You still collect the fee outside in-app purchase, you still own the terms, and on iOS you are still the one who presses submit. App Review Guideline 4.2.6 is why: 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. Read on 14 October 2026.

Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so the payment code is code you can read and a lawyer can be shown. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store on your behalf, for the reason above. It costs $25 a month and there is no free tier. Budget for the rest of the launch as well, which is what it costs to publish an app.

The honest limit is the half a generator cannot touch. It will give you the booking model, the consent row, the saved card and the off session call, and it will do that in an afternoon. It cannot pick your cancellation window, write terms that hold up where you trade, or tell a receptionist when a late arrival becomes a no show. Those three decide whether the fee gets collected or disputed, and all three are yours.

Apple, App Review Guidelines, guideline 4.2.6, read 14 October 2026

Questions people ask about no show fees

No, and the guideline is an instruction rather than an exemption. App 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. Read on 14 October 2026. A missed haircut, dental check or table booking is consumed outside the app, so it is collected on a card, not through Apple's billing.

Write the policy first, then build the screens

Decide the window, the amount and the exact wording before you write a line of the app. Everything above becomes a day of work once the policy exists, and an argument that never ends if it does not.

Start building