3DS2 en México NO es PSD2: guía de ingeniero para 3-D Secure sin las reglas de SCA europeas
3DS2 es el protocolo de autenticación de EMVCo (flujo frictionless o challenge). SCA es un mandato de PSD2 para el EEE y Reino Unido — México no está sujeto a él, y las exenciones europeas de bajo valor y TRA no existen en la ley mexicana, así que nunca las hardcodees. Igual usas 3DS2 en México por decisión de negocio: la responsabilidad del fraude se traslada al emisor. Actívalo desde tu PSP.
Respuesta directa: 3DS2 es un protocolo, SCA es una ley europea
3DS2 (3-D Secure 2) sí se usa en México, pero no por PSD2: PSD2/SCA es ley europea (EEE y Reino Unido) y México no está sujeto a ella. En México activas 3DS2 como decisión de negocio — traslada al banco emisor la responsabilidad del contracargo por fraude —, no para cumplir un mandato. 3DS2 es el protocolo de autenticación de tarjetas de EMVCo, con dos caminos: un flujo frictionless (sin fricción) y un flujo challenge (reto al usuario). Las exenciones europeas de bajo valor y de TRA no existen en la ley mexicana, así que nunca las hardcodees. Lo activas desde tu PSP.
Soy ingeniero y esto lo pongo en producción en checkouts mexicanos. No soy abogado ni vendo compliance. Esta es guía de ingeniería, no asesoría legal ni de cumplimiento de las reglas de las redes de tarjetas.
Qué es realmente 3DS2: flujo frictionless vs flujo challenge
3DS2 es el protocolo que le da al banco emisor datos de la transacción y del dispositivo para que decida si la operación es legítima. A partir de ahí, hay dos caminos.
En el flujo frictionless, el emisor evalúa el riesgo con los datos de contexto (dispositivo, historial, monto) y aprueba sin ninguna interacción del usuario. El comprador ni se entera. En el flujo challenge, el emisor pide un paso adicional de autenticación: un OTP por SMS, biometría, o aprobación desde la app del banco.
3DS2 es el método técnico principal que se usa para satisfacer SCA donde SCA es legalmente obligatorio. Ojo con esa condición: el protocolo y la obligación legal son dos capas distintas. Puedes correr 3DS2 sin que ninguna ley te obligue — que es exactamente el caso de México.
El error #1: SCA es un mandato de PSD2 para el EEE y el Reino Unido, no para México
Este es el malentendido que motiva todo este post. SCA es un mandato de la directiva PSD2 que aplica en el EEE y el Reino Unido — no en México.
Las fechas de entrada en vigor lo dejan claro: PSD2 SCA entró en vigor el 31 de diciembre de 2020 en el EEE, y el 14 de septiembre de 2021 en el Reino Unido. Son marcos regulatorios europeos.
México no está sujeto a PSD2 ni a SCA. No existe un mandato estatutario mexicano de SCA. Ningún regulador mexicano — ni Banxico ni la CNBV — te obliga a autenticar cada transacción con tarjeta como sí obliga la ley europea a los comercios del EEE. Si armaste tu checkout mexicano copiando lógica de “SCA obligatorio”, implementaste una regulación que no aplica en tu jurisdicción.
La trampa de las exenciones: los umbrales de 30 EUR y de TRA son solo del EEE
Aquí está la parte que rompe implementaciones. PSD2 no solo obliga a SCA — también define exenciones para no añadir fricción a cada pago. Y esas exenciones no existen en la ley mexicana.
Las dos que más se copian por error:
- La exención de bajo valor (low-value), alrededor de EUR 30.
- Los umbrales de análisis de riesgo de transacción (TRA), aproximadamente EUR 100 / 250 / 500, escalonados según la tasa de fraude del adquirente.
Estos números salen de la Regulatory Technical Standards de PSD2. Son europeos. No los hardcodees para México. Si tu código tiene algo así, está mal desde el diseño.
# ANTIPATRON: exenciones PSD2 copiadas a un checkout mexicano.
# Estos umbrales en EUR NO existen en la ley mexicana.
def requiere_sca(monto_eur, tasa_fraude_adquirente):
if monto_eur < 30: # exencion low-value del EEE
return False
if monto_eur < 100 and tasa_fraude_adquirente < 0.13: # TRA del EEE
return False
return TrueEn México no hay un “umbral de exención” legal que aplicar. Si decides cuándo disparar 3DS2, esa decisión es de negocio y de riesgo, no de cumplimiento normativo. Modelarla como si fuera una exención regulatoria europea es un bug conceptual que además te ata a montos en euros que nada tienen que ver con tu operación.
EEE + Reino Unido (PSD2/SCA)
- SCA obligatoria por ley
- Vigor: 31-dic-2020 (EEE), 14-sep-2021 (RU)
- Exención low-value approx. EUR 30
- Umbrales TRA approx. EUR 100 / 250 / 500
México
- Sin mandato estatutario de SCA
- Ningún regulador obliga a autenticar cada pago
- Sin exención low-value en la ley
- Sin umbrales TRA en la ley
Entonces, ¿para qué usar 3DS2 en México? El traslado de responsabilidad
Si no hay ley que te obligue, ¿por qué molestarte? Porque en México 3DS2 es una decisión de negocio, impulsada comercialmente por las redes de tarjetas (Visa, Mastercard) y por tu adquirente/PSP, no por un regulador. Y hay dos motivos concretos.
El primero, y el más importante, es el traslado de responsabilidad (liability shift). Cuando un pago con tarjeta se autentica con 3DS, la responsabilidad de un contracargo relacionado con fraude (una operación marcada como “no autorizada”/fraude) se traslada del comercio al emisor. Sin 3DS, ese contracargo por fraude lo comes tú. Con 3DS exitoso, lo carga el banco.
El segundo es la reducción de fraude en sí: meter al emisor en el bucle de autenticación filtra operaciones fraudulentas antes de que se completen.
Si el fraude con tarjeta te está pegando, esto se conecta directo con cómo peleas los contracargos. Ya escribí sobre eso para Conekta y Mercado Pago y para Stripe con Radar. 3DS2 es la palanca que decide quién carga con la pérdida cuando el contracargo es por fraude.
Cómo lo activas de verdad: tu PSP corre el flujo
No construyes 3DS tú. Tu PSP corre el flujo — Stripe, Conekta, Mercado Pago, Adyen. Tú decides cuándo dispararlo y luego lees el resultado de autenticación y de responsabilidad en el cargo resultante.
En Stripe, por ejemplo, esto se controla por PaymentIntent con el campo payment_method_options.card.request_three_d_secure, que acepta valores como automatic o any. Confirma los nombres exactos de los campos contra la documentación vigente de tu PSP — esto evoluciona.
import stripe
# Stripe: siempre solicitar 3DS para asegurar el traslado de responsabilidad.
intent = stripe.PaymentIntent.create(
amount=145000, # en centavos (MXN)
currency="mxn",
payment_method=payment_method_id,
confirm=True,
payment_method_options={
"card": {
# "any" fuerza el intento de 3DS; "automatic" deja decidir a Stripe.
"request_three_d_secure": "any",
}
},
)Después de confirmar, lees el resultado de autenticación en el cargo para saber si obtuviste el traslado de responsabilidad:
charge = stripe.Charge.retrieve(intent.latest_charge)
tds = charge.payment_method_details.card.three_d_secure or {}
# Ejemplo de campos a inspeccionar (verifica los nombres vigentes en tu PSP):
# tds.get("result") -> "authenticated", "attempt_acknowledged", ...
# charge... indicador de liability -> si el traslado aplica a este cargo
print(tds.get("result"))Si estás eligiendo PSP para México, ya comparé las pasarelas de pago en México y escribí una guía de cómo integrar Mercado Pago. Todas soportan 3DS2; lo que cambia son los nombres de los campos y los valores de configuración.
Cuándo dispararlo: siempre-por-el-traslado vs basado en riesgo
Aquí está la decisión de ingeniería real. Tienes dos estrategias, y ninguna es “cumplir la ley”.
Siempre-por-el-traslado: solicitas 3DS en cada operación (o al menos en las de mayor riesgo/valor) para quedarte siempre con el liability shift. Simple, defensivo, pero mete más fricción.
Basado en riesgo/reglas: disparas 3DS solo cuando tus señales de riesgo lo justifican. Menos fricción, pero cargas con la responsabilidad del fraude en las operaciones que dejaste pasar sin autenticar.
// Decision basada en riesgo (negocio, NO exencion regulatoria).
// Los umbrales aqui son TUYOS, en MXN, definidos por tu apetito de riesgo.
function solicitar3ds(orden: Orden): "any" | "automatic" {
const riesgoAlto =
orden.montoMxn >= 5000 ||
orden.emailNuevo ||
orden.binExtranjero ||
orden.mismatchDireccion;
// "any" fuerza 3DS para asegurar el traslado de responsabilidad.
// "automatic" deja que el PSP decida en operaciones de bajo riesgo.
return riesgoAlto ? "any" : "automatic";
}Nota crítica: esos umbrales en MXN son tuyos, definidos por tu apetito de riesgo — no son los EUR 30 / 100 / 250 / 500 de PSD2. Es exactamente el mismo shape de código que el antipatrón de arriba, pero con la semántica correcta: reglas de negocio, no exenciones legales.
El tradeoff: falsos rechazos y abandono de carrito vs cargar con el fraude
No existe la configuración gratis. Sobre-disparar el flujo challenge sube el abandono de carrito y los falsos rechazos: compradores legítimos que no completan el OTP, se frustran, o cuyo emisor rechaza el reto. Sub-disparar te deja cargando con la responsabilidad del fraude en las operaciones que dejaste pasar sin autenticar.
Se afina con reglas de riesgo, no con un mandato general. La palanca correcta es tu motor de reglas: subir 3DS donde las señales de fraude son fuertes, dejar frictionless donde el riesgo es bajo.
Nota sobre las cifras de uplift: son estimaciones de proveedores
Vas a ver números de “+X% de mejora en la tasa de autorización” al activar 3DS2. Trátalos con cuidado: son estimaciones de proveedores, no hechos específicos de México. Atribúyelos como lo que son y no los presentes como una cifra dura de tu operación mexicana.
La única forma de saber tu uplift real es medirlo en tu propio flujo: compara tasa de autorización, tasa de contracargos por fraude y abandono, con y sin 3DS, en tu volumen. Cualquier número que venga de un blog o de un pitch de ventas es un punto de partida para tu hipótesis, no tu resultado.
Antes de lanzar: confirma las reglas vigentes de la red y tu adquirente
Las reglas de las redes de tarjetas y los requisitos de los adquirentes evolucionan. Lo que hoy te da el traslado de responsabilidad puede cambiar de comportamiento o de campos en la siguiente actualización de tu PSP o de la red. Antes de lanzar, confirma con tu PSP/adquirente:
- Qué resultado de 3DS te otorga efectivamente el traslado de responsabilidad para operaciones mexicanas.
- Los nombres y valores vigentes de los campos de configuración (Stripe, Conekta, Mercado Pago cambian su API).
- Si tu adquirente tiene reglas propias sobre cuándo exigir challenge.
Recuerda el marco completo: esto es una decisión de negocio en México, no un tema fiscal ni regulatorio como las retenciones de plataformas del SAT o la Cuenta Nivel 2 Bis de Banxico, que sí son obligaciones legales reales. 3DS2 no lo es. Y para el panorama de pagos en la región, revisa el hub de pagos LATAM.
Última vez que lo digo, porque importa: soy ingeniero, no abogado ni vendedor de compliance. Esto es guía de ingeniería para poner 3DS2 en producción en México sin arrastrar las reglas de SCA europeas. Para el cumplimiento formal de las reglas de las redes de tarjetas, valida con tu PSP y tu adquirente.
Fuentes oficiales: