PSD2 y 3DSv2

¿Qué es PSD2?

PSD2 es la segunda directiva que regula los servicios de pago a través de internet en la Unión Europea y Reino Unido. Entró en vigor el 14 de noviembre de 2020. Sus objetivos son:

Aumentar la seguridad de los pagos por internet en Europa.
Promover la innovación.
Favorecer la adaptación de los servicios bancarios a las nuevas tecnologías.

Con esta nueva normativa, la operativa no segura no está permitida para tarjetas emitidas dentro del Espacio Económico Europeo (EEE). Por tanto, las operaciones por comercios no seguros (sin autenticación) con tarjetas europeas serán rechazadas.

Ventajas de la normativa PSD2

Las 2 ventajas principales de esta normativa son:

Transacciones más seguras con un menor riesgo de fraude. Esto es posible gracias al sistema de doble autenticación o autenticación reforzada.
Mayor confianza de los clientes en los pagos en línea. Esto permite al sector del comercio electrónico crecer y generar una oferta más variada y de mayor calidad para sus consumidores.

Funcionamiento de la autenticación reforzada (SCA) en PSD2

La autenticación reforzada del cliente (SCA) busca mantener un equilibrio entre comodidad y seguridad. Para ello, se deben aplicar al menos dos (2) de estos elementos:

Algo que sólo conoce el cliente, como un PIN o una contraseña.
Alguna cosa que sólo posee el cliente, como su teléfono inteligente a través del que puede recibir una clave de único uso.
Algo que pertenece al cliente, como alguna parte de su cuerpo que pueda usarse como medida de seguridad biométrica (huella dactilar, iris, reconocimiento facial, etc).

Operaciones que requieren autenticación reforzada (SCA)

La autenticación reforzada busca comprobar la identidad del cliente y evitar el fraude. Será obligatoria si:

Compras en un comercio electrónico que se encuentre en la Unión Europea.
Introduces los datos de la tarjeta bancaria en un comercio para realizar futuros pagos online (aunque no hagas una compra en ese momento).

EMVCo y 3DSecure v.2

Con motivo de la implantación de la normativa PSD2 y de la SCA, EMVCo desarrolló una versión actualizada de su estándar de autenticación de transacciones con tarjetas (3DSecure). Este se conoce como 3DSecure v.2 (3DSv2 en adelante). Ofrece las siguientes ventajas:

Fin de las contraseñas estáticas: Los clientes ya no tendrán que recordar sus contraseñas, lo que hace más cómodo el proceso de pago.
Autenticación de dos factores: 3DSv2 implementa la autenticación de dos factores. Para que la experiencia sea más cómoda para los clientes, la autenticación puede realizarse mediante una huella dactilar y el lector biométrico del teléfono, por ejemplo.
Menos falsos rechazos: El nuevo protocolo proporciona diez veces más información a los emisores, lo que ayuda a reducir drásticamente el número de falsos rechazos.
Mayor compatibilidad con dispositivos móviles: Los clientes ya no serán redirigidos a páginas de autorización potencialmente no preparadas para dispositivos móviles.
Menor abandono de carritos: Un proceso de pago más rápido y una experiencia de compra fluida reducen el abandono del carrito en un 70%.
Exclusión voluntaria del comercio: Como comercio puedes elegir qué transacciones se gestionan a través de 3DSv2 y cuáles no. Sin embargo, ten en cuenta que es posible que los emisores rechacen las transacciones no autenticadas porque requieran SCA por su parte.
Protege al comercio de la responsabilidad en caso de fraude. Esto también ocurre con 3DSv1.

Autenticación frictionless y challenge – 3DSv2

Con 3DSecure v.2 se introducen dos modelos de autenticación del cliente:

Autenticación frictionless. El emisor valora que la transacción es de bajo riesgo de fraude y realiza la autorización de la misma sin necesidad de SCA del cliente.
Autenticación challenge. El emisor valora que la transacción es de riesgo medio/alto de fraude y requiere la redirección del cliente a una URL de ACS para realizar la SCA como requisito para la autorización.

Autenticación y autorización por frictionless

Introducción de datos de tarjeta.
Redirección al banco emisor para autenticación.
Redirección del cliente a tu plataforma de comercio electrónico con el resultado de la autenticación/autorización.

Autenticación y autorización por challenge

Introducción de datos de tarjeta.
Redirección al challenge del banco emisor para autenticación.
Redirección del cliente a tu plataforma de comercio electrónico con el resultado de la autenticación/autorización.

Estado de la autenticación 3DS2

Usando 3DS2, la autenticación se utiliza para reducir el fraude en las transacciones con tarjeta. El estado de esta autenticación se indica en el campo «eci» de la notificación. Según ese estado, la responsabilidad financiera de una transacción puede recaer del lado del emisor de la tarjeta o del comercio.

Existen algunas diferencias en función de la marca de tarjeta, consulta la tabla inferior para conocer el detalle. Para conocer más sobre las notificaciones visita la documentación de Gestión de notificaciones.

Son muchos los factores que afectan a que se produzca un cambio de responsabilidad de 3D Secure, en caso de duda consulta con soporte o con tu gestor para adecuar la transaccionalidad de tu comercio.

Tarjeta	Estado de 3DSv2	Descripción	ECI	CAVV	Responsabilidad	Acción recomendada
Visa, Amex, JCB	Y	Autenticado	05	Sí	Emisor	Solicitar autorización
Visa, Amex, JCB	A	Intento de autenticación	06	Sí	Emisor	Solicitar autorización
Visa, Amex, JCB	N	No autenticado	07	No	Comercio	No solicitar autorización
Visa, Amex, JCB	U	Autenticación no disponible
Visa, Amex, JCB	R	Autenticación rechazada
MasterCard	Y	Autenticado	02	Sí	Emisor	Solicitar autorización
MasterCard	A	Intento de autenticación	01	Sí	Emisor	Solicitar autorización
MasterCard	N	No autenticado	00	No	Comercio	No solicitar autorización
MasterCard	U	Autenticación no disponible
MasterCard	R	Autenticación rechazada

Parámetros introducidos en 3DSecure v.2

EMVCo ha introducido distintos parámetros en 3DSecure v.2 para que se pueda valorar más eficientenemente el riesgo de fraude en las transacciones con tarjeta. De esta forma se intenta recoger toda la información posible sobre el perfil y la actividad del cliente en la plataforma del comercio.

Información del navegador web del cliente

Es requerido sólo para integraciones que no delegan este paso a AP. Para obtener algunos de los datos del navegador indicados más adelante, puedes utilizar el siguiente código JavaScript:

				
					function datos_navegador() {function datos_navegador() {
document.getElementById("agente_navegador").value = navigator.userAgent;
document.getElementById("idioma_navegador").value = navigator.language;
document.getElementById("altura_pantalla").value = screen.height;
document.getElementById("anchura_pantalla").value = screen.width;
document.getElementById("profundidad_color").value = screen.colorDepth;
var d = new Date();
document.getElementById("diferencia_horaria").value = d.getTimezoneOffset();
}

Información del navegador web del cliente

Parámetro	Descripción	Formato y valores admitidos
acceptHeader	Cabecera de pedido HTTP “Accept” del navegador del cliente. Se recomienda altamente su envío para evitar rechazo del servidor ACS del emisor.	Alfanumérico, máximo 2048 caracteres.
browserIp	Dirección IP del navegador del cliente.	Alfanumérico, máximo 45 caracteres. Formato: IPv4 o IPv6.
browserLanguage	Idioma del navegador del cliente, según el código IETF-BCP47. Se puede obtener de la propiedad “navigator.language”.	Alfanumérico, máximo 8 caracteres.
challengeWindowSize	Tamaño de la ventana que se muestra al cliente durante la autenticación (challenge). El ACS debe mostrar contenido adaptado al tamaño de la ventana. Los tamaños indicados son ancho x alto en píxeles.	01: 250×400 02: 390×400 03: 500×600 04: 600×400 05: Pantalla completa (por defecto).
javaEnabled	Indica si el navegador del cliente tiene Java habilitado. Es obligatorio si “jsEnabled” es verdadero. Se puede obtener mediante la función “navigator.javaEnabled()”.	Booleano
jsEnabled	Indica si el navegador del cliente tiene JavaScript habilitado.	Booleano
screenColorDepth	Profundidad de color en la pantalla del cliente. Es obligatorio si jsEnabled es verdadero. Se puede obtener de la propiedad “screen.colorDepth”.	Numérico entero 1, 4, 8, 15, 16, 24, 30, 32 y 48.
screenHeight	Altura total en píxeles de la pantalla del cliente. Es obligatorio si “jsEnabled” es verdadero. Se puede obtener de la propiedad “screen.height”.	Numérico entero.
screenWidth	Anchura total en píxeles de la pantalla del cliente. Es obligatorio si “jsEnabled” es verdadero. Se puede obtener de la propiedad “screen.width”.	Numérico entero.
tzOffset	Diferencia horaria en minutos entre UTC y la hora local del navegador del cliente. Positiva si la hora local va por detrás de UTC. Negativa si va por delante. Es obligatorio si “jsEnabled” es verdadero. Se puede obtener mediante la función «»getTimezoneOffset()»».	Entero
userAgent	Agente de usuario del navegador del cliente. Facilita la información sobre el navegador utilizado. Se recomienda altamente su envío para evitar rechazo del servidor ACS del emisor. Se puede obtener de la propiedad “navigator.userAgent”.	Alfanumérico, máximo 256 caracteres.

Parámetros para obtener otra información

A continuación, te dejamos los parámetros para obtener el resto de información de los clientes:

Información de la cuenta del cliente

Parámetro	Descripción	Formato y valores admitidos
accountAge	Antigüedad de la cuenta del cliente en tu plataforma de comercio electrónico.	Numérico, los valores aceptados son: 01: No tiene cuenta (invitado). 02: Creada hoy. 03: Creada hace menos de 30 días. 04: Creada entre 30 y 60 días. 05: Creada hace más de 60 días.
accountChangeDate	Fecha de la última vez que el cliente hizo cambios en su cuenta, como modificaciones en la dirección de envío o facturación, tarjeta, correo electrónico, etc. No se debe enviar este campo si el cliente usa cuenta de invitado.	Alfanumérico. Formato AAAA-MM-DD.
accountChangeInd	Tiempo transcurrido desde que el cliente realizó cambios en su cuenta. No se debe enviar este campo si el cliente usa cuenta de invitado.	Numérico. Los valores aceptados son: 01: Hoy. 02: menos de 30 días. 03: entre 30 y 60 días. 04: más de 60 días.
accountCreationDate	Fecha en la que el cliente creó su cuenta en tu plataforma de comercio electrónico. No se debe enviar este campo si el cliente usa cuenta de invitado.	Alfanumérico. Formato AAAA-MM-DD.
passwordChangeDate	Fecha del último cambio de la contraseña de la cuenta del cliente. No enviar este campo si el cliente usa cuenta de invitado.	Alfanumérico. Formato AAAA-MM-DD.
passwordChangeInd	Tiempo transcurrido desde el último cambio de la contraseña de la cuenta del cliente.	Numérico. Los valores aceptados son: 01: No tiene cuenta (invitado). 02: Creada hoy. 03: Creada hace menos de 30 días. 04: Creada entre 30 y 60 días. 05: Creada hace más de 60 días.
paymentAccountAge	Fecha en la que el cliente registró la cuenta de pagos (tarjeta) en su cuenta en tu plataforma. No enviar este campo si el cliente usa cuenta de invitado.	Numérico. Formato AAAA-MM-DD.
paymentAccountInd	Tiempo transcurrido desde que el cliente registró la cuenta de pagos (tarjeta) en su cuenta en tu plataforma.	Los valores aceptados son: 01: No tiene cuenta (invitado). 02: Durante la transacción. 03: Menos de 30 días. 04: Entre 30 y 60 días. 05: Más de 60 días.
provisioningAttemptsDay	Cantidad de tarjetas que el cliente ha intentado añadir en su cuenta de tu plataforma para pagos en las últimas 24 horas. No enviar este campo si el cliente usa cuenta de invitado.	Numérico. Máximo 999.
purchasesLast6Months	Cantidad de pagos autorizados que el cliente ha realizado en tu plataforma en los últimos seis (6) meses. No enviar este campo si el cliente usa cuenta de invitado.	Numérico. Máximo 999.
shippingAddressUsage	Fecha en la que el cliente introdujo su actual dirección de envío en tu plataforma. No se debe enviar este campo si el cliente usa cuenta de invitado.	Alfanumérico. Formato AAAA-MM-DD.
shippingAddressUsageInd	Tiempo transcurrido desde la introducción de la dirección de envío en tu plataforma.	Los valores aceptados son: 01: Hoy. 02: Menos de 30 días. 03: Entre 30 y 60 días. 04: Más de 60 días.
shippingNameInd	Indica si el nombre del titular de la tarjeta es el mismo que el nombre que figura en la dirección de envío.	Booleano. Los valores aceptados son: true: El nombre del titular es el mismo que el de la dirección de envío. false: El nombre del titular no es el mismo que el de la dirección de envío.
suspiciousAccountActivityInd	Debe indicar si tu plataforma ha detectado actividad sospechosa del cliente.	Booleano. Los valores aceptados son: true: Se ha detectado actividad sospechosa. false: No se ha detectado actividad sospechosa.
txnActivityDay	Número de transacciones (autorizadas, denegadas o canceladas) que el cliente ha realizado en las últimas 24 horas en tu plataforma. No enviar este campo si el cliente usa cuenta de invitado. No cuentan las transacciones indicadas por tu plataforma de forma automática.	Numérico. Máximo 999.
txnActivityYear	Número de transacciones (exitosas, fallidas o canceladas) que el cliente ha realizado en el último año en tu plataforma. No enviar este campo si el cliente usa cuenta de invitado. No cuentan las transacciones indicadas por tu plataforma de forma automática.	Numérico. Máximo 999.

Información de la dirección de envío

Parámetro	Descripción	Formato y valores admitidos
deliveryEmail	En productos virtuales, indica la dirección de correo electrónico a la que se le va a enviar.	Alfanumérico. Máximo 254 caracteres.
deliveryTimeframe	Plazo de entrega del pedido comprado por el cliente.	Numérico entero. Los valores aceptados son: 01: Entrega electrónica. 02: Entrega en el mismo día. 03: Entrega al día siguiente. 04: Entrega de dos (2) días o más.
shippingAddress1	Primera línea de la dirección de envío. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información.	Alfanumérico. Máximo 50 caracteres.
shippingAddress2	Segunda línea de la dirección de envío. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información.	Alfanumérico. Máximo 50 caracteres.
shippingAddressMatch	Indica si la dirección de envío y la dirección de facturación coinciden.	Booleano. Los valores aceptados son: true: La dirección de envío y de facturación coinciden. false: La dirección de envío y de facturación no coinciden.
shippingCity	Ciudad de la dirección de envío. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información.	Alfanumérico. Máximo 50 caracteres.
shippingCountry	País de la dirección de envío. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información.	Código ISO 3166-1 alfa-2 (ES, US, UK, etc.).
shippingMethodInd	Método de envío elegido por el cliente. Se debe indicar que describa con mayor precisión el método de envío elegido para la transacción, no la actividad del comercio en general. Si se incluyen productos físicos y digitales, indica el código de envío para los productos físicos. Si todos los productos son digitales, indica el código de envío del artículo más caro.	Los valores aceptados son: 01: Envío a la dirección principal de la cuenta del cliente. 02: Envío a otra dirección almacenada en la cuenta del cliente. 03: Envío a una dirección diferente a la almacenada en la cuenta del cliente. 04: Entrega en comercio / envío a punto de recogida. 05: Mercancía digital (incluye servicios electrónicos, tarjetas/códigos regalo, etc.). 06: Entradas a eventos o billetes de viaje electrónicos. 07: Otros (por ejemplo, videojuegos, suscripciones electrónicas, etc.).
shippingPhone	Teléfono del cliente en el envío.	Alfanumérico.
shippingState	Provincia o estado de la dirección de envío del cliente. Es sólo la parte correspondiente a la provincia o estado, no la parte del país. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información. No es requerido si el concepto de provincia o estado no aplica en el país.	Código ISO 3166-2. Máximo dos (2) caracteres
shippingZipCode	Código postal de la dirección de envío. Es recomendable su envío aunque sea la misma que la dirección de facturación. Es obligatorio (siempre que esté disponible) salvo que restricciones, leyes regionales o del sector prohíban mandar esta información.	Alfanumérico. Máximo 16 caracteres.

Información de la transacción

Parámetro	Descripción	Formato y valores admitidos
challengeInd	Indica la preferencia marcada por el comercio ante un proceso de autenticación. El emisor puede modificar la preferencia especificada en este campo.	Numérico. Los valores aceptados son: 01: Sin preferencia. (valor por defecto si no se envía este parámetro) 02: Evitar challenge. 03: Requerir challenge (preferencia del comercio). 04: Requerir challenge (obligatorio). 05: Evitar challenge (realizado análisis de riesgo de transacción). 06: Evitar challenge (sólo en compartir datos). 07: Evitar challenge (SCA ya realizada). 08: Evitar challenge (utiliza exención de lista blanca). 09: Evitar challenge (solicitar lista blanca).

Información de riesgo

Parámetro	Descripción	Formato y valores admitidos
gift	Indica si el producto comprado es una tarjeta de regalo o prepago.	Booleano. Los valores aceptados son: true: En el pedido hay tarjetas regalo o prepago. false: En el pedido no hay tarjetas regalo o prepago.
giftCardAmount	Importe total del pedido en tarjetas regalo o prepago.	Número decimal.
giftCardCount	Número de tarjetas regalo o prepago del pedido.	Numérico. Máximo 99.
giftCardCurrency	Divisa de las tarjetas regalo o prepago del pedido. En caso de haber más de una divisa, indicar la de mayor importe.	Código ISO-4217.3 (EUR, USD, GBP, etc.).
preOrderDate	Fecha prevista para el envío de productos reservados.	Numérico. Máximo ocho (8) dígitos. Formato AAAA-MM-DD.
preOrderPurchaseInd	Indica si el producto está disponible o lo estará en el futuro.	Alfanumérico. Los valores aceptados son: true: Producto disponible. false: Producto no disponible todavía.
reorderItems	Indica si el cliente ya había comprado previamente el artículo.	Alfanumérico. Los valores aceptados son: 01: Artículo comprado por primera vez por el cliente. 02: Artículo comprado previamente por el cliente.
traActionInd	Indica la preferencia del comercio respecto al tipo de autenticación que va a solicitar al emisor para una transacción. El valor enviado al emisor dependerá de si tu comercio dispone de ASC activado y de las características de la transacción. El emisor es el que decide en última instancia el tipo de autenticación que aplicará.	Valores: forceChallenge: Forzar autenticación fuerte del cliente frictionless: Auteticación frictionless traExemption: Exención de autenticación por análisis TRA lowValueExemption: Exención de autenticación por bajo importe

Información de la autenticación del cliente en tu plataforma

Parámetro	Descripción	Formato y valores admitidos
authMethod	Mecanismo utilizado por el cliente para autenticarse en tu plataforma.	Numérico. Los valores aceptados son: 01: Cliente sin autenticar (invitado). 02: Credenciales propias de tu plataforma de comercio electrónico. 03: ID federado. 04: Credenciales del emisor. 05: Autenticación de terceros. 06: Autenticador FIDO. 07: Datos de seguridad FIDO firmados. 08: Datos de garantía del CSR.
authTimestamp	Fecha y hora de la autenticación del cliente en tu plataforma de comercio electrónico.	Numérico. Formato YYYYMMDDHHmm.

Exenciones

Parámetro	Descripción	Formato y valores admitidos
merchantExemptionsSca	Exenciones de SCA solicitadas por tu plataforma de comercio electrónico. Se pueden indicar más de una separándolas por coma. El orden en el que se identifiquen define su prioridad.	Los valores aceptados son: LWV: Exención por bajo importe. TRA: Exención por análisis de riesgo realizado. COR: Exención por pago corporativo. MIT: Exención por transacción iniciada por el comercio.

Información para operativa 3RI

Parámetro	Descripción	Formato y valores admitidos
priorACSTransIDRef	Identificador del ACS para la autenticación inicial.	Alfanumérico. Máximo 36 caracteres.
priorAuthData	Datos de la autenticación inicial recibidos desde el ACS.	Alfanumérico. Máximo 2048 caracteres.
priorAuthMethod	Método de autenticación usado por el ACS en la autenticación inicial.	Numérico. Los valores aceptados son: 01: Frictionless. 02: Challenge. 03: Validación AVS. 04: Otro método del emisor.
PriorAuthTimestamp	Fecha y hora de la autenticación inicial.	Numérico entero. Formato YYYYMMDDHHmm.
threeDS3RI	Indica el tipo de solicitud 3RI. Proporciona información adicional al ACS para gestionar una solicitud 3RI.	Numérico. Los valores aceptados son: 01: Transacción recurrente. 02: Transacción a plazos. 03: Añadir tarjeta. 04: Actualizar información de tarjeta. 05: Verificación de cuenta. 06: Envío aplazado o dividido. 07: Recarga. 08: Pedido por correo. 09: Pedido por teléfono. 10: Verificar estado lista blanca (whitelist). 11: Otros pagos.
threeDSDecoupleConfirmationInd	Pide al ACS que utilice la autenticación desacoplada y acepta utilizarla si el ACS confirma su uso.	Alfabético. Máximo un (1) caracter. Los valores aceptados son: Y: Se solicita usar autenticación desacoplada. N: Se solicita no usar autenticación desacoplada.
threeDSDecoupleMaxTimeout	Tiempo máximo en minutos que tu plataforma de comercio electrónico esperará a que el ACS devuelva el resultado de una autenticación desacoplada. Obligatorio si “threeDSDecoupleConfirmationInd = Y”	Numérico. Máximo 10080 minutos.
threeDSDeviceChannel	Canal por el que va a autenticarse la transacción.	Numérico. Los valores aceptados son: 1: App. 2: Navegador web. 3: 2DS iniciado por comercio (3RI).
threeDSServerTransId	Identificador UUID de la transacción en el servidor 3DS. Es obligatorio si “threeDSDeviceChannel = 2”.	Alfanumérico. Formato UUID.

Exenciones y servicio Addon Sales Conversion (ASC)

Exenciones

La normativa PSD2 contempla ciertos casos donde las transacciones quedan fuera de la norma. Son exenciones de la autenticación con 3DSecure siempre y cuando cumplan ciertos requisitos, como: importe inferior a un máximo o haber pasado por un análisis de riesgo. El banco emisor debe aceptar aplicar la exención en la transacción.

Si quieres hacer uso de una exención, la petición de autorización de la transacción deberá incluir el parámetro “merchantExemptionsSca”. Los valores admitidos son los siguientes:

MIT (Merchant Initiated Transaction): Transacción iniciada por el comercio.
LWV (Low Value):Transacción de bajo importe.
TRA (Transaction Risk Analysis): Transacción evaluada como bajo riesgo por un servicio de análisis de riesgo.
COR: Pagos corporativos entre empresas

Un ejemplo sería:

[merchantExemptionsSca] => MIT

Addon Sales Conversion

Addon Sales Conversion (en adelante ASC) es el servicio de Comercia Global Payments (CGP) que te permite mejorar la experiencia de pago en tu comercio electrónico reduciendo el número de veces que se solicita autenticación, sin dejar de lado la seguridad de tu negocio.

El servicio está basado en las exenciones de SCA que permite la normativa PSD2. Las transacciones susceptibles de exención se analizan para determinar el riesgo de la transacción. En caso de resultar de bajo riesgo, se solicita al emisor no autenticar la transacción. El emisor tendrá la última decisión sobre si aplicar o no las exenciones recibidas, por lo que este podrá finalmente solicitar autenticar como requisito para la autorización de la transacción.

Tipos de transacciones que pueden prescindir de SCA

La normativa PSD2 permite solicitar la opción de no autenticar en los siguientes casos:

LWV (Low Value): Transacciones de bajo importe (hasta 30€ por transacción, con un máximo de 5 transacciones consecutivas o 100€ acumulados sin autenticación).
- Transacciones exencionables mediante ASC.
TRA (Transaction Risk Analysis): Transacciones analizadas por la entidad y evaluadas como bajo riesgo hasta un importe máximo definido por la entidad.
- Transacciones exencionables mediante ASC.

COR: Transacciones corporativas entre empresas con métodos de pago no accesibles fuera del entorno empresarial ni para consumidores finales.

DAU (Autenticación Delegada): La autenticación delegada es un programa específico de las marcas, previsto en futuras versiones del protocolo.

Las siguientes operativas no están sujetas al cumplimiento de la PSD2:

M.I.T. (Merchant Initiated Transaction): Transacciones enviadas por el comercio sin intervención del titular de la tarjeta, mediante el envío de datos de tarjeta o token generado previamente.
- La operativa M.I.T. requiere activación por parte de su gestor habitual de Caixabank.
Tarjetas emitidas fuera del E.E.E.: Las tarjetas de emisores externos al Espacio Económico Europeo (EEE) no están afectadas por la nueva normativa PSD2, por lo que podrán seguir operando por comercio no seguro.
M.O./T.O (Mail Order/Telephone Order): Transacciones enviadas por un terminal con operativa MO/TO con introducción manual de datos de tarjeta del titular, facilitados mediante teléfono o correo electrónico.

Cómo usar el servicio ASC

El servicio ASC puede ser activado a través de su gestor habitual de CaixaBank. Una vez el servicio esté activado, tu plataforma podrá hacer uso del mismo de la siguiente forma:

Modo por defecto: Se analizarán todas las transacciones de petición de autorización. El sistema añadirá la petición de exención por análisis (TRA) a la petición enviada al banco emisor. Esto se realizará en transacciones que Comercia Global Payments (CGP) valore con bajo riesgo de fraude.

Modo manual (es necesario solicitar activación a CGP): Tu plataforma de comercio electrónico es la encargada de indicarle al sistema cuáles deben ser analizadas, incluyendo para ello la petición de exención TRA en el parámetro “merchantExemptionsSca”.

- Cuando el sistema configurado en modo manual recibe una petición de autorización con exención TRA en el campo “merchantExemptionsSca”, el sistema evalúa el riesgo de la transacción:

- - Si el riesgo de la transacción es bajo, permitirá el envío de dicha petición de exención al banco emisor.
  - Si el riesgo de la transacción es alto, se solicitará autenticación al banco emisor.

La exención M.I.T.

Desde el punto de vista de la acción del titular de la tarjeta en el momento de la transacción, la PSD2 clasifica las transacciones en dos categorías:

C.I.T. (Customer Initiated Transaction): Transacciones iniciadas por el cliente, en las cuales está presente. Por lo tanto, es posible realizar una SCA.
M.I.T. (Merchant Initiated Transaction): Transacciones iniciadas por el comercio, en las cuales el cliente no está presente. Por lo tanto, no es posible realizar una SCA.

Las transacciones que son lanzadas por un proceso del comercio (pago automático o manual) quedan fuera de la norma PSD2. Deberán incluir el parámetro “merchantExemptionsSca” con valor “MIT” en las transacciones. El uso de esta operativa requiere activación previa por parte de su gestor habitual de CaixaBank.

Para cumplir con la normativa PSD2, si guardas la referencia o token de la tarjeta del cliente para realizar pagos futuros, la primera transacción en la que se genera dicha referencia debe ser autorizada mediante una autenticación fuerte del titular de la tarjeta (SCA).

A continuación, se adjunta un ejemplo de petición de pago recurrente con token o referencia, con la exención M.I.T. incluida:

[merchantId] => 12345
[merchantTransactionId] => 84891340
[amount] => 1.00
[currency] => EUR
[country] => ES
[customerId] => 3
[paymentSolution] => creditcards
[merchantExemptionsSca] => MIT
[cardNumberToken] => 1217106174412227
[paymentRecurringType] => subscription
[subscriptionPlan] => 941789570176899

Integración de 3RI

La autenticación iniciada por el comercio (3RI) es una forma de realizar autenticaciones soportada en la versión 2.2 de 3D Secure.

La autenticación 3RI permite a los comercios realizar autenticaciones y autorizaciones sin que el cliente esté presente durante las transacciones. Estas autenticaciones son posibles al referenciar la autenticación de la operación original, en la que el cliente sí estaba presente durante la transacción.

Esta operativa puede ser de utilidad para tu comercio en los siguientes casos:

Envío de productos escalonado: Cuando no puedes enviar todos los artículos comprados por el cliente al mismo tiempo. Con la operativa 3RI puedes enviarlos en distintos momentos y realizar el cobro cuando los envíes.
Importe final desconocido antes de la compra: Cuando el importe final es desconocido y puede incurrir en costes extra. Por ejemplo, los posibles daños tras el alquiler de una vivienda vacacional.
Cobertura de un artículo devuelto: Cuando el comercio ofrece devoluciones gratuitas al cliente. Si no se devuelven todos los artículos, el comercio puede volver a cobrar al cliente.
Múltiples comercios: Permite una autenticación con el cliente presente y, posteriormente, múltiples autorizaciones para los comercios involucrados. Por ejemplo, un Marketplace que vende distintos productos de distintas tiendas desde su web. El cliente compra desde el Marketplace 2 productos y autentica el importe total. Después, el Marketplace tramita distintas autorizaciones para enviar el importe a las tiendas que venden los productos.

La operativa 3RI necesita ser habilitada en tu comercio para que la puedas utilizar. Ponte en contacto con Soporte para que podamos valorar y personalizar tu caso.

En los siguientes ejemplos, podrás ver cómo funciona 3RI con un caso de uso práctico: El envío de productos escalonado. Además, te daremos indicaciones complementarias para llevar a cabo los otros casos de uso, si fuera necesario.

En este ejemplo, un cliente ha comprado 2 productos. El comercio tiene en stock uno de ellos, por lo que:

Autenticará el importe de los 2 productos.
Autorizará y enviará el que tiene en stock (estás 2 operaciones tienen al cliente presente).
Más adelante, autenticará y autorizará el segundo gracias a 3RI.

Si quieres autenticar y autorizar con el cliente presente en una misma operación, comprueba esta sección.

Autenticación por el importe total

Esta operación se realiza con el cliente presente (CIT, Customer Initiated Transaction). Autenticaremos el importe de los 2 productos, que es de 100€, 50€ cada producto.

Puedes realizar esta operación en integraciones Hosted, Host2Host o JavaScript. Sin embargo, ten en cuenta que las operaciones siguientes 3RI deben ser vía Host2Host. Consulta la documentación específica para más detalles.

En este ejemplo, haremos todos los ejemplos con una integración Host2Host. Consulta la documentación específica para los endpoints de envío de la petición. Recuerda que si envías datos de la tarjeta del cliente desde tu plataforma debes conocer los requerimientos de la certificación PCI DSS.

Petición

Recuerda que las peticiones enviadas a Addon Payments deben ser cifradas. Visita nuestra sección de Cifrado, firma y envío de la petición para más información.

En esta primera operación autenticaremos el importe íntegro de la operación. Este es un ejemplo de petición de autenticación por el importe total, el primero como cadena y el segundo como cURL.

				
					merchantId=102106&amount=0&productId=105960001&merchantTransactionId=3RICITPAtestsoporte1
&country=ES&errorURL=https://ejemplo.com/error&customerId=supportest&currency=EUR
&chName=soporte&paymentSolution=creditcards&operationType=debit&successURL=http://ejemplo.com/success
&statusURL=http://ejemplo.com/status&cardNumber=4907270002222227&expDate=1240
&cvnNumber=123&authenticationInd=02&paymentRecurringExpiry=20231231
&paymentRecurringFrecuency=0&authentication3RIAmount=100

				
					curl --location --request POST 'https://checkout-stg.addonpayments.com/EPGCheckout/rest/online/pay' \
--header 'apiVersion: 5' \
--header 'encryptionMode: CBC' \
--header 'iv: 0Pn6pDEm73YvekNKUJcvwg==' \
--form 'merchantId="102106"' \
--form 'encrypted="YhkE2nrG1vmWRxNnMxWtbqDHsi/+FQs2AfPJBBHwIYOG3JCagem6DSb+D5hF1TUlut+p3/9WUaInomL4o17lyYZds2eQ48hNGO8O8EmnDzTfveqZUASpII=”' \
--form 'integrityCheck="06c928531469eb314c609e9a565567afecae69e644ba0e8cc49c612b6bf35e83"'

Parámetros de la solicitud de autenticación

A continuación tienes los parámetros específicos que debes enviar para la petición de autenticación. Importante: A estos parámetros debes añadir los requeridos de una petición Host2Host vía tarjetas.

El tipo indica si es requerido/obligatorio (R) u opcional (O):

Campo	Formato	Tipo	Descripción	Ejemplo
authenticationInd	01: Transacción de pago 02: Transacción recurrente 03: Pago fraccionado	R	Indica el tipo de autenticación inicial del titular de la tarjeta	02
paymentRecurringExpiry	Alfanumérico AAAA-MM-DD	R (cuando authenticationInd sea 02 o 03)	Último día en el que el comercio puede realizar autorizaciones	2024-12-31
paymentRecurringFrecuency	Numérico entero Mayor o igual que 0	R (cuando authenticationInd sea 02 o 03)	Indica el número mínimo de días que deben pasar entre autorizaciones	0
authentication3RIAmount	Numérico decimal 0~1000000.00 El importe debe ser mayor que el campo “amount”	R (cuando authenticationInd sea 02 o 03)	Indica el importe de la autenticación. Si no se envía, se realizará con el importe del campo “amount”. El separador de decimales es el punto (.). No hay separador de millares	100
purchaseInstalData	Numérico entero Mayor que 1	R (cuando authenticationInd 03)	Indica el número de autorizaciones permitidas para un pago a plazos (instalment). Debe estar acordado entre el titular de la tarjeta y el comercio	3

Respuesta

Visita nuestra sección de Recepción y gestión de las notificaciones para conocer su estructura.

En la notificación, se devolverán unos parámetros siempre que la autenticación se realice con éxito. El comercio deberá guardar estos datos para futuras transacciones.

A continuación, tienes una tabla con algunos de los datos requeridos para operaciones 3RI posteriores que se devolverán en la respuesta tras una autenticación del importe total exitosa. Los encontrarás dentro de < mpi >:

Campo	Formato	Descripción	Ejemplo
acsTransID	Canónico, como se define en IETF RDC 4122 Viene dentro del objeto “mpi”	Valor identificativo de la autenticación en el 3DS ACS	a9be31b1-6d52-44c1-8699-1d37ca4eb1cf
authMethod	01: Autenticación frictionless por ACS 02: Challenge del titular de la tarjeta por ACS 03: Verificado AVS 04: Otros métodos del emisor 05-79: Reservado para futuros usos EMVCo 80-99: Reservado para DS Viene dentro del objeto “mpi”	Método empleado por el dueño de la tarjeta para realizar la autenticación	01
authTimestamp	YYYYMMDDHHMM Viene dentro del objeto “mpi”	Año, mes, día, hora y minuto (UTC) en el que se ha realizado la primera autenticación	202301071540
threeDSv2Token	Alfanumérico	Token de 3DS. Enlaza la autenticación con la autorización.	cf5bf8c8-03e8-4ead-899b-d00b82fa5093
authData	Alfanumérico Viene dentro del objeto “mpi”	Información relativa a la autenticación, con datos extras relativos a esta operativa. Es opcional	N/A

A continuación, tienes un ejemplo de respuesta a una petición de autenticación:

				
					<!--?xml version="1.0"?-->
<payfrex-response operation-size="1">
  <message>WorkFlow has finished successfully, for transaction Id: 7762122</message>
  <operations>
    <operation sorted-order="1">
      <amount>0</amount>
      <currency>EUR</currency>
      <merchanttransactionid>3RI-CIT-PA-testsoporte0001</merchanttransactionid>
      <message>3dsv2 - processed</message>
      <operationtype>DEBIT</operationtype>
      <payfrextransactionid>7762122</payfrextransactionid>
      <paymentdetails>
        <cardnumbertoken>2420835988782227</cardnumbertoken>
        <extradetails>
      </extradetails></paymentdetails>
      <service>3DSv2</service>
      <status>SUCCESS3DS</status>
      <respcode>
        <code>8000</code>
        <message>Successful authentication</message>
        <uuid>6a69447e_51fe_4689_b6f8_c4943bcd2ac2</uuid>
      </respcode>
      <mpi>
        <acstransid>62eecff1-471d-4d0a-902f-c1a535b9cf68</acstransid>
        <authmethod>01</authmethod>
        <authtimestamp>202312140942</authtimestamp>
        <authenticationstatus>Y</authenticationstatus>
        <cavv>AJkBB4OBmVFmgYFYFIGZAAAAAAA=</cavv>
        <eci>05</eci>
        <messageversion>2.2.0</messageversion>
        <threedssessiondata>NGJhNDgyZmEtZjJiZS00ODVkLTkzYTgtZjE2OGRiYzdhNGQ3</threedssessiondata>
        <threedsv2token>4ba482fa-f2be-485d-93a8-f168dbc7a4d7</threedsv2token>
      </mpi>
      <paymentcode>nsY1</paymentcode>
      <paymentmessage>Authenticated successfully</paymentmessage>
    </operation>
  </operations>
  <optionaltransactionparams>
    <entry>
      <key>3riauthentication</key>
      <value>true</value>
    </entry>
  </optionaltransactionparams>
  <status>SUCCESS</status>
  <workflowresponse>
    <id>51498</id>
    <name>3RI H2H autenticacion</name>
    <version>0</version>
  </workflowresponse>
</payfrex-response>

Autorización de un importe inferior al total

En esta operación, que se realiza con el cliente presente (CIT), vamos a autorizar el importe de uno de los productos que el cliente ha comprado, ya que es el que tenemos en stock. El valor es de 50€. Recuerda que el valor debe ser inferior al importe total autenticado.

En este ejemplo estamos trabajando con una integración Host2Host, aunque recuerda que puedes realizar esta operación en integraciones Hosted o JavaScript. Las operaciones siguientes 3RI deben ser vía Host2Host.

Petición

Recuerda que las peticiones enviadas a Addon Payments deben ser cifradas. Visita nuestra sección de Cifrado, firma y envío de la petición para más información.

En esta segunda operación autorizaremos el importe del artículo en stock. Este es un ejemplo de una autorización por un importe inferior al total, el primero como cadena y el segundo como cURL.

				
					merchantId=102106&amount=50&productId=105960001&merchantTransactionId=3RICITPAtestsoporte1
&country=ES&errorURL=https://ejemplo.com/error&customerId=supportest&currency=EUR
&chName=soporte&paymentSolution=creditcards&operationType=debit&successURL=http://ejemplo.com/success
&statusURL=http://ejemplo.com/status&cardNumber=4907270002222227&expDate=1240
&cvnNumber=123&paymentRecurringType=newCof
&threedParams={"threeDSv2Token":"4ba482fa-f2be-485d-93a8-f168dbc7a4d7"}

				
					curl --location --request POST 'https://checkout-stg.addonpayments.com/EPGCheckout/rest/online/pay' \
--header 'apiVersion: 5' \
--header 'encryptionMode: CBC' \
--header 'iv: 12dsdpDEm73YvekNKdfdfg==' \
--form 'merchantId="102106"' \
--form 'encrypted="TuHAIJhyagYU237JIGMxWtbqDHsi/+FQs2AfPJBBHwIYOG3JCagem6DSb+D5hF1TUlut+p3/9WUaInomL4o17lyYZds2e932AGyu6SA6S6=”' \
--form 'integrityCheck="sfsdfwf9eb314c609e9a565567afecae69e644ba0e8cc49c612b6basda3"'

Parámetros de la solicitud de autorización

A continuación tienes los parámetros específicos que debes enviar para la petición de autorización del importe menor al total. Importante: A estos parámetros debes añadir los requeridos de una petición Host2Host vía tarjetas.

El tipo indica si es requerido/obligatorio (R) u opcional (O):

Campo	Formato	Tipo	Descripción	Ejemplo
paymentRecurringType	– newCof: Pagos puntuales, sin importe ni intervalo de tiempo fijo. – newSubscription: Pago recurrente con importe e intervalo de tiempo definido. – newInstallment: Pago aplazado limitado a una compra individual con importe e intervalo de tiempo definido.	R	Tipo de pago recurrente o sucesivo. Indica si la transacción C.O.F. es inicial o sucesiva, así como el motivo u objetivo del pago	newCof
threedParams	JSON Alfanumérico	R	Enlaza la autenticación desacoplada con las autorizaciones. En el JSON, debes incluir el campo «threeDSv2Token» junto su valor, como ves en el ejemplo	{«threeDSv2Token «:»cf5bf8c8-03e8-4ead-899b-d00b82fa5093»}

Respuesta

Visita nuestra sección de Recepción y gestión de las notificaciones para conocer su estructura.

En la notificación se recibirán unos parámetros cuando la autorización se realice con éxito. Deberás usar estos datos, junto los de la respuesta anterior, para operaciones 3RI posteriores.

A continuación, tienes una tabla con algunos de los parámetros necesarios que recibirás en la notificación a una autorización de un importe inferior al total.

Campo	Formato	Descripción	Ejemplo
cardNumberToken	Alfanumérico 16~20 caracteres	Token de Addon Payments del número de tarjeta. Los últimos 4 dígitos coinciden con el número de tarjeta original.	4535954006730084
subscriptionPlan	Alfanumérico Máximo 45 caracteres.	Identificador del plan de subscripción, uniendo la autorización con el cliente y el comercio. Este parámetro es obligatorio para sucesivas autorizaciones.	708120533554282

A continuación, tienes un ejemplo de respuesta a una petición de autorización.

				
					<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<payfrex-response operation-size="1">
	<message>WorkFlow has finished successfully, for transaction Id: 7762182</message>
	<operations>
		<operation sorted-order="1">
			<amount>50</amount>
			<currency>EUR</currency>
			<details>{"resultCode":"00000","resultDescription":"OK","values":{"rfTransactionCurrency":"EUR","rfRTS":"999008881 790190 900879 231214110620","rfContactlessLogo":"false","rfOperationType":"Settle","rfAuthMode":"On","rfDataEntryMode":"Manual","rfCardHolderVerificationMode":"No","rfFuc":"999008881","rfTerminalID":"00000713","rfProcessor":"Redsys","rfMerchantName":"Easy Payment Gateway","rfMerchantCity":"Mijas","rfMerchantPostalCode":"29651","rfMerchantAddress":"Av. Carmen Saenz de Tejada, S208, 001B, Edificio Miramar","rfMaskedPan":"************2227","rfOperationDateTime":"14/12/23 11:06:20","rfTerminalOperationNumber":"0051","rfAuthNumber":"597386","rfTransactionAmountCurrency":"250,00 EUR","rfProcessorMessage":"","OperationResult":"000","cofAdditionalInformation":"CS098715813517364"}}</details>
			<merchantTransactionId>3RI-CIT-AO-testsoporte0002</merchantTransactionId>
			<message>Success 'Settle' operation</message>
			<operationType>DEBIT</operationType>
			<optionalTransactionParams>
				<entry>
					<key>3riauthorization</key>
					<value>true</value>
				</entry>
			</optionalTransactionParams>
			<payFrexTransactionId>7762182</payFrexTransactionId>
			<paySolTransactionId>999008881 790190 900879 231214110620</paySolTransactionId>
			<paymentDetails>
				<cardHolderName>test soporte</cardHolderName>
				<cardNumber>490727****2227</cardNumber>
				<cardNumberToken>2420835988782227</cardNumberToken>
				<cardType>VISA/CREDIT</cardType>
				<expDate>1240</expDate>
				<extraDetails>
					<entry>
						<key>cardCategory</key>
						<value>Not Available</value>
					</entry>
					<entry>
						<key>rememberMe</key>
						<value>true</value>
					</entry>
				</extraDetails>
				<issuerBank>SERVIRED MASTERCARD INTERNACIONAL</issuerBank>
				<issuerCountry>ES</issuerCountry>
			</paymentDetails>
			<paymentSolution>caixapucpuce</paymentSolution>
			<status>SUCCESS</status>
			<respCode>
				<code>0000</code>
				<message>Successful</message>
				<uuid>f2c9b387_0d5d_4c8a_a203_0b797af1148d</uuid>
			</respCode>
			<authCode>597386</authCode>
			<mpi>
				<eci>05</eci>
			</mpi>
			<paymentCode>000</paymentCode>
			<paymentMessage>Operación finalizada con éxito</paymentMessage>
			<subscriptionPlan>098715813517364</subscriptionPlan>
		</operation>
	</operations>
	<status>SUCCESS</status>
	<workFlowResponse>
		<id>51501</id>
		<name>3RI H2H autorizacion</name>
		<version>0</version>
	</workFlowResponse>
</payfrex-response>

Autenticación y autorización 3RI por el importe restante

En esta operación, donde el cliente ya no está presente (MIT, Merchant Initiated Transaction), vamos a autenticar y autorizar la cantidad restante, que corresponde al objeto que el comercio ya tiene en stock. Llegados a esta operación, tenemos:

El importe total autenticado.
Información necesaria para la operación 3RI.
La primera autorización, donde hemos obtenido detalles de del plan de subscripción y de la tarjeta.

Con esta información podemos realizar la operación 3RI del importe restante. Ten en cuenta lo siguiente:

No tienes por qué procesar todo el importe restante, puede realizar varias operaciones 3RI (siempre que no superen el importe restante autenticado).
Puedes usar un «productId» diferente, siempre que pertenezca al mismo «merchantId».
Puedes realizar la autenticación y autorización separadas, comprueba esta sección para más información. Para este ejemplo, realizaremos las operaciones en un mismo paso.

Petición

Recuerda que las peticiones enviadas a Addon Payments deben ser cifradas. Visita nuestra sección de Cifrado, firma y envío de la petición para más información.

En esta operación, autenticaremos y autorizaremos el importe restante de la autenticación original, lo que correspondería al segundo artículo que compró el cliente y que el comercio ya tiene en stock. El primer ejemplo es la petición en cadena y el segundo en cURL.

				
					merchantId=102106&amount=50&productId=105960001&merchantTransactionId=3RIMITPAtestsoporte1
&country=ES&errorURL=https://ejemplo.com/error&customerId=supportest&currency=EUR
&chName=soporte&paymentSolution=creditcards&operationType=debit&successURL=http://ejemplo.com/success
&statusURL=http://ejemplo.com/status&cardNumberToken=2420835988782227&expDate=1240
&subscriptionPlan=098715813517364&paymentRecurringType=cof
&threedParams={"threeDSv2Token":"4ba482fa-f2be-485d-93a8-f168dbc7a4d7"}
&threeDSDeviceChannel=03&threeDS3RI=01&priorACSTransIDRef=62eecff1-471d-4d0a-902f-c1a535b9cf68
&priorAuthMethod=01&priorAuthTimestamp=202312140942
&paymentRecurringExpiry=20231231&paymentRecurringFrecuency=0

				
					curl --location --request POST 'https://checkout-stg.addonpayments.com/EPGCheckout/rest/online/pay' \
--header 'apiVersion: 5' \
--header 'encryptionMode: CBC' \
--header 'iv: 12dsdpDEm73YvekNKdfdfg==' \
--form 'merchantId="102106"' \
--form 'encrypted="TuHAIJhyagYU237JIGMxWtbqDHsi/+FQs2AfPJBBHwIYOG3JCagem6DSb+D5hF1TUlut+p3/9WUaInomL4o17lyYZds2e932AGyu6SA6S6=”' \
--form 'integrityCheck="sfsdfwf9eb314c609e9a565567afecae69e644ba0e8cc49c612b6basda3"'

Parámetros de la solicitud 3RI

A continuación tienes los parámetros específicos que debes enviar para la petición 3RI. Importante: A estos parámetros debes añadir los requeridos de una petición Host2Host vía tarjetas, a excepción de los relacionados con la tarjeta (cardNumber, expDate y cvnNumber), ya que estamos usando el token.

El tipo indica si es requerido/obligatorio (R) u opcional (O):

Campo	Formato	Tipo	Descripción	Ejemplo
threeDSDeviceChannel	03: 3DS Requestor Initiated	R	Indica el canal de autenticación para esta petición. En este caso 3RI (03).	03
threeDS3RI	01: Transacción recurrente	R	Indica el tipo de 3RI. Es información extra para procesar la operación de la mejor forma posible.	01
threeDSMessageCategory	01: autenticación con pago (PA) 02: autenticación sin pago (NPA)	O	Indica la categoría de la autenticación. Por defecto es 01 (autenticación con pago).	01
priorACSTransIDRef	Alfanumérico Es el valor del “acsTransID” de la notificación de la transacción previa (CIT)	R	Referencia a la autenticación en el 3DS ACS realizada previamente. Este valor es el mismo para todos los pagos sucesivos, en el caso que sea necesario más de una vez.	a9be31b1-6d52-44c1-8699-1d37ca4eb1cf
priorAuthMethod	Es el valor del “authMethod” de la notificación de la transacción previa (CIT)	R	Método empleado por el dueño de la tarjeta para realizar la autenticación.	01
priorAuthTimestamp	Es el valor del “authTimestamp” de la notificación de la transacción previa (CIT)	R	Año, mes, día, hora y minuto (UTC) en el que se ha realizado la primera autenticación.	202301071540
priorAuthData	Es el valor del “authData” de la notificación de la transacción previa (CIT)	O	Información relativa a la autenticación, con datos extras relativos a esta operativa. Es opcional.	N/A
paymentRecurringExpiry	Alfanumérico AAAA-MM-DD	R	Último día en el que el comercio puede realizar autorizaciones	2024-12-31
paymentRecurringFrecuency	Numérico entero Mayor o igual que 0	R	Indica el número mínimo de días que deben pasar entre autorizaciones	0
subscriptionPlan	Alfanumérico Máximo 45 caracteres.	R	Identificador del plan de subscripción, uniendo la autorización con el cliente y el comercio. Este parámetro es obligatorio para sucesivas autorizaciones.	708120533554282
cardNumberToken	Alfanumérico 16~20 caracteres	R	Token de Addon Payments del número de tarjeta. Los últimos 4 dígitos coinciden con el número de tarjeta original.	4535954006730084
paymentRecurringType	cof	R	Tipo de pago recurrente o sucesivo. Indica si la transacción C.O.F. es inicial o sucesiva, así como el motivo u objetivo del pago.	cof
merchantExemptionsSca	MIT = Transacción iniciada por el comercio	R	Exención PSD2 a aplicar. Normalmente se debe enviar únicamente en pagos sucesivos y con el valor “MIT”.	MIT

Respuesta

Visita nuestra sección de Recepción y gestión de las notificaciones para conocer su estructura.

Este es un ejemplo de notificación recibida tras la operación 3RI. Si vas a realizar más operaciones 3RI, debes usar los detalles de autenticación y pago recibidos en la primera autenticación y autorización.

Nota: Si la autenticación y autorización es para otro comercio (caso de múltiples comercios, deberás enviar el «amount» y el «productId» correspondiente).

				
					<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<payfrex-response operation-size="2">
    <message>WorkFlow has finished successfully, for transaction Id: 520480949</message>
    <operations>
        <operation sorted-order="1">
            <amount>50</amount>
            <currency>EUR</currency>
            <merchantTransactionId>HdR612TsFZ3ri</merchantTransactionId>
            <message>3dsv2 - processed</message>
            <operationType>DEBIT</operationType>
            <payFrexTransactionId>520480949</payFrexTransactionId>
            <paymentDetails>
                <cardNumberToken>2420835988782227</cardNumberToken>
                <extraDetails/>
            </paymentDetails>
            <service>3DSv2</service>
            <status>SUCCESS3DS</status>
            <respCode>
                <code>8000</code>
                <message>Successful authentication</message>
                <uuid>22631ee0_445d_4e8f_895f_4981540ec07c</uuid>
            </respCode>
            <mpi>
                <acsTransID>e4061b62-0894-41c3-1336-e2c1c1287e14</acsTransID>
                <authMethod>01</authMethod>
                <authTimestamp>202301071548</authTimestamp>
                <authenticationStatus>Y</authenticationStatus>
                <cavv>AJkCB2VhBQAAAAABl4FYAQAAAAA=</cavv>
                <eci>05</eci>
                <messageVersion>2.2.0</messageVersion>
                <threeDSSessionData>ZDI1MDljNzgtMTU0Yy00MGIwLWJhMWEtMDYyYTZkZDYyOGQ1</threeDSSessionData>
                <threeDSv2Token>12509c78-354c-40b0-ba1a-062a6dd628d5</threeDSv2Token>
            </mpi>
            <paymentCode>nsY1</paymentCode>
            <paymentMessage>Authenticated successfully</paymentMessage>
        </operation>
        <operation sorted-order="2">
            <amount>0.01</amount>
            <currency>EUR</currency>
            <details>{"resultCode":"00000",...,"merchantExemptionSca":"MIT"}</details>
            <merchantTransactionId>HdR612TsFZ3ri</merchantTransactionId>
            <message>Success 'Auth' operation with status 'PENDING'</message>
            <operationType>DEBIT</operationType>
            <optionalTransactionParams>
                <entry>
                    <key>3ds</key>
                    <value>2</value>
                </entry>
            </optionalTransactionParams>
            <payFrexTransactionId>520480949</payFrexTransactionId>
            <paySolTransactionId>008043853 190190 558593 2110607174810</paySolTransactionId>
            <paymentDetails>
                <cardHolderName>Andres</cardHolderName>
                <cardNumber>49072****2227</cardNumber>
                <cardNumberToken>2420835988782227</cardNumberToken>
                <cardType>VISA/DEBIT OR CREDIT</cardType>
                <expDate>0927</expDate>
                <extraDetails>
                    <entry>
                        <key>cardCategory</key>
                        <value>Not Available</value>
                    </entry>
                    <entry>
                        <key>rememberMe</key>
                        <value>true</value>
                    </entry>
                </extraDetails>
                <issuerBank>BANCOSABADELL</issuerBank>
                <issuerCountry>ES</issuerCountry>
            </paymentDetails>
            <paymentSolution>caixapucpuce</paymentSolution>
            <status>PENDING</status>
            <respCode>
                <code>0000</code>
                <message>Successful</message>
                <uuid>a89237db_d0f9_43bf_b650_803a85e411ff</uuid>
            </respCode>
            <authCode>481157</authCode>
            <mpi>
                <eci>05</eci>
            </mpi>
            <paymentCode>000</paymentCode>
            <paymentMessage>Operación finalizada con éxito</paymentMessage>
        </operation>
    </operations>
    <optionalTransactionParams>
        <entry>
            <key>3ds</key>
            <value>2</value>
        </entry>
    </optionalTransactionParams>
    <status>SUCCESS</status>
    <workFlowResponse>
        <id>28082</id>
        <name>3RI</name>
        <version>0</version>
    </workFlowResponse>
</payfrex-response>

Otros flujos disponibles en 3RI

En el ejemplo que hemos visto, el flujo es el siguiente:

Autenticar el importe de los 2 productos.
Autorizar y enviar 1 de los productos (estás 2 operaciones tienen al cliente presente).
Más adelante, autenticará y autorizará el segundo gracias a 3RI.

Sin embargo, con esta operativa podemos realizar las operaciones de formas distintas, como:

Autenticar y autorizar con el cliente presente en una única operación.
Autenticar y autorizar con 3RI en pasos diferentes.

A continuación, vamos a ver las indicaciones complementarias para estos supuestos.

Autenticar y autorizar en una operación

Si queremos autenticar y autorizar en una sola operación, debemos lanzar una petición con estos parámetros, añadiendo el «paymentRecurringType».

Además, deberemos enviar los parámetros básicos requeridos dependiendo del tipo de integración: Hosted, JavaScript o Host2Host.

Recuerda que esta operación se puede realizar con cualquiera de las integraciones, pero las siguientes que sean 3RI sin el cliente presente, deben ser mediante Host2Host.

Autenticar y autorizar con 3RI en operaciones diferentes

Para autenticar y autorizar con 3RI en operaciones diferentes, sigue estos pasos:

Lanza una petición 3RI con los parámetros de esta tabla a excepción de: «subscriptionPlan» y «paymentRecurringType».
Guarda el «threeDSv2Token» de la notificación de esa autenticación.
Envía una petición de autorización 3RI con los siguientes parámetros de esta tabla: «cardNumberToken», «subscriptionPlan», «paymentRecurringType». Además, envía el «threedParams» , que contiene un JSON con el valor de «threeDSv2Token» que has guardado en el paso anterior.

PSD2 y 3DSv2

¿Qué es PSD2?

Ventajas de la normativa PSD2

Funcionamiento de la autenticación reforzada (SCA) en PSD2

Operaciones que requieren autenticación reforzada (SCA)

EMVCo y 3DSecure v.2

Autenticación frictionless y challenge – 3DSv2

Autenticación y autorización por frictionless

Autenticación y autorización por challenge

Estado de la autenticación 3DS2

Parámetros introducidos en 3DSecure v.2

Información del navegador web del cliente

Parámetros para obtener otra información

Exenciones y servicio Addon Sales Conversion (ASC)

Exenciones

Addon Sales Conversion

Tipos de transacciones que pueden prescindir de SCA

Cómo usar el servicio ASC

La exención M.I.T.

Integración de 3RI

Autenticación por el importe total

Petición

Parámetros de la solicitud de autenticación

Respuesta

Autorización de un importe inferior al total

Petición

Parámetros de la solicitud de autorización

Respuesta

Autenticación y autorización 3RI por el importe restante

Petición

Parámetros de la solicitud 3RI

Respuesta

Otros flujos disponibles en 3RI

Autenticar y autorizar en una operación

Autenticar y autorizar con 3RI en operaciones diferentes

Tabla de Contenidos

Productos

Ventas

Soporte técnico

Socios

SmartWiki, Impulsada por IA

Cyberpac

Consulta la documentación de las distintas secciones de integraciones:

Addon Payments

Pagos integrados en TPV