Hotel Payment Solutions UK: Merchant Accounts, PMS Integrations & Multi-Property Payments

Hotel Group Payment Strategy: PMS Integrations, Restaurants, Spas and Multi-Property Payments

A hotel group doesn't have one checkout.

A single guest stay might create payments through the booking engine, front desk, restaurant, bar, spa and room account before a final balance is settled at departure.

That becomes more complicated again across a hotel group.

One property may operate a restaurant under the same legal entity. Another may have a separately managed spa. A third may use different point-of-sale software. Guests might move between properties, charge services back to their room or pay in different currencies.

Behind all of that could sit:

• a Property Management System (PMS);

• central reservation system;

• booking engine;

• channel manager;

• restaurant POS;

• restaurant reservation software;

• spa-management platform;

• event or conference software;

• payment gateway;

• acquiring bank;

• physical terminals; and

• finance or ERP software.

For a hotel group processing significant card volume, the payment question is therefore not:

“Which payment provider has the best hotel rate?”

It is:

“How should payments move through our entire hospitality technology stack — and are we paying for that structure efficiently?”

For groups processing hundreds of thousands or millions each month, this becomes a board-level commercial, technology and operational decision.

The wider principles around enterprise payment strategy are covered in our Payments Strategy Library and High-Volume Merchant Processing guide.

Key Takeaways 

For a hotel group, payment-provider selection should start with the guest journey and existing software architecture, not a provider shortlist.

A group may need payments to work across:

• direct online bookings;

• OTA bookings and virtual cards;

• deposits;

• scheduled payments;

• pre-authorisations;

• card-present transactions;

• MOTO payments;

• room accounts;

• restaurants and bars;

• spas and leisure;

• event and conference payments;

• stored payment credentials;

• refunds;

• international guests;

• multiple currencies;

• multiple properties;

• different legal entities; and

• central finance and reconciliation.

The most important technical question is often:

Can the chosen payment infrastructure work properly with the PMS and the other systems already used across the group?

For larger groups, the commercial review should also ask:

Are our acquiring, gateway and payment costs still appropriate for the volume we process?

Should every property and channel use the same payment provider?

Can guest payment credentials work securely across properties?

Can restaurant and spa charges be posted cleanly to a room account?

Are international and cross-border payment costs being managed effectively?

Can finance see what was paid, where it was paid, which property it belongs to and when it settles?

A hotel payment strategy should ultimately connect three things:

the guest journey + the technology stack + the money.

Find Your New Processor

One Guest. Multiple Payment Events.

Consider a guest booking a three-night spa break.

They might:

Before arrival

Book directly online and pay a £200 deposit.

At check-in

Provide a card which is pre-authorised for the accommodation balance plus incidentals.

During the stay

Charge dinner to the room.

Book a £150 treatment through the spa system.

Buy drinks at the bar.

Extend checkout and incur an additional room charge.

At departure

Have the final amount settled against the authorised card.

Afterwards

Receive a partial refund for a disputed restaurant item.

Commercially, that is one guest stay.

Technically, it may have touched several separate systems.

The payment architecture needs to maintain the relationship between those transactions and the guest account.

That is why hotel payments are less about the checkout and more about the folio.

The Folio Should Sit at the Centre of the Payment Strategy

A hotel folio brings together the charges associated with a guest stay.

That can include:

Room
Food and beverage
Spa
Minibar
Parking
Events
Additional services
Payments
Deposits
Refunds

For groups using Oracle Hospitality OPERA Cloud, this is visible in the way the platform itself is structured.

OPERA Cloud supports multiple billing windows, charge routing, credit-card pre-authorisation, settlement and payment instructions. Oracle's current payment architecture also uses tokenisation when OPERA is integrated with a payment partner.

The important lesson isn't that every hotel should use OPERA.

It is that a hotel group's payment architecture needs to understand where a payment belongs operationally, rather than treating each card transaction as an isolated event.

A restaurant payment charged to a room needs ultimately to reconcile to that guest folio.

The same is true of the spa.

The Hotel Group Payments Map

Before reviewing payment providers, we would map where payment actually enters the business.

For a group, add another dimension:

Which property and which legal entity does each transaction belong to?

That question can fundamentally change how merchant accounts, settlements and reporting need to be structured.

Your PMS Should Influence the Payment Shortlist

For hotel groups, this is one of the most important practical points.

A payment provider may have excellent commercial pricing but still be a poor choice if connecting it properly to the existing hotel technology requires workarounds.

Large hotel groups may already be committed to platforms such as:

• Oracle Hospitality OPERA;

• Mews;

• Cloudbeds;

• SiteMinder;

• another PMS or CRS; or

• different systems across acquired properties.

The payment review should therefore start by understanding what those systems can support.

Find Your New Processor

If You Use OPERA, Understand OPI Before Changing PSP

For groups using Oracle Hospitality OPERA Cloud, Oracle Payment Interface (OPI) can sit between OPERA and external Payment Service Providers.

Oracle describes OPI Cloud as a common interface through which OPERA Cloud can communicate with payment providers for card payments and token exchange.

That matters because a group considering changing its acquiring or payment arrangements needs to understand:

• whether the PSP is compatible with the relevant OPERA environment;

• how tokens are exchanged;

• how authorisations are performed;

• how settlement posts back to the folio;

• how refunds work;

• how physical terminals connect;

• whether Pay by Link is required;

• and what changes will be required across every property.

A commercial payment saving can quickly lose its value if the integration creates operational problems at front desk.

For larger OPERA estates, payments should therefore be treated as an OPERA integration project and a commercial acquiring project at the same time.

Mews, Cloudbeds, and SiteMinder Create a Different Decision

Not every hotel group has the same degree of separation between PMS and payments.

Some hospitality platforms increasingly incorporate payments directly into their own ecosystem.

Mews, for example, currently positions Mews Payments as embedded within its PMS and POS and designed to follow the guest from booking through the stay and checkout.

Cloudbeds similarly integrates payment activity with reservation and guest information.

SiteMinder Pay can automate scheduled guest payments and connect transactions to reservations, while SiteMinder's wider technology ecosystem connects booking engines, channel management, PMS platforms and hundreds of other hospitality technologies.

For a hotel group, that creates a strategic decision:

Do we want payments embedded inside the hotel operating platform?

or:

Do we want greater independence between our hospitality software and payment providers?

There is no universally correct answer.

Embedded payments can reduce integration work.

A more independent payment architecture may offer greater flexibility over acquiring, pricing or future provider changes.

The right decision depends on the group's technology strategy as much as the payment rate.

What Happens When the Restaurant Is on a Different System?

This is where hotel payment architecture starts becoming genuinely hotel-specific.

A group might use one platform for rooms and another for F&B.

The restaurant could have:

• its own POS;

• separate merchant account;

• restaurant reservation technology;

• separate terminals;

• independent reconciliation; and

• different pricing.

But hotel guests may still expect to say:

“Put it on my room.”

That apparently simple request requires systems to communicate.

The restaurant charge needs to reach the correct:

guest → room → reservation → property → folio

without a staff member manually rekeying it.

Oracle OPERA, for example, supports property interfaces through which integrated systems such as point-of-sale can post charges to reservation accounts.

That is why the question for a hotel group isn't simply whether a restaurant POS “takes payments”.

It is whether the restaurant technology and hotel PMS work together in the way the operation requires.

The Spa Can Be Even More Complicated

Hotel and resort spas can operate almost like a separate business inside the property.

A spa may have its own:

• booking software;

• therapists;

• treatment rooms;

• memberships;

• retail products;

• gift cards;

• recurring payments;

• POS;

• reporting; and

• payment requirements.

But hotel guests may still expect the spa to behave like part of the hotel.

For example:

Guest books treatment → spa identifies hotel reservation → guest attends treatment → £180 spa charge is posted directly to Room 304 → charge appears on guest folio → guest settles once at checkout

Current resort-spa software demonstrates how specific this integration can become.

Zenoti, for example, currently integrates its resort-spa platform with hotel PMS products including OPERA, Mews, Apaleo and Cloudbeds. Its OPERA integration can post spa services directly to guest rooms and support cross-centre posting in relevant configurations.

This is a useful example of why hotel-group payments cannot be reviewed in isolation from the wider software stack.

The question isn't:

“Which provider offers the cheapest spa transaction?”

It's:

“Can the spa payment and room-account journey work without creating a separate reconciliation process?”

Find Your New Processor

What If a Guest Uses the Spa at Another Property in the Group?

This is where multi-property architecture becomes important.

Imagine a guest stays at:

Hotel A

but uses the spa at:

Hotel B

and wants the treatment charged back to their room at Hotel A.

Operationally, that may be entirely reasonable.

Technically, it requires the relevant hotel and spa systems to understand:

• which property owns the reservation;

• where the service was delivered;

• where the revenue should be recorded;

• which merchant account is involved;

• and where the payment eventually settles.

Some current hospitality systems already support versions of cross-property posting.

That should tell hotel groups something important:

multi-property payments need to be designed at group level, not property by property.

Tokenisation Becomes a Group-Level Decision

Stored payment credentials are especially important in hospitality.

A guest card may initially be captured:

• during direct booking;

• through a call centre;

• at check-in;

• through a payment link;

• during a spa booking; or

• through another payment journey.

The underlying card number should generally not need to move around the hotel group's systems.

Instead, the payment provider typically creates a secure token representing that card.

But groups need to ask a harder question:

Where can that token actually be used?

For example:

Can a card captured during a central reservation be used at the hotel?

Can the same credential work at another hotel within the group?

Can it be used in the spa?

Can it be used for a later guest-initiated or merchant-initiated payment?

What happens if the PSP changes?

Oracle's 2026 OPERA Cloud functionality now includes options for sharing profile credit-card wallets across properties when shared profiles are enabled, while specifically advising hotel groups to check cross-property token usability with their payment provider.

That's a very good illustration of the issue.

The PMS may technically support the concept.

The PSP and token architecture still need to support it too.

For groups considering a provider migration, see our guide to moving stored cards and payment tokens.

Hotel Groups Need to Decide Where Merchant Accounts Sit

A multi-property hotel group may have:

• one legal entity;

• several legal entities;

• separate companies for different hotels;

• separate restaurants;

• separately operated spas;

• management contracts;

• franchises;

• international properties.

Payments and settlement need to respect that structure.

This is why a hotel group shouldn't automatically assume:

one group = one merchant account

or:

one hotel = one completely independent payment arrangement

The right structure might involve separate merchant accounts by:

• legal entity;

• property;

• country;

• business unit; or

• payment channel.

The key questions are:

Who is legally selling the service?

Where should the money settle?

Which entity should appear to the guest?

How does finance need to report the revenue?

Those questions should be answered before negotiating the acquiring arrangement.

Centralised Commercial Terms Do Not Have to Mean Centralised Settlement

This distinction can be commercially useful for hotel groups.

A hotel group may want to use its combined processing volume when negotiating commercial terms.

But individual properties or legal entities may still require:

• separate merchant accounts;

• separate bank settlement;

• separate reporting;

• separate tax treatment; and

• independent reconciliation.

The commercial strategy can therefore be negotiated at group level even where settlement remains property-specific.

For a CFO, this is particularly important.

A group processing £50 million annually should understand whether it is receiving commercial terms appropriate to the group's aggregate payment value, rather than allowing every property to negotiate independently without leverage.

Our High-Volume Merchant Processing guide and guide to auditing payment fees for high-turnover businesses explore this more broadly.

Find Your New Processor

Hotel Payment Costs Are More Than the Headline Acquiring Rate

Hospitality finance teams should be particularly cautious about comparing providers using a single percentage.

The effective payment cost can include:

• interchange;

• scheme fees;

• processor margin;

• gateway charges;

• terminal costs;

• international-card fees;

• cross-border costs;

• currency conversion;

• MOTO pricing;

• virtual-card costs;

• chargebacks;

• refunds;

• PCI-related costs;

• PMS/payment-interface charges; and

• other service fees.

Card mix can also be very different from a typical domestic retailer.

A central London hotel group may accept substantial volumes of:

• international consumer cards;

• premium cards;

• commercial cards;

• corporate travel cards; and

• OTA virtual cards.

That means another hotel group's advertised rate tells you very little about what your own payment costs should be.

Our UK Merchant Fees Benchmark and IC+ / IC++ guide explain why transaction mix matters.

OTA Virtual Cards Need to Be Included in the Review

Hotels don't receive every booking directly.

OTAs may collect payment from the guest and provide the hotel with a virtual credit card (VCC) through which the hotel receives payment.

This introduces another payment stream with its own:

• card type;

• processing economics;

• activation rules;

• reconciliation process; and

• booking relationship.

SiteMinder Pay, for example, currently identifies and processes virtual cards connected to OTA reservations within its hotel-payment environment.

For a large hotel group, VCC volume should therefore be separated and analysed rather than buried inside the overall card-processing figure.

A CFO reviewing hotel payment costs should know:

What percentage of card volume comes from OTA virtual cards?

What does that volume actually cost to process?

Can those transactions be automatically reconciled to reservations?

MOTO Is Still a Hospitality Issue

Hotels frequently accept bookings and payment instructions through telephone reservation teams.

This can create Mail Order / Telephone Order (MOTO) transactions where a guest is not completing a standard ecommerce checkout.

For hotel groups, MOTO can be commercially and operationally important because:

• fraud risk can differ;

• authentication differs from ecommerce;

• processing economics may differ;

• staff payment handling matters;

• PCI exposure needs to be controlled; and

• payment links may offer an alternative journey.

A hotel group reviewing payments should therefore analyse transaction channels separately.

A £20 million annual card estate might include very different economics across:

direct ecommerce + MOTO + card present + OTA VCC + merchant-initiated transactions

Treating all of that as “our card rate” hides useful information.

Authorisation Rates Matter in Hotels Too

Payment cost is only half of the commercial picture.

An international guest whose legitimate booking payment is declined may simply book elsewhere.

Factors influencing authorisation can include:

• card geography;

• acquiring location;

• authentication;

• stored credentials;

• payment routing;

• transaction data;

• card type;

• merchant category; and

• issuer behaviour.

For international hotel groups, analysing declines by country, channel and card type can expose issues that a group-wide approval percentage hides.

Our guide to improving payment authorisation rates for enterprise merchants covers this in more detail.

Should Every Hotel in the Group Use the Same Payment Provider?

Possibly.

But it should be a deliberate decision.

One provider across the group can offer:

• stronger buying power;

• fewer integrations;

• more consistent reporting;

• unified terminal estates;

• easier support;

• central commercial management; and

• more consistent guest journeys.

More than one provider may offer:

• geographic flexibility;

• local acquiring;

• greater resilience;

• specialist functionality;

• support for different business units;

• negotiating leverage; and

• alternatives where one provider cannot support every requirement.

The answer depends on:

group geography + systems + legal entities + card volume + integrations + risk + operational model

For larger groups considering multiple acquiring relationships, see our Acquirer-Agnostic Payment Gateways guide.

The Biggest Risk in Changing Hotel Payment Provider Is Often the Integration

Hotel groups can see substantial theoretical savings by moving to another acquiring arrangement.

But the payment rate is only valuable if the new setup works.

Before switching, map every point where the existing PSP touches the hotel technology estate.

That might include:

• PMS;

• central reservation system;

• booking engine;

• channel manager;

• terminals;

• restaurant POS;

• spa platform;

• payment links;

• stored-card tokens;

• call centre;

• event software;

• finance platform;

• refunds;

• reconciliation;

• chargebacks; and

• property-level bank settlement.

The group then needs to understand:

what stays

what changes

what needs recertifying

what needs migrating

and

what could temporarily break

This is why hotel groups should review payments before contract renewal rather than trying to replace a complex infrastructure under time pressure.

A Hotel Group Should Be Able to Answer These 12 Questions

For a board-level or procurement review, we would want clear answers to the following.

1. What is our total annual payment volume across the group?

Not just one property.

2. What does our card mix actually look like?

Domestic, EEA, international, commercial, premium and virtual cards.

3. What is our true effective payment cost?

Including more than the headline acquiring margin.

4. Which systems currently touch payments?

PMS, booking engine, POS, restaurant, spa, terminals, events and finance.

5. Which integrations are genuinely non-negotiable?

This should narrow the payment-provider universe quickly.

6. Where are cards tokenised?

And who controls those tokens?

7. Can credentials work across properties where required?

Particularly relevant for shared guest profiles and central reservations.

8. Can restaurant and spa charges post directly to room accounts?

If not, what manual process exists?

9. Where does each legal entity receive settlement?

And is that structure intentional?

10. How do our authorisation rates differ by market and channel?

A group-wide percentage isn't enough.

11. Do we need one PSP or a multi-provider strategy?

Consider resilience, geography and software requirements.

12. What will the group look like in three years?

New properties, acquisitions, countries and software changes should form part of today's provider decision.

The MAS Hotel Group Payment Architecture Review

For a large hospitality business, Merchant Advice Service would not begin by asking:

“Who is your current processor and what rate are you paying?”

That comes later.

We would first build a picture across four layers.

The Guest Journey

Where can a guest pay?

We map:

booking → pre-arrival → check-in → room → restaurant → bar → spa → checkout → post-stay

This identifies the payment events the technology needs to support.

The Systems

We establish which platforms sit behind those payment events.

For example:

PMS → booking engine → channel manager → restaurant POS → spa platform → terminal estate → finance

That tells us which integrations are required and which payment-provider options are technically realistic.

The Group Structure

We establish:

• properties;

• countries;

• legal entities;

• merchant accounts;

• bank accounts;

• settlement;

• central reservations; and

• cross-property requirements.

This tells us how the payment and acquiring structure may need to be organised.

The Commercial Position

Only then do we examine:

• group card volume;

• existing pricing;

• IC+ / IC++;

• gateway costs;

• international cards;

• VCCs;

• MOTO;

• terminals;

• authorisation performance;

• settlement; and

• contract terms.

The result may not necessarily be a provider switch.

It could be:

renegotiating existing terms

consolidating fragmented arrangements

changing one part of the stack

introducing another acquirer

changing PSP

or simply confirming that the existing structure remains appropriate.

That is why MAS treats a large hotel payment review as a payments strategy exercise rather than a quote comparison.

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

Sources & Further Reading

This guide has been informed by current hospitality-system documentation, payment-platform information and Merchant Advice Service research into enterprise payment infrastructure.

Oracle Hospitality — OPERA Cloud Payment Instructions

Oracle documents OPERA Cloud functionality covering billing windows, payment instructions, credit-card pre-authorisation, token wallets, settlement and payment-partner integration.

Oracle Hospitality — Managing Reservation Payment Instructions

Oracle Hospitality — Oracle Payment Interface Cloud

Oracle Payment Interface Cloud provides connectivity between OPERA Cloud and payment providers for payment and token-exchange transactions.

Oracle Payment Interface Cloud

Oracle Hospitality — Multi-Property Payment Functionality

Current OPERA Cloud functionality includes shared-profile card wallets and cross-property postings, demonstrating some of the additional payment considerations arising in hotel groups.

Oracle Hospitality OPERA Cloud Feature Summary

Mews Payments

Mews' current hospitality-payment proposition demonstrates an embedded model connecting payment activity from booking through in-stay transactions and checkout.

Mews Payments

SiteMinder Pay

SiteMinder's current payment product includes automated scheduled payments, virtual-card processing, reservation-linked reconciliation and digital wallets.

SiteMinder Pay

Cloudbeds Payments

Cloudbeds provides another current example of hotel payments integrated into property and reservation workflows.

Cloudbeds Payments

Zenoti — Resort and Hotel Spa Payments

Zenoti's current resort-spa platform demonstrates how spa-management systems can integrate with hotel PMS environments, support room charging and manage multi-property hospitality workflows.

Zenoti Resort Spa Software

Find Your New Processor

Related Merchant Advice Service Guidance

• Payments Strategy Library

• High-Volume Merchant Processing

• Payment Providers for Booking Systems

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

• How High-Turnover Businesses Audit Payment Fees

• UK Merchant Fees Benchmark 2026

• How Enterprise Merchants Improve Payment Authorisation Rates

• 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 and software businesses have not paid for inclusion in this article unless explicitly stated.

Providers and hospitality platforms named within this article are examples used to illustrate payment and integration requirements. They do not represent a complete whole-of-market list, ranking or recommendation.

Payment functionality including pre-authorisation, card storage, tokenisation, cross-property payment credentials, virtual-card processing, room charging, MOTO, multi-acquirer support and property-level settlement varies between providers and software configurations.

PMS, booking-engine, POS, spa and payment integrations can change. Compatibility should always be confirmed against the specific software version, property configuration, region and payment provider before a contractual decision is made.

A hotel group's aggregate processing volume does not guarantee particular rates, provider acceptance or commercial terms.

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

Payment-provider capabilities, hospitality-software integrations, 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.