It is the answer we get most often when we ask how a booking or ordering system takes money. It is a fine answer to a question about providers. It answers nothing about the system.
Stripe — or Adyen, or Worldpay, or whoever — is a set of primitives. Which primitives you use, in what order, and what your business does when one of them fails, is a design. Somebody makes that design. If you did not brief it, your developer made it in an afternoon, reasonably, based on the tutorial, and you will discover the consequences one at a time over about two years: at the first no-show you can't charge, the first Christmas party that arrives on a corporate card, the first month your kitchen has more orders than your settlement file.
Yesterday we pulled apart what card payments cost. This is the other half: what they are, structurally, and the seven decisions inside every hospitality payment flow. It's written so you can hand it to whoever is building yours.
Decision 1: Are you authorising, or are you taking the money?
These are different operations and most systems conflate them.
An authorisation asks the issuer to ring-fence funds. A capture actually moves them. Between the two is a window, and the window has a hard edge: a typical authorisation is valid for around 48 hours, or five days on Visa, before it expires and the funds are released.
That matters because hospitality routinely wants a longer gap than that. You authorise at booking and capture at check-out. You authorise a deposit in March for a wedding in September. The mechanism for this is an extended authorisation, and the numbers are specific: for hotel and lodging merchant categories, Visa allows 30 days (29 days and 18 hours in practice, to leave room for clearing), Mastercard allows 30 days across all categories, and American Express allows 30 days for lodging but requires capture no later than the end of the stay.
The trap: extended authorisation has to be requested when the payment is created. You cannot decide on day four that you'd like longer. If your booking flow doesn't ask for it, you have a 48-hour window and a business model that assumes months.
The second trap is subtler and it costs real money. If a guest cancels before you've captured, cancel the authorisation — don't capture and refund. A refund keeps the original processing fee; a cancelled authorisation never incurred one. Refunds issued very shortly after a charge can also process as a reversal, which carries lower network costs than a refund. Three different operations, three different costs, one button in most systems.
For the brief: which payments authorise-then-capture and which capture immediately; what the capture window needs to be; whether extended authorisation is requested at creation; and a cancel path that is distinct from the refund path.
Decision 2: Who holds the card, and under what agreement?
If you ever intend to charge a customer when they are not sitting in front of you — a no-show fee, a balance, a damage charge, a second night — you need the card stored, and "stored" has a precise meaning that is not "written on the booking form."
The card is tokenised: your system holds a reference, the card data lives with the processor, and the reference is useless to anyone who steals it. That part is easy and every processor does it.
The part people skip is the agreement. A later charge you initiate is a merchant-initiated transaction, and Visa's own guidance defines these as transactions where "a cardholder has pre-agreed (and pre-authenticated) a future transaction(s)" and cannot authenticate at the moment of payment. Read the two words in brackets. The initial transaction has to have been authenticated, and the future charge has to have been agreed — specifically enough that the terms describe what you may charge, when, and how much.
Get this right and your no-show fee is chargeable and defensible. Get it wrong and you have a card token you are not entitled to use, and a dispute you will lose — which, as we covered yesterday, costs you the case fee whether you win or not.
For the brief: which flows store a card; what the customer is shown and agrees to at that moment; where that agreement is recorded; and whether the stored credential is flagged correctly as customer-initiated or merchant-initiated on every subsequent charge.
Decision 3: Which of your payments need the customer to authenticate?
Since 14 March 2022 — the FCA's final deadline, described as "the latest we expect full SCA compliance for e-commerce transactions" — UK online card payments require strong customer authentication unless something takes them out of it.
There are two different escape routes and conflating them is the most common mistake in this area.
Out of scope means SCA never applied. Per Visa's UK guidance, that covers merchant-initiated transactions, mail order and telephone order payments, "one leg out" transactions where the issuer or acquirer sits outside the EEA, and anonymous payment methods.
Exempt means SCA applied and someone chose to waive it — and the issuer can decline to. That covers transaction risk analysis, low-value payments within cumulative limits, trusted beneficiaries the customer has whitelisted, and secure corporate payments made "from secure corporate environments."
The operational consequences are strange until you see them laid out:
The booking taken over the phone is MOTO and out of scope. The identical booking taken on your website is not.
The no-show charge you raise three days later is merchant-initiated and out of scope — if decision 2 was done properly. If it wasn't, it is an unauthenticated charge with no mandate behind it.
Corporate cards carry an exemption of their own where the payment is initiated "from secure corporate environments" — a lodged or virtual card inside a company travel system, not simply a business card typed into your checkout. They are also the transactions that cost you the most in interchange. Two separate reasons to know which of your payments arrive on commercial cards.
None of this is a reason to avoid authentication. It is a reason to know which of your flows carry it, because every unnecessary authentication step is friction on a booking you already paid to acquire.
For the brief: a list of every payment flow in the business, each marked in-scope, out-of-scope or exempt, with the reason.
Decision 4: Where do the card fields actually live?
This is the decision with the most changed answer, and almost nobody has revisited it.
The received wisdom for a decade was: embed the processor's hosted fields or iframe, card data never touches your server, you complete the shortest PCI self-assessment questionnaire — SAQ A — and compliance is basically someone else's problem.
That stopped being the whole story on 31 March 2025. The PCI Security Standards Council rewrote SAQ A's eligibility criteria. Merchants now have to meet two conditions: that all elements of the payment page delivered to the customer's browser "originate only and directly from a PCI DSS compliant TPSP", and — the new one — that "the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
Requirements 6.4.3, 11.6.1 and 12.3.1 were removed from SAQ A itself, but they remain in PCI DSS v4.0.1, and the eligibility criterion replaced them with something you have to be able to say truthfully. A merchant who cannot meet it doesn't get to use SAQ A; they drop to SAQ A-EP, which is considerably more work.
In plain terms: the fact that your payment form is an iframe no longer means the rest of your page is irrelevant. Every analytics tag, chat widget, review pixel, heatmap tool and marketing script your agency added to the booking page is now inside the question you are attesting to. Most sites carry more of these than anyone can name from memory, and almost none keep an inventory.
For the brief: which integration pattern you're on and which SAQ that puts you in; an actual inventory of third-party scripts on any page that leads to payment; and who is responsible for knowing when one changes.
Decision 5: What happens when it doesn't work?
Payment code is mostly failure handling, and failure handling is mostly where the tutorial stopped.
Declines are normal. Some are retryable — a temporary issuer decline, an expired hold — and some are not, and treating them identically either annoys good customers or generates a stream of authorisation attempts you are billed for. Every attempt carries a fee, typically 3p–5p, whether it succeeds or not.
Two things must never diverge: the order or booking your operation can see, and the payment your finance can see. The failure mode that hurts hospitality most is not a lost payment, it's a half one — a kitchen ticket with no authorisation behind it, or an authorisation with no booking attached, discovered on the twelfth of the following month. That is an idempotency and reconciliation problem, and the fix is designed in at the start or retro-fitted expensively later.
Webhooks arrive late, twice, or out of order. A system that treats the customer's browser returning to a success page as proof of payment will, eventually, be wrong.
For the brief: the retry policy; what the customer sees for each failure class; guaranteed one-to-one mapping between order and payment; and idempotent handling of duplicate or out-of-order webhooks.
Decision 6: What does the payment write into the rest of the business?
A payment is not a self-contained event. It has to land in at least four other places, and how many of those are automatic is the single biggest driver of how much admin your business does.
The EPOS or PMS needs the order. The accounts need the transaction, at the right VAT treatment. Settlement — the money that actually arrives in your bank, net of fees, batched, usually a day or two later — needs to reconcile back to individual transactions, which is the step almost every small integration skips and every bookkeeper does by hand.
And the tax treatment is not always the obvious one. HMRC's position on retained deposits and hotel no-show charges is that they are consideration for the customer's right to benefit from the contract "regardless of whether the customer exercises that right", VAT is due when the payment is taken, and the payment "cannot be retrospectively re-characterised as an outside the scope compensation payment." So your no-show fee is a VATable sale at the moment you take it, and if your system books it as something else, your VAT return is wrong in a small, recurring, entirely avoidable way.
For the brief: every downstream system the payment must reach; which are real-time and which are batch; how settlement reconciles to transactions; and the VAT treatment for deposits, no-shows, refunds and service charge.
Decision 7: What can you see afterwards?
The authorisation response contains far more than approved/declined. It knows the card's product type — consumer or commercial, debit or credit — and the issuing country. Almost no booking or ordering platform surfaces any of it.
That's a shame, because those two fields are the ones with money attached. Commercial cards sit outside the consumer interchange caps and cost several times more to accept; they are also outside the consumer surcharge ban, which makes them the only transactions you are legally permitted to price for. Issuing country tells you your cross-border exposure. Both arguments are in yesterday's post — but neither is actionable unless the data reaches a report.
For the brief: store the card product type, funding type and issuing country on every transaction, and put them in a report someone actually reads.
The brief itself
If you take nothing else, take this. Send it to whoever is building or maintaining your payment flow and ask for it in writing.
List every payment flow in the business — online booking, deposit, balance, in-person, phone, no-show, damage, refund, cancellation — and for each one: authorise or capture, when, and in what window.
For every stored card, show me the customer-facing agreement text, where it's stored, and how subsequent charges are flagged.
Mark each flow in-scope, out-of-scope or exempt for SCA, with the reason.
Tell me which PCI SAQ we're eligible for under the criteria in force since 31 March 2025, and give me the inventory of third-party scripts on every page that leads to a payment.
Show me the failure paths — decline handling, retry policy, and how you guarantee an order and its payment can never exist without each other.
Show me settlement reconciling to individual transactions, and the VAT treatment of deposits and no-shows.
Confirm we capture card product type, funding type and issuing country, and show me where I can read them.
Seven answers. A supplier who has them will produce them in a morning. A supplier who doesn't will tell you it's all handled by Stripe — which is the sentence this post is named after, and the point at which you have learned something worth knowing.
Why this is worth caring about
Payment integration looks like plumbing, so it gets briefed like plumbing: make it work, keep it cheap. Then it turns out to be the layer that decides whether you can charge for a no-show, whether your VAT return is right, whether your busiest night reconciles, whether you can see the transactions that cost you most, and — because it holds the tokens and the history — how hard it is to change supplier later.
It is not plumbing. It is the part of the business that decides which money arrives.
Building or rebuilding one? We've built the payment, booking and ordering flows behind our own products as well as clients', so we've made every decision on this page with our own money at stake. Send us the seven questions and whatever answers you got back — we'll tell you which ones are load-bearing. See what we've built, or tell us what you're trying to do.
Related reading: You don't have a card rate, you have a card mix · Every supplier looks the same until you try to leave · A channel manager will never win you a direct booking · Your ordering website is the easy part
