Hotel payment technology terms: virtual POS, 3D Secure, tokens and chargebacks

A virtual POS is the card-acceptance service a bank or payment provider gives a hotel so it can take payments through a web page instead of a terminal. Around it sit payment links, 3D Secure, authorization and capture, tokens, settlement, refunds, chargebacks and channel virtual cards: each names one step between a guest's card and the hotel's bank account.

A guest pays a deposit by link on Monday, the balance at the desk on Friday, and disputes the whole stay three weeks later. The hotel now holds three different records of one payment and has no single word for any of them. This article on hotel payment terms defines the words route by route, so that after reading you can name each step, write a rule for it, and match every payment to a reservation reference.

Which ways can a hotel take a card payment?#

Five routes cover almost every hotel payment: the terminal at the desk, a payment link, a virtual POS on the hotel's own website, a card taken over the phone, and a virtual card issued by a booking channel. The route is chosen by who is present and who holds the card, not by habit.

The physical POS terminal is the simplest case. The card is present, the guest enters a PIN or signs, and a receipt prints at the desk. The staff member and the card are in the same room, which is what makes this route the easiest to defend later if the payment is questioned.

A payment link is a one-time web page tied to an amount and a reference such as the reservation number. The guest pays on their own phone, so nothing is read aloud and no number is written down. A virtual POS is the card-acceptance service the hotel's bank or payment provider runs for it, used by the hotel website, the booking engine and the guest app; there is no device and no card present.

Mail order (in Turkish, kartsız ödeme, a payment taken without the card) means card details given by phone or message. It carries the highest dispute risk, so many hotels limit it to deposits, no-show charges and repeat guests. Finally, a channel virtual card is issued by a booking channel for a single reservation, and the hotel charges it like any other card, within limits the channel sets.

A hotel usually needs three of these routes at once, and each one produces a different piece of paper or screen. That is the real reason payment words feel confusing: one guest, several routes. A wider set of hotel technology terms, from PMS to channel manager, is defined in our hotel technology glossary.

What is a virtual POS, and how is it different from the terminal at the desk?#

A virtual POS is the account and service that lets a hotel accept cards through a web page rather than a device. The money still settles to the hotel's bank account, but no card is present at the moment of payment.

What the hotel actually receives is a contract with a bank or payment provider, credentials for the payment page, and usually an integration for the website or booking engine. The terminal is hardware; the virtual POS is a service. Typical uses are prepayment or deposit on the hotel's own website, payment of the balance before arrival, in-app purchases in the guest app, and any payment link the reservations team sends.

The systems around it matter as much as the service. The reservation reference and the amount must travel with the payment; without a reference, matching money to a booking becomes manual work at month end. The trade-off is that card-not-present payments carry more dispute exposure than a card tapped at the desk, and 3D Secure, which reduces one kind of dispute, adds a step the guest can abandon.

Commercial terms, including rates, payout timing and accepted currencies, are agreed with the provider and are not standard across the market. Confirm them in writing before signing, and quote them to nobody as if they were universal. The common mistake is treating the virtual POS as a separate cash box that nobody reconciles to the folio, so the hotel's records and the bank's records drift apart.

What does 3D Secure check, and what does it not check?#

3D Secure is the extra step where the cardholder confirms the payment with their own bank, usually with a code sent to their phone. It confirms who approved the payment; it does not confirm that the guest will keep the booking or accept the charge later.

The mechanism is simple. The payment page hands the guest to their bank for a challenge, the bank authenticates the cardholder, and the result returns to the hotel's payment page as passed, failed or unavailable. What it protects against is the dispute that says "I never made this payment". It does not protect against "I cancelled in time" or "the room was not what was shown", which are argued on the hotel's own records.

"Unavailable" is a real outcome, not an error to ignore. The hotel needs a written fallback rule decided in advance: hold the reservation for a set period, ask for another card, or release the room. Our article on hotel no-show handling covers how that decision fits the wider cancellation procedure.

Authorization and capture are two separate events, and hotel payment terms often blur them. An authorization reserves an amount on the card; a capture actually takes it. A hotel can authorize at booking and capture at arrival or departure, and whether a no-show charge works depends on whether the authorization is still valid at the moment of charging. That is why the no-show procedure and the payment route have to be written together. Blocking an amount at the desk for extras is a front desk procedure with its own steps and its own wording for the guest; keep it in the front desk instructions.

One last distinction: a green tick on the screen means the payment step succeeded. It does not mean the money is in the hotel's account; that is settlement, and it happens later.

After the payment: what are settlement, refund and chargeback?#

Settlement is the money arriving in the hotel's bank account. A refund is the hotel sending money back through the same route. A chargeback is the guest's bank reversing a payment and asking the hotel to prove the charge was correct.

Card payments are batched and paid out on the provider's schedule, net of fees. The folio date and the bank date rarely match, so reconciliation has to work from the payment reference, not from the date. A refund goes back to the same card: a hotel cannot refund to a different card, and it should not delete the original charge. The correct move is a void or a reversing entry so the trail stays readable, as explained in how to void a folio charge without breaking the audit trail.

Partial refunds and cancelled deposits need the amount and the reason recorded on the folio at the time, because that record becomes the chargeback file months later. When a chargeback opens, the guest's bank asks the hotel's bank for evidence, and the hotel answers with what it kept: the signed registration record, the cancellation terms the guest accepted, the correspondence, and the payment record with its reference.

Prevention is cheaper than defence. Cancellation terms shown at the point of payment, a confirmation sent to the guest, a named contact for questions, and a note of what was actually delivered will prevent more disputes than any argument afterwards. The decision itself follows the card schemes' rules, not the hotel's sense of fairness, and the payment provider explains which process and which deadlines apply to the hotel's contract.

What is a token, and why should staff never write down a card number?#

A token is a stand-in number a payment provider issues for a card, so the hotel can charge or refund that card again without holding the card number itself. The provider keeps the card; the hotel keeps the token.

A repeat charge sends the token, not the number. If a token is stolen, it is useful only inside the rules the provider attached to it, which is why tokens are safer than a card number in a reservation note. A related term is the stored card, or card on file: the guest agrees that the hotel may charge the card later for extras or a no-show. Record what was agreed, when, and up to what amount, because that agreement is the whole defence.

Card numbers leak in real hotels through predictable places: emails, messaging apps, reservation notes, paper registration cards, a notebook at the night desk, and photographs of terminal screens. The rule is absolute: if a card number reaches the hotel, it goes straight into the payment page and is written down nowhere. The same applies to the security code on the back of the card.

The card industry sets data-security rules for handling card data. Which of them apply to a particular hotel is confirmed by that hotel's payment provider in writing, not by a blog article and not by a colleague's memory. Expiry also matters twice: a token tied to an expired card fails, and a card on file that expires before arrival leaves the reservation without a payment method at the worst moment.

How do bookings from channels pay the hotel: virtual cards and payouts?#

A booking channel usually pays either with a virtual card issued for that one reservation or by a periodic payout covering many reservations. The hotel charges the virtual card, or matches the payout to a batch of bookings.

A virtual card is a single-use card number with an amount limit and a validity window. A charge above the limit, or after the window closes, fails for reasons that have nothing to do with the guest. Activation timing matters too: many virtual cards only become chargeable close to the arrival date, so charging early fails, and the failure is easy to misread as a bad card.

In the payout model, the channel collects from the guest and pays the hotel later, net of its commission. The hotel then invoices the channel, which is city ledger work with its own rules, covered in hotel city ledger explained. Reconciliation should match by the channel's reservation reference, not by amount alone, because a payout covering ten reservations rarely arrives as ten separate bank lines.

A declined virtual card is a payment problem, not a no-show. It has to be flagged and resolved before arrival, not discovered at the desk with the guest standing there. The channel's extranet and the hotel's payment provider define the rules, but the hotel's own records must still show what was charged, when, and against which reservation.

What to do next#

Write a one-page payment map for your own hotel. For each route, record who is allowed to take the payment, which reference is recorded on the folio, where the money lands, and who reconciles it each week. The glossary only gives the words; the map is what stops one guest's payment from becoming three unrelated records.