Great stays.
Clearer
payments.

A better stay starts before the room key.

Hotel payments have more moving parts than a checkout terminal.

A guest books on your website, changes the arrival date, presents a different card at check-in, charges dinner to the room, and splits the final bill with a colleague. Your front desk needs one clear payment story through all of it.

Credit card processing for hotels connects reservations, payment authorization, the guest folio, settlement, and the deposit that reaches your bank. The right setup helps staff understand what has been paid, what is only on hold, and what still needs attention.

Start with three questions: does the processor work with your exact property management system, can it handle your lodging payment workflows, and what does the complete arrangement cost? A low advertised rate is useful only when the system supports the way your hotel actually operates.

This guide is for hotel owners, general managers, and finance teams comparing a new setup or reviewing an existing one. For the wider sector, see our travel payment processing guide. Operators managing individual homes can use the separate vacation rental payment processing guide.

01 / Know the complete cost

Hotel credit card processing fees depend on how you collect payment.

Separate your payment channels before comparing quotes: cards presented at reception, website deposits, manually entered payments, and online travel agency virtual cards. One blended percentage can hide a very different mix underneath.

As a public reference checked October 9, 2026, Stripe lists U.S. standard domestic online card pricing at 2.9% + 30¢ and Terminal domestic in-person pricing at 2.7% + 5¢. Its online schedule adds 0.5% for manually entered cards; international cards and currency conversion have separate adjustments. These are Stripe examples, not hotel-industry averages or NUMUS offers.¹

This comparison excludes hardware, hotel software, integration charges, optional services, and other applicable fees. It illustrates the cost of different payment routes, not a recommendation to change how a transaction is classified. Collect each payment through its genuine, supported channel.

Ask for the full fee stack.

• Payment charges: percentage, per-transaction fee, authorization charges, card-type differences, and international or currency adjustments.
• Hotel technology: PMS payment module, gateway, booking-engine connection, terminals, licenses, installation, and support.
• Exceptions: refunds, disputes, failed or unused authorizations, and any applicable account or compliance charges.
• Contract and funding: minimums, term, cancellation costs, transfer options, and any reserve or withholding conditions.

With interchange-plus pricing, the processor's markup is only one layer. Ask for an estimate based on your actual card mix and a sample statement showing underlying costs separately. Our credit card processing fees guide explains the pricing structures in more detail.

Measure the cost against the same denominator.

For a monthly comparison, divide the processing fees you have included by the corresponding gross card volume. If you also include PMS and equipment costs, label the result as an all-in payment operating cost. Keep room revenue, card charges including taxes, and net bank deposits distinct.

A deposit and a later balance payment are two payment events. Count both when estimating transaction fees. Refunds need their own line: Stripe, for example, says its original processing fees are not returned when a payment is refunded.⁸ Confirm your proposed provider's treatment in writing.

Use the comparison tool below to explore your mix, then check the result against a written quote. The broader processing fee calculator is useful when reviewing an entire merchant statement.

02 / Keep holds and payments clear

A reservation, a hold, and a completed payment are different events.

Train staff to identify the payment's actual status before explaining a guest's balance. Stripe's separate-authorization documentation describes reserving funds first and capturing later; an uncaptured authorization can expire without becoming a completed payment.²

These distinctions follow the provider and network workflows—not just the label on a PMS button.²³⁸

Separate an advance deposit from a check-in authorization.

If you actually charge a deposit at booking, show it as a payment and apply it correctly to the folio. If you only verify or authorize a card, do not describe the room as paid. Write your booking confirmation so guests can distinguish the amount charged now, the balance due later, and the applicable cancellation terms.

Get the incidental workflow approved for your setup.

Do not assume a blanket damage buffer belongs in every authorization. Visa's current estimated-authorization guide requires a genuine estimate, disclosure of the amount and possible subsequent authorizations, and excludes arbitrary incidental buffers such as tips or damage. Work with your acquirer on the permitted approach for your lodging transactions.³

If the stay changes, use the provider's supported adjustment process. Visa explains that an incremental authorization increases the approved amount but does not restart the authorization's validity period. Unused amounts require the appropriate reversal.³

Use the actual deadline, not a memorized number.

Stripe Terminal supports extended authorizations of up to 30 days for eligible transactions, depending on card brand and business category. Its documentation instructs integrations to use the returned capture-before time because rules and eligibility vary.⁴ Ask your provider how expiring authorizations appear to staff and what happens when a guest extends a stay.

03 / Make the systems work together

PMS compatibility is a workflow, not a logo on a sales slide.

The property management system holds reservations and folios. The booking engine handles direct online reservations. Restaurant or spa POS systems handle other sales. The gateway and processor move payment instructions. Your evaluation should show how information travels between the components you actually use.

Oracle's OPERA documentation, for example, describes using Oracle Payment Interface with payment service providers to obtain tokens and process authorizations and payments. Oracle's OPI Cloud documentation also describes a hosted token-exchange form and Pay By Link capability.⁵⁶ Those documented features do not establish compatibility with every processor, property configuration, or NUMUS offering.

Request a demonstration using your exact configuration.

• Identify the PMS product, version, region, booking engine, gateway, and supported terminal models.
• Show a deposit posting to the correct reservation without a second manual entry.
• Demonstrate a check-in authorization, a stay extension, final capture, and unused-amount release.
• Split a folio between two payers, then refund one original payment.
• Trace a restaurant room charge into the hotel folio without charging the guest twice.
• Show which support team owns a failed payment sync and how staff recognize it.

For a migration, ask what happens to existing reservations, saved payment tokens, refunds, and open authorizations. Do not assume a token in one provider's vault will work with another. Require a documented transition plan and secure handling by the relevant vendors.

Keep a rollback and outage plan at reception. A staff member should know which approved fallback to use, how to check whether an interrupted transaction succeeded, and who resolves a mismatch after connectivity returns.

04 / Follow who collected the money

Direct bookings and OTA payments need separate instructions.

“Booked online” does not tell the front desk who should be charged. A direct website booking, an OTA booking paid at the property, and an OTA booking paid through a virtual card can arrive in the same reservations screen with different payment responsibilities.

Make the payer, collection status, and outstanding amount visible. If the room has already been paid through an intermediary, staff need clear instructions for any separately payable items rather than charging the whole stay to the arriving guest again.

Treat an OTA virtual card as a booking-specific payment instruction.

Booking.com's current payment documentation exposes a VCC's activation date, current balance, currency, expiration date, and status. It distinguishes a card that exists but is not activated from one that is activated and funded. It also distinguishes charges already collected from the guest from those the property must collect.⁷

Use the current reservation instructions to confirm when the card can be charged and for what amount. Investigate an unsuccessful attempt before retrying. Check whether the issue is timing, balance, currency, changed reservation details, or the supported payment route.

Maintain a daily list of eligible but uncollected OTA payments, assigned to a named role. Reconcile each collection against the reservation, not just the total payout. Keep OTA commissions and payment charges separate from your processor fees so you can compare distribution costs honestly.

For group and corporate reservations, record the authorized payer and which charges that payer covers. Route any uncovered guest purchases through their own properly disclosed payment arrangement.

05 / Protect the guest and the operation

Keep card data out of the places your team improvises.

An emailed card form, a photographed card, or a card number pasted into reservation notes creates a problem that a better terminal cannot fix. Use the payment provider's supported secure collection and tokenization tools. Staff should not need to retrieve raw card details to answer an ordinary payment-status question.

PCI SSC explicitly prohibits retaining card verification codes after authorization, including for future card-on-file transactions. Encryption or a guest's permission does not make that storage acceptable.⁹ Confirm your applicable PCI validation tasks and responsibilities with your acquirer and providers.

Design access around hotel roles.

Give reception, night audit, finance, and management the access each role needs. Require a defined approval path for refunds and bank-detail changes. Remove access promptly when staff leave and keep a record of who performed payment adjustments. During training, use the provider's approved test environment, not a guest's live card.

Build the evidence while the stay is happening.

Retain the reservation confirmation, terms shown at booking, relevant guest communications, itemized folio, and payment or refund references in approved systems. For a cancellation or no-show, preserve the applicable policy and event timeline. Record a later adjustment clearly enough that another employee can understand it.

Stripe's dispute guidance recommends matching evidence to the specific dispute reason and presenting a clear chronology. Evidence must also reach the provider within the applicable response window.¹¹ A signed document is useful context, not a guarantee that every disputed charge will be upheld.

Use a recognizable statement descriptor and send a clear receipt. Give guests a straightforward route to resolve billing questions. A guest who understands the final folio should not need to call their card issuer to identify the hotel charge.

06 / Close the loop

Match the reservation, payment, and bank deposit.

Night audit answers what happened in the hotel. Processor reporting answers what happened to payments. The bank shows the money that arrived. Reconcile all three without assuming they share the same dates or totals.

1. Start with folios: identify captured card payments, deposits applied, refunds, and unresolved balances.
2. Match processor activity: connect payment references to the right property and reservation; separate holds from settled charges.
3. Explain the payout: reconcile included payments, refunds, fees, disputes, and other adjustments.
4. Match the bank: record the actual deposit and assign every remaining difference for follow-up.

Stripe's payout reconciliation report is one example of transaction-to-payout reporting for automatic payouts. Its documentation directs manual-payout users to different reporting and notes that reporting availability can lag the payout itself.¹⁰ Ask prospective providers to demonstrate their equivalent reports.

Keep a short exception log: uncaptured authorizations approaching expiry, unsuccessful refunds, uncollected virtual cards, duplicated postings, and unexplained settlement differences. Give each exception an owner and next action; a long spreadsheet nobody works is not a control.

Before relying on accelerated funding, confirm cutoffs, time zones, eligibility, charges, and weekend treatment. Our same-day funding guide explains the questions to ask. A paid folio and cash available in your bank are separate milestones.

07 / Compare like an operator

Bring one realistic stay to every provider demonstration.

Build a sample reservation with a website deposit, an extra night, a restaurant charge, split payment, and a partial refund. Have each provider show the complete sequence. You will learn more from the awkward steps than from the first successful card tap.

Prepare recent statements, payment volume by channel, average payment size, refund activity, property count, and the software inventory. Explain seasonal peaks and how far ahead guests pay. These details make a review more useful than asking for a rate with no operating context.

Before signing, identify who bills each part of the arrangement, who supports it after hours, which obligations survive cancellation, and what access you retain to historic reports. Review any equipment lease separately from the processing agreement.

Choose the provider that can document the required workflow at an understandable total cost. Treat unanswered compatibility or funding questions as items to resolve before migration, even when the advertised price is attractive.

Make the next conversation useful.

Start with your hotel's real payment setup.

Bring your PMS name, property count, estimated monthly card volume, and the part of the process that needs improvement. It might be expensive keyed payments, unclear holds, a difficult reconciliation, or a disconnected booking engine.

NUMUS can begin with a conversation about those processing needs. Specific pricing, supported integrations, equipment, funding arrangements, and account terms require confirmation for the proposed solution. Do not replace your existing system until the details and transition plan are clear.

Use the review checklist to collect your questions before you speak with a provider. Leave guest card data out of an ordinary inquiry; it is not needed to describe your operation.

Questions hotel operators ask

Hotel payment processing FAQs.