We only charge guests when they check in

Our guests won't pay when they book.

They'll pay when they turn up. And getting there took more thinking than I expected.

We've been working on a booking engine for an association of rural houses. Guests pick dates, add the stay to the cart, and pay through the bank's payment gateway, Redsys. Simple.

Until you ask when the money should actually move.

The developer of the payment-gateway plugin we use sent me two options. Card and cardholder authentication, the one hotels and hostels usually use. Or pre-authorisation with later confirmation, more common for businesses selling fresh products.

That night I wrote back with the flow as I understood it. The guest adds the booking to the cart. Pays with Redsys. Enters the card. The order goes to "Processing". Then, on the check-in date, the owner moves it to "Completed", and only then is the card charged.

And I asked the question I wasn't sure about. What amount does the guest see when they enter the card? The full total, or zero?

The screen you don't control

He answered the next morning. His part is the payment gateway, not the booking system; how the two fit together is on our side. When the order is marked "Completed", the confirmation goes to the bank. I asked him to confirm: is that the moment of the charge? Exactly, he said.

As for the screen, it depends on each bank. If ours doesn't make it clear, we should tell guests they're authorising the amount, not paying it yet.

That's the bit I like. The bank's screen is part of your product, even though you can't touch it. Like the waiter at a restaurant you don't own: if he's rude, the customer still blames the restaurant.

Around the same time we looked at the rest: syncing availability, and extras that depend on occupancy. The outside developer building those parts estimated around 40 hours. And he said something honest that stuck with me. Without understanding the business deeply, it's hard to cover every case.

He was right. And it wasn't his business to understand. It was ours.

Not a setting

Here's the confession. I came into this thinking payments were a technical detail. Pick a gateway, plug it in, done.

They aren't. When you charge is a business decision. It decides how guests feel when they book, how many cancellations turn into refunds, and how much admin the owner has every week.

It would have been easy to let a plugin's default make that decision for us. Defaults are very convenient. That's exactly what makes them dangerous.

When you charge a customer is a product decision, not a payment setting.

So the order is: decide when the money moves, write the flow in plain steps, and only then look for the gateway option that does exactly that. An outside developer can build the pieces. Knowing which cases matter, cancellations, extras, no-shows, has to stay with whoever knows the business.

We build websites for small accommodation businesses. We know what a cancellation costs them, and what a commission takes from them.

That knowledge is the one thing a freelancer can't quote in hours. It's also the reason a small studio like ours can build products at all. We started with 300 €; what we have that others don't is time spent close to the client's problem. No investor can wire you that.

A booking engine is mostly code. The part that makes it worth using is understanding the business.

Guests won't pay when they book.

They'll pay when they arrive, because that's how the business they're booking actually works.

P.S. The most important line in that whole flow wasn't code. It was a question: "full total, or zero?"