Which payment methods should I offer at a minimum?

Credit card and a common instant bank transfer cover most guests in the DACH region. If you have many guests from abroad, also check the payment methods that are common in their markets. What matters more than the number of methods is their reliability: a rarely used method that occasionally fails costs more than it brings.

Should I ask guests to create an account?

Not as a requirement. An account before booking is an extra step with a password, a confirmation email and points of failure. It makes more sense to offer access after booking, via a link in the confirmation, where details can be added or extra services booked. That way the benefit comes without the hurdle in front of it.

How do I handle group enquiries?

Above a certain number of rooms or guests, the flow should not book but switch to an enquiry form. Groups need different payment and cancellation rules and often an arrangement for breakfast. Set the threshold at which this applies and name it in the booking step, rather than letting the booking fail.

What do I do with abandoned bookings?

Anyone who did not complete the last step has not necessarily cancelled. Often information was missing or the connection dropped. A single, factual email with the chosen dates and a direct link back is acceptable if the person entered their address beforehand. More than one reminder is advertising and reads as such.

Booking flow without drop-offs: steps and payment

Key takeaways

Three steps are the norm, four the limit; every additional step has to justify itself.
Six required fields cover most properties: name, email, phone, number of guests, billing address and payment method.
The payment rule and the cancellation rule belong together and should be shown on the same screen, not hidden in linked terms.
The confirmation is a working document: arrival time, address, parking, cancellation deadline and invoice total.
web.dev puts a good Largest Contentful Paint at 2.5 seconds or below, and that applies to the booking page too.

A booking flow that does not break off gets by with three steps: choose dates and unit, enter your details, pay and confirm. Anything beyond that has to earn its place, because every extra field and every extra screen costs bookings.

This sounds like a design question, but it is mainly a decision about what you really need to know before a guest is allowed to pay. Nobody else can make that decision for you.

Three steps are enough, four is the limit

Step one: dates, unit, number of guests, price. The guest already sees the total amount here, not just a nightly rate. Step two: the details you need for the contract. Step three: payment and confirmation on the same screen.

A fourth step is justifiable if you sell additional services: breakfast, parking, a dog fee, spa access. It belongs between step one and step two, not at the end, and it needs a visible option to skip it.

What does not deserve its own step: the form of address, the choice between two rate variants that were already visible in step one, an intermediate page noting that the booking is about to become binding. Count your flow once by making a booking yourself and noting every screen change. If there are five or more, you know where to start.

The fields a booking really needs

Six are enough for most properties: first and last name, email, phone number, number of guests, billing address and payment method. The phone number is not a marketing field but the way to reach someone who is not standing outside the property at 21:00.

Not part of the booking flow: date of birth, nationality, ID number, vehicle registration plate, arrival time as a required field, company name as a required field, "How did you hear about us?" What you need for guest registration (Meldewesen) you collect at check-in or through a separate pre-arrival link after booking. There it does not get in the way, because the decision has already been made.

An optional notes field makes sense, but it should be voluntary and short. Whoever writes there tells you something important about the stay. What you keep on guest data long term, and how you use it for the next stay, belongs in organised guest data management, not in a longer form.

When to take payment in full and when a deposit is enough

The payment rule follows the cancellation rule. If a guest may cancel free of charge until 24 hours before arrival, they do not need to pay in advance; holding a card on file as security is enough. If they book a non-refundable rate, they pay immediately. That is the counterpart to the lower price.

In between sits the deposit, usually one night or a fixed share of the total, due immediately, with the balance on arrival. For longer stays and for the main season it is the calmest solution, because it binds both sides without burdening the guest's account months in advance.

What matters is that the payment rule and the cancellation rule appear on the same screen, in full sentences, with dates: "Free cancellation until 14 June, 18:00. After that, one night will be charged." A link to general terms does not replace that.

The final amount must be the final amount

What appears in the last step must not change at reception. That means the overnight tourism levy (Nächtigungsabgabe), cleaning fee, pet fee and VAT are included and shown separately. In Austria, accommodation is subject to the reduced VAT rate (Umsatzsteuer); other services, such as certain drinks, carry different rates [Q1]. Which item is charged at which rate in your case, you clarify with your tax adviser. That is not a question for the software.

The local tourism tax (Ortstaxe) is the most common point of dispute at check-out, because it often does not appear in the online total. Show it as a separate line with the amount per person per night, even if it is passed on to the municipality.

Why loading time is part of the booking flow

A flow with three clean steps helps little if the first step takes seven seconds. web.dev puts a good Largest Contentful Paint at 2.5 seconds or below, measured at the 75th percentile of page views [Q2]. This applies to the booking page just as much as to the home page, except that the booking page is usually opened on the move and over mobile networks.

The study "Milliseconds Make Millions" by Deloitte and Google (2020) describes how an improvement of 0.1 seconds in mobile loading time went together with higher conversion rates, including in travel [Q3]. Do not transfer this one-to-one to your property, but take the direction seriously. What exactly to do is covered under loading time and direct booking.

On mobile, the booking flow either holds or fails

Most bookings start on the phone, often in the evening, often on a mobile network. This changes the requirements. The calendar must be operable with a thumb and show both dates in one view, without tapping forward month by month. Input fields must open the right keyboard (numbers for the phone number, email keyboard for the address) and allow autofill from the browser.

The most delicate moment is the switch to the payment app or to the bank's approval step. The guest leaves the page and comes back; if the entered details are lost in the process, the booking is gone. Test exactly this transition, and test it with a poor connection. Equally important: error messages must appear at the field, not as a red box at the top of the page that is hardly visible on a small screen.

The confirmation is a working document

The confirmation page and confirmation email are not a thank-you note. They are the document the guest opens on arrival day. It should contain: booking number, dates, unit, number of guests, total with itemised lines, amount already paid, outstanding balance, cancellation deadline with date, arrival time, address with final directions, parking situation and a phone number in case of delay.

Two things are missing almost everywhere: what to do if arriving late, and a way to change the booking without phoning. Both noticeably reduce the number of messages in the days before arrival. And the email must arrive immediately. A confirmation that only leaves the booking system the next morning produces exactly one phone call in the meantime.

What you need to handle yourself

The software provides the steps; you write the content. That means the descriptions of the categories in two to three sentences, the cancellation rules in exact wording, the additional services with prices, and the texts of the confirmation email. Allow half a day for this.

Add a monthly test booking: go through your own flow once, with a real card, on a phone, outside the property's Wi-Fi. Then cancel. Anyone who does this for a year finds expired payment connections, broken email templates and wrong prices before a guest does.

When your own booking flow does not pay off

Let us work through it for four holiday apartments with 180 booked nights each: 720 nights a year, at four nights per stay roughly 180 stays. Assume a third of these already come in directly: 60 bookings. If a tidy flow converts five percent more of them, that is three additional stays a year. At an assumed price of 140 euros per night, this gives roughly 1,680 euros of additional revenue without portal commission. The figures are assumptions; use your own.

Set against this sum are the set-up, the payment connection and ongoing fees. With a few units and mostly returning regulars who call anyway, this often does not pay off. With twelve or more units, or a high share of new guests, the ratio shifts significantly, and then the flow is the heart of a direct booking website.

As a next step, make a complete test booking on your own phone and count the screens and required fields. With this list you can trim your booking flow with online payment in a targeted way. You can also book an appointment.

Sources and further reading

[Q1] Austrian Federal Business Service portal (Unternehmensserviceportal): VAT rates in Austria

[Q2] web.dev: Largest Contentful Paint (LCP)

[Q3] Deloitte / Google: Milliseconds Make Millions (2020, PDF)

Booking flow without drop-offs: steps, fields and payment