United Kingdom flagIndependent UK business banking research
UK Business Banking Research · BanksGB
Business typesCards & expensesCash flowSecurityDigital bankingMerchant servicesFX & tradeInsightsAll topics
BanksGB · Payments

MOTO card payments: control telephone and mail-order card risk

A practical UK merchant guide to mail-order and telephone-order card payments covering PCI DSS, staff handling, card-not-present fraud, recording, SCA and reconciliation.

Mail-order and telephone-order card payments allow staff to key card details into a virtual terminal when the customer is not present. The method can be useful for professional services, hospitality and bookings, but it creates card-not-present risk because the merchant employee hears or handles sensitive payment information directly.

Use MOTO only where remote staff-entered card payments are genuinely needed

MOTO stands for mail order and telephone order. A merchant receives card details remotely and enters them into an approved virtual terminal or payment system. It is different from a payment link, where the customer enters the card details directly into a hosted checkout.

If customers can safely pay through a link or online checkout, that can reduce staff exposure to card data. Keep MOTO for situations where the customer cannot use self-service or where the commercial process genuinely requires telephone payment.

MOTO remains inside PCI DSS scope

PCI DSS applies to merchants handling cardholder data, including card-not-present environments. If staff write card numbers on paper, type them into local software or store recordings containing card details, those systems and procedures can increase compliance scope.

Use a virtual terminal supplied by the acquirer or approved provider and design the process so card details are entered directly and not stored elsewhere. Confirm the appropriate SAQ or validation route with the acquirer because MOTO scope differs from a fully outsourced ecommerce payment link.

Do not keep card details in ordinary call recordings

If business calls are recorded, build a process that prevents sensitive authentication data from being captured. Staff can pause recording during payment, use secure keypad entry or transfer the customer to an approved payment system, depending on the provider.

Do not ask employees to write the card security code on a sticky note for later entry. Sensitive authentication data has strict storage restrictions. Payment should happen during the controlled interaction and any temporary notes should follow the merchant's PCI process.

Card-not-present transactions need stronger identity and order controls

A MOTO payment does not provide the same physical-card signals as chip-and-PIN. Check the customer's order history, billing information, delivery risk and unusual urgency. High-value first-time telephone orders deserve additional verification.

Do not invent authentication questions that expose more personal data. Use the acquirer's fraud tools and merchant procedures. If the transaction looks inconsistent, offer a secure payment link or bank transfer rather than forcing approval through the virtual terminal.

MOTO transactions are treated differently from ordinary ecommerce SCA flows

Because MOTO is initiated through a staff-assisted mail or telephone channel, it is not the same transaction flow as a customer entering card details into an ecommerce checkout and completing 3-D Secure. Merchants should classify transactions correctly with their acquirer.

Misclassifying ecommerce payments as MOTO to avoid authentication can create compliance and fraud problems. The transaction indicator should reflect how the payment was actually initiated, not whichever route appears to produce fewer declines.

Link each virtual-terminal payment to the customer invoice or booking

Use an invoice, booking or customer reference when staff key the transaction. Reconcile MOTO payments separately from ecommerce and in-person card sales so management can see fraud, refund and chargeback performance by channel.

Review which employees have virtual-terminal access and remove leavers promptly. A remote card-entry tool is a financial permission. Named user accounts and transaction logs make it easier to investigate disputed or unusual payments.

Design a call script that tells the customer when payment is about to be taken and prevents employees from repeating card details aloud unnecessarily. Staff should never read the full PAN back to the caller as a confirmation method. Confirm amount, merchant name and non-sensitive order details instead.

Separate MOTO users from ordinary customer-service users. Give virtual-terminal access only to employees who need it, use transaction limits where available and review daily totals. A compromised staff login can create fraudulent card charges or refunds even if the merchant never stores card numbers locally.

Measure MOTO chargeback rate against payment links. If customers who pay by link have materially lower fraud and fewer disputes, move repeat customers to that channel. The best MOTO control can be reducing how often employees need to key card data in the first place.

Keep MOTO fraud losses separate from ecommerce fraud in management reporting. The absence of 3-D Secure and the human handling of card data can produce a different risk profile. If MOTO has a materially higher chargeback rate, tighter order limits or more payment-link migration may be justified.

For repeat customers, do not ask staff to keep card details in notes or CRM free-text fields. Use a provider-supported token or customer profile where allowed. The objective is to avoid collecting the full card number again while keeping sensitive data out of ordinary business systems.

Editorial Verdict

MOTO remains useful, but it puts staff closer to sensitive card data and card-not-present fraud. Use an approved virtual terminal, minimise what employees see or record and keep the process inside the correct PCI DSS scope.

Where possible, move customers to hosted payment links or another self-service method. Keep MOTO as a controlled exception rather than making telephone card details the default way the business gets paid.

Sources

Banking decisions work better when the business model comes first

Use the provider directory, comparisons and practical guides to narrow the questions before choosing products.

Start comparison