When you charge is a business decision, not a technical setting

Getting paid looks like the easy part.

You pick a payment gateway, plug it in and you're done.

Until you ask yourself when the money should actually move.

Here's how I think about it.

When we built a booking engine for some rural holiday homes, the question came up straight away. Does the guest pay when they book or when they arrive? Both are technically possible. Both are a button in the settings.

That's exactly why it's easy to get wrong: it looks like just another checkbox.

It isn't.

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

What changes depending on the moment

The moment of payment decides many things that don't look related.

How the customer feels when buying. Paying everything months before a trip weighs more than leaving a card and paying on arrival.

How much work the business has. If you charge at booking, every cancellation is a refund. If you charge on arrival, many cancellations cost nothing.

How much risk you take. Charge late and someone may not show up. Charge early and the customer carries the risk.

No option is right for everyone. But each one builds a different experience. And that experience is your product, even if you choose it on a settings screen.

Defaults decide for you

Almost every payment tool comes with an option ticked by default. It's very convenient.

And it's dangerous, because the default was chosen by someone who doesn't know your business.

The order I try to follow is this:

1. Decide when the money moves, thinking about the customer and the business, not the tool.
2. Write it down in simple steps: what the customer sees, what happens if they cancel, what happens if they don't show.
3. Only then look for the setting that does exactly that.

Do it the other way round and the tool will design your business for you.

The screen you don't control is yours too

There's a detail I think matters. When the customer pays, they often see a screen that isn't yours: the bank's or the gateway's.

If that screen says something confusing ("am I being charged now?"), the customer doesn't blame the bank. They blame you.

So even if you can't touch it, you have to explain it. A clear message before payment ("you're only authorising your card now; you'll be charged on arrival") prevents a lot of doubts and the odd phone call.

This isn't the developer's call

A developer can build any of the options. What they can't know, without knowing the business, is which one fits.

Which cases matter (cancellations, extras, no-shows) is known by whoever has been close to the customer. And that knowledge is exactly what lets a small company build good products without big budgets.

It doesn't compete on money. It competes on understanding.

Next time you set up payments, don't start with the tool.

Start with the question: when should the money move so that everyone feels at ease?

P.S. The most important question in a payment system is rarely technical. It's usually something as simple as "what does the customer see on that screen?"