No-Shows and Guests Who Never Pay

Four different problems wearing one name

“The guest never paid” covers four situations that look similar and need completely different handling:

The abandoned checkout. Someone started booking, the dates went on hold, and they vanished at the payment step.
The offer that lapsed. You built a booking and sent it to a guest to confirm. They never did.
The unpaid balance. A real, confirmed booking with a deposit paid and the rest never arriving.
The no-show. Paid or unpaid, the guest simply didn’t turn up.

Only the third is a chasing problem, and it has its own article. This one covers the other three, because each quietly damages something different — your calendar, your books, or your costs — and most tools handle at least one of them badly.

The abandoned checkout: give the dates back fast

When a guest reaches your payment page, the dates have to be held. Otherwise two people pay for the same week in the ninety seconds it takes to enter a card. So a pending booking blocks availability from the moment checkout starts.

The question is how long you hold it for. Too short and you double-book someone whose bank is being slow about a 3-D Secure prompt. Too long and a busy property sits on dead holds all week.

Airflow holds for 30 minutes, with a sweep every five, so the worst case is about 35 minutes from abandonment to bookable. That covers a normal card confirmation with real margin, without parking your calendar for an afternoon.

Two design details worth copying if you’re evaluating anything else:

The row is expired, not deleted. You keep the record. How many guests start and don’t finish is a genuinely useful number — a high rate usually means something on your checkout is broken rather than that your guests are flaky. And when someone emails asking “did my booking go through?”, you can answer.

The expired booking stops blocking immediately. Sounds obvious; isn’t always. The availability view has to exclude expired, cancelled, rejected and no-show rows, or the dates stay dark forever while the booking list looks clean.

The lapsed offer: don’t sweep away what you built on purpose

This one produced the most instructive bug we’ve shipped, and it’s worth telling because the same trap exists in most systems.

When an admin builds a booking and sends it to a guest to confirm by paying, that booking is pending and unpaid by design, sometimes for days, while the guest decides.

Now recall the rule above: sweep pending, unpaid bookings after 30 minutes. Both are pending. Both are unpaid.

So every offer the portal ever created was destroyed half an hour after it was made, along with its payment schedule. Silently. The host saw an offer go out and a booking disappear, with nothing connecting the two.

The fix is that “abandoned” and “awaiting the guest” are different states, even though they look identical in the data. An anonymous checkout that stops is abandoned — sweep it. A booking you deliberately created and sent is waiting — it gets its own expiry, which you choose: 24 hours, 48, 72, a week, or never.

And a lapsed offer is cancelled, not deleted, so you can still see it. A guest who let an offer expire is someone worth following up; a deleted row is someone you’ve forgotten exists.

The general lesson: a cleanup job that keys on a state rather than on how the row came to exist will eventually eat something it shouldn’t. Check what your housekeeping rules would do to a booking you created by hand.

The no-show: decide what it means before it happens

A no-show is the one situation where the right answer is a business decision rather than a setting.

If they paid in full, nothing needs to happen operationally. You keep the money under your policy, the booking stands, the invoice stands. Mark it as a no-show rather than cancelling it — cancelling implies a reversal that didn’t occur, and your revenue for the month should reflect what you kept.

If they paid a deposit and never the balance, you have a decision: keep the deposit under your cancellation policy, or refund some of it as a gesture. Either is legitimate. What matters is that the booking ends up in a state that matches what actually happened with the money — a “cancelled” booking that kept a deposit is a misleading record.

If they paid nothing — which should be rare, because a booking with no payment shouldn’t be holding dates that long — then it never really existed as a stay, and the question is why it was confirmed.

Whichever way it goes, the invoice needs attention, and this is where no-shows leak into your books. A confirmed booking with an approved invoice that never happened will sit on your debtors list indefinitely. The rule depends entirely on the invoice’s live status — delete a draft, void an approved one, credit-note a paid one — and it’s laid out in What Happens to Your Invoice When a Guest Cancels.

The cost nobody counts

Here’s something that only shows up in tools with a usage allowance rather than per-property pricing, and it’s worth knowing generally: failed and abandoned work can cost you real money.

We found this on a real account. A draft invoice was failing for a fixable configuration reason, and a retry job ran every fifteen minutes. Each attempt used an automated task before the attempt, with no refund when it failed. Four failures cost four tasks and produced nothing. Left alone, the retry cap would have allowed 55 tasks of pure failure — far more than that plan’s whole monthly allowance (pricing).

Two changes came out of it, and both are worth asking about wherever your costs are usage-based. Charge after the work succeeds, or refund when it doesn’t. And stop the loop at the source — with no tasks available, skip the account rather than re-attempting every booking and recording a denial for each.

The same logic applies to your own operational costs. An abandoned checkout that triggers a guest email, a calendar sync and an accounting attempt has cost you something, even if the booking never existed.

A short checklist

Pending checkouts release within the hour, and expired rows stop blocking availability.
Expired bookings are kept as records, not deleted.
Offers you send have their own expiry, separate from abandoned checkouts, and lapse to cancelled.
No-shows are marked as no-shows, not cancellations, so your revenue reflects what you kept.
Every ended booking’s invoice is resolved from its live status.
Nothing bills you repeatedly for work that keeps failing.

None of this is glamorous, and all of it is the difference between a calendar you can trust and one you have to audit.