The money goes to you, because we are not in the payment
You connect your own Stripe account and you stay merchant of record. Your customers pay you directly. We never hold funds, we never control payout timing, and we take nothing out of the processing.
Not restraint. Architecture.
A platform that sits inside the payment can always choose to take a slice of it, hold the balance for a few days, or change the payout schedule when its own cash flow needs it. Those are decisions someone gets to make about your money.
We are not in the payment, so there is nothing to skim and no decision to make. The funds move from your customer to your Stripe account and settle on your terms with your acquirer. Refunds, disputes and payout timing all sit where they already sit.
What we hold is the booking record: what was sold, to whom, for how much, and which payment it is joined to. That is the part we are useful for.
Roughly twenty four questions instead of about a hundred and forty
Nobody explains this part to operators, so here it is in plain language. If a card number is typed into a field that your website is responsible for rendering, your business is treated as handling card data, even though the data is passed straight on. That puts you in the long version of the annual card industry self assessment.
The card step here is served by Stripe rather than rendered inside your page, so there is never a card field on your domain. That is the difference between the shortest self assessment questionnaire and the longest one: on the order of twenty four requirements rather than about a hundred and forty.
The long version does not stop at paperwork. It usually brings quarterly network scans by an approved vendor and an annual penetration test, both of which you commission and pay for, both of which need someone in your business to own them. For a venue with no in-house security team that is real money and several days of somebody's year, repeated annually.
A platform that embeds card fields in your page cannot make this claim, and most of them do embed, because a card field inside the checkout looks tidier in a demo.
We are describing the standard, not certifying anyone. Your obligations depend on how you take payments everywhere else too, including over the phone and at the counter, so confirm your own position with your acquirer before you rely on it.
Charged with no booking is a state that does not exist
Every operator has taken that phone call. The customer has a receipt, the diary has nothing, and your host is apologising for something they cannot see or fix.
The card is authorised while the booking is being confirmed, and captured only once the confirmation has been written. If the slot has gone in the meantime, the authorisation is released and nothing is ever taken. There is no window in which money has moved and no booking exists.
The customer sees a pending amount fall away rather than a charge followed by a refund three days later, and your team is not reconciling a payment against a booking that was never made.