Why DTMF Masking Alone Is Not Enough: Adding SCA and EMV 3-D Secure to Telephone Payments

July 31, 2026

Protecting card data is essential. Authenticating the person using the card is the next major step.

DTMF Masking has transformed payment security in contact centres.

It enables customers to enter their card details using the telephone keypad while preventing agents, call recordings and contact centre systems from seeing, hearing or storing the sensitive information.

For organisations that accept card payments over the telephone, this is an essential security capability. It can substantially reduce PCI DSS scope, remove cardholder data from the agent environment and preserve the value of human assistance throughout the payment journey.

But DTMF Masking solves one specific problem:

How can card data be captured without exposing it to the contact centre?

It does not answer a different and equally important question:

Is the person using the card the legitimate cardholder — or someone authorised to use it?

A telephone payment can be perfectly protected from a PCI DSS perspective and still be fraudulent.

The card number may have been stolen. The credentials may have been obtained through phishing. A third party may be using the card without permission. The issuing bank may not have authenticated the person making the payment.

In all these cases, DTMF Masking may perform its function flawlessly. The agent never receives the card data, the recording remains clean and the transaction reaches the PSP securely.

But the payment may still result in a fraud claim and a subsequent chargeback.

This distinction lies at the centre of the next evolution of Telephone Order payments:

Card-data protection and payer authentication are complementary controls. They are not substitutes for each other.

DTMF Masking protects the credentials.

SCA and EMV 3-D Secure help authenticate the person using them.

For many sectors, secure telephone payments increasingly require both.

The four different questions every telephone payment architecture must answer

Payment security is often discussed as if it were a single control. In practice, a secure payment journey must answer several different questions.

Security layer	Primary question	What it addresses	What it does not solve alone
DTMF Masking	Can sensitive card data enter the contact centre?	Exposure to agents, recordings, CRM and telephony systems	Whether the payer is authorised to use the card
PCI DSS	Is the card-data environment appropriately secured and controlled?	Storage, processing and transmission of payment account data	Cardholder identity or transaction consent
Issuer authorisation	Can the transaction be approved?	Card status, available funds, limits and issuer risk decisions	Definitive proof that the legitimate cardholder initiated the payment
SCA and EMV 3DS	Can the payer and the specific transaction be authenticated?	Issuer-backed authentication, transaction risk assessment and dynamic linking	Service disputes, refunds, cancellations or every form of first-party misuse

These controls perform different functions.

A robust Telephone Order architecture should not ask whether it needs DTMF Masking or 3-D Secure. The correct question is how the two technologies can work together.

What is DTMF Masking?

DTMF stands for Dual-Tone Multi-Frequency, the signalling technology used when a caller presses numbers on a telephone keypad.

In an ordinary telephone payment, the caller may read the card number aloud while the agent enters it into a virtual terminal. This exposes the Primary Account Number, expiry date and security code to the agent and potentially to the call recording, desktop environment and wider contact centre infrastructure.

DTMF Masking changes this process.

Instead of reading the card information aloud, the customer enters the numbers using the telephone keypad. A specialised payment platform detects and replaces the tones before they reach the contact centre.

The agent may hear flat tones, neutral sounds or another masking signal. On screen, the agent may see only progress indicators or masked characters confirming that the customer is entering the required digits.

The agent remains available to guide the customer but cannot reconstruct the card details.

A well-designed DTMF payment flow can therefore prevent card data from entering:

The agent desktop.
The CRM.
The contact centre telephony platform.
The call recording.
Quality-assurance systems.
Workforce-management tools.
Speech analytics platforms.
AI transcription or summarisation systems.
Other systems connected to the agent environment.

The PCI Security Standards Council states that properly designed and deployed DTMF-masking solutions can remove the telephony environment, agent environment and CRM from PCI DSS scope, subject to the specific architecture and appropriate validation. PCI SSC: Protecting Telephone-Based Payment Card Data

This can represent a major reduction in security exposure and compliance complexity.

DTMF Masking must also be implemented correctly

DTMF technology should not be treated as inherently secure regardless of implementation.

The PCI SSC specifically warns about DTMF bleed. This can occur when tone detection introduces a short delay and an initial portion of the original tone reaches the contact centre before masking is applied.

A secure implementation must therefore ensure that:

All sensitive tones are replaced before reaching the agent environment.
No original tones remain available in recordings.
Card data is not reproduced in agent desktops or logs.
Telephony and payment components are correctly segmented.
Monitoring confirms the continuing effectiveness of the masking process.
Failures do not return the call to an insecure card-capture method.
Speech analytics, transcription and AI tools cannot ingest sensitive payment data.
The payment infrastructure is assessed within the correct PCI DSS scope.

These requirements demonstrate why DTMF Masking should be delivered as part of a specialised, controlled payment environment rather than as a simple telephony feature.

What DTMF Masking cannot determine

DTMF Masking can determine that digits were entered.

It can securely route those digits to the payment infrastructure.

But it cannot determine:

Who physically pressed the keys.
Whether the card was stolen.
Whether the card credentials were purchased on the dark web.
Whether the caller obtained the details through phishing.
Whether the cardholder authorised the transaction.
Whether the person paying is the cardholder or an authorised third party.
Whether the cardholder will subsequently deny participating in the transaction.
Whether the authentication should be dynamically linked to the merchant and amount.

This is not a technical failure. It is simply outside the purpose of DTMF Masking.

The technology protects the confidentiality of the credentials. It does not establish the identity or legitimacy of the person using them.

PCI DSS compliance is not the same as transaction authentication

PCI DSS provides a baseline of technical and operational requirements for protecting payment account data wherever it is stored, processed or transmitted. PCI Security Standards Council

Its controls are essential for reducing the likelihood that card data will be exposed or compromised.

However, PCI DSS is not a cardholder-authentication protocol.

A PCI DSS-compliant transaction may still involve:

A valid card used by an unauthorised person.
Stolen credentials entered into a secure IVR.
A customer later claiming not to recognise the transaction.
A merchant with insufficient authentication evidence.
A fraud-related chargeback for which the merchant remains liable.

This explains an apparently paradoxical situation:

A transaction can be completely compliant from a card-data-security perspective and still be fraudulent from a payment-authentication perspective.

PCI DSS protects the payment environment.

SCA and EMV 3-D Secure add issuer-backed authentication to the transaction.

Why remote card transactions require additional controls

Remote card payments are structurally more exposed to fraud than face-to-face transactions because the merchant cannot physically inspect the card or verify the cardholder in person.

The latest joint report from the European Central Bank and the European Banking Authority provides clear evidence of this difference.

According to the report, in 2024:

Approximately 17.06 million fraudulent card transactions were recorded out of 111.05 billion card payments.
Fraud involving cards issued in the EU/EEA amounted to approximately EUR 1.3 billion.
The fraud rate by value was 0.091% for remote card payments, compared with 0.007% for non-remote card payments.
Remote card-payment fraud was therefore 13 times higher by value and 22 times higher by transaction volume.
Theft of card credentials accounted for more than 56% of the value of fraudulent remote card transactions.
Fraud rates for remote card payments without SCA ranged from 0.01% to 0.17%, depending on the reason why strong authentication was not applied.
Card-payment fraud was approximately 17 times higher for transactions involving a counterparty outside the EEA than for domestic transactions, potentially reflecting the lower application of SCA.

The report concluded that SCA-authenticated transactions generally displayed lower fraud rates than non-SCA transactions, particularly for card payments. ECB/EBA: 2025 Report on Payment Fraud

Previous ECB research also found that Card-Not-Present fraud declined by 12% in 2021 following the market-wide introduction of SCA, although it still accounted for approximately 84% of the total value of card fraud. ECB: Card Fraud in Europe Declines Significantly

The evidence does not suggest that SCA eliminates fraud completely. Fraudsters continually adapt and increasingly target exemptions, out-of-scope transactions and the customer directly.

However, it demonstrates that authentication materially affects the risk profile of remote card payments.

The growing economic impact of chargebacks

Fraud losses are only one part of the economic problem.

When a cardholder disputes a payment, the merchant may face:

Reversal of the transaction amount.
Chargeback fees.
Loss of the product or service already provided.
Operational costs associated with investigation.
Evidence-collection and representment costs.
Additional acquirer monitoring.
Higher reserves or processing costs.
Reputational consequences.
Possible restrictions if dispute thresholds are exceeded.

Global research commissioned by Mastercard and conducted by Datos Insights projected:

261 million chargebacks worldwide in 2025.
324 million by 2028, representing growth of 24%.
An increase in chargeback value from USD 33.79 billion to USD 41.69 billion.
Forecast growth of 27% in Europe between 2025 and 2028.
More than 10% annual chargeback growth reported by 59% of merchants and 56% of financial institutions surveyed.
Approximately 45% of merchant chargeback volume identified as fraudulent.

The research also found that travel and hospitality merchants experienced the highest average chargeback value of the verticals analysed, at USD 120 per dispute. Mastercard/Datos Insights: State of Chargebacks

Visa reported separately that it processed 106 million disputes globally in 2025, representing an increase of 35% since 2019. Visa: Modernising Dispute Resolution

Chargebacks have therefore moved beyond the payments back office. They now affect fraud strategy, operational efficiency, customer experience and business margins.

Not every chargeback has the same cause

A credible chargeback-reduction strategy must distinguish between different types of disputes.

Third-party fraud

An unauthorised person obtains and uses the cardholder’s credentials.

SCA and EMV 3DS can be particularly valuable in this category because the issuer can assess the transaction and authenticate the person using the card.

First-party misuse or “friendly fraud”

The genuine cardholder — or someone closely connected to them — participates in the transaction but later disputes it.

Authentication can provide stronger evidence that the cardholder participated in the payment. However, it cannot eliminate every first-party dispute, especially when the dispute concerns the service rather than authorisation.

Merchant or service disputes

The customer claims that:

The service was not provided.
The product differed from its description.
A booking was cancelled.
A refund was not processed.
The amount was incorrect.
The transaction was duplicated.

SCA does not resolve these disputes. They require clear commercial records, transparent policies, good customer service and effective dispute management.

Recognition problems

The cardholder may not recognise the merchant descriptor on the statement or may have forgotten the transaction.

Authentication evidence can help, but clear descriptors, digital receipts and proactive communication remain important.

Processing errors

Technical duplication, incorrect amounts, late presentment or other processing issues can also lead to chargebacks. These problems must be addressed through payment operations rather than authentication alone.

The goal of SCA and 3DS is therefore not to make every chargeback impossible.

The goal is to reduce unauthorised use, strengthen transaction evidence and, where applicable, change the allocation of liability for fraud-coded disputes.

The historical MOTO gap under PSD2

Strong Customer Authentication became one of the central security controls introduced by PSD2.

Under the regulation, SCA must use at least two independent elements from the following categories:

Knowledge: something only the user knows.
Possession: something only the user possesses.
Inherence: something the user is.

For remote electronic transactions, SCA must also incorporate dynamic linking so that the authentication is specifically associated with the amount and payee. PSD2, Article 97

Traditional Mail Order/Telephone Order transactions were treated differently.

Genuine remote, non-electronic MOTO transactions have historically remained outside the scope of the PSD2 SCA requirement. The regulatory treatment reflected both the classification of the transaction and the historical difficulty of applying an electronic authentication protocol inside a live telephone payment.

But this creates an important misunderstanding:

Being outside the regulatory scope of SCA does not make a transaction low risk.

The absence of a legal obligation does not authenticate the cardholder.

The Euro Retail Payments Board Working Group on Fraud Prevention highlighted this issue in 2024. It noted that MOTO payments can be insecure because the merchant and customer are not physically present and there is normally no PIN or comparable evidence linked to the person approving the transaction.

The report stated that payment methods requiring strong customer authentication are safer than traditional MOTO. ERPB Working Group on Fraud Prevention

The strategic question for merchants should therefore not be limited to:

“Does PSD2 legally require SCA for this transaction?”

The more relevant question is:

“Does the fraud, chargeback, transaction-value or reputational risk justify authenticating the payer?”

What is Strong Customer Authentication?

SCA is not simply an SMS message or a password.

It is an authentication outcome based on at least two independent factors. Compromising one factor should not compromise the reliability of the other.

For remote electronic payments, the authentication should also be bound to:

The specific payee.
The specific amount.
The transaction being approved.

This dynamic linking is important because it helps prevent an authentication code from being reused for a different merchant or modified amount.

SCA describes the required security result. It does not prescribe a single customer interface.

The issuer may authenticate the customer through:

A mobile banking application.
Biometrics.
A push notification.
A one-time password.
A possession-based credential.
Other methods supported by the bank and applicable regulation.

What is EMV 3-D Secure?

EMV 3-D Secure is a messaging protocol maintained by EMVCo that allows merchants and issuing banks to exchange information and authenticate consumers during Card-Not-Present transactions.

EMVCo describes 3DS as a technology that enables merchants and issuers to exchange transaction, payment-method and device information so that the issuer can evaluate risk and determine whether the person making the purchase is the legitimate user of the card. EMVCo: EMV 3-D Secure

The “three domains” are:

The acquirer domain, which includes the merchant and its payment infrastructure.
The issuer domain, where the card issuer authenticates the cardholder.
The interoperability domain, which supports communication between the other domains through the payment scheme infrastructure.

The critical 3DS components include:

The 3DS Server, operating in or supporting the merchant/acquirer domain.
The Directory Server, which routes authentication messages within the payment-scheme environment.
The Access Control Server, operated by or on behalf of the issuer and responsible for the authentication decision.

The PCI 3DS Core Security Standard defines security requirements for these components to protect the integrity and confidentiality of the authentication process. PCI SSC: PCI 3DS Core Security Standard

Frictionless authentication and challenge authentication

EMV 3DS supports two principal authentication outcomes.

Frictionless flow

The issuer receives sufficient information to assess the transaction without requiring an additional action from the cardholder.

The authentication may occur in the background, preserving a seamless customer experience.

According to EMVCo, the frictionless flow uses real-time risk assessment to allow issuers to accept appropriate transactions without challenging the cardholder. EMVCo: Optimising Online Payment Authentication

Challenge flow

If the issuer considers the transaction higher risk or requires confirmation, it asks the cardholder to complete an additional authentication step.

This may involve:

Approving the transaction through a banking application.
Entering an OTP.
Using biometric authentication.
Responding to a push notification.
Completing another issuer-supported verification method.

A challenge introduces an additional action, but it also provides a stronger confirmation of the cardholder’s participation.

The objective is not to challenge every transaction. It is to enable the issuer to apply an authentication method proportionate to the risk.

Authentication and authorisation are different decisions

This distinction is essential.

Authentication evaluates whether the person using the card is legitimate.

Authorisation determines whether the transaction should be approved based on factors such as:

Available funds or credit.
Card status.
Spending limits.
Merchant category.
Issuer risk policies.
Geographical indicators.
Previous cardholder behaviour.

A transaction can be authenticated but still declined because of insufficient funds.

A transaction can also receive authorisation without having been strongly authenticated, depending on its classification, geography and the applicable rules.

A secure Telephone Order flow must therefore coordinate both processes without confusing them.

Why 3-D Secure has historically been difficult in telephone payments

EMV 3DS evolved primarily within e-commerce and mobile-commerce environments.

The usual customer journey assumes the existence of:

A website or application.
A checkout page.
Browser or device information.
A merchant-controlled digital interface.
A transition into the issuer authentication flow.

Traditional Telephone Order does not naturally provide this environment.

The merchant and customer are already interacting through a live call. The transaction context has been established conversationally. The customer may be receiving assistance from an agent and may not be comfortable navigating a separate web checkout.

Historically, merchants have dealt with this gap in one of two ways:

Continue processing the transaction as unauthenticated MOTO.
Send the customer a payment link and move the transaction into an e-commerce flow.

Both options can be useful, but neither fully solves every live telephone-payment scenario.

Pay by Link is valuable — but it changes the channel

Pay by Link is an effective solution when:

The payment is asynchronous.
The customer wants to pay later.
A quotation has been issued.
A booking or additional service must be paid after the call.
The customer is digitally autonomous.
The merchant does not need the agent to remain involved.

However, when a customer is already speaking to an agent and has decided to pay, sending a link creates a new journey:

Voice call → SMS or email → link → browser → payment page → card entry → issuer authentication → result

The payment may still be secure, but the commercial interaction has moved away from the original channel.

Potential sources of friction include:

The message arriving late.
The customer not locating it.
Distrust of links received by SMS.
Difficulty switching between the call and another application.
Accessibility limitations.
Expired or unopened links.
The agent losing visibility of the payment process.
The customer deciding to complete the transaction later and never returning.
Additional calls when the payment fails.

Pay by Link should therefore not be rejected. It should be used where it is the natural solution.

For a live assisted Telephone Order, the more natural objective may be to introduce authentication while keeping the call active as the primary interaction.

From MOTO to Authenticated Telephone Order

The evolution of telephone payments can be divided into three stages.

Stage 1: Traditional MOTO

The customer reads the card details aloud.

The agent receives and enters the information.

Risks include:

Exposure to the agent.
Sensitive data in call recordings.
Broad PCI DSS scope.
Insider risk.
Weak authentication.
Limited evidence in unauthorised-payment disputes.

Stage 2: Protected Telephone Order

The customer enters the card data through DTMF Masking inside a secure PCI DSS environment.

The agent remains available but does not receive the credentials.

Benefits include:

Protected card capture.
Cleaner recordings.
Reduced PCI DSS scope.
Preserved agent assistance.
Improved operational security.

However, the payer may still remain unauthenticated.

Stage 3: Authenticated Telephone Order — ATO

Protected card capture is combined with SCA and EMV 3-D Secure.

The issuing bank participates in the authentication. The authentication is linked to the transaction, and the result is returned to the live service flow.

This creates a new model:

Authenticated Telephone Order — a telephone-initiated payment in which the card data is protected and the person using the card can be authenticated through the issuer without terminating the voice interaction.

ATO does not eliminate DTMF Masking.

It completes it.

PBC 3DS: native 3-D Secure for the voice channel

Pay by Call SL has developed PBC 3DS, its proprietary, exclusive and patent-pending technology for orchestrating SCA and EMV 3-D Secure within Telephone Order payments.

PBC 3DS is designed around a specific objective:

Allow the customer to complete an authenticated telephone payment without being redirected to a separate merchant checkout or abandoning the live call.

A typical PBC 3DS journey works as follows:

The customer is speaking to a human agent, AI agent or IVR.
The merchant, payment purpose and amount are established during the conversation.
The call enters PaybyCall’s secure PCI DSS payment environment.
The customer enters the card details using the telephone keypad.
DTMF Masking prevents the sensitive data from reaching the agent, recording or contact centre systems.
PaybyCall communicates through an API with the customer’s existing PSP.
PBC 3DS orchestrates the 3DS2 authentication process through the integrated payment infrastructure.
The issuer evaluates the transaction.
If the flow is frictionless, no additional customer action may be required.
If the issuer requests a challenge, the customer authenticates through the bank’s usual method, such as its mobile application, biometrics, OTP or push notification.
The call remains active while the authentication is completed.
The authentication and payment result are returned to the voice journey.
The agent or AI can confirm success, manage a decline, retry or propose another payment option.

The customer may use the issuer’s normal authentication channel, but voice remains the primary commercial session.

There is no need to move the customer into a separate merchant checkout or terminate the conversation.

PBC 3DS does not replace the existing payment ecosystem

Pay by Call is not a general-purpose PSP.

PBC 3DS and the PaybyCall platform are designed to integrate with the infrastructure already selected by the customer.

Pay by Call does not seek to replace:

The contact centre platform.
The BPO.
The PBX.
The CCaaS provider.
The CRM.
The acquiring bank.
The existing PSP or gateway.
The issuer.
The payment scheme.
The issuer’s authentication method.
Existing fraud-detection systems.

Each participant retains its role:

The contact centre manages the customer interaction.
PaybyCall protects the card capture and orchestrates the secure voice-payment flow.
The PSP or acquirer processes the transaction and connects to the required payment infrastructure.
The issuing bank evaluates and authenticates the cardholder.
The payment scheme supports interoperability and transaction rules.

Pay by Call operates as a specialised PCIaaS and authentication layer over the customer’s existing architecture.

API integration and transparent deployment

PaybyCall is integrated through an API, allowing the platform to exchange transaction context and payment results with the customer’s systems.

Depending on the use case, the integration may include:

Customer or account reference.
Merchant and service information.
Transaction amount.
Currency.
Payment concept.
Internal case or booking identifier.
Selected PSP.
Authentication requirement.
Risk or threshold rules.
Payment result.
Authentication outcome.
Reconciliation data.

Sensitive card data remains inside the controlled PaybyCall payment environment.

The customer’s CRM and contact centre systems receive the information required to manage the operation without receiving the card credentials.

This allows PaybyCall to integrate with the existing operational ecosystem while minimising architectural disruption.

Flexible activation according to risk

Not every Telephone Order transaction necessarily requires the same authentication treatment.

PBC 3DS can be configured according to factors such as:

Transaction amount.
Merchant or service.
Customer type.
Sales or collections campaign.
Geography.
Card type.
Vertical.
Fraud exposure.
Chargeback history.
Regulatory classification.
Business rules agreed with the PSP or acquirer.

An organisation may decide to authenticate:

All eligible Telephone Order payments.
Transactions above a particular amount.
Payments in high-risk verticals.
Specific products or services.
Transactions involving immediate delivery of value.
First-time customers.
Payments using a cardholder name that differs from the customer.
Transactions identified by risk-management rules.

This risk-based approach allows businesses to balance security, conversion, customer experience and cost.

PBC 3DS patent-pending protection strategy

PBC 3DS is the subject of a patent-pending protection strategy comprising:

Spanish patent application OEPM P202630243.
International patent application PCT/ES2026/070099.
European patent application EP26178269.2

More information: PBC 3DS: Native 3D Secure for Voice Payments

Why this matters for travel, hospitality and transport

Travel and hospitality face a particularly difficult combination of payment risks:

High average transaction values.
Long periods between booking and consumption.
Cross-border payments.
Cardholders paying for other travellers.
Intermediaries and travel agents.
Cancellations and no-shows.
Services consumed before the chargeback is raised.
Complex evidence requirements.

A customer may complete a journey, hotel stay or rental and subsequently claim that the card payment was unauthorised.

PCI DSS and DTMF Masking can demonstrate that the card data was captured securely. They cannot, by themselves, demonstrate that the issuing bank authenticated the person using the card.

For eligible flows, SCA and EMV 3DS can add stronger authentication evidence and may provide liability shift for certain fraud-coded chargebacks, subject to the relevant payment-scheme and acquirer rules.

Why this matters for telecommunications and prepaid services

Prepaid top-ups and digital telecommunications services deliver value immediately.

Once a recharge has been applied, the value may be consumed or transferred before fraud is detected.

The combination of instant fulfilment and card-not-present payment makes retrospective recovery difficult.

PBC 3DS allows the issuing bank to participate in authenticating the transaction before the top-up is executed, while the customer remains assisted within the telephone journey.

Why this matters for insurance

Insurance telephone payments may involve several different identities:

The policyholder.
The insured person.
The beneficiary.
The customer speaking to the agent.
The cardholder.

These parties are not always the same person.

A secure payment flow must protect the credentials while creating a clear record of the payment context and the authentication result.

This is particularly important in telephone sales, policy renewals, missed-premium recovery and one-off payments.

Why this matters for utilities and debt collection

Utilities and debt-collection operations frequently process payments involving:

Customers in arrears.
Third-party cards.
Family members paying on behalf of the debtor.
High-volume agent-assisted calls.
Customers with limited digital confidence.
Immediate service-restoration requirements.
Multiple payment attempts.

Sending a payment link may work for some customers. Others require live assistance.

DTMF Masking preserves that assistance without exposing the credentials. PBC 3DS adds the possibility of issuer-backed authentication where the transaction risk justifies it.

Why this matters for BPOs and contact centres

BPOs often operate on behalf of multiple clients, using different PSPs, CRMs, CCaaS platforms and payment processes.

A central PCIaaS layer can help standardise secure payment capture across this complexity.

The advantages can include:

Reduced exposure across agent environments.
Lower PCI DSS scope.
Cleaner call recordings.
Compatibility with different PSPs.
Centralised payment controls.
Consistent reporting and reconciliation.
Authentication without replacing the client’s acquiring relationship.
A differentiated service for BPO customers.

PBC 3DS can therefore become not only a risk-control technology but also a commercial capability for contact centres and BPOs.

Why this matters for AI and Agentic Voice Commerce

Conversational AI is moving from customer service towards transaction execution.

An AI agent may increasingly be able to:

Identify the customer’s need.
Recommend a product or service.
Confirm the price.
Make a booking.
Renew a contract.
Negotiate a repayment plan.
Collect a payment.

But intelligence does not equal authority.

An AI agent can understand the customer’s intention. It cannot assume that the card presented belongs to that customer or that the person is authorised to use it.

Agentic Voice Commerce therefore requires a trusted execution layer capable of:

Protecting card data.
Preventing the AI and its logs from accessing sensitive credentials.
Connecting to the merchant’s existing PSP.
Requesting issuer-backed authentication.
Binding the authentication to the transaction.
Returning the result to the conversational flow.
Maintaining complete traceability.

This is where the combination of PaybyCall, DTMF Masking and PBC 3DS becomes strategically important.

Without a secure payment-execution layer, conversational AI remains an information and service tool.

With protected capture and authenticated execution, it can become part of a trusted commerce infrastructure.

PCIaaS: PCI security as a usage-based service

PaybyCall is delivered through a PCIaaS — PCI as a Service — model.

Instead of building, certifying and maintaining a complete internal telephone-payment infrastructure, the customer consumes PaybyCall as a specialised service.

The commercial model is aligned with use, allowing organisations to treat secure telephone payments as an operational capability rather than a major infrastructure project.

This approach can provide:

Lower initial investment.
Usage-based costs.
Faster deployment.
Continuous platform maintenance.
Reduced internal PCI DSS burden.
Access to specialised payment expertise.
Integration with existing PSPs and contact centre systems.
Scalability across campaigns, clients and verticals.
Selective activation of PBC 3DS.
A pathway towards AI-assisted payment journeys.

Pay by Call’s differentiation combines:

PCI DSS Level 1.
Spanish ENS High Category certification.
Secure IVR and DTMF payment capabilities.
API-based PSP integration.
PBC 3DS for native authentication in the voice channel.
A roadmap focused on secure conversational and Agentic Voice Commerce.

How to measure the business impact

The impact of authenticated telephone payments should be measured through controlled operational data.

Relevant KPIs include:

Payment performance

Payment completion rate.
Authorisation rate.
Authentication success rate.
Frictionless rate.
Challenge rate.
Challenge completion rate.
Soft and hard decline rates.
Retry success.
Average time to payment confirmation.

Customer experience

Abandonment before card capture.
Abandonment during authentication.
Repeated calls.
Average handling time.
Customer satisfaction.
Complaints related to payment complexity.
Accessibility outcomes.
Percentage of customers requiring agent assistance.

Fraud and disputes

Fraud rate by value and volume.
Chargeback rate.
Chargeback rate by reason code.
Fraud-coded chargebacks.
First-party disputes.
Representment success.
Average chargeback cost.
Liability-shift coverage.
Chargebacks by payment flow.

Operational efficiency

PCI DSS scope reduction.
Number of systems exposed to cardholder data.
Agent training requirements.
Reconciliation time.
Manual payment intervention.
Cost per completed payment.
Payment-related contact recurrence.

The most useful comparison may be between:

Live call plus payment link.
Live call plus protected DTMF payment.
Live call plus DTMF Masking and PBC 3DS.
Unassisted IVR payment.
Traditional manually entered MOTO.

This allows each organisation to determine which flow produces the best balance between conversion, risk and operational cost.

What PBC 3DS can reduce — and what it cannot eliminate

PBC 3DS is designed to bring issuer-backed authentication into the Telephone Order journey.

This can help reduce exposure to:

Stolen card credentials.
Unauthorised use.
Fraud claims based on lack of cardholder participation.
Certain fraud-coded chargebacks.
Weak authentication evidence.
Merchant liability in eligible transactions benefiting from liability shift.

However, no authentication technology can eliminate every chargeback.

PBC 3DS does not by itself resolve:

Services not provided.
Cancelled bookings.
Refund delays.
Incorrect transaction amounts.
Duplicate processing.
Product-quality disputes.
Confusing statement descriptors.
Every form of first-party misuse.
Fraud in which the legitimate customer is manipulated into authenticating the payment.

A complete chargeback strategy must therefore combine:

Secure card capture.
Strong authentication.
Transaction monitoring.
Clear commercial terms.
Recognisable payment descriptors.
Digital receipts.
Customer-service processes.
Refund management.
Evidence retention.
Pre-dispute and dispute-management tools.

Authentication is a critical layer, but it should operate inside a broader risk-management framework.

The strategic conclusion: protecting the card is no longer enough

DTMF Masking solved one of the most important problems in telephone payments: preventing agents and contact centre systems from receiving sensitive card data.

That capability remains essential.

But many industries now face a second challenge:

How can the organisation establish that the person using the protected card data is authorised to do so?

The answer lies in combining two complementary layers:

PCI DSS and DTMF Masking to protect the credentials.
SCA and EMV 3-D Secure to authenticate the payer and transaction.

Historically, these two layers could not be combined naturally inside the telephone channel.

PBC 3DS is designed to close that gap.

It allows Pay by Call to operate as a specialised PCIaaS layer over the customer’s existing contact centre, PSP and acquiring infrastructure, adding issuer-backed authentication without requiring the customer to abandon the live call or complete a separate merchant checkout.

The future of secure Telephone Order is therefore not simply MOTO with better data protection.

It is the transition from MOTO to Authenticated Telephone Order:

DTMF Masking + PCI DSS + SCA/EMV 3DS + voice continuity.

Because protecting card data is essential.

But in many verticals, it is no longer enough.

The person using the card must also be authenticated.

Frequently Asked Questions

Is DTMF Masking PCI DSS compliant?

DTMF Masking can form part of a PCI DSS-compliant telephone-payment architecture. A properly designed implementation can prevent cardholder data from entering the agent, recording, CRM and telephony environments, potentially reducing PCI DSS scope. The final scope and compliance position depend on the complete architecture and appropriate assessment.

Does DTMF Masking authenticate the cardholder?

No. DTMF Masking protects the card data while it is entered and transmitted. It does not establish whether the person pressing the telephone keys is the legitimate cardholder or is authorised to use the card.

Can a PCI DSS-compliant telephone payment still be fraudulent?

Yes. PCI DSS protects payment account data and the systems that store, process or transmit it. A fraudster may still enter stolen card credentials into a fully compliant payment environment.

Are MOTO transactions exempt from SCA?

Genuine remote, non-electronic Mail Order/Telephone Order transactions have historically been treated as outside the scope of the PSD2 SCA requirement. This regulatory treatment does not mean that MOTO transactions are authenticated or low risk.

What is the difference between SCA and 3-D Secure?

SCA is a regulatory authentication requirement based on two or more independent factors. EMV 3-D Secure is a messaging protocol through which merchants and issuers can exchange information and authenticate Card-Not-Present transactions. EMV 3DS can support the application of SCA.

Does 3-D Secure eliminate chargebacks?

No. It can reduce unauthorised-payment fraud and may provide liability shift for eligible fraud-coded chargebacks. It does not eliminate disputes concerning service delivery, refunds, cancellations, duplicate transactions or every form of first-party misuse.

Can 3-D Secure be used in a telephone payment?

PBC 3DS is Pay by Call’s patent-pending technology designed to orchestrate SCA and 3-D Secure in Telephone Order payments while keeping the call active as the primary customer interaction.

Does the customer have to leave the telephone call?

No. The call remains active. If the issuer requires a challenge, the customer may approve the transaction through the bank’s usual authentication method, such as its mobile application, biometrics, OTP or push notification, while remaining connected to the voice session.

Does Pay by Call replace the merchant’s PSP?

No. Pay by Call is not a general-purpose PSP. PaybyCall integrates with the merchant’s existing PSP, acquirer, contact centre and telephony environment through an API.

What is PCIaaS?

PCIaaS means PCI as a Service. The organisation consumes a specialised PCI DSS telephone-payment platform as a service instead of building and maintaining the complete infrastructure internally. The model is aligned with usage.

In which sectors is PBC 3DS particularly relevant?

PBC 3DS is particularly relevant to sectors with high-value or high-risk assisted payments, including travel, hospitality, airlines, transport, insurance, telecommunications, prepaid services, utilities, debt collection, BPOs and contact centres.

Is PBC 3DS patented?

PBC 3DS is patent pending. Its protection strategy includes Spanish application OEPM P202630243, international application PCT/ES2026/070099 and European patent application EP26178269.2 filed with the European Patent Office.

What is Authenticated Telephone Order?

Authenticated Telephone Order, or ATO, is the evolution of traditional MOTO into a telephone-initiated payment in which card data is captured inside a secure PCI DSS environment and the payer can be authenticated through SCA and EMV 3-D Secure while voice remains the primary channel.

Learn more about PBC 3DS and secure authenticated telephone payments or contact Pay by Call to discuss integration with your existing PSP and contact centre ecosystem.

ATO — Authenticated Telephone Order: The Birth of Authenticated Telephone Payments