Pay by Call’s technological innovation to solve PSD2 / SCA / 3D Secure in the voice channel
For years, the telephone channel has remained essential in sectors where customer relationships do not end on a website: public administrations, utilities, insurance, healthcare, debt collection, transport, hospitality, BPOs and contact centers.
Yet telephone payments have traditionally been caught between two imperfect models.
On one side, there is traditional MOTO — Mail Order / Telephone Order — where the customer provides card details over the phone and the merchant manually enters them into a payment environment. This approach creates obvious challenges around security, call recordings, exposure of card data, PCI DSS scope and operational control.
On the other side, there is Pay by Link, which moves the customer to a web-based payment page through a link sent by SMS or email. This has been an important step forward for remote payments, but it does not solve every use case. In particular, it introduces friction when the customer is already speaking to an agent, has already been identified, understands the amount to be paid and is ready to complete the transaction.
This is the context in which PBC 3DS was created: a technological innovation developed by Pay by Call, with OEPM patent application P202630243 and international PCT application PCT/ES2026/070099, designed to solve PSD2 / SCA / 3D Secure natively in the voice channel.
The proposition is simple to explain, but highly complex to execute:
to enable a customer to complete a secure, authenticated telephone payment with 3D Secure without leaving the call.
Pay by Link works, but it is not always the natural channel for a live telephone payment
Redsys describes PayGold as a payment method that allows merchants to request payment from customers by sending a unique payment link by email or SMS, so that the customer can complete the transaction securely on the payment gateway through redirection.
This model works well in many scenarios: deferred payments, reservations, quotes, post-sale collections, additional charges, order incidents or situations where the customer is not necessarily in a live call.
But there is a different use case: the customer is already speaking with an agent.
At that moment, the user is at the point of highest payment intent. The customer has been attended to, has received an explanation, understands the amount and often simply wants to finish the operation without additional steps.
If a link is sent at that point, the journey changes:
call → SMS/email → link opening → browser → payment gateway → card entry → bank authentication → result.
Each additional step can create abandonment.
The issue is not that the link is technically insecure. The issue is that it introduces a channel switch at the most sensitive moment of the process: precisely when the customer was ready to pay.
Friction does not start at 3D Secure. It starts earlier.
When discussing payment abandonment, the focus often goes directly to 3D Secure. But in a pay-by-link journey, leakage can happen before authentication even begins.
The SMS may not arrive. The email may go to spam. The user may not open the link. The customer may distrust it. The flow may be unclear. The user may not have the right device at hand. The link may open in another browser or app. The session may expire. The user may abandon when seeing an unexpected payment page. The bank authentication step may create confusion. The agent may no longer be able to guide the customer effectively.
That is why Pay by Link creates two layers of friction in a live telephone payment:
First friction: delivery, opening and trust in the link.
Second friction: navigation, card entry and authentication outside the call.
In a live call, both types of friction matter because they break the conversational flow.
Trust is a critical factor in any checkout
Baymard Institute’s checkout research confirms that trust and simplicity are essential to payment completion. Among the reasons for abandonment, Baymard identifies lack of trust with credit card information, a checkout process perceived as too long or complicated, website errors or crashes, and insufficient payment methods. Its data includes 19% abandonment because users did not trust the site with their credit card information, 18% because the checkout process was too long or complicated, 15% due to website errors or crashes and 10% because there were not enough payment methods.
These figures come from ecommerce, but the logic transfers directly to the telephone channel. If users abandon a web checkout because of trust or complexity, the risk becomes even greater when the checkout appears as an unexpected interruption within a call.
In a telephone payment, the user did not start the journey on a website. The user started it in a conversation.
That is why forcing a channel switch can weaken payment intent.
Smishing has changed user psychology
Distrust of links is not anecdotal. It is learned behavior.
INCIBE explains that smishing attacks use malicious text messages that appear to come from legitimate sources, such as banks, utilities, transport companies or courier services, and often include links to fraudulent websites or requests to call a phone number.
This has a direct consequence for payment links: many users have been educated to be cautious with links received by SMS.
The paradox is clear:
a payment link may be technically secure, but psychologically suspicious.
And in sensitive payments — taxes, bills, water, energy, insurance, healthcare, collections, reservations or public services — that psychological barrier may be enough to prevent completion.
PBC 3DS removes that initial point of friction because it does not require the customer to click a link to start the payment. The payment remains in the channel where contextual trust already exists: the call.
Spain already experienced the cost of poorly integrated authentication
The Spanish market offers a useful reference for understanding how authentication friction can affect conversion.
During the initial implementation of 3DS2 and PSD2/SCA, Unnax published an analysis on the impact of 3DS2 in Spain, pointing to very high abandonment levels in redirection-based authentication flows. It referred to payment abandonment of around 60% and cited a figure attributed to Amazon indicating that abandonment could reach 88% after the bank authentication page loaded.
This figure belongs to a specific implementation period and to ecommerce/bank redirection flows. It should not be interpreted as a current abandonment rate for all payment links.
But it illustrates an important principle that remains valid:
when authentication feels abrupt, unexpected or poorly integrated, conversion suffers.
The conclusion is not that 3D Secure is the problem.
The conclusion is that the way 3D Secure is delivered to the user is decisive.
3D Secure should not be avoided. It should be orchestrated better.
EMVCo defines EMV 3-D Secure as an ecommerce fraud prevention protocol that enables consumer authentication for card-not-present purchases without adding unnecessary friction to the checkout process.
In other words, 3D Secure is not designed to damage the user experience. It is designed to protect it.
The challenge lies in how it is integrated into the user journey. Stripe makes this point clearly in its analysis of regulated markets: the business impact of authentication depends not only on how often 3DS is used, but on the implementation quality of authentication flows.
This point is central for voice payments.
The problem is not applying SCA.
The problem is not using 3D Secure.
The problem is forcing the customer out of the call in order to do it.
PBC 3DS proposes a different path: applying 3D Secure while keeping the call active as the primary channel.
Frictionless vs challenge: what the data really means
When discussing 3D Secure, it is important to distinguish between frictionless authentication and challenge authentication.
A frictionless authentication means the issuer can authenticate the transaction in the background, without asking the customer to do anything. The customer does not need to open the banking app, enter an SMS code or approve a push notification. The transaction is assessed silently using risk data.
A challenge means the issuer asks the customer to perform an additional action: approve the transaction in the banking app, enter an OTP code, use biometrics, confirm a push notification or complete another verification step.
The distinction matters because a frictionless rate is not the same as a success rate.
Ravelin’s authentication data for Europe in January–July 2025 shows three different metrics: 83% 3DS success rate, 75% 3DS challenge success rate and 62% frictionless rate.
This does not mean that “frictionless performs worse than challenge”. It means something different:
- 3DS success rate measures the share of transactions sent to 3DS that authenticate successfully overall.
- Challenge success rate measures the share of challenged transactions that are completed successfully.
- Frictionless rate measures the share of authentications completed successfully without requiring a challenge.
So the relevant message is not that frictionless is “less successful”. The relevant message is that a significant share of 3DS transactions still require user intervention.
And whenever a transaction moves from frictionless to challenge, the customer has to do something.
In ecommerce, that additional step happens in a browser or app checkout.
In Pay by Link, it happens after the customer has already left the call.
In PBC 3DS, it can happen while the call remains active and the user is still guided through the process.
That is the key difference.
Ravelin also warns that frictionless authentication has fallen across regions, standing at 62% in Europe, 54% in North America and 58% globally, meaning fewer customers are enjoying a smooth checkout experience without challenge.
The conclusion is clear: the debate is not “3DS or no 3DS”.
The real question is:
how can 3DS be applied without breaking the customer experience?
The voice channel needs a native solution
The historical mistake has been to solve telephone payments using solutions inherited from other channels.
Traditional MOTO comes from an old model: the customer dictates card details and the merchant enters them.
Pay by Link comes from a web logic: the customer is moved to an online payment page.
But neither model fully uses the natural strengths of the voice channel.
A call has its own characteristics:
- the customer is being assisted;
- there is context;
- there is immediate intent;
- doubts can be resolved in real time;
- the customer can be guided step by step;
- the result can be confirmed;
- a failed attempt can be redirected or recovered.
When payment is moved out of the call, part of that value is lost.
PBC 3DS enables voice to stop being merely the origin of the transaction and become the channel where the transaction is securely completed and authenticated.
What is PBC 3DS?
PBC 3DS is Pay by Call’s technology for executing native 3D Secure in the voice channel.
Its objective is to solve a very specific problem: how to apply PSD2 / SCA / 3D Secure to telephone payments without forcing the customer to leave the call and without exposing card data to the agent or the contact center.
The innovation is based on the orchestration of several elements:
- an active call with an agent or IVR;
- secure card capture within a PCI DSS IVR environment;
- integration with the customer’s PSP;
- a 3DS2 request to the issuing bank;
- customer authentication through the bank’s usual channel;
- the call remaining active throughout the process;
- the OK/KO result being returned to the customer service flow.
The key is not only authentication.
The key is authentication without breaking the voice channel.
That is why Pay by Call has filed patent protection for PBC 3DS through OEPM patent application P202630243 and international PCT application PCT/ES2026/070099. PBC 3DS is designed as a native PSD2/3DS2 authentication layer for the telephone channel over Pay by Call’s secure IVR infrastructure, allowing the user to remain in the call during authentication.
How PBC 3DS works in a real call
The flow can be explained simply.
The user calls or receives a call. The agent identifies the customer, confirms the amount and validates the intention to pay. At the moment of payment, the call enters Pay by Call’s secure environment.
The customer enters card details using the telephone keypad. The agent does not see or hear the card data. The contact center systems do not capture PAN, expiry date or CVV. The call recording does not store sensitive card data.
Pay by Call then sends the transaction through the integrated PSP. If the payment requires strong customer authentication, PBC 3DS orchestrates the 3DS2 process with the issuer. The customer confirms the operation through the banking app, SMS OTP, push notification or the authentication method enabled by the bank.
Meanwhile, the call remains active.
When the response arrives, Pay by Call returns the result to the customer’s system and, if an agent is online, the agent can confirm the payment, resolve an issue or redirect the flow.
The customer did not have to click a link.
The agent did not see the card.
The PSP keeps its role.
The voice channel is not broken.
Authentication is completed natively within the telephone experience.
PBC LAA: agent-assisted payment without card data exposure
One of the most relevant modalities for this use case is PBC LAA — Live Agent-Assisted.
In PBC LAA, the agent remains in the call throughout the payment process and can guide the customer step by step. However, card data is not heard or viewed by the agent. The user enters the information using DTMF and the platform protects the capture of the data inside the secure environment.
This solves one of the major dilemmas for contact centers: how to keep human assistance without exposing sensitive card data.
The combination of PBC LAA + PBC 3DS creates a particularly powerful experience:
- the customer receives guidance;
- the agent remains in control of the closing moment;
- the contact center reduces PCI DSS exposure;
- the PSP retains its processing role;
- the customer authenticates with the issuing bank;
- the call remains active until the result is received.
PCI DSS and telephone payments: card data should not enter the contact center
PCI SSC’s guidance on telephone-based payment card data states that PCI DSS applies to all payment acceptance channels, including MOTO, and focuses on protecting card data in voice, recording, agent and contact center environments.
This is essential.
When a contact center allows an agent to hear, view, enter or record card data, the compliance perimeter can expand significantly. This is not only a technical issue. It is operational, contractual, reputational and audit-related.
Pay by Call’s PCIaaS proposition is based on isolating the capture of sensitive card data in a specialized secure platform, so the contact center can continue assisting the customer without becoming the place where card risk resides.
Pay by Link and PBC 3DS do not compete. They complement each other.
The right market evolution is not to replace Pay by Link. It is to use each solution where it creates the most value.
Pay by Link is ideal when the payment is asynchronous: sending a quote, collecting a reservation, charging a later add-on, recovering a failed operation or allowing the user to pay later.
PBC 3DS is ideal when the payment starts in a live call: the customer is speaking to an agent, needs guidance, the amount is sensitive, the user may distrust links or the organization wants to avoid cooling down the payment intent by switching channels.
| Scenario | Natural solution |
|---|---|
| Deferred payment | Pay by Link |
| Payment after a quote | Pay by Link |
| Digitally autonomous customer | Pay by Link |
| Customer already in a call | PBC LAA + PBC 3DS |
| User needing guidance | PBC LAA + PBC 3DS |
| Sensitive or reputationally critical payment | PBC LAA + PBC 3DS |
| Contact center reducing PCI DSS exposure | PBC LAA / PBC TFA |
| Telephone payment with strong authentication | PBC 3DS |
The message is clear:
Pay by Link for asynchronous payments.
PBC 3DS for authenticated telephone payments inside the call.
A new category: secure Voice Commerce
Voice is no longer a residual channel.
Conversational AI, voicebots, virtual agents and intelligent contact centers are turning conversation into a transactional interface. But that evolution raises a critical question:
how is the payment securely executed when the conversation reaches the moment of payment?
An assistant can inform.
An agent can guide.
A PSP can process.
But a specialized layer is needed to capture card data, preserve PCI DSS compliance, orchestrate 3D Secure and return the result to the conversational flow.
That layer is Pay by Call.
And PBC 3DS is the technology that allows Voice Commerce not to end in a link, but in a secure transaction inside the call itself.
The opportunity: recovering conversion where friction exists today
The opportunity is not only about compliance. It is also about conversion.
When a user is in a call and agrees to pay, there is immediate intent. If the process is diverted to a link, part of that intent may be lost. The payment cools down, the agent loses control and the user enters an environment they may not have expected.
PBC 3DS keeps context, guidance and trust.
The most rigorous way to measure the impact is through comparative pilots:
Group A: live agent call + payment link.
Group B: live agent call + PBC LAA + PBC 3DS.
Relevant metrics include:
- completed payments;
- time to confirmation;
- abandonment before payment starts;
- abandonment during authentication;
- 3DS failures;
- retries;
- repeated calls;
- OK/KO rate;
- customer satisfaction;
- agent workload;
- disputes or chargebacks.
The hypothesis is clear:
when the customer is already in a call, keeping the customer inside the call should improve conversion compared with sending the customer to a link.
Conclusion
Pay by Link has been a necessary and useful solution for remote payments. But it should not be the only answer for MOTO payments.
The voice channel needs a native solution.
The external evidence points in that direction. Redsys documents PayGold as a link-and-redirection flow. Baymard shows that trust and complexity directly affect checkout abandonment. INCIBE confirms that users have increasing reasons to distrust SMS links. Unnax documented the cost of friction in 3DS redirection flows during PSD2 implementation in Spain. Ravelin shows that 3DS is still not 100% frictionless and that many authentications still require user action. Stripe confirms that the key factor is the quality of authentication-flow implementation. EMVCo reminds the industry that 3DS should authenticate without adding unnecessary friction. PCI SSC confirms that PCI DSS also applies to telephone-based MOTO environments.
The logical evolution is clear:
from insecure manual MOTO to Pay by Link; and from Pay by Link to native 3D Secure in voice.
That is precisely the proposition behind PBC 3DS, Pay by Call’s technological innovation with OEPM patent application P202630243 and international PCT application PCT/ES2026/070099.
A technology designed to solve PSD2 / SCA / 3D Secure in the voice channel, without forcing the customer to leave the call.
Because when the customer has already decided to pay by phone, the best channel to complete the payment may be exactly that:
the call itself.
For more information, contact Pay by Call by clicking here.