A card guarantee: the guest pays later, you have certainty

What we hear when we sit down with operators

In practice a stored card, a block on funds and a completed payment are often mixed up. They are three different states.

A tokenised card can later be invalid, a preauthorisation has time limits, and without clear cancellation rules the hotel does not know when it even has the right to charge a fee.

Why fixing a single step is not enough

Technology does not settle the commercial terms. It has to be clear first when a cancellation fee arises and what the hotel tells the guest. Only then does it make sense to automate the payment scenario.

The guest sees clear terms when booking

Web Booking shows the cancellation and payment rules before confirmation. The guest knows whether they are only providing a card as a guarantee, whether a preauthorisation will run, or whether a deposit will be taken.

Transparency reduces complaints and at the same time protects the hotel when cancellation terms are applied later.

The card is tokenised at the payment partner

Ellipse does not need to treat the card number as ordinary text. The payment partner creates a token that is tied to a specific payment relationship under its own rules.

That lowers the risk of handling sensitive card data inside the operational system.

A preauthorisation and a payment have different purposes

A preauthorisation can block funds for a while, but how long it lasts depends on the bank and the card scheme. It is not money set aside forever.

When a cancellation fee is actually charged, the process must follow the agreed terms and the payment result should be written onto the booking.

A declined card is an operational event

If the bank declines the transaction, the booking should not automatically look settled. The front desk needs a clear status and a next step: contact the guest, ask for another payment, or follow the hotel's rules.

Automation should speed up the reaction, not hide the problem.