A booking deposit is either money you hold or money you take, and the two behave nothing alike.
Taking a deposit for an appointment is one of three mechanisms, and Stripe documents each of them separately. You can place a hold, which reserves the amount on the card without moving any money. You can take a real payment now and refund it later if you decide to. Or you can save the card, charge nothing today, and charge it if the appointment goes wrong. Stripe calls the first one manual capture, the second is an ordinary payment, and the third is the Setup Intents API. Every figure and parameter name below comes from Stripe's and Apple's own documentation, read on 14 October 2026. If all of this is going to sit behind one button in a booking app builder, the decision underneath the button is still a money decision and not a design one.
What follows is which mechanism fits which kind of booking, how many days a hold really survives before the bank lets the money go, and the store rule that decides how you are allowed to collect it at all. That last one catches people out, because for a real world service Apple points you away from in-app purchase rather than towards it.
Work out which one you needThe short version
Hold the money when the amount is not final. Take it when it is.
A hold is an authorisation and nothing more. The customer sees the amount reserved on their card, you capture it later for the full figure or for less, and a partial capture releases the balance on its own. That is the right shape when you genuinely do not know the number yet. A groom that might take two hours. A table of six that turns up as four. A repair quoted as a range.
A charge is a payment. The money leaves the customer, lands in your balance, and the only way back is a refund. That is the right shape when the deposit is a fixed slice of a fixed price and when you intend to keep it if nobody arrives. Plenty of small businesses want exactly this and reach for the hold instead, because a hold sounds gentler. It is not gentler. It is shorter.
The third option moves no money at all. You collect the card now, authenticate the customer, and keep the details for later. Stripe documents that as the Setup Intents API, which saves a customer's payment details without an initial payment. It is the only one of the three that can sit quietly for a month, which is why it beats a hold for anything booked far ahead.
Should you hold the money or take it?
Start with the mechanics, because the names make the rest readable. To hold money you create a PaymentIntent with capture_method set to manual. Stripe's own example of why is a hotel: authorise in full before the guest arrives, capture when they check out. Once the card is authorised the payment status becomes requires_capture, and an amount_capturable field tells you what is actually there to take. You can also set the manual flag on cards only, through payment_method_options, so that a customer paying by some other method is charged normally instead of being refused.
Capturing takes the full authorised amount by default, or less if you pass amount_to_capture. The sentence worth tattooing somewhere: a partial capture automatically releases the remaining amount, and for most payments you can only capture once. Take sixty of a hundred and the other forty is gone from your reach. Certain online card payments are eligible for multicapture, and some can even be captured above the authorised figure, but a small business should plan as though one capture is all there is. If you need to bill several times, save the card instead and create each payment when you know the number.
Not every payment method can be held. Stripe lists cards, Affirm, Afterpay, Cash App Pay, Klarna and PayPal among those that support separate authorisation and capture, and names bank debits such as ACH and iDEAL among those that do not. The ones that do support it have their own windows, and they are not the card windows. A Klarna charge has to be captured by midnight of the twenty eighth calendar day after the charge request. PayPal holds the amount for ten days and Stripe automatically tries to extend it once, for twenty in total. Afterpay collects the first instalment at authorisation and refunds it if you never capture.
Then the detail that turns into a phone call rather than a bug report. Stripe warns in the same document that card statements from some issuers do not always distinguish between authorisations and captured payments, which can confuse customers. Translated into a shop: the person believes the deposit is paid, you capture the full bill a week later, and they see what looks like two charges. Nothing has gone wrong, but you will spend twenty minutes explaining that. Saying the word reserved on the screen and on the receipt is the cheapest fix available.
Stripe, place a hold on a payment method, read 14 October 2026
Pick your case
Which deposit mechanism fits
Choose the sentence that sounds most like your bookings. The mechanism names are the ones in Stripe's own documentation, so they are what you search for later.
Hold the money, capture the real amount at the end
In Stripe: A PaymentIntent with capture_method set to manual, captured with amount_to_capture. A partial capture releases the rest on its own.
What the customer must be told: Say the amount is reserved and not yet paid, because some card statements do not tell the two apart.
Usual answers, not advice about your contract. Deposit terms are a legal question in most countries and worth ten minutes of someone else's time.
How long can a deposit hold last before it expires?
Seven days, for an online card payment on Visa, Mastercard, American Express or Discover, where the customer is there in the checkout. Stripe publishes the table and splits it by who started the transaction. A merchant-initiated Visa authorisation gets five days, and Stripe notes the real figure is four days and eighteen hours so that clearing has room. Card-present payments through Stripe Terminal are the short ones: five days on Visa, two days on Mastercard, American Express and Discover. An account based in Japan can hold a transaction denominated in yen for up to thirty days on Visa, Mastercard, JCB, Diners Club and Discover, though not on American Express.
Miss the window and the result is not an error you can retry. The funds are released and the payment status changes to canceled. The booking still exists in your app, the money does not, and nobody told you. The authoritative figure is not the table either. Stripe publishes a capture_before timestamp on the charge, inside payment_method_details for the card, and tells you to rely on that field for any given payment because network rules can change without prior notice. Read it when the authorisation succeeds and store it next to the booking.
A longer hold exists and it has conditions. An extended authorisation can reach thirty days, requested by setting request_extended_authorization to if_available in the card payment method options. It is limited to Visa, Mastercard, American Express and Discover. Several networks allow it only for certain merchant categories, mostly lodging, vehicle rental, cruise and passenger transport. For Visa in any other category Stripe charges an extra 0.08% per transaction, and Visa's effective window is twenty nine days and eighteen hours. Stripe offers the feature to accounts on interchange plus pricing. Whether you got it is reported by an extended_authorization status field on the charge, after confirmation, not before.
Put those two facts together and most booking businesses have their answer handed to them. If people book three weeks ahead, a hold is the wrong mechanism no matter how much you like it. Charge the deposit, or save the card and charge nothing. And if you do hold, something has to chase the clock: a reminder to the customer the day before the appointment and an alert to you before capture_before passes. That is a job for push notifications and a daily job on the server, and it is the part people leave until after the first expired authorisation.
Stripe, authorisation validity windows, read 14 October 2026
Does Apple make you use in-app purchase for a deposit?
No, and it is firmer than no. For a service consumed outside the app you are not permitted to use in-app purchase. App Review Guideline 3.1.3(e) is titled 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. The section it sits in is headed with the softer line that these apps may use other purchase methods, but the subsection itself says must.
The test is where the thing is consumed, not where it was bought. A haircut, a table for two, a yoga class in a room, a dog groom, a plumber and a tattoo are all consumed outside the app. A deposit against any of them is collected with Apple Pay or a card form, and Apple takes no commission on that money. This is the single biggest reason a service business should not be scared of the App Store: the fifteen or thirty per cent everybody worries about is not charged on a deposit for real world work.
The other side of the line is just as clear. Guideline 3.1.1 says that if you want to unlock features or functionality within your app, by way of example subscriptions, in-game currencies, game levels, access to premium content or unlocking a full version, you must use in-app purchase. So a bundle of class credits that only means anything inside your app, or a paid tier for your staff features, is the other path, and in-app purchases is how you build it. An app can legitimately have both, with two separate payment paths and two separate sets of receipts.
One sentence in 3.1.3 trips up the apps that do have both. 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 out in 3.1.1(a) and 3.1.3(a). Nothing there stops you taking a card for the haircut. What it stops is nudging a customer out of in-app purchase for the things that do require it. And one more, because it decides who presses submit: guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The salon publishes the salon's app.
Apple, App Review Guidelines, 3.1.1, 3.1.3, 3.1.3(e) and 4.2.6, read 14 October 2026
What does a deposit actually need in the app?
Less than people build, and in a stricter order. The amount and the rule have to appear before the card form, not after it, because that is the moment the customer agrees to something. The receipt has to use the right verb, reserved or paid. The deposit has to be a field on the booking rather than a payment sitting on its own in Stripe, or you will be matching two lists by hand on a Monday morning. Staff need one screen that lists uncaptured money with the date each one dies. And capture has to be one tap from that screen, because the person doing it has a customer in front of them.
The deposit is the small part. The booking is the hard part: two people cannot hold the same slot, a cancellation has to free it, and the time zone has to be the shop's rather than the phone's. If the schedule itself is not built yet, build that first and bolt money on afterwards. What an appointment calendar app has to get right is a longer list than anything on this page, and a deposit attached to a slot that can be double booked is worse than no deposit at all.
Taking money almost always means accounts, because the customer has to come back and find the booking their deposit belongs to. That brings one store rule with it that people meet during review rather than during planning. Guideline 5.1.1(v) says that if your app supports account creation, you must also offer account deletion within the app, read on 14 October 2026. Build the deletion path beside sign-in, and decide at the same time what deleting an account does to a booking with money attached. The answer is usually that the booking survives without the profile, but it has to be a decision rather than a crash.
What to leave out of the first version: part payments, deposits that convert into store credit, and anything automatic that charges a card without a human looking at it. Each of those is a support burden with a refund attached. The version that earns its keep is smaller than that. Ask for the deposit, show the rule, store the payment against the booking, and give one member of staff a button that captures or cancels. Everything else can wait until you have seen a hundred real bookings go through it.
Apple, App Review Guidelines, 5.1.1(v) Account Sign-In, read 14 October 2026
Three ways to ask for money before the appointment
| What you care about | Hold, manual capture | Charge it now | Card on file, no charge |
|---|---|---|---|
| Money leaves the customer today | No | Yes | No |
| How long it survives | 7 days online, 2 to 5 days in person, up to 30 with an extended authorisation | Settled, so no window | No window, the card is stored |
| Final amount can be lower | Yes | No | Yes |
| Giving it back | Cancel the authorisation, nothing was taken | A refund, with the admin that implies | Nothing to give back |
| Safe for a booking a month out | No | Yes | Yes |
| Customer may think they already paid | Yes | No | No |
Where this lands if a builder generated your app
Nothing above changes because an AI wrote the screens. The deposit rule is yours, the Stripe account is yours, and the submission is yours, because guideline 4.2.6 puts the content owner on the submit button. What a builder changes is how long it takes to get the first honest version in front of a customer, which matters here because the deposit question is usually settled by watching people, not by reasoning about them.
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 a contractor can pick it up later. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and produces a standalone Android APK. It does not submit to the App Store for you, for the reason in the paragraph above. It is paid from $25 a month and there is no free tier.
The practical route is to describe the booking flow with the deposit as a single number and a single rule, run it with real customers for a fortnight, and then decide whether you needed a hold at all. Most businesses discover they wanted a charge with a clear cancellation rule, which is the simplest of the three to build and the easiest to explain at the counter. The honest limit is the same for every tool: nobody can write your deposit policy for you, and the policy is the part your customers will argue about.
Questions people ask about booking deposits
A hold is an authorisation. The amount is reserved on the customer's card and no money has moved. Stripe calls the pattern separate authorisation and capture, and you ask for it by setting capture_method to manual on the PaymentIntent. A charge is a settled payment: the money leaves the customer, lands in your Stripe balance, and only comes back as a refund. Hold when the final amount is not known yet. Charge when it is, and when you intend to keep the deposit if nobody turns up.
Describe the booking, then decide what the deposit does
One amount, one rule, one place it is stored. Get that version in front of real customers and the argument about holds against charges answers itself within a fortnight.
Start building