Stripe Payment Design for Lodging — Choosing Not to Charge at Booking

Introduction

Payments for an online store are refreshingly simple. Add to cart, pay by card, the package arrives. Lodging bookings, though, get complicated fast.

The stay might be six months away. Cancellation fees kick in on a sliding scale as the date approaches. Just deciding when and how much to charge took us days of deliberation. In this article we walk through the payment design we landed on, and why.

Why lodging payments are hard

"Pay in full right now" kills bookings

The simplest option is to charge the full amount by card at the moment of booking. It's easy to build, and you never miss out on the money.

But plenty of people balk at having 300,000 yen pulled from their card today for a stay that's nearly a year away. The booking hurdle goes up, and the guest books on an OTA instead. It also means the property has to process a refund every time someone cancels.

But "pay at check-in" isn't an option either

Go the other way and take nothing up front, and you absorb the entire no-show risk yourself. With a whole-house rental the value per booking is large, so a single no-show in peak season really hurts.

Options we considered and rejected

Why "just hold the authorization" didn't work

Credit cards have a mechanism called an authorization (an "auth hold"): you reserve room on the card now and capture the actual charge later. Hotels use it for deposits all the time.

If we could have used it, it would have been ideal. But the deeper we dug, the more we ran into a hard limit.

This property accepts bookings up to 365 days out. If an authorization only lasts 30 days, then holding an authorization taken at booking all the way to 14 days before check-in is simply impossible. That killed the authorization approach outright.

Deposits and split payments were out too

We also looked at splitting the payment — 30% at booking, 70% just before the stay. But that means carrying the risk of two payments failing, and it complicates day-to-day operations. Given that a whole-house rental doesn't have a huge number of bookings, we chose simplicity.

The design we chose: card on file, charged automatically later

All that happens at booking is "we hold onto the card"

What we settled on: at booking we only save the card — no charge — and then automatically bill it 14 days before check-in.

Matching the charge date to the date cancellation fees begin made operations wonderfully clear. Cancel before the charge date and there's simply nothing to bill; cancel after and it's a refund. We never end up in the awkward position of chasing a cancellation fee on a booking we haven't charged yet.

Get cardholder authentication out of the way at booking

When you bill a card later, with the customer nowhere near a screen, some card issuers will decline the payment because they can't verify the cardholder.

So we made cardholder authentication (3-D Secure) mandatory at the moment the card is saved. That way the charge is treated as an ongoing payment the customer has already consented to, and the later automatic charge sails through.

Put consent on the record

We tell guests plainly at booking that the card will be charged automatically 14 days out, and they tick a checkbox to agree. We record that consent in the database, right down to when it was given and which version of the wording they agreed to.

If someone later says "nobody told me about that," having the record changes the conversation entirely.

Three sub-topics

Payment design covers a lot of ground, so we've split the details across three articles.

• Charge timing in detail — why we saved the card instead of holding an authorization, and how the auto-charge actually runs, is covered in "What 'Holding a Payment' Really Means"
• State management — how to handle a guest returning from the payment page, and how to stop duplicate notifications, is covered in "An Unbreakable Payment Flow with Webhooks and Status Management"
• Security — preventing price tampering and double charges, and separating live from test, is covered in "Payment Security Against Price Tampering and Double Charges"

Wrapping up

Three principles anchored our payment design for lodging bookings.

1. Align the charge date with the cancellation-fee date — operations collapse to just two cases, "nothing to bill" or "refund"
2. Choose card-on-file over an authorization — authorizations expire, so they can't cover far-off dates
3. Record consent — save both the explanation of the later charge and the guest's agreement, including which version of the wording