%20(1).png)
La doble autenticación es el momento en que un emisor confirma que quien está comprando es realmente su usuario. También es uno de los puntos que más definen si esa compra se completa o se abandona.
Durante años se resolvió de una sola manera: un código enviado por SMS. Hoy ese método muestra sus límites, tanto en seguridad como en conversión, y las marcas ya empezaron a exigir alternativas. Pomelo sumó la autenticación Out-of-Band (OOB) a su módulo de 3D Secure. A continuación, conoce todo sobre este método.
Out-of-Band significa "fuera de banda", es decir, fuera del canal en el que ocurre la transacción.Y ese canal puede ser la aplicación del emisor de la tarjeta, o bien una clave criptográfica vinculada al dispositivo del usuario —como una passkey— que el browser activa con biometría local.
En lugar de enviar un código para que el usuario lo copie en el sitio del comercio, ahora el emisor envía una notificación push a su propia app. El usuario la abre, revisa el detalle de la operación y la aprueba con biometría o PIN. El resultado viaja directamente del emisor a la red, sin pasar por el navegador.
El flujo arranca siempre con una notificación push. Lo que varía es el dispositivo desde el que se compra:
El código por SMS resolvió un problema real en su momento, pero su limitación es estructural: se puede compartir. Sobre esa posibilidad se construye buena parte del fraude actual, desde el SIM swap hasta los kits de phishing en tiempo real que capturan el código y lo utilizan en segundos.
Los números de los últimos años muestran la dirección. La FTC reportó que en 2024 los consumidores estadounidenses perdieron 470 millones de dólares por estafas iniciadas con un mensaje de texto, cinco veces más que en 2020. En Reino Unido, Cifas registró un aumento del 1.055% en los SIM swaps no autorizados durante 2024, con casi 3.000 casos, y señaló que el objetivo de esos ataques es interceptar los códigos de autenticación para tomar el control de las cuentas.
La respuesta regulatoria ya está en marcha. El NIST (National Institute of Standards and Technology) clasifica los OTP por SMS como un autenticador restringido dentro de su estándar de identidad digital, los bancos de Singapur los retiraron del login en 2024 y Emiratos Árabes Unidos los eliminó de todo el sistema bancario. En el caso de Mastercard, el 13 de octubre de 2026 el OTP deja de ser suficiente como método de autenticación para sus programas. OOB es hoy el camino disponible para resolver esa migración.
Pomelo sumó OOB como método de autenticación dentro de su módulo de 3D Secure, disponible para todos sus programas de tarjetas sin importar la marca con la que operen. En tarjetas emitidas con Mastercard, la migración de OTP a OOB será obligatoria a partir del 13 de octubre de 2026. La integración con Pomelo es vía webhooks y contempla:
Además, Pomelo se encarga de toda la infraestructura de 3DS: la comunicación con la marca, el manejo del protocolo, el liability shift y la orquestación del challenge. Del lado del emisor queda la experiencia dentro de su aplicación.
OOB en la forma descrita arriba asume que el emisor cuenta con una aplicación mobile y que sus usuarios la usan. Pero hay emisores —brokers, ALyCs, plataformas de inversión— cuyo tráfico principal es desktop y que no tienen una app propia instalada en el dispositivo del usuario.
Para esos casos, el camino no es OOB clásico, sino métodos como WebAuthn o Passkeys: el usuario registra una clave criptográfica en su dispositivo (laptop, PC) y en el momento del pago autentica con su biometría local, directamente desde el browser. No hay código que ingresar ni app que abrir. El resultado cumple con MFA según la especificación 2.3.1 de 3DS.
Lo que Mastercard exige es que los factores de autenticación sean independientes entre sí. Un código generado dentro de la misma sesión autenticada del usuario no cumple esa condición. WebAuthn y Passkeys sí.
Pomelo puede orientar a emisores en cualquiera de estos caminos según su arquitectura y base de usuarios.
Para un emisor que está evaluando implementar 3DS, adoptar OOB desde el inicio evita duplicar el trabajo, es decir, montar un flujo basado en OTP que deberá migrar poco después. Además, permite diseñar desde el primer día una experiencia de autenticación integrada a la app, en lugar de un proceso que ocurre por fuera de ella.
Para implementarlo, el emisor necesita:
La integración con Pomelo se realiza vía webhooks y el desarrollo del lado del emisor se concentra en esa pantalla de aprobación, que es también la que define la experiencia que verán sus usuarios en cada compra.
Entra en contacto con el equipo de Pomelo para implementarlo.
Es un método de autenticación en el que la verificación de identidad se resuelve fuera del canal donde ocurre la transacción. En lugar de ingresar un código en el sitio del comercio, que es la forma de verificación conocida como OTP, el usuario aprueba la operación desde la aplicación de su emisor con biometría o PIN.
Con OTP, el emisor envía un código que el usuario debe copiar en el checkout, lo que expone ese código a interceptación e ingeniería social. Con OOB, la validación ocurre dentro de la app del emisor y el resultado viaja directamente a la red: no hay ningún código que el usuario pueda compartir por error, por lo tanto mitiga las posibilidades de fraude.
En tarjetas emitidas con Mastercard, el OTP deja de ser suficiente como método de autenticación a partir del 13 de octubre de 2026.
Sí, ya que OOB admite un flujo de multiple devices. Si la compra ocurre en la computadora, la aprobación se resuelve con el celular mediante una notificación push. El usuario valida su identidad en la app y regresa a la computadora para finalizar la operación.
Para emisores cuyo tráfico es principalmente desktop y que no cuentan con una app mobile, Pomelo también puede implementar OOB mediante passkeys o WebAuthn: el usuario autentica directamente desde el browser con biometría del dispositivo (huella, Face ID, Windows Hello), sin ingresar códigos ni salir del checkout. El principio es el mismo: un factor criptográfico independiente del canal de la transacción.
Para implementar OOB con Pomelo, los emisores necesitan una aplicación con sesión autenticada, capacidad de enviar notificaciones push y el desarrollo de la pantalla de aprobación con biometría o PIN. La integración con Pomelo se realiza vía webhooks.
Sí. Está disponible dentro del módulo de 3DS de Pomelo para todos los programas, con independencia de la marca con la que operen.
Es un reemplazo completo del flujo, no una capa adicional sobre el código por SMS. El challenge basado en OTP se sustituye de punta a punta por un flujo OOB.
La doble autenticación es el momento en que un emisor confirma que quien está comprando es realmente su usuario. También es uno de los puntos que más definen si esa compra se completa o se abandona.
Durante años se resolvió de una sola manera: un código enviado por SMS. Hoy ese método muestra sus límites, tanto en seguridad como en conversión, y las marcas ya empezaron a exigir alternativas. Pomelo sumó la autenticación Out-of-Band (OOB) a su módulo de 3D Secure. A continuación, conoce todo sobre este método.
Out-of-Band significa "fuera de banda", es decir, fuera del canal en el que ocurre la transacción.Y ese canal puede ser la aplicación del emisor de la tarjeta, o bien una clave criptográfica vinculada al dispositivo del usuario —como una passkey— que el browser activa con biometría local.
En lugar de enviar un código para que el usuario lo copie en el sitio del comercio, ahora el emisor envía una notificación push a su propia app. El usuario la abre, revisa el detalle de la operación y la aprueba con biometría o PIN. El resultado viaja directamente del emisor a la red, sin pasar por el navegador.
El flujo arranca siempre con una notificación push. Lo que varía es el dispositivo desde el que se compra:
El código por SMS resolvió un problema real en su momento, pero su limitación es estructural: se puede compartir. Sobre esa posibilidad se construye buena parte del fraude actual, desde el SIM swap hasta los kits de phishing en tiempo real que capturan el código y lo utilizan en segundos.
Los números de los últimos años muestran la dirección. La FTC reportó que en 2024 los consumidores estadounidenses perdieron 470 millones de dólares por estafas iniciadas con un mensaje de texto, cinco veces más que en 2020. En Reino Unido, Cifas registró un aumento del 1.055% en los SIM swaps no autorizados durante 2024, con casi 3.000 casos, y señaló que el objetivo de esos ataques es interceptar los códigos de autenticación para tomar el control de las cuentas.
La respuesta regulatoria ya está en marcha. El NIST (National Institute of Standards and Technology) clasifica los OTP por SMS como un autenticador restringido dentro de su estándar de identidad digital, los bancos de Singapur los retiraron del login en 2024 y Emiratos Árabes Unidos los eliminó de todo el sistema bancario. En el caso de Mastercard, el 13 de octubre de 2026 el OTP deja de ser suficiente como método de autenticación para sus programas. OOB es hoy el camino disponible para resolver esa migración.
Pomelo sumó OOB como método de autenticación dentro de su módulo de 3D Secure, disponible para todos sus programas de tarjetas sin importar la marca con la que operen. En tarjetas emitidas con Mastercard, la migración de OTP a OOB será obligatoria a partir del 13 de octubre de 2026. La integración con Pomelo es vía webhooks y contempla:
Además, Pomelo se encarga de toda la infraestructura de 3DS: la comunicación con la marca, el manejo del protocolo, el liability shift y la orquestación del challenge. Del lado del emisor queda la experiencia dentro de su aplicación.
OOB en la forma descrita arriba asume que el emisor cuenta con una aplicación mobile y que sus usuarios la usan. Pero hay emisores —brokers, ALyCs, plataformas de inversión— cuyo tráfico principal es desktop y que no tienen una app propia instalada en el dispositivo del usuario.
Para esos casos, el camino no es OOB clásico, sino métodos como WebAuthn o Passkeys: el usuario registra una clave criptográfica en su dispositivo (laptop, PC) y en el momento del pago autentica con su biometría local, directamente desde el browser. No hay código que ingresar ni app que abrir. El resultado cumple con MFA según la especificación 2.3.1 de 3DS.
Lo que Mastercard exige es que los factores de autenticación sean independientes entre sí. Un código generado dentro de la misma sesión autenticada del usuario no cumple esa condición. WebAuthn y Passkeys sí.
Pomelo puede orientar a emisores en cualquiera de estos caminos según su arquitectura y base de usuarios.
Para un emisor que está evaluando implementar 3DS, adoptar OOB desde el inicio evita duplicar el trabajo, es decir, montar un flujo basado en OTP que deberá migrar poco después. Además, permite diseñar desde el primer día una experiencia de autenticación integrada a la app, en lugar de un proceso que ocurre por fuera de ella.
Para implementarlo, el emisor necesita:
La integración con Pomelo se realiza vía webhooks y el desarrollo del lado del emisor se concentra en esa pantalla de aprobación, que es también la que define la experiencia que verán sus usuarios en cada compra.
Entra en contacto con el equipo de Pomelo para implementarlo.
Es un método de autenticación en el que la verificación de identidad se resuelve fuera del canal donde ocurre la transacción. En lugar de ingresar un código en el sitio del comercio, que es la forma de verificación conocida como OTP, el usuario aprueba la operación desde la aplicación de su emisor con biometría o PIN.
Con OTP, el emisor envía un código que el usuario debe copiar en el checkout, lo que expone ese código a interceptación e ingeniería social. Con OOB, la validación ocurre dentro de la app del emisor y el resultado viaja directamente a la red: no hay ningún código que el usuario pueda compartir por error, por lo tanto mitiga las posibilidades de fraude.
En tarjetas emitidas con Mastercard, el OTP deja de ser suficiente como método de autenticación a partir del 13 de octubre de 2026.
Sí, ya que OOB admite un flujo de multiple devices. Si la compra ocurre en la computadora, la aprobación se resuelve con el celular mediante una notificación push. El usuario valida su identidad en la app y regresa a la computadora para finalizar la operación.
Para emisores cuyo tráfico es principalmente desktop y que no cuentan con una app mobile, Pomelo también puede implementar OOB mediante passkeys o WebAuthn: el usuario autentica directamente desde el browser con biometría del dispositivo (huella, Face ID, Windows Hello), sin ingresar códigos ni salir del checkout. El principio es el mismo: un factor criptográfico independiente del canal de la transacción.
Para implementar OOB con Pomelo, los emisores necesitan una aplicación con sesión autenticada, capacidad de enviar notificaciones push y el desarrollo de la pantalla de aprobación con biometría o PIN. La integración con Pomelo se realiza vía webhooks.
Sí. Está disponible dentro del módulo de 3DS de Pomelo para todos los programas, con independencia de la marca con la que operen.
Es un reemplazo completo del flujo, no una capa adicional sobre el código por SMS. El challenge basado en OTP se sustituye de punta a punta por un flujo OOB.
La doble autenticación es el momento en que un emisor confirma que quien está comprando es realmente su usuario. También es uno de los puntos que más definen si esa compra se completa o se abandona.
Durante años se resolvió de una sola manera: un código enviado por SMS. Hoy ese método muestra sus límites, tanto en seguridad como en conversión, y las marcas ya empezaron a exigir alternativas. Pomelo sumó la autenticación Out-of-Band (OOB) a su módulo de 3D Secure. A continuación, conoce todo sobre este método.
Out-of-Band significa "fuera de banda", es decir, fuera del canal en el que ocurre la transacción.Y ese canal puede ser la aplicación del emisor de la tarjeta, o bien una clave criptográfica vinculada al dispositivo del usuario —como una passkey— que el browser activa con biometría local.
En lugar de enviar un código para que el usuario lo copie en el sitio del comercio, ahora el emisor envía una notificación push a su propia app. El usuario la abre, revisa el detalle de la operación y la aprueba con biometría o PIN. El resultado viaja directamente del emisor a la red, sin pasar por el navegador.
El flujo arranca siempre con una notificación push. Lo que varía es el dispositivo desde el que se compra:
El código por SMS resolvió un problema real en su momento, pero su limitación es estructural: se puede compartir. Sobre esa posibilidad se construye buena parte del fraude actual, desde el SIM swap hasta los kits de phishing en tiempo real que capturan el código y lo utilizan en segundos.
Los números de los últimos años muestran la dirección. La FTC reportó que en 2024 los consumidores estadounidenses perdieron 470 millones de dólares por estafas iniciadas con un mensaje de texto, cinco veces más que en 2020. En Reino Unido, Cifas registró un aumento del 1.055% en los SIM swaps no autorizados durante 2024, con casi 3.000 casos, y señaló que el objetivo de esos ataques es interceptar los códigos de autenticación para tomar el control de las cuentas.
La respuesta regulatoria ya está en marcha. El NIST (National Institute of Standards and Technology) clasifica los OTP por SMS como un autenticador restringido dentro de su estándar de identidad digital, los bancos de Singapur los retiraron del login en 2024 y Emiratos Árabes Unidos los eliminó de todo el sistema bancario. En el caso de Mastercard, el 13 de octubre de 2026 el OTP deja de ser suficiente como método de autenticación para sus programas. OOB es hoy el camino disponible para resolver esa migración.
Pomelo sumó OOB como método de autenticación dentro de su módulo de 3D Secure, disponible para todos sus programas de tarjetas sin importar la marca con la que operen. En tarjetas emitidas con Mastercard, la migración de OTP a OOB será obligatoria a partir del 13 de octubre de 2026. La integración con Pomelo es vía webhooks y contempla:
Además, Pomelo se encarga de toda la infraestructura de 3DS: la comunicación con la marca, el manejo del protocolo, el liability shift y la orquestación del challenge. Del lado del emisor queda la experiencia dentro de su aplicación.
OOB en la forma descrita arriba asume que el emisor cuenta con una aplicación mobile y que sus usuarios la usan. Pero hay emisores —brokers, ALyCs, plataformas de inversión— cuyo tráfico principal es desktop y que no tienen una app propia instalada en el dispositivo del usuario.
Para esos casos, el camino no es OOB clásico, sino métodos como WebAuthn o Passkeys: el usuario registra una clave criptográfica en su dispositivo (laptop, PC) y en el momento del pago autentica con su biometría local, directamente desde el browser. No hay código que ingresar ni app que abrir. El resultado cumple con MFA según la especificación 2.3.1 de 3DS.
Lo que Mastercard exige es que los factores de autenticación sean independientes entre sí. Un código generado dentro de la misma sesión autenticada del usuario no cumple esa condición. WebAuthn y Passkeys sí.
Pomelo puede orientar a emisores en cualquiera de estos caminos según su arquitectura y base de usuarios.
Para un emisor que está evaluando implementar 3DS, adoptar OOB desde el inicio evita duplicar el trabajo, es decir, montar un flujo basado en OTP que deberá migrar poco después. Además, permite diseñar desde el primer día una experiencia de autenticación integrada a la app, en lugar de un proceso que ocurre por fuera de ella.
Para implementarlo, el emisor necesita:
La integración con Pomelo se realiza vía webhooks y el desarrollo del lado del emisor se concentra en esa pantalla de aprobación, que es también la que define la experiencia que verán sus usuarios en cada compra.
Entra en contacto con el equipo de Pomelo para implementarlo.
Es un método de autenticación en el que la verificación de identidad se resuelve fuera del canal donde ocurre la transacción. En lugar de ingresar un código en el sitio del comercio, que es la forma de verificación conocida como OTP, el usuario aprueba la operación desde la aplicación de su emisor con biometría o PIN.
Con OTP, el emisor envía un código que el usuario debe copiar en el checkout, lo que expone ese código a interceptación e ingeniería social. Con OOB, la validación ocurre dentro de la app del emisor y el resultado viaja directamente a la red: no hay ningún código que el usuario pueda compartir por error, por lo tanto mitiga las posibilidades de fraude.
En tarjetas emitidas con Mastercard, el OTP deja de ser suficiente como método de autenticación a partir del 13 de octubre de 2026.
Sí, ya que OOB admite un flujo de multiple devices. Si la compra ocurre en la computadora, la aprobación se resuelve con el celular mediante una notificación push. El usuario valida su identidad en la app y regresa a la computadora para finalizar la operación.
Para emisores cuyo tráfico es principalmente desktop y que no cuentan con una app mobile, Pomelo también puede implementar OOB mediante passkeys o WebAuthn: el usuario autentica directamente desde el browser con biometría del dispositivo (huella, Face ID, Windows Hello), sin ingresar códigos ni salir del checkout. El principio es el mismo: un factor criptográfico independiente del canal de la transacción.
Para implementar OOB con Pomelo, los emisores necesitan una aplicación con sesión autenticada, capacidad de enviar notificaciones push y el desarrollo de la pantalla de aprobación con biometría o PIN. La integración con Pomelo se realiza vía webhooks.
Sí. Está disponible dentro del módulo de 3DS de Pomelo para todos los programas, con independencia de la marca con la que operen.
Es un reemplazo completo del flujo, no una capa adicional sobre el código por SMS. El challenge basado en OTP se sustituye de punta a punta por un flujo OOB.
🤩 Forma parte del único programa de entrenamiento en Neobanking de Latam. Más información aquí
.png)
