Stripe capture vs authorization for solo beauty deposits: when each one fits

April 25, 2026 · 9 min read · back to blog

When a client books a $40 deposit for a haircut next Thursday, you have two ways to handle the card on Stripe: take the money right now (a capture), or put a temporary hold on it and only move the money on the day of the appointment (an authorization followed by a later capture). Most solo pros default to capture-now without realizing the second option exists, because every booking tool that ships Stripe Checkout uses it by default. But the authorization-then-capture model is the right answer for a meaningful slice of the work — particularly high-ticket bridal, full lash sets, color correction, and any deposit you'd consider refundable up until the appointment. This post walks through exactly when each one fits, the 7-day authorization window that bounds the choice, and how to actually configure both in your Stripe account or any booking tool that lets you choose.

The two modalities, defined exactly

Stripe's PaymentIntent object has a parameter called capture_method. It takes one of two values that matter for solo-pro deposits:

• automatic (the default) — the moment a client successfully authenticates their card on the checkout page, Stripe authorizes the card AND moves the funds in the same step. Money lands in your Stripe balance immediately. This is what people mean by "taking the deposit" in casual language. It's what ChairHold, Square Appointments, Booksy, Fresha, and virtually every other "deposit-at-booking" tool does out of the box.
• manual — the moment a client successfully authenticates, Stripe authorizes the card (puts a hold on the funds, the same way a hotel or rental-car company does) but does NOT move the money. The hold sits open for up to 7 days. You — or your tool, on a scheduled trigger — call Stripe's capture endpoint on the day of the appointment to actually move the money. If you cancel the authorization before capture, no money ever leaves the client's account; the hold just drops off their statement within 1-3 business days.

Both modalities use the same checkout flow from the client's perspective. Both create the same on-statement notification ("AUTH HOLD: CHAIRHOLD" vs "PAYMENT: CHAIRHOLD" — the wording differs by issuer, but most clients don't notice the distinction). Both are 2.9%+30¢ when captured. The difference is entirely in when the money moves and what happens if you cancel.

The 7-day window — what it actually means

A Stripe authorization is good for 7 days on a standard online card payment, after which it expires automatically. If you don't capture within 7 days, the hold falls off the client's account and the funds are gone — you can't extend it, you'd need to re-authorize against the same card (which requires the client to be back in checkout flow, defeating the point).

This window is the single biggest constraint on the model. If the appointment is more than 7 days from the booking date, an authorization can't reach it. A solo barber whose typical lead time is 2-5 days is fine. A bridal artist booking 6 weeks out is not — they need to use immediate capture (or a different bridge tool, see below). A lash artist booking a full set 10 days out is on the edge: an auth at booking-time would expire 3 days before the appointment.

There's a separate construct called an extended authorization that some platforms can request from the card networks for up to 30 days. It's gated to specific MCC codes (mostly hospitality + car rental + cruise lines), is not generally available to beauty-services merchants, and Stripe does not expose it for self-serve enablement. Don't plan around it — for a solo beauty pro, the 7-day window is the binding constraint.

Why most solo beauty pros default to immediate capture

There are three reasons capture-now is the right default for the majority of the solo-pro market, and it's worth naming each one before talking about when to switch off it.

1. The money's actually yours. Cash flow for a solo operator is 70% of the game. Captured funds hit your Stripe balance the same day, payout to your bank in the standard 2-day window, and are real working capital — supplies, booth rent, taxes. Held funds aren't your money yet; they're your client's money on a string. You can't pay your supplier with an authorization.
2. No-show protection is the whole point. The reason a deposit exists is to make a no-show financially symmetrical. If the client knows the money is sitting in your account already, the cancellation friction is real — they have to ask you for a refund. If they know the money's only on hold and will be refunded silently when they ghost, the friction evaporates. The behavioral economics of capture-now are stronger than authorization-now for the no-show prevention case, which is the headline reason 95% of solo pros take a deposit at all.
3. Refund flow is one click either way. People imagine the auth model is "easier to refund because you just don't capture" — but in capture-now, a refund is one button in the Stripe Dashboard, takes 5 seconds, and the client sees the refund pending on their card within minutes. The operational difference vs canceling an auth is essentially zero. The Stripe processing fee (2.9%+30¢) is NOT refunded by Stripe on a refund of a captured charge — that's a real $1.46 hit on a $40 deposit refund — but a canceled authorization never charges you that fee in the first place. So there's some fee math difference, but it only matters at high refund rates (covered in the decision matrix below).

When authorization-then-capture wins

Switch off the default in the following shapes:

• Patch-test or consultation gate. If the appointment is contingent on something happening between booking and service — a 24-hour patch test for color or lash chemicals, a phone consult to confirm hair type, a fit check for a wig — you don't actually know the appointment is going forward at the moment of booking. Authorize at booking, capture after the gate clears. If the patch test fails, cancel the auth, no money moved, no chargeback risk, no "why am I paying you for an appointment I can't have" client friction.
• Contingent pricing. Color correction, weave/extension installs, microblading touch-ups — services where the final price isn't knowable until you see the work in person. Authorize for the upper bound at booking; capture the actual amount on the day. Stripe lets you capture for less than the authorized amount (any amount up to the auth ceiling) without a second client interaction. You CANNOT capture for more — if the actual price came in over the auth, you'd need a fresh charge for the delta.
• High-ticket where holds feel softer. On a $200+ deposit for bridal trial or full lash set, some clients balk at the immediate hit. An authorization feels like a card check — "we're verifying your card works, the actual charge runs the day of." This is behaviorally true (you ARE only charging the day of) and it tends to convert better at the >$150 deposit tier. Below ~$75, the conversion difference is negligible and the cash-flow loss isn't worth it.
• Low-trust new client + reschedule risk. A client you've never worked with who booked through a channel you don't fully trust (random IG DM, a referral from someone you barely know) is statistically more likely to reschedule once before the actual appointment. Authorize at booking; if the first reschedule is more than 7 days from original booking, cancel the auth and re-authorize on the rebooked appointment. This pushes some friction onto the client but they self-select — serious clients won't mind, time-wasters drop off.
• Refund-rate above ~12%. If your historical refund rate on captured deposits is above ~12%, the cumulative non-refunded Stripe fees ($1.46 per $40 deposit refunded) start to outweigh the cash-flow benefit of capture-now. At 100 bookings/month with a 15% refund rate, that's 15 × $1.46 = $21.90/month in fees on money you didn't keep. Auth-then-capture eliminates that bleed by simply never charging Stripe for the refunded ones.

The paste-ready PaymentIntent config

If you're building your own checkout (or working with a developer on a custom Stripe Payment Link variant), here's the actual API call. Both modalities use the same endpoint; the only difference is one parameter:

// Authorization-then-capture (manual capture method)
const intent = await stripe.paymentIntents.create({
  amount: 4000,                      // $40.00 in cents
  currency: 'usd',
  payment_method_types: ['card'],
  capture_method: 'manual',          // <-- the magic word
  description: 'Haircut deposit, Aug 4',
  receipt_email: client.email,
  metadata: {
    appointment_id: 'apt_2026_08_04_1330',
    service: 'haircut',
    client_id: client.id,
  },
});

// On the day of the appointment:
await stripe.paymentIntents.capture(intent.id);
// Or capture less than the authorized amount:
await stripe.paymentIntents.capture(intent.id, {
  amount_to_capture: 3500,           // $35 of the $40 hold
});

// Or cancel before capture (no money moves, no fee):
await stripe.paymentIntents.cancel(intent.id);

That's the entire technical surface area. The capture_method: 'manual' flag is everything. Everything else is the same checkout flow your clients already see.

If you're using Stripe Checkout (the hosted page) rather than building your own form, you set the same flag in the Checkout Session creation:

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [{ price_data: { /* ... */ }, quantity: 1 }],
  payment_intent_data: {
    capture_method: 'manual',        // <-- here for Checkout
  },
  success_url: 'https://yourbookingpage.com/booked',
  cancel_url: 'https://yourbookingpage.com/cancel',
});

Stripe Payment Links (the no-code, dashboard-created links) do NOT currently expose capture_method: 'manual' in the dashboard UI — they're hardcoded to immediate capture. If you want auth-then-capture without writing code, you need either Stripe Checkout via API (or via a tool that does it for you) or a third-party booking tool that exposes the toggle. As of April 2026, the booking tools that explicitly support auth-then-capture for service deposits are a small set: Acuity (with a custom Stripe app integration), Square Appointments (called "Card on File hold" — slightly different mechanic, same behavior), and a handful of industry-specific tools.

Mixing them: deposit-capture + pre-auth-balance

The most powerful pattern for high-ticket solo work is to use BOTH at once: a small immediate-capture deposit (to lock in the no-show economics and put real money in your account) AND a separate authorization for the remaining balance (to lock in payment for the service without holding the full amount yet). The client sees two charges on their statement at booking — one capture, one hold — and the math works out clean on the day of.

Concrete example for a $400 bridal trial:

• Booking-time charge 1: $50 immediate capture (the no-show deposit, your money the moment they pay).
• Booking-time charge 2: $350 authorization hold (the appointment-day balance, sitting on their card).
• Day of trial, after service complete: capture the $350 hold. Now you have the full $400, the client has been charged once at booking and once at service, and they had no "surprise" because both holds appeared at booking.
• If the client cancels with sufficient notice and you choose to refund the deposit per your published policy: refund the $50 captured deposit (eat the $1.16 fee on the captured deposit per your policy), cancel the $350 hold (no fee).

The split-charge pattern requires you to have a tool that can issue two separate PaymentIntent calls in one checkout flow, which most no-code booking tools do not support. It's straightforward in custom-built or API-integrated checkouts. It's the right pattern for the bridal/extension/lash-set tier and we'd recommend it strongly for any deposit work above ~$200, even though v1.0 of ChairHold (immediate capture only) doesn't ship the split pattern yet — that's on the v1.2 roadmap, called "deposit + final" in our planning notes.

Common gotchas

Five things that bite people the first time they switch to or mix in the auth-then-capture model:

• Auth expiry sneaks up on you. If you forget to capture within 7 days, the hold drops and your money is gone. Set a calendar reminder for every authorized appointment. Better — automate the capture trigger in your tool. Best — set it to fire 24 hours BEFORE expiry rather than on the day of, so a forgotten Sunday capture has Saturday to recover.
• Partial captures forfeit the rest. If you authorize $40 and capture $30, the remaining $10 of authorization is automatically released — you CANNOT capture the rest later as a second pull. If there's any chance you'll capture more than you initially expected, authorize for the upper bound, not the typical case.
• Some cards don't honor 7-day holds. Most US-issued credit cards do. Some debit cards (particularly older Visa/Mastercard debit) drop holds at 3-5 days regardless of what Stripe sends. Some prepaid cards drop holds in 24 hours. There's no reliable way to know in advance. Treat the 7-day window as a target, not a guarantee, and capture as soon as the gating event clears (not at the last possible moment).
• Chargeback dynamics differ. A chargeback can be filed against an authorized-but-not-captured transaction, but you'll typically win it automatically because no money moved. A chargeback against a captured-then-refunded transaction (client refund-shopping after the fact) is harder to win and can hit your dispute-rate ratio with Stripe and the card networks. See the chargeback-response post for the full evidence bundle. The auth model has a smaller chargeback surface area in absolute terms.
• Client-side wallet behavior. Apple Pay and Google Pay both support capture_method: 'manual' on the Stripe side, but some wallet apps display authorized transactions differently than captured ones (Apple Wallet shows "Pending" on holds, "Cleared" on captures). Most clients aren't confused by it but a small fraction will message asking why they were "charged twice" if they see the auth show up first and the capture show up later. Pre-empt with a line in your booking confirmation: "Your card will show a hold today and a final charge on the day of your appointment."

Decision matrix

If you don't want to think about it post-by-post, here's the rule of thumb by service type:

If you want a single rule with no nuance: capture now if the appointment is < 7 days out and the price is known and there's no patch-test gate; otherwise pick the model that matches the constraint that bites first.

What ChairHold ships

Honest disclosure since the IDENTITY of this site is build-in-public:

• v1.0 (current): Immediate capture only. Set the deposit amount, share the link, money lands in your Stripe the second a client books. This covers the 90% of solo-pro deposit work where capture-now is the right answer.
• v1.1 (planned, no commitment date): Optional capture_method: 'manual' per-link setting in your dashboard. Picks up the patch-test + contingent-pricing + low-trust-new-client cases.
• v1.2 (further out): Split-charge support — one immediate capture + one held auth at booking, with day-of capture flow for the held side. Picks up the bridal/lash-full-set tier.

If your work is heavily v1.1 / v1.2 shaped — bridal-only, PMU-only, color-correction-only — you'll be better served by Acuity or Square Appointments today. We're not the right fit for that volume yet. We will be later. The honest answer for now: hop on the waitlist and we'll email when v1.1 ships if your use case needs it. Don't switch tools before the feature lands.

FAQ

Does Stripe charge the 2.9%+30¢ on the authorization or only on the capture?

Only on the capture. An authorization that's never captured costs you nothing in Stripe processing fees. (You pay zero for the auth itself; the 2.9%+30¢ runs against the captured amount when you capture.) This is part of the fee-math win for high-refund-rate operators — see the fee math post for the worked numbers.

What if I forget to capture an authorization within 7 days?

The hold expires automatically and the funds return to the client's available balance. You'd have to re-authorize, which requires the client to be back in checkout with their card — defeating the point. Set a reminder, automate the capture, or default to immediate capture for any appointment you might forget about. The 7-day window is hard.

Can I extend a 7-day authorization?

No, not on a standard MCC. Extended authorizations (up to 30 days) exist for hospitality and car-rental MCCs but are not available to beauty-services merchants and Stripe doesn't expose the toggle for self-service. Plan around the 7-day window.

If I use auth-then-capture, can the client see the hold on their statement?

Yes. Most issuers show authorized transactions as "Pending" with the auth amount and your statement descriptor. Most clients don't notice. The minority that do will sometimes message asking why the charge "hasn't gone through yet" — pre-empt by adding "your card will show a hold today and the actual charge on the day of your appointment" to your booking confirmation.

Is auth-then-capture a workaround for chargebacks?

Not exactly — it reduces chargeback surface area for the cancelled-before-service case (because no money moved) but doesn't help with the captured-then-disputed case (where the client claims the service wasn't as described). The four-piece evidence bundle in the chargeback-response post is what you actually need when a real dispute lands. Auth-then-capture is a prevention layer; the bundle is the cure.

What's the difference between "Card on File" and an authorization?

Card on File (Stripe's setup_intent + saved payment_method) stores the card for future charges WITHOUT placing a hold. You can charge the card later but you have no guaranteed funds availability — if the card has been canceled or maxed, the future charge fails. An authorization places real funds on hold (good for 7 days) so the capture is essentially guaranteed to succeed within that window. For a deposit you want to actually collect, an authorization is materially stronger than card-on-file. For a recurring subscription where the next charge is a month out, card-on-file is the only option (because the auth window doesn't reach a month). Both have their place.

Does the Stripe Tax product apply to authorizations?

Stripe Tax is calculated and applied at capture time, not at authorization time, so the math is the same as the capture-now case but timed differently. If you're in a state that requires sales tax on a beauty-service deposit (very few do — see the state-by-state post) the same 0.5% Stripe Tax product fee applies to the captured amount.