☎️ Taking payments by phone

What counts as a mail order or telephone order sale

A mail order or telephone order transaction is a remote sale in which the card data reaches the merchant by mail or over the phone line, with no browser involved. The card networks group both under a single label, Mail Order / Telephone Order, or MOTO. In a mail order, the customer writes the card number on a paper order form and mails it. In a phone order, the customer reads it out to an agent or keys it in on the phone keypad. In both cases the cardholder is absent and the card never touches a terminal, which makes both of them card-not-present transactions. The same legal regime applies to both.

A transaction is classified as MOTO in the authorization message, regardless of how the merchant describes its business. The acquirer fills in the entry mode, which indicates manual key entry, and the cardholder presence indicator, which distinguishes a mail order from a phone order. The entry mode travels in data element 22 of the ISO 8583 message. Cardholder presence sits in a network-specific field: data element 61 at Mastercard, and a dedicated indicator in the Visa specification. The merchant fills in none of these fields. Its acquirer derives them from the channel enabled under the merchant agreement, so the value sent with each authorization depends on how that agreement is set up. Enabling a phone channel requires notifying the acquirer in advance.

Interchange is the fee the acquirer pays the issuer on every card transaction. The rate depends on how the transaction is classified. A key-entered transaction falls under the card-not-present schedule, the most expensive tier in most regions of the world. Regulation (EU) 2015/751 neutralizes that gap within the European Economic Area. There, interchange is capped at 0.2% for consumer debit cards and 0.3% for consumer credit cards, whatever the sales channel. Outside the EEA, the full gap between card-present and card-not-present remains, and a phone sale carries the highest rate.

Strong customer authentication is a check that combines at least two independent factors drawn from knowledge, possession, and inherence (something the payer is). Article 97 of Directive (EU) 2015/2366 requires the payer's provider to apply it in three situations. Two matter here: when the payer initiates an electronic payment transaction, and when the payer carries out any action through a remote channel that may carry a risk of fraud. A card number read out to an agent meets neither condition, because the payer initiates nothing electronically and never goes through any interface of the provider. The European Banking Authority confirmed this reading in its June 2018 opinion on implementing the regulatory technical standards. Its Single Rulebook Q&A repeats it. Phone sales therefore fall outside the scope of Article 97.

• Accessing the payment account online, whatever device is used to access it.
• Initiating an electronic payment transaction, by the payer themselves.
• Carrying out any action through a remote channel that may carry a risk of fraud or other abuse.

An exemption and an out-of-scope transaction both result in a payment processed without strong authentication, but through two mechanisms that must not be confused. An exemption applies only to a transaction that falls within the scope of Article 97. The merchant requests it in the authorization flow, and the issuer can refuse it with a soft decline that calls for authentication. An out-of-scope transaction requires no request: the law imposes nothing on the issuer, so the issuer has nothing to grant. When a phone transaction is declined, the cause lies elsewhere: the issuer's risk assessment, an applicable limit, or the profile of the merchant agreement.

MOTO volume cannot be measured from public sources. The networks do not publish the share of MOTO transactions in their authorizations. Public central bank statistics lump all remote sales together, without separating phone orders from e-commerce. Any claim about the size of this channel would therefore be unverifiable. This guide describes how the mechanisms work without putting a figure on volume.

No liability shift, and an evidence package to build

The liability shift moves fraud losses from the merchant to the issuer when the cardholder has been authenticated. It relies on the proof of authentication that the 3-D Secure protocol generates and carries through to the authorization. A MOTO transaction does not go through 3-D Secure. It carries neither an authenticated e-commerce indicator nor a cryptogram, so the issuer keeps its full right to raise a fraud dispute. The reason code is 10.4 in Visa's classification and 4837 in Mastercard's.

Directive (EU) 2015/2366 contains a second loss-allocation rule, but it does not apply here. Article 74(2) requires the payee or its provider to compensate the payer's provider when it fails to accept strong authentication. That obligation assumes authentication was required in the first place. Because MOTO is out of scope, the article does not apply, and no EU rule allocates the loss. Allocation then falls to network rules alone, which put the loss on the merchant.

An evidence package is what a merchant submits to rebut a dispute when fraud has not been proven. Visa codified it with Compelling Evidence 3.0, in effect since April 18, 2023. Under the framework, a merchant can get a 10.4 dispute reclassified as a non-fraud dispute by producing two undisputed transactions made with the same payment credential 120 to 365 days before the disputed one. The IP address or the device fingerprint must match across all three transactions, and a second data element must match as well: IP address, device fingerprint, customer account ID, or shipping address. A phone order generates neither an IP address nor a device fingerprint, so it cannot qualify.

The phone channel generates other evidence, and the decision to keep it has to be made before the first dispute, not after. The items below are created during the call or in the days that follow, and none of them can be rebuilt once a dispute has arrived.

• The call recording, with the segment in which the card details are spoken or keyed in cut out, and linked to the order reference.
• The calling number when it is displayed, the agent ID, and timestamps for the start and end of the call.
• The order record in the application, with the line items, the amount quoted to the customer, and the verbal consent obtained.
• The written confirmation sent after the call, on paper or on a durable medium, and proof that it was delivered.
• The check results returned in the authorization: the security code and address verification, where the issuing market supports it.
• Signed proof of delivery, which ties the goods to an address and to a person who was there to receive them.

A sale concluded orally over the phone is a distance contract, just like an order placed on a website. Directive 2011/83/EU requires a trader who calls a consumer to state its identity and the commercial purpose of the call at the start of the conversation. It grants a 14-day right of withdrawal, which runs from receipt of the goods for a sales contract. Under Article 8(6), each member state may require the offer to be confirmed on a durable medium and the consumer to be bound only after signing it. In a member state that has taken up this option, a trader without the consumer's written agreement has no enforceable contract. Any commercial dispute is then decided against the trader, who has no commitment to rely on.

PCI compliance scope in a contact center

PCI DSS scope is defined by the path data takes through an organization. Any component that stores, processes, or transmits account data is in scope, along with every system connected to it or able to affect its security. In a contact center, card data is spoken before it is written down. It passes through the phone network, the agent's ear, keyboard, and screen, the CRM tool, the call recorder, and the recorder's storage. Each of those points stays in scope until it has been taken off the path. How departments and teams are organized has no bearing on that boundary.

The PCI Security Standards Council addressed this case in a 2011 information supplement, Protecting Telephone-Based Payment Card Data, which has since been revised. It covers call center architectures, VoIP, call recording, and masking technologies. An information supplement explains how to apply the standard; it neither adds nor removes any requirement. It is guidance only. A product's compliance is judged against the standard itself. A product billed as compliant with the supplement alone proves nothing about the requirements the merchant will have to meet.

Network segmentation isolates the systems that handle card data in a dedicated segment, keeping the rest of the IT environment out of scope. It does little for a contact center, because the audio stream passes through the session border controller, the media servers, the recorder, and sometimes the agent's workstation. Isolating those components in a dedicated segment means isolating the entire platform. Scope then stays about the same size. Scope shrinks when the data is taken off the voice path, not when the equipment carrying it is walled off.

Some businesses are legally required to record calls, which rules out pausing the recording during the payment sequence. Article 16(7) of Directive 2014/65/EU requires firms to record telephone conversations relating to investment services. The same paragraph sets a five-year retention period, extended to seven years at the competent authority's request, and Delegated Regulation (EU) 2017/565 sets out the details. A duty to record and a ban on storing the security code then apply to the same audio stream. The way to reconcile them is an architecture in which the digits never enter the recorded stream. Recording then continues without interruption.

Call recording raises a second issue, separate from card compliance: personal data protection. The data controller must have a legal basis, inform the caller at the start of the call, collect only what is necessary, and set a retention period. The CNIL considers that permanently and systematically recording every call is disproportionate when the purpose is training or quality control. Retention is set purpose by purpose, since proof of a sale and coaching do not call for the same period. A single period matched to the longer of the two keeps the recordings made for the other purpose far longer than that purpose justifies. That excess retention cannot be defended before the regulator or in court.

Five setups, and what each one leaves in scope

A setup here means a way of organizing phone payments, either by moving the point where card data stops or by verifying who is providing it. Five setups come up again and again in projects, with very different effects on compliance scope. Four of them take components out of scope. How far each one goes depends on where in the merchant's infrastructure the card digits are stopped. A solution that stops them at the network edge removes almost every component. One that stops them just before the recorder removes only the recorder, which explains the limited results of projects that start there. The fifth setup reduces no technical scope and addresses an entirely different risk.

Masking works by intercepting the signal each keypress produces, and it almost always fails at the same point: how that signal is transported. A digit keyed on a phone keypad can travel through a VoIP infrastructure in three distinct ways, and equipment that handles only one of them lets the full number through the other two.

• In band, as sound within the audio stream itself. Masking then has to alter the media in transit.
• As a telephony event, in the RTP payload defined by RFC 4733, which replaced RFC 2833 in 2006. Here the digit travels as a value, not as a sound.
• As signaling, in a SIP INFO request sent outside the media stream. A device that sits only on the media never sees it go by.

Acceptance testing of a masking solution must therefore cover every path, every piece of equipment, and every carrier separately. A carrier that switches transport mode after an update lets the digits flow again with no visible symptom, because the call carries on normally. The merchant remains responsible for this check, even when a provider runs the solution. A periodic packet capture on the relevant segment is the only check that does not rely on the vendor's word. It has to be repeated after every infrastructure change.

Masking also changes the agent's script, which projects tend to discover late. When a customer keys a wrong digit, nobody can catch it by ear, because nobody hears the tones. The solution must therefore return a usable entry status: how many digits have been entered, an option to clear them, and whether the number has failed its validity check. The agent guides the sequence from those indicators alone, which shifts the challenge from the hardware to the call script. Here, agent training matters as much as the equipment installed.

• What exactly does the attestation cover? It must name the service purchased, with its validity date and the assessor's name.
• Where are the tones intercepted? A device installed on the merchant's premises leaves all of the merchant's telephony in scope.
• Which transport modes are handled? In-band audio, RTP telephony events, and SIP signaling must all be covered, not just some of them.
• Who assembles the number and sends it to the gateway? Whoever performs that step owns the cardholder data environment.
• What happens on a technical fallback? Falling back to a degraded mode that sends the tones in the clear defeats the whole setup.
• How is the pause proven? Timestamped logging of every sequence makes the control verifiable after the fact, one sequence at a time.

What a payment link gains, and what it costs

A payment link is a single-use URL that the provider generates for a specific order and amount. The merchant sends it by text message or email. The customer pays on a page hosted by the provider. The customer's experience changes little: they open a page instead of reading out a card number. But the network classification of the transaction, its authentication regime, and who bears fraud losses all change.

A transaction paid on a hosted page becomes an online payment, initiated by the payer through an interface. In the European Economic Area, strong authentication is required again, 3-D Secure runs, and the liability shift to the issuer is available again. The merchant trades the fraud losses it bore alone on the phone channel for an authentication step. Compliance scope follows suit: a merchant that no longer touches any card data can aim for SAQ A. A phone channel kept running alongside still carries its own scope, and adding a link channel does nothing to shrink it.

The trade-off with payment links is that some customers abandon the payment, a real cost that nobody documents. No network or provider publishes figures comparing a link sent during a call with card entry completed on the same call. Each merchant has to measure its own rate on its own traffic, separating links sent during the call from those sent afterward. A customer who hangs up without paying leaves an unpaid order, whose fate depends on a follow-up and the collection cost that comes with it. Run the numbers by customer segment, because a single average masks very different behaviors.

Several design choices reduce abandonment without removing the extra step. The agent announces the link during the call, with the amount, the sender to expect, and the expiration time, so the customer recognizes the message when it arrives. The agent stays on the line until the payment is confirmed, which turns sending the link into assistance rather than shifting the burden onto the customer. Each link covers one amount and one order, never an open session that could be replayed. Expiration is set in minutes when the agent is waiting, and in hours when the customer has asked to pay later.

Some sales situations do not tolerate pushing payment past the end of the call, for two reasons that should be kept apart. In some, the customer's agreement falls apart once the conversation ends. In others, the customer lacks the practical means to open a payment page.

• Collections and overdue accounts. Payment is secured during the conversation; a link sent to a reluctant debtor rarely gets paid.
• Customers without a digital channel. No email address on file, a phone that cannot open a payment page, or an accessibility barrier that makes the flow unusable.
• Outbound telesales. The call is the sale; pausing the conversation to wait for payment gives the customer time to back out.
• B2B orders taken by an account manager. The buyer reads out a lodged card number, often from a workstation with no direct access to their personal email.
• Emergency call-outs and on-call services. The customer is calling from a place, and in a state, poorly suited to a web flow, and the work starts before any payment.
• Public service agencies and assistance lines. The phone line remains the only point of access for part of the public, who would be shut out entirely if the channel were dropped.

Running phone payments and payment links side by side calls for one last configuration rule, often overlooked at go-live. A payment made through a link is an e-commerce transaction. The authorization must flag it as one. Leaving it under the telephone order indicator forfeits the liability shift that 3-D Secure has just secured. The reverse, flagging a phone order as an online payment, exposes the merchant to the circumvention charge described above. Each channel therefore needs its own configuration at the acquirer and its own dispute monitoring.