Hotel Payment SOPs: How to Standardise Payment Posting, Night Audit and Reconciliation

Payments rarely go wrong because a hotel cannot take a card.

They go wrong because the payment was taken in one system, recorded differently in another and discovered later by someone in finance who was not there when it happened.

A deposit is collected before arrival but never transferred to the folio. A receptionist takes a payment on a standalone terminal and forgets to post it. An authorisation no longer covers the guest's growing balance. A refund is processed at the payment provider but not reflected in the PMS. Or the folio looks correct, yet the amount eventually settled by the acquirer is different.

Individually, these are exceptions. Repeated across shifts, properties and payment channels, they become an operating model.

A hotel payment SOP prevents that.

It defines how every payment event should be processed, where it should be recorded, who can perform it, what happens when systems disagree, what night audit must check and how finance reconciles the result to settlement.

The central rule is simple:

Every payment relating to a guest stay must be traceable to the record it belongs to, and onward into reconciliation.

That does not mean every payment starts in the PMS. Deposits, booking-engine payments, payment links and some POS payments legitimately originate elsewhere — and a POS payment may settle at the outlet rather than on the folio. What matters is that the hotel can connect the payment to the right operational record and reconcile it to the money received.

This guide provides a practical framework for doing that, with the primary documentation behind each control collected at the end of the guide.

In this guide

• What is a hotel payment SOP?
• The golden rule: keep the payment and folio aligned
• The lifecycle, stage by stage: arrival to after departure
• When the payment succeeds but the posting fails
• Standalone terminals
• Night audit payment checklist
• Reconciliation: four boundaries, not one
• Roles, permissions and audit trail
• The 12 controls every SOP should define
• Applying the SOP to your PMS
• A reusable SOP template

Who this guide is for

This guide is intended for hotel General Managers, Operations and Front Office Managers, night-audit teams, Finance Directors and hotel finance teams, as well as CIOs and IT leaders responsible for payment and PMS architecture.

It is particularly relevant to multi-property groups trying to replace property-by-property payment practices with one consistent operating standard.

What is a hotel payment SOP?

A hotel payment SOP (standard operating procedure) is the documented set of controls governing how a property processes, records, verifies and reconciles payment events across the guest journey.

That includes deposits, pre-authorisations, payments, incremental authorisations, captures, voids, refunds and releases.

A good payment SOP answers five questions every time money moves:

1. Where should the payment action take place?
2. What should appear in the PMS or guest folio as a result?
3. Who is authorised to perform or approve the action?
4. How will the hotel detect and resolve an exception?
5. How will finance reconcile the transaction to settlement?

This makes a payment SOP different from a general front-office procedure: it is organised around payment events rather than shifts, and it does not stop when a terminal displays "Approved".

A payment is operationally complete when the payment record and guest folio are aligned. Financially, the process continues until the transaction can be reconciled to the settlement received from the acquirer.

The golden rule: keep the payment and folio aligned

The guest folio should be the hotel's operational record of what a guest owes and how that balance was settled.

But it is important not to confuse the folio with every other financial record involved in a payment.

A typical hotel payment ultimately exists in several places:

These records are related, but they are not identical.

An acquirer settlement may combine many transactions. Fees can be deducted. Settlement timing can differ from the business date. Chargebacks and other adjustments can appear later.

The objective is therefore not to make every record look identical. It is to make every payment traceable and reconcilable across them — and that starts at the point of payment.

If a payment relating to a stay is taken outside the PMS, the SOP should define how it is reliably associated with the correct reservation or folio. If that relationship depends on a member of staff remembering to re-key the transaction later, the hotel has created a reconciliation problem before finance has even seen it.

How payments technically reach the folio — interfaces, certification, tokenisation — is an architecture question rather than an SOP question. For Oracle estates, we cover it in Oracle OPERA Cloud payment integration: OPI, OHIP and how payments post back.

There are legitimate exceptions to PMS initiation

The principle does not mean every payment must originate in the PMS. Several routes legitimately start elsewhere.

Deposits may sit in a separate deposit ledger before arrival and transfer to the guest folio at check-in — the model Oracle documents for OPERA Cloud in its reservation deposit payments guide.

Booking-engine or central-reservation payments may occur before the PMS reservation exists.

POS transactions may either be posted to the guest's room and settled through the folio, or paid directly at the outlet and reconciled through the POS payment path.

Remote payments may originate through a secure payment link.

All of these fit a disciplined payment model. The requirement is that the hotel knows where the transaction belongs, how it is linked to the guest or sale and how it will enter reconciliation.

A hotel payment SOP should follow the guest journey

The easiest way to build a useful SOP is not around individual systems or departments. Build it around the payment lifecycle.

For each stage, define the expected payment action, system of record, control, exception and owner.

1. Before arrival: deposits and remote payments

Pre-arrival payments are often where payment discipline first breaks down.

A hotel may collect a deposit through a booking engine, payment link or central reservation channel days or months before the guest arrives. The payment may therefore exist before a live folio does.

The SOP should define:

• which remote-payment methods are approved;
• how the payment is linked to the reservation;
• where a deposit is recorded before arrival;
• when it transfers to the guest folio;
• how the guest receives confirmation; and
• who investigates an unallocated or unmatched deposit.

The control is not "all deposits must already be on the folio".

It is every deposit must have a traceable path to the reservation and eventual folio.

Hotels should also avoid processes that unnecessarily expose employees to card data. For telephone payments in particular, PCI SSC guidance on protecting telephone-based payment card data is that card details should not be written down or recorded. Secure payment links and tokenised payment methods provide a cleaner operational model than asking staff to receive and manually record card details — and a hosted payment link completed on the provider's page keeps card entry outside the hotel's systems altogether (see PCI SSC FAQ 1588 on fully outsourced payment flows).

2. Check-in: pre-authorisation

At check-in, the payment question changes from "has the guest paid anything?" to "does the hotel have sufficient payment cover for the expected stay?"

The SOP should define a consistent pre-authorisation rule based on the property's operating model — for example, expected accommodation plus an agreed allowance for incidentals.

The important word is rule. If one receptionist authorises the room rate, another adds a fixed amount and a third guesses what feels appropriate, the hotel does not have a payment control. It has three individual practices. Configure the rule in the PMS where it supports one — OPERA Cloud, for instance, calculates the anticipated amount from configurable credit card authorisation rules rather than leaving the estimate to the operator.

The pre-authorisation should be associated with the guest's stay and visible to the operational team.

Staff should also be able to explain clearly that a pre-authorisation is a hold rather than a completed charge: it reserves funds on the guest's card without debiting them, and if it is never captured it expires and the funds release. Validity windows and release timing vary by card scheme and issuer — each scheme publishes its own merchant rules (Mastercard's Transaction Processing Rules; the American Express Merchant Reference Guide).

Lodging is a recognised special case in scheme rules. Visa gives lodging, vehicle-rental and cruise merchants a 30-day window from an estimated authorisation approval to add incremental authorisations and complete the transaction (Visa, Authorization and Reversal Processing Best Practices for Merchants). Other schemes publish their own timeframes — the SOP should state what your payment provider actually supports rather than generalising across schemes.

The SOP should define what happens when an authorisation fails. A declined authorisation should create an operational exception with a named owner, not simply disappear into the next shift.

3. During the stay: keep authorisation aligned with the folio

A payment SOP should not assume that the amount authorised at check-in will remain sufficient.

The folio changes throughout the stay. Room charges post. Guests use restaurants, spas and other services. A stay can be extended. Incidentals can exceed the original estimate.

The hotel should therefore monitor the relationship between the folio balance and the authorised amount.

Where the PMS and payment integration support incremental authorisation, the process can maintain payment cover as the guest's balance grows — often automatically as part of the end-of-day routine (OPERA Cloud obtains additional authorisations during End of Day as balances consume the original hold; Infor HMS requests an incremental authorisation when the final amount exceeds the original, manually or as an end-of-day procedure).

The operating principle is:

The pre-authorised amount should be kept aligned with the folio balance throughout the stay.

The SOP should define when incremental authorisation occurs, what threshold triggers it and what staff should do if the additional authorisation is declined.

This is particularly important for long stays and high-spend guests. Discovering at checkout that a large folio is no longer adequately authorised turns an avoidable operational exception into a guest-facing payment problem.

4. Checkout: capture, completion and release

Checkout should close the operational payment loop.

The final folio should be reviewed, the appropriate amount captured or completed against the existing authorisation, and any unused authorisation handled according to the payment-provider and scheme process.

The result should be simple:

the amount charged to the guest should be explainable from the final folio.

Unused authorisation is not a cosmetic detail. Visa's published best practice is that where estimated and incremental authorisations exceed the final amount, the excess should be reversed within 24 hours of transaction completion — and Visa assesses a Misuse of Authorization System fee against approved authorisations that are never matched to a clearing transaction or a reversal (Visa, Authorization and Reversal Processing Best Practices). Whether the release happens automatically depends on your PMS and payment provider — verify the behaviour once, then write the SOP around what your stack actually does.

Common failures at this stage include taking a new payment rather than completing an existing authorisation, leaving unnecessary holds in place or settling a different amount from the folio without recording why.

The SOP should specify how staff handle each case rather than relying on experience or improvisation.

5. After departure: voids, refunds and adjustments

Reversal procedures deserve their own control because they move money in the opposite direction and can create both guest-service and fraud risk.

It is worth being precise about three operations that are often lumped together, because they behave differently at the payment provider and on the folio:

• A void (or cancellation) reverses a payment that has not yet been captured — no funds have moved, so there is nothing to refund.
• A refund returns funds that have been captured, and should be processed as a linked refund referenced to the original transaction — with the guest told honestly that the money can take days, and for some payment methods considerably longer, to arrive back. Reversals, refunds and credits are governed by the card schemes' merchant rules (Mastercard's Transaction Processing Rules covers reversals and refund transactions; the American Express Merchant Reference Guide covers processing credits).
• An adjustment or rebate corrects the folio's charges rather than the payment itself — OPERA Cloud, for example, distinguishes adjustments, rebates and credit-card refunds as separate cashiering operations in its charges, adjustments and payments documentation.

Exact terminology and transaction behaviour vary by PMS and payment provider — RMS Cloud, for instance, separates a reverse receipt from a refund — so the SOP should use your systems' vocabulary precisely rather than a generic "void/refund".

For each reversal type, the SOP should define:

• who can initiate it;
• whether additional approval is required above a threshold;
• how the original transaction is identified;
• how the action is reflected against the guest folio;
• what reason or reference must be recorded;
• how partial actions are handled;
• what audit trail is retained; and
• how a failed or rejected reversal is escalated.

The operational principle is the same as for the original payment:

the action at the payment provider and the action in the PMS must remain connected.

A refund that exists only in one system creates an exception that finance will eventually have to reconstruct.

When the payment succeeds but the posting fails

This is one of the most important exceptions for a hotel SOP to define.

Imagine the payment provider approves a transaction but the response to the PMS fails.

The hotel now has two different truths:

Payment provider: payment succeeded. PMS: no payment recorded.

The wrong response is simply to take the payment again. Before retrying anything, staff need to establish whether money has already moved or been authorised.

Check the provider before checking anything else. Did the original transaction succeed, fail, or is the state genuinely unknown? Everything downstream depends on which of the three applies, and no amount of searching the PMS will settle it.

If it succeeded, the question is whether the folio carries it with a matching reference. If it does, the records are aligned and no action is needed. If it does not, correct the record rather than the payment: post to the folio using the provider's transaction reference, and log the incident. Match on references where they exist rather than on amount and time alone.

If it failed, no money moved. Reverse any phantom folio posting, then re-take payment with the guest — before departure, not after.

If the state is uncertain, escalate it. Do not ask front-office staff to guess whether a transaction succeeded; a named owner resolves it with the provider.

This is where integrated payment architecture materially improves the SOP: automation handles the normal flow, leaving staff to manage exceptions.

Standalone terminals need a stricter procedure

Standalone terminals are sometimes operationally necessary. They are also one of the easiest ways to create a reconciliation gap.

A terminal can successfully take money without knowing which reservation, folio or PMS transaction it relates to. This is not a hotel-specific quirk: a non-integrated terminal leaves the merchant to reconcile transactions against sales manually, because nothing ties the payment to an order or folio. Offline store-and-forward modes go further still, typically leaving the merchant liable for failed captures and related disputes.

That does not make standalone payments inherently wrong. It means the SOP must compensate for the missing integration.

If a standalone terminal is used, require at minimum:

• the payment to be posted to the correct folio or operating system immediately;
• the terminal transaction reference to be retained;
• a reason for using the standalone path;
• shift-close verification that standalone transactions have corresponding operational records; and
• reconciliation of the terminal batch to those postings.

The principle is simple: no successful standalone payment should become an anonymous line on tomorrow's settlement report.

Night audit is the operational control boundary

What is the night audit in a hotel?

The night audit (end of day) is the hotel's daily closing routine: it verifies and balances the day's transactions, posts room and tax, produces the day's audit reports and advances the business date. In OPERA Cloud, for example, the End of Day routine also obtains outstanding credit-card authorisations, retries stored offline settlements and closes cashiers (Oracle, About End of Day).

Night audit is where a hotel should discover whether the day's payment activity makes operational sense. It should not be where staff begin manually rebuilding the entire day.

Night audit payment checklist

A payment-focused night-audit checklist should answer questions such as:

• Are all successful payments represented in the PMS or appropriate operating system?
• Are there folio postings with no corresponding payment transaction?
• Did any authorisations or incremental authorisations fail?
• Are in-house balances adequately covered?
• Were deposits transferred or allocated correctly?
• Are voids and refunds supported by an original transaction and appropriate approval?
• Were standalone or offline terminal transactions posted correctly?
• Are cashier and terminal totals consistent with the operational records? (Individual cashier closure — expected versus actual takings under a named cashier ID — is standard, documented PMS functionality; see Oracle's cashier closure guide.)
• Are there unresolved payment exceptions from earlier shifts?

Where night audit hands off to finance

The aim is not necessarily to resolve every financial difference before the business date closes. It is to separate operational exceptions that the property can correct now from financial exceptions that need to move into settlement reconciliation.

That distinction matters. A missing folio posting may be fixable by the property before close. An acquiring fee that causes settlement to differ from gross transactions is not a front-office error, and should not block night audit simply because the numbers are different.

Night audit should therefore create a clean hand-off to finance rather than pretending that every payment difference has the same cause.

Hotel payment reconciliation: four boundaries, not one

Payment reconciliation is often described as one task. In practice, a hotel needs to prove the payment across four boundaries — PMS → payment provider → acquirer settlement → bank → accounting.

Boundary 1: folio to payment transaction

Does the payment recorded in the PMS correspond to a real transaction at the payment provider?

This catches missing postings, duplicate postings and transactions taken outside the expected operational flow. It is a daily, operational check — most of it belongs to shift close and night audit.

Boundary 2: payment transaction to acquirer settlement

Was the transaction included in the expected settlement, and what did it cost?

Settlement reports itemise each settled transaction with its fees, commissions and any currency effects, from gross through to net — the artefact that lets finance tie individual folios to a payout. (The card schemes document their side of this in their merchant guides — the American Express Merchant Reference Guide, for example, has dedicated sections on submission and settlement.) Differences here may be legitimate — fees, timing, chargebacks, currency effects. The goal is not equality. It is explainability.

Boundary 3: settlement to bank

Did the expected net amount actually arrive? The settlement report is matched to the bank statement, payout by payout.

Boundary 4: bank and settlement to accounting

Does the whole chain reconcile into the hotel's accounting records — revenue, fees, deposits and ledger balances recognised correctly in the ERP or finance system?

At this point the payment has moved beyond front-office operations into financial control.

A strong SOP defines who owns each boundary and what evidence moves with an unresolved exception. And the causality runs one way: every exception the operation did not catch at boundary 1 — the unposted payment, the anonymous terminal transaction, the refund processed outside the PMS — resurfaces at boundaries 2–4 as manual work for someone with none of the context the front desk had at the time.

Roles, permissions and audit trail

A payment SOP is incomplete if it describes what should happen but not who is allowed to make it happen.

The person taking a payment does not necessarily need authority to issue a large refund. The person approving an exception should not necessarily be the same person who created it. Finance needs visibility without requiring operational permissions.

This is standard segregation-of-duties thinking: payment initiation, approval and reconciliation should have appropriate separation, because self-approved reversals are the classic concealment pattern for payment fraud. Where small teams cannot fully separate the duties, the recognised compensating control is independent periodic review of all voids and refunds, plus management approval above a threshold.

At minimum, define responsibility for:

The exact roles will vary by hotel. The control principle should not: sensitive actions need named permissions and an audit trail. Your PMS gives you the enforcement surface — individual operator IDs, task-level permissions on deposits and refunds, mandatory reason codes on negative postings, and the audit reports that make independent review possible.

PCI DSS belongs in the SOP

Payment procedure and card-data security cannot be separated.

The SOP should tell staff not only how to take a payment, but which payment methods are permitted when the guest is not physically present and what card information must never be recorded in notes, emails, spreadsheets or other hotel systems. The baseline is PCI DSS's own storage rules: sensitive authentication data — security codes, PINs, track data — must never be stored after authorisation, even encrypted, and displayed card numbers should be masked (PCI SSC data storage guidelines).

Tokenisation can reduce the amount of card data a hotel handles directly by replacing the card number with a token for subsequent use.

It does not, by itself, remove the hotel's PCI DSS obligations. The PCI Security Standards Council is precise on this point: tokenisation does not remove the requirement to maintain and validate compliance. What it can do is narrow the job — fewer system components fall within scope, so validation becomes simpler rather than unnecessary (PCI SSC Tokenization Guidelines).

The SOP should therefore align with the hotel's assessed PCI scope and the specific implementation of its PMS, payment provider, terminals, e-commerce channels and remote-payment processes.

For staff, the rule should be much simpler:

Use the approved payment channel. Do not create a new place for card data to live.

The 12 controls every hotel payment SOP should define

A hotel does not need a hundred-page payment manual. It needs unambiguous controls at the points where mistakes create downstream work.

A practical SOP should define these twelve:

1. Approved payment channels — where staff are permitted to take in-person and remote payments.
2. PMS posting rule — every stay-related payment is initiated from the PMS or traceable to the record it belongs to, and onward into reconciliation.
3. Deposit control — where deposits sit before arrival, how they are allocated and when they transfer.
4. Pre-authorisation rule — how the amount is calculated, recorded and explained to the guest.
5. Incremental authorisation rule — when additional cover is obtained during the stay and how failures are handled.
6. Checkout control — how the final amount is captured/completed and how unused authorisation is released.
7. Void, refund and adjustment control — permissions, approval thresholds, original-transaction linkage and required reason.
8. Standalone/offline procedure — when it may be used and how every transaction is subsequently linked and checked.
9. Payment/posting mismatch procedure — what staff do when the provider and PMS disagree, including the rule not to charge again until transaction status is known.
10. Shift-close and night-audit checks — the daily controls that identify operational payment exceptions before they become finance problems.
11. Settlement reconciliation ownership — who matches transactions to settlement, what tolerances apply and how differences are classified.
12. Audit and evidence retention — what references, approvals, folios and exception records must be retained and where.

For a hotel group, these twelve controls should be standard across the estate wherever possible.

Property-specific configuration can vary. The control objective should not.

Applying the SOP to your PMS

The operating model should be vendor-neutral, but implementation is not.

Different PMS platforms use different terminology, reports, permissions and payment workflows. Some automate authorisation and posting extensively; others rely more heavily on provider integrations or property procedure.

Your SOP should therefore have two layers:

Group or property policy: what must happen.

System procedure: exactly how it happens in the PMS and payment platform being used.

Do not copy an SOP from one PMS into another and assume the buttons mean the same thing. Instead, map each of the twelve controls to the relevant PMS procedure and payment-provider documentation. That approach also makes PMS migrations easier: the control remains stable even when the system changes.

As a starting point, this is where the six platforms most commonly integrated in hospitality document their payment operations — the vendor remains the authority for screens, configuration and product behaviour:

A reusable hotel payment SOP template

For each payment event, document the same fields.

Then test the SOP against real scenarios rather than reviewing it only as a document.

Can a new receptionist follow it when a payment appears to fail?

Can night audit tell whether a payment was taken but not posted?

Can finance trace a settlement difference back to a transaction?

Can a manager see who approved a refund?

Can the hotel operate safely when the normal terminal or integration is unavailable?

If the answer depends on "ask the person who normally does it", the SOP is not finished.

Common payment SOP mistakes

The most common failures are rarely sophisticated.

Treating an approved terminal transaction as the end of the process. Approval proves that the payment provider accepted an action. It does not prove that the PMS, settlement and accounting records are aligned.

Allowing standalone payments without a posting control. This creates transactions with no reliable operational reference.

Using different pre-authorisation practices by employee or property. Rules should be configured and documented, not inherited as folklore.

Retaking a payment when system state is uncertain. Check the original transaction before risking a duplicate charge.

Processing a refund outside the operational record. The reversal must remain linked to the original payment and folio.

Making night audit responsible for settlement differences it cannot resolve. Night audit owns operational completeness. Finance owns the later financial reconciliation.

Giving permissions without auditability. A payment action should leave enough evidence to determine who did what, when and why.

Writing an SOP around today's screens. Systems change. Controls should survive upgrades, integrations and PMS migrations.

Where 934 fits

934's approach to hospitality payments is built around the same principle: payment activity should remain connected to the hotel's operational systems rather than creating a separate payment world that finance has to reconcile later.

Juno connects payment processing with hotel-system integrations, transaction visibility and operational reporting. Depending on the implementation, hotels can combine integrated in-person payments with remote payment collection, settlement visibility and reconciliation workflows.

The important outcome is not simply having another payment dashboard.

It is maintaining a traceable chain from the hotel operation to the payment transaction and onward to settlement — so exceptions can be identified and resolved without reconstructing the guest journey from several disconnected systems.

Key takeaways

A hotel payment SOP should make payment behaviour consistent across people, shifts, channels and properties.

The most important control is that every stay-related payment is traceable to the record it belongs to, and onward into reconciliation. The PMS folio remains the operational record for the stay, while payment-provider, acquirer and finance records provide different parts of the financial truth.

Night audit should detect and resolve operational payment exceptions before they become tomorrow's reconciliation work. Finance should then reconcile the payment across four boundaries — PMS to provider, provider to settlement, settlement to bank, and into accounting — explaining legitimate differences rather than expecting every record to be identical.

The technology matters because good integration can enforce much of this discipline automatically. But technology does not replace the SOP — the SOP defines what "correct" looks like.

Glossary

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

Adjustment / rebate — A correction to the folio's charges (as distinct from reversing a payment). PMS terminology varies.

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

Capture / completion — The action that converts an authorised amount into a transaction to be settled.

Deposit — Money collected before or during the reservation lifecycle and held against the guest's future balance.

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.

Night audit — The hotel's end-of-business-day process for closing operational activity, checking exceptions and advancing the business date.

Payment provider / PSP — The platform or provider handling payment transactions between the hotel and the acquiring/payment network.

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.

Refund — Returning captured funds to the guest, linked to the original transaction.

Release / authorisation reversal — Cancelling an unused authorisation so held funds return to the guest's available balance.

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 the underlying card number.

Void — Cancelling a payment before capture; no funds have moved, so there is nothing to refund.

Editorial note

This guide is vendor-neutral operational guidance based on the published documentation of the PMS platforms, card schemes and payment bodies cited, together with 934's implementation experience. Product names remain the property of their owners; vendor documentation is the authority for exact product behaviour and configuration, and several linked help-centre pages are version-specific. Controls described here are recommended operating practice rather than regulatory requirements, except where PCI DSS is explicitly cited.

Primary sources

PMS documentation

• Oracle Hospitality OPERA Cloud — Charges, Adjustments and Payments: https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.5/ocsuh/c_postings_adjustments_postings_adjustments_and_payments_ch.htm
• Oracle Hospitality OPERA Cloud — Credit Card Authorization Rules: https://docs.oracle.com/en/industries/hospitality/opera-cloud/23.2/ocsuh/c_admin_financial_cashiering_about_credit_card_authorization_rules.htm
• Oracle Hospitality OPERA Cloud — Managing Reservation Deposit Payments: https://docs.oracle.com/en/industries/hospitality/opera-cloud/23.5/ocsuh/t_managing_reservations_deposit_payments.htm
• Oracle Hospitality OPERA Cloud — About End of Day: https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.4/ocsuh/c_endofday_procedures.htm
• Oracle Hospitality OPERA Cloud — Closing Cashiers: https://docs.oracle.com/en/industries/hospitality/opera-cloud/24.4/ocsuh/t_cashiers_closure.htm
• Oracle Hospitality — OPI OPERA Cloud User Guide: https://docs.oracle.com/cd/F36206_01/doc.193/f36006.pdf
• RMS Cloud — Pre-Authorisation / Release / Reverse Receipt vs Refund: https://support.rmscloud.com/hc/en-gb/articles/12546520641679-Pre-Authorisation
• Infor HMS — Payment card authorizations: https://docs.infor.com/hms/3.8/en-us/hmsolh/s_t1424428571939.html
• SIHOT — Deposit payment (online help): https://help.sihot.com/Nethelp/V9.0.0.1046/EN/Documents/depositpayment.htm
• Clock PMS+ — Payments, Posting and Voiding: https://support.clock-software.com/en/support/solutions/articles/9000178343-payments-posting-and-voiding
• Shiji — Payby: https://www.shijigroup.com/digital-payby

Card schemes and PCI SSC

• Visa — Authorization and Reversal Processing Best Practices for Merchants (©2024): https://usa.visa.com/content/dam/VCOM/regional/na/us/support-legal/documents/authorization-and-reversal-processing-best-practices-for-merchants.pdf
• Mastercard — Transaction Processing Rules (10 June 2025): https://www.mastercard.us/content/dam/public/mastercardcom/na/global-site/documents/transaction-processing-rules.pdf
• American Express — Merchant Reference Guide, U.S. (October 2021 edition): https://www.americanexpress.com/content/dam/amex/us/merchant/merchant-channel/US-Reference-Guide.pdf
• PCI SSC — Tokenization Guidelines Information Supplement: https://listings.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
• PCI SSC — Protecting Telephone-Based Payment Card Data: https://listings.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf
• PCI SSC — Data Storage Do's and Don'ts: https://listings.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf
• PCI SSC — FAQ 1588 (fully outsourced payment flows and SAQ A eligibility): https://www.pcisecuritystandards.org/faqs/1588/