Knowledge Base

MOTO payments in travel.

A practical guide to MOTO (mail order, telephone order) payments in travel — when to use them, how to take them securely, the liability and fraud picture without 3DS, the cost economics, and when to migrate volume to embedded checkout, payment links or open banking.

Book a walkthrough See payment collection

Phonebookings still need a rail

Liabilitystays with the merchant

Reservesoften tighter than card

Why MOTO still matters in travel.

Travel runs on relationships, and many of those relationships still happen on the phone. A repeat customer calling to amend a balance, an agent taking a deposit while finalising an itinerary, a supplier paying a late invoice - these conversations end with a card number being read aloud, which is what MOTO (mail order, telephone order) actually is. The rail is older than the web, but it has not gone away.

Phone bookings have not disappeared

For older demographics, high-value bookings and complex itineraries, the phone is still where the conversation happens - and the card payment follows.

Amendments and balances run on calls

Even where the original booking was online, customers ringing to change dates or pay a balance often expect to give card details on the call rather than wait for a link.

Agent and supplier flows still use it

Agent-to-supplier deposit payments, ad-hoc supplier invoices and back-office one-offs are often easiest to handle as MOTO, especially where the supplier does not yet take open-banking.

How to take MOTO payments securely.

MOTO is the lowest-evidence payment rail you run. There is no 3DS challenge, no SCA step-up, no biometric prompt - just a card number, an expiry, a CVC and a verbal yes. That puts the security and evidence burden squarely on the merchant.

Use a virtual terminal, not a card reader

A virtual terminal designed for MOTO carries the transaction in the right MCC and CNP framing, gives the issuer the right metadata, and lives behind your acquirer relationship rather than a card-reader contract. A face-to-face card reader being used for phone payments is a fraud and compliance red flag.

Channel MOTO virtual terminal

MCC Travel-specific

Evidence Booking-linked

See virtual terminal in the glossary

Capture verbal authorisation evidence

For high-value travel transactions, capturing verbal authorisation against the booking - whether through call recording, an authorisation log or a confirmation email back to the customer - is what defends a future dispute. Without it, the issuer's reason code wins by default.

Call recording PCI-compliant

Consent log Per booking

Email confirmation Retained

See dispute resolution

Take CVC, but never store it

Capturing CVC strengthens the authorisation outcome and is part of a compliant MOTO flow. Storing CVC after authorisation is a PCI DSS violation that can void your card-acceptance relationship - so the discipline is to capture, transmit, authorise, forget.

Capture Verbal

Transmit Encrypted

Store Never

See CVC in the glossary

Section 02

Liability and fraud — what changes without 3DS.

A MOTO transaction does not carry the liability shift that a 3DS-authenticated CNP transaction does. When a chargeback lands, the issuer assumes the merchant cannot prove the cardholder authorised the payment, and the merchant has to defend that position from evidence.

No liability shift

Without 3DS, chargeback liability stays with the merchant. Issuer-side fraud disputes will land against the booking unless you can demonstrate authorisation through other evidence.

Higher fraud-prevention burden

Fraud risk is higher for MOTO because the rail bypasses cardholder authentication. AVS checks, BIN screening and call-recording discipline are the substitutes you actually have available.

Reason codes work differently

Issuers code MOTO disputes under reason codes that assume merchant responsibility - 4837 "no cardholder authorisation" being the most common. Representment requires the evidence to be already attached to the booking.

How the MOTO cost picture compares.

The real cost of MOTO is rarely the headline transaction rate - it is the chargeback exposure, the reserve and holdback picture, and the operational overhead of running a verbal-authorisation workflow at scale. Looking only at the per-transaction rate misses where the money actually goes.

Chargeback exposure is the headline cost

The single biggest cost of MOTO is not the per-transaction rate - it is the chargeback exposure. Fraud-family disputes that would shift to the issuer under 3DS stay with the merchant under MOTO. For a high-value travel transaction, that exposure can run into thousands per dispute, plus fees, plus operational time on representment.

Liability Merchant

Reason codes Fraud family

Per-dispute cost Transaction + fees + time

See chargebacks in travel

Reserve and holdback exposure

An acquirer reviewing a travel merchant with significant MOTO volume is often more cautious on rolling reserves and settlement holdbacks. That is operational cash that moves slower because of the rail mix you run - sometimes meaningfully so on a book of any size.

Rolling reserve Often tighter

Settlement Sometimes slower

Underwriting More cautious

See rolling reserve in the glossary

Clean evidence keeps the relationship clean

At the next acquirer review, the merchant with clean MOTO evidence - low chargeback ratio, booking-level authorisation trail, PCI-compliant call recording - holds a much better position than the one without. The lever is operational discipline, not negotiation tactics.

Chargeback ratio Below 0.5%

Authorisation evidence Booking-linked

Review position Defensible

Review cycle Quarterly

See payment optimisation

Section 04

Compliance and consent — what MOTO needs.

MOTO sits inside the same PCI DSS regime as the rest of your card flows, and Package Travel Regulations apply to the booking the payment supports. Getting these right is mostly discipline rather than infrastructure.

PCI DSS scope

A MOTO virtual terminal expands your PCI scope. Use a tokenisation-backed terminal where possible to keep cardholder data out of your systems.

Consent and confirmation

For travel bookings, send a same-day email confirmation that restates the booking, the amount and the cancellation terms. That email is part of the contract evidence behind the MOTO payment.

Call recording rules

Call recording for MOTO must be PCI-compliant — CVC capture muted or pause-and-resume, retention windows defined, access controlled. Treat the recording stack like the payment stack, not the contact-centre stack.

Section 05

When to move MOTO volume onto modern rails.

MOTO has a place, but most travel businesses carry more MOTO than they need to. The lever is to make it easy for the customer to choose a more secure rail at the moment of decision.

Switch to a payment link mid-call

For a high-value balance taken over the phone, sending a payment link by SMS or email during the call gives the customer a 3DS-protected transaction with full liability shift, while keeping the agent in control of the booking.

See payment links

Embed for online amendments

Where the conversation started online (chat, form, email) and the customer is ready to confirm, embedded checkout brings the payment back into the booking flow with full 3DS protection.

See embedded checkout

Offer open banking for balances

Open-banking initiation gives the customer a bank-app authenticated payment with no card-rate surcharge - particularly compelling for repeat customers paying a balance.

See PISP in the glossary

What MOTO looks like in felloh.

felloh is built for travel businesses that run a mixed-rail payment book - including MOTO when the conversation genuinely needs it. The platform keeps every payment, whatever the rail, attached to the booking, traveller and supplier behind it.

See this guide running on your booking data.

Bring the workflow or rail you want to improve and we will show how felloh keeps the booking-level evidence connected end to end.