Hotel Payment Gateways: How They Work in Hospitality

A hotel payment gateway connects a hotel's systems — principally the property management system (PMS) — to the payment infrastructure that processes card transactions. It carries the payment instruction out and returns the result, so the hotel's operational record and the payment record stay connected.

Three systems do three different jobs. The PMS holds the operational record: the reservation, the stay, the folio and the amount due. The gateway carries the payment instruction between the hotel workflow and the payment environment, and returns the transaction result. The acquirer processes the card transaction under the hotel's merchant arrangement and plays a central role in settlement.

That division of responsibility is the simplest way to understand hotel payment architecture, and the fastest way to work out what has gone wrong when a payment fails.

In short: the PMS knows what the hotel needs to charge. The gateway connects that workflow to the payment infrastructure. The acquirer processes the card transaction and participates in settlement.

Hotels need this connection to hold across a guest journey that can begin months before arrival and continue after checkout. A guest may pay a deposit, present a card at check-in, add charges during the stay, settle a balance at checkout and receive a refund a week later.

A hotel payment is not an isolated event. It is part of the hotel's operational record.

What are the main parts of a hotel payment flow?

In short: three layers, three different jobs. The PMS holds the operational record, the gateway carries the transaction, the acquirer processes and settles it. They work together, but they do not own the same decisions.

Layer	Primary role	Hotel context
PMS	Holds the operational record and the hotel workflow	Reservation, stay, folio, charges and amount due
Payment gateway	Connects the hotel workflow to payment infrastructure	Carries the payment instruction and returns the transaction result
Acquirer	Processes card transactions under the merchant acquiring relationship	Card processing, merchant acquiring and settlement

The PMS: the operational record

The property management system sits at the centre of hotel operations. It knows the reservation, the room, the guest, the stay dates and the folio. Where the property's systems are integrated, charges from restaurants, bars, spas and other outlets become part of that same operational record.

The PMS determines what the hotel believes the guest owes. It is not the card-payment network.

The payment gateway: the connection

The gateway connects the hotel workflow to payment infrastructure.

In an integrated flow, the payment instruction originates in the hotel workflow rather than being typed into a separate terminal. The gateway passes the transaction into the payment environment and returns the result.

That creates a link between the operational event and the payment event. Instead of the PMS holding one record and the terminal producing an unrelated second one, both carry a reference that ties them together. Everything downstream — investigation, night audit, reconciliation — depends on that reference existing.

The acquirer: processing and settlement

The acquirer provides card-acquiring services to the merchant. It participates in the processing chain that produces an approval or a decline, and it settles processed transactions to the hotel.

The gateway does not replace the acquirer. A gateway can transmit a transaction perfectly and still see it declined by the issuer. A payment can succeed at the acquirer while the corresponding posting in the hotel system fails.

Knowing which system owns which decision is what turns an open-ended investigation into a specific question.

Why are hotel payments different from retail payments?

In short: a retail purchase is one interaction. A hotel stay is a payment lifecycle that can run for months, change value mid-way, and continue after the guest has gone.

A retail purchase is usually a single event: the customer selects an item, pays, leaves.

A hotel guest might:

• provide payment details when making a reservation;
• pay a deposit before arrival;
• receive a payment link for a remote balance;
• present a card at check-in;
• have an amount pre-authorised;
• extend the stay or add charges from hotel outlets;
• settle the final balance at checkout;
• require an adjustment or refund after departure.

The value attached to the stay also moves. A stay can be extended, and outlet charges can accumulate, so the amount authorised at check-in may no longer cover what the guest owes.

Whether anyone notices before checkout depends on whether the PMS and the payment environment are exchanging that information, or whether a person is expected to spot it. That is an architecture question before it is a procedure question.

This is why hospitality payment architecture has to connect payment activity to the guest lifecycle, not just to a terminal.

For the operating procedures around pre-authorisation, checkout, exception handling and night audit, see Hotel Night Audit & Payment Reconciliation: An SOP Framework.

What does an integrated hotel payment gateway do?

In short: it connects the hotel workflow to the payment environment at each stage of the stay, and returns enough transaction detail to keep both sides traceable. What it cannot do is decide the hotel's commercial rules.

The exact functions available depend on the property's PMS, payment providers, integrations and configuration. The architectural role stays the same across all of them.

Before arrival

Payment activity can begin long before the guest reaches the property.

A hotel may collect a deposit, guarantee a reservation or request a balance remotely. The transaction can originate in a booking workflow or through a secure Pay-by-Link journey.

The operational requirement is traceability: the hotel needs to know how that payment relates to the reservation or guest account, and needs to know it without someone remembering.

At check-in and during the stay

Hotels commonly pre-authorise at arrival. During the stay, the folio grows through additional nights and outlet charges, which can create a need for further payment activity.

The architectural distinction matters here: the gateway executes payment instructions. It does not invent the hotel's commercial rules. What amount to authorise, when to increase it and what to do when an authorisation declines are decided by the PMS configuration and the property's operating procedure.

At checkout

Checkout is where integration is most visible to staff.

In a connected workflow, the amount due passes from the hotel system into the payment process rather than being typed into a separate device. The result returns to the hotel workflow.

That removes a common source of mismatch — one amount in the PMS, a different amount entered by hand — and leaves both records carrying a shared reference.

After departure

The financial lifecycle continues after the guest leaves. Hotels investigate transactions, issue adjustments and refunds, and reconcile operational records against payment and settlement records.

The detailed controls belong in the Hotel Payment SOP. At architecture level the principle is simpler: a payment should stay traceable across every system involved in its lifecycle.

Integrated gateway or standalone terminal: what changes?

In short: a standalone terminal can take a valid payment without knowing which folio it belongs to. That is not a fault, but it moves the linking work onto a person.

A standalone payment terminal processes a card transaction without a direct connection to the PMS workflow. That can be a deliberate choice — a particular outlet, a fallback procedure, a specific payment scenario.

The architectural difference is where the hand-off happens.

Integrated payment flow	Standalone terminal flow
The hotel workflow supplies the payment amount	A staff member reads the amount from the hotel system
The instruction and result stay linked to the hotel workflow	The amount is re-entered into a separate device
Transaction references tie the two records together	The result is recorded or posted back separately
Fewer manual hand-offs	Each hand-off is another opportunity for the records to diverge

A standalone terminal is not an inherently poor way to take a payment. It requires a different operating procedure, because the link between the hotel record and the payment record is made by a person rather than by the systems.

The SOP guide covers the controls hotel teams need around standalone payments. This article is concerned with the architectural difference.

Who owns a hotel payment problem?

In short: most payment incidents are resolved fastest by asking which system made — or failed to make — the decision that looks wrong, before escalating to anyone.

Which system made — or failed to make — the decision that appears to be wrong?

Symptom	First boundary to investigate	Why
Reservation, folio or amount due is wrong	PMS / hotel system	The operational record originates there
Payment instruction never reaches the payment environment	Gateway / integration	The connection between systems may have failed
Card transaction is declined	Payment-processing chain	A gateway does not decide whether the issuer approves
Payment succeeds but the hotel record is not updated	Payment record and PMS posting	A successful payment and a successful posting are separate states
Processed transactions do not match expected settlement	Acquiring, settlement and reconciliation records	Processing and settlement are different financial boundaries
Terminal cannot communicate	Terminal, local connectivity, payment environment	A correct instruction cannot complete without a working payment path

Some incidents cross more than one boundary. The table is a starting point, not a substitute for the property's incident procedure.

One rule carries more weight than the rest: if a payment appears to have succeeded but the PMS has not been updated, establish the state of the original transaction before attempting another charge. The full exception procedure is in the Hotel Payment SOP.

How does a payment gateway work with a hotel PMS?

In short: the integration model varies by PMS, but the objective does not — connect the operational context of the stay to the payment action and its result.

A deep PMS integration makes payment activity part of the hotel workflow rather than a task performed alongside it.

Oracle OPERA is the most documented example, with its own payment-interface architecture and a separate integration platform for OPERA Cloud. Rather than repeat that here, our Oracle OPERA Cloud payment integration guide explains OPI, OHIP and the payment lifecycle in detail.

The principle holds across platforms. For hotel groups it matters more, because the estate is rarely uniform. One property runs one PMS while another runs something else. Groups acquire hotels, change management arrangements and migrate systems, usually while still operating.

Payment architecture therefore needs to be evaluated at estate level, not property by property.

What should hotel groups understand about payment architecture?

In short: at estate level, the questions that matter are integration depth, token portability, the difference between visibility and reconciliation, and whether the architecture survives change.

Integration depth matters more than the existence of a connector

A logo on an integrations page does not describe what the integration does.

The questions worth asking: which payment actions can originate in the PMS, what information returns to it, how transaction references are retained, and how the integration behaves when one part of the workflow fails.

That is the difference between integration availability and integration depth.

Card-present and remote payments belong to the same guest journey

A guest may pay remotely before arrival and at a terminal in the property. Different channels, one lifecycle. Architecture that treats them as separate systems pushes the joining work onto finance.

Tokenisation reduces unnecessary handling of card data

Tokenisation substitutes payment credentials with a token that can be referenced in later payment workflows.

The architectural question is not whether a platform uses tokens. It is where a token can be used, which systems can reference it, and what happens to it when the payment provider or PMS environment changes. See Juno Universal Token for 934's approach.

Transaction visibility and reconciliation answer different questions

Visibility tells an operations team what happened to one payment. Reconciliation asks whether records across operational, payment and financial systems agree.

They are related. They are not the same control, and a platform that offers one is not offering the other. The Hotel Payment SOP sets out the reconciliation boundaries in detail.

Architecture should survive change

A payment layer tightly coupled to one property, one PMS or one acquiring configuration becomes a constraint the moment the estate changes.

Interoperability, integration depth and clear system boundaries are strategic questions, not implementation details.

Where 934 fits

934 provides the payment layer between hotel workflows and payment infrastructure.

Juno Hospitality Suite covers hospitality payment workflows across hotel environments, and 934's payment integration capabilities connect payment activity to the hotel systems a property already runs.

934 does not replace the PMS or the acquirer. The role of the platform is to make the payment layer work coherently between them.

Key takeaways

• The PMS owns the operational context — reservation, stay, folio, and the amount the hotel expects to collect.
• The gateway connects systems. It carries the payment instruction between the hotel workflow and payment infrastructure and returns the result.
• The acquirer processes card payments under the merchant relationship and participates in settlement.
• Hotel payments form a lifecycle. Deposits, pre-authorisations, in-stay charges, checkout and post-stay activity all relate to one guest journey.
• Integration reduces manual hand-offs. It does not remove the need for clear operating procedures.
• System boundaries decide how fast you resolve a failure. Identify which system owned the decision before escalating.
• Groups should evaluate architecture at estate level. PMS platforms, payment providers and property configurations change over time.

Glossary

Acquirer — The financial institution or payment organisation that processes card transactions for the merchant and settles funds to the hotel.

Authorisation — Approval from the payment chain that funds or credit are available for a proposed transaction.

Folio — The operational record in the PMS showing charges, credits and payments relating to a guest stay.

Incremental authorisation — An increase to an existing authorisation as the expected or actual guest balance grows.

Payment gateway — The layer that connects hotel workflows to payment infrastructure, carrying transaction instructions and responses between them.

Payment terminal — A device used to accept card-present payments.

PMS (Property Management System) — The hotel system used to manage operational information including reservations, stays, rooms and guest folios.

Pre-authorisation — A temporary hold on card funds used to secure expected payment without immediately completing the charge.

Reconciliation — The process of comparing related financial records and explaining or resolving differences.

Settlement — The movement and reporting of funds from the acquiring/payment chain to the merchant.

Tokenisation — Replacement of sensitive card data with a token that can be used within the permitted payment environment without repeatedly exposing or storing the underlying card number.

Editorial note

This guide is vendor-neutral architectural guidance. It describes system boundaries rather than the configuration of any particular product. Operating procedures are covered in the Hotel Payment SOP; Oracle-specific integration detail is covered in the Oracle OPERA Cloud payment integration guide. Product names remain the property of their owners.

Primary sources

Terminology and system boundaries in this guide are grounded in the following primary documentation:

Payment-data and tokenisation terminology

• PCI Security Standards Council — Glossary of Terms, Abbreviations and Acronyms (acquirer, authorisation, merchant, tokenisation)
• PCI Security Standards Council — Document Library (tokenisation guidance and current standards)
• EMVCo — Payment Tokenisation (payment tokens and their scope of use)

Authorisation and pre-authorisation

• Visa Core Rules and Visa Product and Service Rules (authorisation, estimated and incremental authorisation, reversal)

PMS and hospitality payment interfaces

• Oracle Hospitality — Payments (referenced for the governed OPI/OHIP guidance linked above)

934 statements

Every statement about 934 capability in this guide is governed by the 934 payment capability registry and marketing claims register, and is limited to the wording those registers approve.