Payment Providers for Booking Systems: Designing Payments Around the Booking Lifecycle

Payment Providers for Booking Systems 

A booking is rarely just a checkout.

A customer might reserve today, pay a deposit next week, amend the booking in two months and settle the final balance six months later.

They might never pay online at all.

A restaurant might only want a card to secure the table.

A hotel might take a deposit, place a pre-authorisation at check-in and capture a different final amount at departure.

A membership platform might combine a recurring monthly payment with individual class or facility bookings.

And a booking marketplace may need to work out not only when payment happens, but who should receive the money.

That makes payments for booking systems fundamentally different from a straightforward ecommerce transaction.

The mistake is to start with:

“Which payment gateway should we integrate?”

For a booking platform, the better starting point is:

“What needs to happen to the payment from the moment a reservation is made until the booking is finally closed?”

That payment lifecycle should determine the technology — not the other way around.

Quick Summary

A payment provider for booking software may need to support several different payment events around the same booking.

These can include:

• taking a deposit;

• storing a payment method without charging it;

• collecting a balance later;

• applying a cancellation or no-show charge;

• pre-authorising a card;

• increasing or changing the final amount;

• collecting recurring payments;

• accepting payment online and at the venue;

• processing refunds;

• settling money to the correct merchant; and

• reconciling several transactions back to one booking.

For booking platforms serving other businesses, there are two additional questions:

Who is the merchant accepting the payment?

and

Should the software company itself participate commercially in the payment volume?

The Financial Conduct Authority also specifically identifies booking businesses as companies that should consider whether their funds flow amounts to providing payment services where customer money is received before being passed to a seller.

There is therefore no universal “best payment provider for booking systems”.

The right provider depends on the booking lifecycle, funds flow, customer portfolio and commercial model.

You can also explore our wider Payments Strategy Library.

A Booking Is a Payment Lifecycle

This is the most useful way to think about booking payments.

Instead of designing one checkout, map what could happen to the booking over time.

Find Your New Processor

Stage 1: The Reservation Is Made

At the point of booking, the business may want to:

• take full payment;

• take a deposit;

• store a card;

• verify a card;

• take no payment at all; or

• establish permission for a later payment.

Those are very different payment instructions.

A booking platform designed only around “charge card now” immediately limits the commercial models its customers can offer.

Stage 2: The Booking Needs to Be Secured

This is where booking payments become particularly interesting.

The business may want financial commitment without collecting the whole value of the booking.

There are several ways this can work.

Deposit

The customer pays part of the booking value upfront.

Prepayment

The customer pays all or part of the service before it is delivered.

Card guarantee

The card is securely stored, but the customer is not charged unless a particular event occurs.

Pre-authorisation

Funds are temporarily authorised without immediately completing the transaction.

These approaches are not interchangeable.

For example, OpenTable currently supports restaurant booking models incorporating deposits, no-show fees and credit-card holds, demonstrating why restaurant reservations cannot be treated simply as ecommerce checkout transactions.

See OpenTable's current booking-payment examples

Deposits and Card Holds Solve Different Problems

This distinction deserves more attention than it normally gets.

A restaurant requiring a £20-per-person deposit is actually taking money.

A restaurant asking for a card to secure a table may be trying to achieve something different:

commitment without immediate payment.

OpenTable's own guidance illustrates the distinction.

Its restaurant platform currently supports deposits as well as card-based booking policies designed to reduce no-shows. OpenTable reports that guests making reservations backed by a card hold can be less likely to no-show or cancel late than customers booking without a payment policy.

Read OpenTable's current guidance on reducing no-shows

The payment choice therefore affects more than cash collection.

It can affect:

• customer commitment;

• cancellations;

• operational planning;

• refund administration;

• disputes; and

• the overall booking experience.

For booking software, the useful question is not simply:

“Can the gateway take deposits?”

It is:

“Can our merchants choose the payment policy that fits the type of booking?”

Stage 3: The Booking Changes

This is where basic payment integrations often begin to struggle.

Imagine a customer books:

Two-night stay: £600

They pay:

Deposit: £150

A month later they add:

Spa package: £120

Then they extend the stay:

Additional night: £250

The final booking value is now:

£970

But £150 has already been paid.

The software needs to understand:

Original booking value
Payments already received
Changes to the booking
Remaining amount due

The payment provider only sees transactions.

The booking system understands why those transactions exist.

A good integration needs the two systems to communicate properly.

Otherwise the business ends up reconciling payment activity manually against booking records.

Stage 4: Payment Happens Later

Booking businesses often need to charge a customer when they are no longer actively using the website or app.

Examples include:

• collecting the final balance before arrival;

• charging an agreed no-show fee;

• collecting a recurring membership payment;

• taking payment for an amended booking; or

• charging an additional amount after the original reservation.

This is why storing card details and setting up a payment method for future use are not the same thing.

Modern payment providers normally use tokenisation so the booking platform does not need to store raw card numbers itself.

The payment method also needs to be established correctly for its intended future use.

Stripe's current technical documentation, for example, distinguishes between payment credentials intended for future on-session and off-session transactions and explains that future off-session use may require customer permission and appropriate authentication when the card is first set up.

Read Stripe's guidance on saving payment methods for future use

The precise implementation varies by provider.

The principle does not:

A booking platform should decide how a card will be used later before deciding how to collect it today.

No-Show Payments Need to Be Designed Into the Booking Journey

No-show fees are a good example of payments, product design and customer terms all meeting in one place.

It isn't enough for the payment provider technically to support a later transaction.

The booking journey should make clear:

• whether a card is being stored;

• what the cancellation window is;

• whether a no-show charge can apply;

• how much could be charged; and

• under what circumstances the business may make that charge.

OpenTable's booking-policy documentation is a useful real-world example. It surfaces booking and cancellation policies during the reservation process so the customer can understand the terms attached to the booking.

See OpenTable's booking-policy documentation

That is an important lesson for anyone building booking software.

Payment terms are part of the booking UX.

They should not be hidden in the payment integration.

Stage 5: The Customer Arrives - But the Payment Is Still Not Finished

Hotels demonstrate this particularly well.

The guest may have booked months earlier.

They may have:

• paid nothing;

• paid a deposit;

• paid in full;

• supplied a card guarantee; or

• booked through another distribution channel.

At arrival, the hotel may then need to verify or pre-authorise a card.

During the stay, the guest might add:

• meals;

• drinks;

• spa treatments;

• room upgrades;

• parking;

• additional nights; or

• other services.

The final transaction value therefore might not exist until checkout.

This is one reason hotel payment infrastructure often needs authorisation and capture rather than a simple immediate sale.

Payment providers can support transactions where an amount is authorised before being captured later, but authorisations have validity periods that vary by card network, transaction type and provider.

That means booking software should not assume an authorisation taken at reservation can simply remain open until a distant booking date.

This is an area we cover further in our Hotel Merchant Accounts and Payment Integration guide.

Find Your New Processor

Booking Payments Should Reconcile Back to the Booking

This sounds obvious.

In practice, it is one of the biggest reasons integrated payments become valuable.

A single booking might generate:

• £100 deposit;

• £400 balance;

• £75 additional service;

• £25 partial refund.

The finance team should not have to manually discover that those four transactions belong to the same reservation.

The booking platform should ideally connect:

booking ID → customer → transaction → settlement → refund

Cloudbeds' current hotel-payment proposition, for example, emphasises putting guest payment information and transaction data directly against the relevant reservation and automating reconciliation inside the property-management system.

See Cloudbeds' current integrated-payments model

This is an important point for booking software vendors.

Sometimes the value of integrated payments isn't a lower processing rate.

It is removing operational work that exists because payment data and booking data live in different places.

Not Every Booking Business Needs the Same Payment Flow

This is why broad “booking system payment provider” lists are not particularly useful.

Consider five very different booking businesses.

Every one of these businesses has a booking system.

Their payment architecture is not remotely identical.

When Does a Booking System Become a Marketplace?

This is an important boundary.

A software business can provide booking technology without operating a marketplace.

For example:

Restaurant uses software → diner books restaurant → restaurant accepts payment

The software platform may simply provide the technology connecting the booking and payment provider.

Now compare:

Customer books provider through platform → platform receives £500 → platform keeps £50 commission → £450 goes to service provider

That is a different payment flow.

Once the platform becomes involved in receiving or distributing customer money, regulatory considerations become more important.

The FCA specifically states that businesses providing booking services may be providing payment services where they receive customer money before passing it to a seller.

Read the FCA guidance for booking and marketplace businesses

That does not mean every booking platform requires payment-services authorisation.

The FCA's own perimeter guidance recognises that the answer depends on the activities being performed and whether exclusions or exemptions apply.

But the flow of funds should be established before the payment architecture is built.

Where a booking platform needs to distribute payments between multiple parties, our Split Payment Gateways guidecovers the payment considerations in more detail.

The Question Booking Platforms Often Miss: Who Owns the Payment Relationship?

For a small integration, this may feel unimportant.

For a platform with thousands of merchants, it can become strategically significant.

Imagine a booking software company connects 3,000 businesses to one payment provider.

Several years later it decides the commercial arrangement is no longer right.

What happens?

Can it change payment partner?

Can merchants move?

What happens to stored payment credentials?

Who holds the merchant relationship?

Does the platform control its payment pricing?

Will every business need to apply again?

Can more than one provider eventually be supported?

These questions are far easier to answer before thousands of merchants have been onboarded.

For established platforms, payment-provider selection should therefore consider portability as well as integration.

Our guide to changing payment gateways and moving stored cards, tokens and recurring payments explains why token ownership and migration matter.

Should the Booking Platform Make Money From Payments?

If you're a booking software company with an established customer portfolio, this question deserves to be considered separately from the technical integration.

Suppose your software creates the booking.

Your customers collectively process £100 million a year.

A third-party payment provider handles every transaction.

Your software business may receive nothing from that payment volume.

Depending on the provider relationship, another model may allow the platform to participate commercially through:

• referral revenue;

• revenue share;

• transaction-related fees;

• a negotiated underlying payment rate;

• platform-controlled customer pricing; or

• a white-labelled payment proposition.

That does not mean every booking platform should monetise payments.

Payment pricing still needs to be attractive to the merchants using the software.

The payment solution still has to work technically.

And greater commercial control can come with greater operational responsibility.

But ignoring the economics completely can mean overlooking one of the largest potential revenue opportunities inside a mature booking platform.

For a fuller explanation of the commercial models, see:

Integrated Payments for ISVs

and

Embedded Payments for SaaS and Platforms

A Better Way to Value the Payment Opportunity

For booking platforms, we don't think the first calculation should be:

“What percentage will the payment provider give us?”

Start with the customer portfolio.

For example:

How many active merchants do we have?

How much do they process?

What percentage could realistically adopt an integrated payment product?

Which merchant sectors are represented?

How much of that volume is online, in-person or recurring?

Which countries do those merchants operate in?

Now you can estimate:

Potential participating merchants × average payment volume = addressable payment portfolio

Only then does it make sense to discuss payment economics.

MAS View

A booking platform should understand the value of the portfolio before negotiating the commercial model.

A provider discussion looks very different when the conversation is:

“We need a payment API.”

compared with:

“We have 1,200 established merchants processing an estimated £300 million annually through businesses using our platform, and we want to understand the best long-term payment structure.”

Those are not the same commercial conversation.

One Provider May Not Fit the Whole Booking Portfolio

This becomes important for vertical platforms serving different merchant categories.

Imagine one booking platform serving:

• restaurants;

• hotels;

• travel companies;

• experiences; and

• event venues.

Payment-provider appetite can vary across those sectors.

Geography can vary.

Transaction values can vary.

Future-delivery exposure can vary.

Payment flows can vary.

A payment partner that works extremely well for one part of the portfolio may not necessarily accommodate every customer.

Before committing to one provider, ask:

Which of our merchant categories can actually be supported?

Which countries are covered?

Are online and card-present payments available?

Can we add another provider later?

What happens to merchants outside the provider's risk appetite?

For more complex arrangements, our guide to acquirer-agnostic payment gateways and multiple acquirers explains some of the options available.

Booking-system payments are part of a wider integrated-payments strategy. The payment provider may also need to exchange information with CRM, accounting, ERP, property-management or other business systems.

See our Integrated Payments Solutions UK guide for the broader framework for connecting payments with operational software.

Find Your New Processor

The Payment Questions We Would Ask a Booking Platform

Before considering individual providers, Merchant Advice Service would want to understand the booking itself.

Not just the card volume.

Questions would include:

What exactly is being booked?

Who sells the underlying product or service?

When is payment normally due?

Does the customer pay a deposit?

Does a card need to be stored?

Can the final amount change?

Are no-show or cancellation charges required?

Are pre-authorisations used?

Are payments taken online, in person or both?

Are recurring payments involved?

Who receives settlement?

Does the platform deduct commission?

How many merchants use the software?

What do those merchants currently process?

Do you want payments simply to work — or do you want payments to become part of your commercial model?

Once those answers are known, provider selection becomes considerably more meaningful.

This is how Merchant Advice Service approaches complex payment requirements: define the payment structure first, then identify providers whose technology, underwriting and commercial model fit it.

You can read more about How Merchant Advice Service Works, How MAS Researches and Compares Payment Providers and explore the wider Payments Strategy Library.

Sources & Further Reading

This guide has been informed by UK regulatory guidance, current booking-platform functionality, payment-provider technical documentation and Merchant Advice Service research.

Financial Conduct Authority — Booking Businesses and Payment Services

The FCA specifically identifies businesses providing booking services as organisations that should assess whether their activities may constitute payment services, including circumstances where they receive customer money before passing it to a seller.

Read the FCA guidance

Financial Conduct Authority — Payment Services Regulations

Further FCA guidance on businesses providing regulated payment services in the UK.

Read the FCA Payment Services Regulations guidance

OpenTable — Deposits, Card Holds and No-Show Payments

OpenTable's current restaurant functionality demonstrates several distinct booking-payment models, including deposits, credit-card holds and no-show fees.

Read OpenTable's booking-payment guidance

OpenTable — Booking Policies

OpenTable's API documentation demonstrates how booking and cancellation policies can be surfaced as part of the reservation journey.

Read OpenTable's API documentation

Stripe — Saving Payment Methods for Future Use

Technical documentation covering payment credentials intended for later on-session and off-session transactions.

Read Stripe's Setup Intents documentation

Cloudbeds — Integrated Hotel Payments

Cloudbeds' current payments proposition provides a real-world example of payments being linked directly to reservation data and automated payment schedules within a booking/PMS environment.

Read Cloudbeds Payments

Related Merchant Advice Service Guidance

• Payments Strategy Library

• Embedded Payments for SaaS and Platforms

• Integrated Payments for ISVs

• Hotel Merchant Accounts and Payment Integration

• Subscription Payment Processing

• Split Payment Gateways for Marketplaces and Platforms

• Changing Payment Gateway: Stored Cards, Tokens and Recurring Payments

• Acquirer-Agnostic Payment Gateways

Editorial and Commercial Disclosure

Merchant Advice Service is an independent payments information, comparison and provider-matching service.

MAS may receive commission or a referral fee from some payment providers where a business chooses to proceed following an introduction. This does not determine the factual information or provider capabilities included in this guide.

Providers have not paid for inclusion in this article unless explicitly stated.

Providers named within this article are examples and do not represent a complete whole-of-market list or ranking.

Payment functionality including deposits, stored payment methods, card guarantees, pre-authorisation, delayed capture, off-session charging, split payments and merchant onboarding varies between providers. Availability may depend on card-network rules, merchant sector, geography, underwriting criteria and the provider's technical implementation.

A booking-platform integration does not guarantee that every underlying merchant will qualify for a particular payment provider. Merchant eligibility and provider risk appetite vary.

Booking and marketplace businesses should establish whether the way they receive or distribute customer money involves regulated payment services. Merchant Advice Service does not provide legal or regulatory advice.

Merchant Advice Service does not make underwriting decisions or guarantee merchant-account acceptance.

Payment-provider functionality, regulation, card-network requirements, pricing and underwriting criteria can change. This guide provides general information and should not be treated as legal, regulatory or financial advice.