artistryhost
← Operator notes
June 11, 20266 min readoperationspaymentsbooking-policy

Card-on-file booking: when 'pay in-store' beats prepayment

Most booking platforms force operators into a binary choice: full prepayment or no card at all. The third option, card on file charged at the venue, is the right model for a meaningful number of operators. Here's when, and why most platforms don't support it.

Jordan Bishop·Customer success, ArtistryHost team

About a year ago we were on a call with a pottery studio owner who was evaluating booking platforms. She'd just left Acuity. She was looking at Bookeo, FareHarbor, and us. She was clear about what she wanted: customers could book online, hold their seat with a card on file, but actually pay when they showed up in person.

Her reason was specific. She ran walk-in pottery sessions where the final cost depended on what the guest made. A small bowl was $30, a vase was $50, a wheel-thrown plate was $35. She couldn't charge a fixed price up front because the final amount was determined at the end of the session.

She'd been turned down by FareHarbor (forces full prepayment), Peek (same), Bookeo (assumes the booking price is known at booking), and Tock (built for restaurant prepay). The only platforms that handled her flow were generic appointment schedulers like Acuity, which she'd left because the rest of the experience was wrong for her venue.

She represents a real segment of experiential operators who need a third option between "full prepayment" and "no payment information at all." This post is about that segment, and the policy that fits them.

The three booking-payment policies

Almost every experiential booking flow falls into one of three buckets.

Full prepayment. The guest pays the full ticket price at the moment of booking. The booking is confirmed. The transaction is closed. Most experiential venues default to this for public classes, paint-and-sip, candle bars, traditional cooking schools, where the price is known and prepayment reduces no-shows.

Deposit at booking, balance in-person. The guest pays a deposit (typically 30–50%) to confirm the booking, and the balance is settled at the venue. This is the model most venues use for private events and certain higher-priced experiences. It limits chargeback exposure (covered in a separate post) and reduces booking friction at the prepayment step.

Card on file, charged at the venue. The guest provides a card to confirm the booking, but no charge happens at booking. The full amount is charged in person at the end of the experience. This is the model the pottery studio owner needed.

The third bucket exists for a real reason, but it's the bucket most booking platforms don't support.

When card-on-file is the right model

Several scenarios where card-on-file is the operator's right answer.

The price isn't known until the experience is complete. Pottery studios pricing by piece, cooking schools where the guest picks their menu on arrival, salon-adjacent experiential businesses, certain workshop formats. The operator can't pre-charge an amount they don't know.

The class has variable add-ons that are typically chosen at the venue. Some candle bars sell a base experience ($75 per person) plus an upsell ladder that's chosen day-of. Premium vessels ($15), custom labels ($8), take-home tote bags ($12), additional fragrance pours ($5 each). The guest is more likely to add upsells when the decision is made in the moment rather than in a checkout flow.

No-show protection matters but full prepayment hurts conversion. A card on file is enough commitment to reduce no-shows by ~70% of what full prepayment would, without the full friction of asking for money up front. For some venues, the conversion lift from removing prepayment friction outweighs the no-show cost.

The customer base prefers it. Some categories, particularly higher-end experiences with returning customers, find prepayment crass. The "we'll bill you at the end" model fits the experience.

Why most platforms don't support it

The technical reason is that card-on-file flows require different payment infrastructure than prepayment flows. Specifically:

  • The card needs to be tokenized at booking (saved without being charged).
  • The token needs to be retrieved at the venue and authorized for the final amount.
  • The transaction needs to clear in real time at the host stand, in person.
  • The whole thing needs to integrate with the POS at the venue.

Most booking platforms aren't payment platforms. They handle "charge a card at booking" because that's a standard ecommerce flow. They don't handle "save the card now, charge it at our POS later" because that requires actual POS integration. The platforms that handle it tend to be the ones built on top of an actual POS.

Acuity supports a version of this because Acuity is owned by Squarespace and has Stripe payment integration with saved cards. Square Appointments handles it because it's built directly into Square POS. Most experience-specific platforms (FareHarbor, Peek, Tock) force prepayment because the alternative is too operationally complex to build.

That's why operators with this need have historically been stuck with generic appointment schedulers. They got the payment flow they needed but lost the experiential workflows.

What we built into ArtistryHost

We built card-on-file as a first-class booking option because we wanted to serve the pottery studios, the cooking schools with variable menus, the candle bars with heavy day-of upsells. The flow:

At booking: The guest provides a card. The card is tokenized via Square. No charge happens. The booking is confirmed.

At the venue: The host pulls up the booking on the run sheet. The card token is right there. At the end of the experience, the host enters the final amount (or adds it to the open tab if there were upsells), and the saved card is charged in one tap. The transaction clears as a card-present transaction through Square, which is also the cheaper processing rate.

For the guest: It feels like dining at a restaurant where they handed over the card at the start and got it back at the end. Frictionless on both ends.

The operator can choose card-on-file per booking type. Public classes default to deposit-plus-balance. Card-on-file is opt-in for the venues and class types where it's the right model. We don't force anyone into one policy.

What to ask when you're evaluating platforms

If you're a venue where card-on-file is the right model, three specific questions to ask any booking platform during evaluation:

  1. Does your platform support card-on-file with no charge at booking? Many platforms will say yes here, then walk it back when you press.
  2. Does the card-on-file charge run as card-present at the venue? If it runs as card-not-present (the same as online), you're paying the higher processing rate even though the card is physically in front of you.
  3. Does the venue staff trigger the charge from the run sheet, or do they have to switch into a separate POS app? Workflow matters; switching apps means slower service.

If the answers are yes/yes/from-the-run-sheet, the platform handles your use case. If any answer is "we have a workaround," the workaround will cost you in operational friction every single day.

The principle

Not every booking model needs full prepayment. The "book now, pay in-store" flow fits a meaningful share of experiential venues, but most platforms don't support it because it requires real POS integration.

If your venue's pricing is variable, your upsells are day-of, or your customers prefer to settle at the end of the experience, you need a platform that treats card-on-file as a first-class option. Not as a generic-scheduler workaround that loses the rest of the experiential workflow.

The third option exists. Just make sure the platform you pick actually supports it.