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.
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
Process MOTO via a properly-segregated virtual terminal, not a chip-and-PIN device.
Capture verbal authorisation evidence
Record the call, log the consent, attach it to the booking.
Take CVC, but never store it
Ask for CVC at point of authorisation; never write it down or store it.
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
Without a 3DS liability shift, every fraud-family dispute lands against the merchant.
Reserve and holdback exposure
High MOTO volume can drive rolling-reserve and holdback decisions.
Clean evidence keeps the relationship clean
Booking-level evidence and call-recording discipline keep MOTO volume defensible.
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.
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.
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.
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.
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.
Booking-level MOTO evidence
Every MOTO transaction is tied to the booking, traveller and call evidence behind it, so disputes can be answered from the record rather than rebuilt under pressure.
One picture across rails
MOTO sits alongside card, open banking, embedded checkout and payment links in one booking-level ledger. Finance reads one source of truth, not five.
Easy migration off MOTO when ready
Where you want to reduce MOTO volume, felloh's payment links, embedded checkout and open-banking flows give the agent a one-click alternative without restarting the booking conversation.
See how this works around your bookings.
Bring one payment, reporting or cash-position problem. We will show how felloh connects the booking-level money trail behind it.
Book a walkthrough