La innovación tecnológica de Pay by Call para autenticar pagos telefónicos sin sacar al usuario de la llamada.
Durante años, el canal telefónico ha seguido siendo esencial para cobrar en sectores donde la relación con el cliente no termina en una web: administraciones públicas, utilities, seguros, salud, recobro, transporte, hospitality, BPO y contact centers.
Sin embargo, el pago telefónico ha vivido atrapado entre dos modelos imperfectos.
Por un lado, el MOTO tradicional, en el que el cliente comunica los datos de tarjeta por teléfono y el comercio los introduce manualmente en un entorno de pago. Este modelo plantea retos evidentes de seguridad, grabaciones, exposición del dato, cumplimiento PCI DSS y control operativo.
Por otro lado, el Pay by Link, que ha permitido trasladar el pago a una pasarela web mediante un enlace enviado por SMS o e-mail. Esta solución ha supuesto un avance importante, pero no resuelve todos los escenarios. En particular, introduce fricción cuando el cliente ya está en una llamada, ya ha sido identificado, ya conoce el importe y ya ha manifestado voluntad de pagar.
En ese contexto nace PBC 3DS, una innovación tecnológica desarrollada por Pay by Call, con solicitud de patente ante la OEPM número P202630243 y solicitud internacional PCT/ES2026/070099, diseñada para resolver la aplicación de PSD2 / SCA / 3D Secure de forma nativa en el canal de voz.
La propuesta es sencilla de explicar, pero compleja de ejecutar:
«permitir que un usuario complete un pago telefónico seguro y autenticado con 3D Secure sin abandonar la llamada.»
El Pay by Link funciona, pero no siempre es el canal natural del pago telefónico
Redsys documenta PayGold como una modalidad que permite solicitar pagos enviando al cliente un link único de pago por e-mail o SMS, para que pueda realizar la operación de forma segura en la pasarela por redirección.
Este enfoque funciona muy bien en muchos escenarios: pagos diferidos, reservas, presupuestos, cobros posteriores, extras, incidencias en un pedido o situaciones donde el cliente no está necesariamente en una llamada activa.
Pero hay un caso de uso diferente: el cliente ya está hablando con un agente.
En ese momento, el usuario está en el punto de máxima intención de pago. Ya ha sido atendido, ya ha recibido explicación, ya conoce el importe y, en muchas ocasiones, solo quiere resolver la operación sin más pasos.
Si entonces se le envía un enlace, el flujo cambia:
llamada → SMS/e-mail → apertura del enlace → navegador → pasarela → introducción de tarjeta → autenticación bancaria → resultado.
Cada paso adicional puede provocar abandono.
El problema no es que el enlace sea inseguro técnicamente. El problema es que introduce un salto de canal en el momento más delicado del proceso: justo cuando el usuario estaba preparado para pagar.
La fricción no empieza en el 3D Secure: empieza antes
Cuando hablamos de abandono en pagos, solemos pensar en la autenticación 3D Secure. Pero en un pago por enlace la fuga puede empezar mucho antes:
el SMS puede no llegar, el e-mail puede entrar en spam, el usuario puede no abrir el enlace, puede desconfiar, puede no entender el flujo, puede no tener el móvil a mano, puede abrir el enlace en otro dispositivo, puede perder la llamada, puede abandonar al ver una pasarela que no esperaba o puede fallar durante la autenticación.
Por eso el Pay by Link tiene una doble fricción:
Primera fricción: recepción, apertura y confianza en el enlace.
Segunda fricción: navegación, introducción de tarjeta y autenticación fuera de la llamada.
En una llamada viva, ambas fricciones son especialmente relevantes porque rompen la continuidad conversacional.
La confianza es un factor crítico en cualquier checkout
Los datos de Baymard Institute confirman que la confianza y la simplicidad del checkout son factores esenciales para completar un pago. Entre las causas de abandono identificadas por Baymard aparecen la falta de confianza al introducir datos de tarjeta, el proceso demasiado largo o complicado, errores en la web y falta de métodos de pago suficientes. En concreto, Baymard recoge un 19% de abandono por falta de confianza con los datos de tarjeta, un 18% por checkout largo o complicado, un 15% por errores o caídas de la web y un 10% por falta de métodos de pago.
Estos datos proceden del entorno ecommerce, pero la lógica se traslada perfectamente al canal telefónico: si un usuario ya abandona un checkout web por falta de confianza o complejidad, el riesgo aumenta cuando el checkout aparece como una interrupción inesperada dentro de una llamada.
En un pago telefónico, el usuario no ha iniciado su experiencia en una web. La ha iniciado en una conversación. Por eso obligarle a cambiar de canal puede erosionar la intención de pago.
El smishing ha cambiado la psicología del usuario
La desconfianza frente a los enlaces no es una percepción anecdótica. Es una conducta aprendida.
INCIBE explica que el smishing utiliza SMS maliciosos que parecen provenir de fuentes legítimas, como bancos, empresas de servicios públicos, transporte o mensajería, e incluyen enlaces fraudulentos o solicitudes para llamar a determinados números.
Esto tiene una consecuencia directa sobre los pagos por enlace: muchos usuarios han sido educados para desconfiar de los links recibidos por SMS.
La paradoja es clara:
un enlace de pago puede ser técnicamente seguro, pero psicológicamente sospechoso.
Y en pagos sensibles —tributos, recibos, agua, energía, seguros, salud, recobro, reservas, servicios públicos— esa barrera psicológica puede ser suficiente para que el usuario no complete la operación.
PBC 3DS elimina ese punto de fricción inicial porque no obliga al usuario a pulsar un enlace para iniciar el pago. El pago se mantiene en el canal donde ya existe confianza contextual: la llamada.
España ya vivió el coste de una autenticación mal integrada
El caso español ofrece una referencia muy útil para entender el impacto de la fricción en la autenticación.
Durante la implantación inicial de 3DS2 y PSD2/SCA, Unnax publicó un análisis sobre los efectos de 3DS2 en España en el que señalaba que el abandono de pagos podía situarse alrededor del 60% y recogía un dato atribuido a Amazon según el cual el abandono podía alcanzar el 88% tras cargar la página bancaria de autenticación.
Ese dato corresponde a un momento concreto de implantación y a flujos de redirección bancaria en ecommerce. No debe interpretarse como una cifra actual de abandono de todos los pagos por enlace.
Pero sí ilustra una realidad que sigue siendo válida:
cuando la autenticación se percibe como un salto brusco, inesperado o poco integrado, la conversión sufre.
La conclusión no es que 3D Secure sea el problema. La conclusión es que la forma de entregar 3D Secure al usuario es decisiva.
3D Secure no debe eliminarse: debe orquestarse mejor
EMVCo define EMV 3-D Secure como un protocolo de prevención de fraude en ecommerce que permite autenticar al consumidor en compras card-not-present sin añadir fricción innecesaria al checkout.
Es decir, 3D Secure no nace para complicar la experiencia. Nace para protegerla.
El reto está en cómo se integra en el flujo real del usuario. Stripe lo resume de forma muy clara en su análisis sobre mercados regulados: el impacto del 3DS en la conversión no depende solo de cuánto se use, sino de la calidad de implementación de los flujos de autenticación.
Este punto es clave para el canal voz.
El problema no es aplicar SCA.
El problema no es utilizar 3D Secure.
El problema es sacar al usuario de la llamada para hacerlo.
PBC 3DS propone otra vía: aplicar 3D Secure manteniendo la llamada activa como canal principal.
Los datos actuales muestran que 3DS sigue teniendo fricción
Aunque el mercado ha mejorado mucho desde los primeros años de PSD2, 3D Secure sigue sin ser un flujo perfecto.
Ravelin muestra que, para Europa, en el periodo enero-julio de 2025, la tasa media de éxito 3DS fue del 83%, la tasa de éxito en challenge fue del 75% y la tasa frictionless fue del 62%.
Además, Ravelin advierte en su Global Payments Report 2026 de que las tasas frictionless han caído en el 76% de los países analizados, situándose en el 62% en Europa, el 54% en Norteamérica y el 58% a nivel global.
Esto significa que cada vez más usuarios tienen que realizar algún paso activo de autenticación. Si ese paso ocurre fuera de una llamada asistida, aumenta el riesgo de abandono.
Por eso, el debate ya no es “3DS sí o no”. El debate real es:
cómo aplicar 3DS sin romper la experiencia de usuario.
El canal voz necesita una solución nativa
El error histórico ha sido resolver el pago telefónico con soluciones heredadas de otros canales.
El MOTO manual procede de una lógica antigua: el cliente dicta la tarjeta y el comercio la introduce.
El Pay by Link procede de la lógica web: se envía al usuario a una pasarela online.
Pero ninguno de los dos modelos aprovecha plenamente la naturaleza del canal voz.
La llamada tiene características propias:
- el usuario está acompañado;
- existe contexto;
- existe intención inmediata;
- se pueden resolver dudas en tiempo real;
- se puede guiar paso a paso;
- se puede confirmar el resultado;
- se puede reconducir un fallo.
Cuando el pago se saca de la llamada, se pierde parte de ese valor.
PBC 3DS permite que la voz deje de ser solo el canal que origina la operación y se convierta en el canal donde la operación se completa de forma segura y autenticada.
Qué es PBC 3DS
PBC 3DS es la tecnología de Pay by Call para ejecutar 3D Secure nativo en canal voz.
Su objetivo es resolver un problema muy concreto: cómo aplicar PSD2 / SCA / 3D Secure en pagos telefónicos sin obligar al usuario a abandonar la llamada ni exponer los datos de tarjeta al agente o al contact center.
La innovación se basa en la orquestación de varios elementos:
- llamada activa con agente o IVR;
- captura segura de tarjeta en entorno IVR PCI DSS;
- integración con el PSP del cliente;
- solicitud 3DS2 hacia el banco emisor;
- autenticación del usuario en su canal bancario habitual;
- mantenimiento de la llamada durante todo el proceso;
- devolución del resultado OK/KO al flujo de atención.
La clave no está únicamente en autenticar. La clave está en autenticar sin romper el canal de voz.
Por eso Pay by Call ha solicitado protección para PBC 3DS mediante solicitud de patente OEPM P202630243 y solicitud internacional PCT/ES2026/070099.
Cómo funciona PBC 3DS en una llamada real
El flujo puede explicarse de forma sencilla:
El usuario llama o recibe una llamada. El agente identifica al cliente, confirma el importe y valida la voluntad de pago. En el momento de pagar, la llamada entra en el entorno seguro de Pay by Call.
El usuario introduce los datos de tarjeta mediante el teclado del teléfono. El agente no ve ni escucha la tarjeta. Los sistemas del contact center no capturan PAN, caducidad ni CVV. La grabación de la llamada no almacena los datos sensibles.
A continuación, Pay by Call lanza la operación a través del PSP integrado. Si el pago requiere autenticación reforzada, PBC 3DS orquesta el proceso 3DS2 con el banco emisor. El usuario confirma la operación en su app bancaria, mediante SMS OTP, push notification o el método habilitado por su banco.
Mientras tanto, la llamada sigue activa.
Cuando llega la respuesta, Pay by Call devuelve el resultado al sistema del cliente y, si hay agente en línea, este puede confirmar el pago, resolver una incidencia o reconducir la operación.
El usuario no ha tenido que pulsar un link.
El agente no ha visto la tarjeta.
El PSP mantiene su papel.
El canal voz no se rompe.
La autenticación se completa de forma nativa en la experiencia telefónica.
PBC LAA: pago asistido por agente sin exposición del dato
Una de las modalidades más relevantes para este caso de uso es PBC LAA — Live Agent-Assisted.
En PBC LAA, el agente permanece en la llamada durante todo el proceso y puede guiar al usuario paso a paso. Sin embargo, los datos de tarjeta no son escuchados ni visualizados por el agente. El usuario introduce la información mediante DTMF y la plataforma protege la captura del dato dentro del entorno seguro.
Esto resuelve uno de los grandes dilemas del contact center: cómo mantener la asistencia humana sin exponer datos sensibles.
La combinación de PBC LAA + PBC 3DS permite una experiencia especialmente potente:
- el usuario recibe ayuda;
- el agente mantiene el control del cierre;
- el contact center reduce exposición PCI DSS;
- el PSP conserva su rol de procesamiento;
- el usuario autentica con su banco;
- la llamada permanece activa hasta el resultado.
PCI DSS y pagos telefónicos: el dato de tarjeta no debe entrar en el contact center
PCI SSC recuerda que PCI DSS aplica a todos los canales de aceptación de pago, incluido MOTO, y que los entornos que almacenan, procesan o transmiten datos de tarjeta deben aplicar medidas adecuadas para protegerlos. Su guía sobre pagos telefónicos se centra precisamente en cómo proteger datos de tarjeta en entornos de voz, grabaciones, agentes y tecnologías de contact center.
Este punto es esencial.
Cuando un contact center permite que un agente escuche, vea, introduzca o grabe datos de tarjeta, el perímetro de cumplimiento puede ampliarse de forma significativa. No es solo una cuestión técnica; es una cuestión operativa, contractual, reputacional y de auditoría.
La propuesta PCIaaS de Pay by Call se basa en aislar la captura del dato sensible en una plataforma especializada, de forma que el contact center pueda seguir atendiendo al usuario sin convertirse en el punto donde reside el riesgo de tarjeta.
Pay by Link y PBC 3DS no compiten: se complementan
La evolución correcta del mercado no consiste en sustituir el Pay by Link. Consiste en utilizar cada solución donde aporta más valor.
El Pay by Link es idóneo cuando el pago es asíncrono: enviar un presupuesto, cobrar una reserva, resolver un extra posterior, recuperar una operación fallida o permitir que el usuario pague más tarde.
PBC 3DS es idóneo cuando el pago nace en una llamada viva: el cliente está hablando con un agente, necesita acompañamiento, el importe es sensible, el usuario puede desconfiar de un enlace o la organización quiere evitar que el pago se enfríe al cambiar de canal.
La comparación correcta es esta:
| Escenario | Solución natural |
|---|---|
| Pago diferido | Pay by Link |
| Pago posterior a presupuesto | Pay by Link |
| Cliente digitalmente autónomo | Pay by Link |
| Cliente ya en llamada | PBC LAA + PBC 3DS |
| Usuario que necesita asistencia | PBC LAA + PBC 3DS |
| Pago sensible o de alto valor reputacional | PBC LAA + PBC 3DS |
| Contact center que quiere reducir exposición PCI DSS | PBC LAA / PBC TFA |
| Pago telefónico con autenticación reforzada | PBC 3DS |
El mensaje es claro:
Pay by Link para pagos asíncronos.
PBC 3DS para pagos telefónicos autenticados dentro de la llamada.
Una nueva categoría: Voice Commerce seguro
La voz está dejando de ser un canal residual.
La IA conversacional, los voicebots, los agentes virtuales y los contact centers inteligentes están convirtiendo la conversación en una interfaz transaccional. Pero esa evolución plantea una pregunta crítica:
¿cómo se ejecuta el pago de forma segura cuando la conversación llega al momento de pagar?
Un asistente puede informar.
Un agente puede acompañar.
Un PSP puede procesar.
Pero hace falta una capa especializada que capture el dato de tarjeta, preserve PCI DSS, orqueste 3D Secure y devuelva el resultado al flujo conversacional.
Esa capa es Pay by Call.
Y PBC 3DS es la pieza tecnológica que permite que el Voice Commerce no termine en un link, sino en una transacción segura dentro de la propia llamada.
La oportunidad: recuperar conversión donde hoy hay fricción
La oportunidad no es solo de cumplimiento. Es también de conversión.
Cuando un usuario está en una llamada y acepta pagar, existe una intención inmediata. Si el proceso se desvía a un link, parte de esa intención se puede perder. El pago se enfría, el agente pierde control y el usuario entra en un entorno que quizá no esperaba.
PBC 3DS permite mantener contexto, asistencia y confianza.
La forma más rigurosa de medir el impacto es mediante pilotos comparativos:
Grupo A: llamada con agente + envío de link.
Grupo B: llamada con agente + PBC LAA + PBC 3DS.
Métricas relevantes:
- pagos completados;
- tiempo hasta confirmación;
- abandonos antes de iniciar pago;
- abandonos durante autenticación;
- fallos 3DS;
- reintentos;
- llamadas repetidas;
- tasa OK/KO;
- satisfacción del usuario;
- carga operativa del agente;
- repudios o chargebacks.
La hipótesis es clara:
cuando el cliente ya está en llamada, mantenerlo dentro de la llamada debería mejorar la conversión frente a enviarlo a un enlace.
Conclusión
El Pay by Link ha sido una solución necesaria y útil para el pago remoto. Pero no debe ser la única respuesta para el pago MOTO.
El canal voz necesita una solución nativa.
Los datos externos apuntan en esa dirección:
Redsys documenta PayGold como un flujo por enlace y redirección. Baymard muestra que confianza y complejidad impactan directamente en abandono. INCIBE confirma que los usuarios tienen motivos crecientes para desconfiar de enlaces por SMS. Unnax documentó en España el coste de la fricción en redirecciones 3DS durante la implantación de PSD2. Ravelin muestra que 3DS sigue sin ser 100% frictionless. Stripe confirma que la clave está en la calidad de implementación del flujo de autenticación. EMVCo recuerda que 3DS debe autenticar sin añadir fricción innecesaria. PCI SSC confirma que PCI DSS aplica también a entornos telefónicos MOTO.
La evolución lógica es clara:
del MOTO manual inseguro al Pay by Link; y del Pay by Link al 3D Secure nativo en voz.
Esa es precisamente la propuesta de PBC 3DS, la innovación tecnológica de Pay by Call con solicitud de patente OEPM P202630243 y solicitud internacional PCT/ES2026/070099.
Una tecnología diseñada para resolver PSD2 / SCA / 3D Secure en el canal de voz, sin obligar al usuario a abandonar la llamada.
Porque cuando el cliente ya ha decidido pagar por teléfono, el mejor canal para cerrar el pago puede ser exactamente ese:
la propia llamada.
Si quieres más información contacta con Pay by Call pulsando aquí.