When the person booking isn't the person paying

Consumer checkout rests on an assumption so quiet nobody states it: the person at the keyboard is the person whose card gets charged. Service businesses violate that assumption every single day. The assistant books the photo shoot for the agent. The brokerage covers whatever its team orders. The office manager schedules five jobs on one account. The bill for the transaction gets settled by a third party at closing. Force all of them through a consumer checkout and something breaks, quietly, in one of two directions.

The two ways it breaks

The first failure is the card wall. The booking dies at the payment step because the person at the keyboard cannot pay, was never supposed to pay, and is not going to front six hundred dollars of someone else's expense on a personal card. They close the tab, and the job goes to whoever answers the phone instead. You will never see this loss in a dashboard, because the abandoned checkout looks identical to a tire kicker.

The second failure is the wrong-pocket invoice. The system happily charges whoever clicked, and then the money is in the wrong place: the assistant expenses it, the agent reimburses it, accounting untangles it at month end, and every job adds another thread to the knot. The work got done and the money arrived, so nobody calls it a failure. It is a failure. It just bills the cleanup to people whose time you do not measure.

Ask the question at the right moment

Who pays for this? is a booking-time question, not an invoicing-time question. By the time an invoice exists, every wrong answer has already been baked in. So make the payer a first-class field in the booking itself, and you will find three patterns cover nearly every service business: the booker pays now, at checkout, like a consumer. A designated payer inside the same company pays, from an approval or a saved card. Or the bill routes to a third party on terms, invoiced per job or rolled up every few jobs on a cadence the payer chooses.

The guardrails that make it safe

We build these flows for a living, and the scars are specific. First: a booking must have exactly one open path to money. The moment a job can carry both an invoice and a live checkout link, you have built the double-collection bug, and it will find you. Second: validate the relationship on the server, never in the dropdown. If a client can pick a payer, the list should come from records you control, and the choice should be re-checked when the booking is finalized, because forms can be replayed and teams change. Third: decide what the money actually gates. When a trusted account books on terms, confirm the calendar slot immediately and let billing follow on its own schedule. When a stranger self-pays, hold the slot briefly and release it if the checkout is abandoned, so an unpaid draft never locks your calendar on a busy Saturday.

What this looks like in the wild

We built exactly this for a real estate media studio. Agents book shoots; some pay upfront at checkout, and some route the bill through the transaction itself, where a settlement company pays it from proceeds at closing, batched on the cadence that company prefers. The checkout asks one required question when it applies, who is paying for this, and everything downstream hangs off that single answer: invoices that carry the agent names and property addresses the payer needs to reconcile, batch rollups, and refund paths that return credit to the right account when a job cancels. None of it is exotic. All of it starts with refusing to assume the booker and the payer are the same person.

If your checkout has only one answer to who pays, you are quietly turning away the accounts that book the most.