Adaptaciones PSD2 (Septiembre 2019)

PSD2 es el acrónimo de Payment Services Directive 2 y que hace alusión a la segunda Directiva de servicios de pago de la Unión Europea. Esta directiva a través de su tras­posición a los Estados Miembros incorpora medidas que afectan de forma importante a todos los pagos electrónicos, y especialmente a los pagos remotos como las compras por internet.

De acuerdo a la normativa que entra en vigor el 14 de septiembre de 2019, en general, todas las operaciones de comercio electrónico dentro de la EEA (European Economic Area) deberán utilizar autenticación reforzada (SCA – Strong Customer Authentication / Au­tenticación Reforzada), si bien se contemplan algunos escenarios para los cuales se exime de esta obligatoriedad (exenciones).

De cara a un comercio que acepta pagos de forma remota, cumplir con esta normativa de­penderá del método de pago utilizado, siendo la principal solución la implementación de 3D Secure como protocolo de autenticación para los pagos con tarjeta. Otros métodos de pago como los X-pays (Apple Pay, Google pay... etc.) podrían tener incorporados otros sistemas de autenticación delegada por parte del emisor de la tarjeta o bien tener incorporados ya de entrada estos mecanismos SCA (p ej. Bizum) y no requerir 3D Secure.

Los casos de pagos remotos que no requieren utilizar SCA son aquellos que están recogidos en las exenciones de la directiva, o bien están fuera del alcance de la misma:

Fuera de alcance de PSD2:

• Pagos iniciados por el comercio sin participación del cliente (MIT – Merchant Initiated Transactions), como los pagos recurrentes de una subscripción
• Pagos por teléfono o por correo (Pago MOTO)
• Transacciones no de pago, como las de validación de tarjeta de importe 0 euros.

Casos de posible aplicación de exenciones (opcional):

Son los casos de bajo riesgo que en conjunción con la existencia de un sistema de análisis de riesgos permiten opcionalmente la no aplicación de SCA

• Exención de bajo importe (low value): pagos < 30 € y cuando no se acumulen más de 100 € o 5 operaciones seguidas sin SCA. El control de estos contadores depende de la entidad emisora de la tarjeta.
• Exención por bajo riesgo - Análisis de riesgo realizado (TRA – transaction risk analisys): Su aplicación requiere de unas condiciones
  adicionales sobre el histórico de fraude acumulado que deben ser valoradas a nivel de Entidad Adquirente.
• Exención Protocolo de Pago Corporativo Seguro: Uso restringido a casos especiales de pagos entre empresas donde el canal utilizado no está disponible para el público general e incorpora otros mecanismos de seguridad al mismo nivel que SCA

Para que un comercio pueda aplicar las exenciones debe tener autorización de su Entidad Adquirente

Para enviar una operación sin autenticación reforzada sin que ésta sea denegada se debe informar del caso que aplica de la lista anterior. Esto significa que para evitar rechazos por parte del adquirente o el emisor por no utilizar 3DSecure se deben marcar las operaciones debidamente para justificar el no uso de 3DSecure :

* Se deberá tener en cuenta que para las exenciones LWV, TRA y COR la primera opción será marcar la exención en el paso de la autenticación, para mejorar la experiencia de usuario. Esto permite que si el emisor no quiere aceptar la propuesta de exención y requiere SCA pueda solicitar la autentica­ción en el mismo momento sin necesidad de rechazar la operación (challenge required EMV3DS).

Transacciones iniciadas por el comercio (MIT)

Son aquellas transacciones iniciadas por el comercio sin que haya interacción posible con el cliente. Por ejemplo, pago mensual de un recibo o cuota de subscripción. Este tipo de exención requiere el marcaje de la operativa como COF (Credencial on File) de acuerdo al uso concreto que se esté haciendo de las credenciales almacenadas (consultar Anexo Credenciales en Archivo (COF)).

Sin embargo no todas las operativas en las que se utilizan datos de tarjeta/credenciales almacenadas (COF) son consideradas MIT. Por ejemplo, la operativa de pago en 1 clic, donde las credenciales del cliente están almacenadas o tokenizadas (pago por refe­rencia) con el objetivo de facilitar al máximo el momento del pago sin tener que solicitarlas de nuevo al cliente, no se puede considerar una transacción iniciada por el comercio. En tal caso según PSD2, y mientras no se aplique otra exención, se requiere el uso de autenticación reforzada (SCA).

No obstante, con PSD2 estando en vigor, toda operativa de pago iniciada por el comercio (MIT) requiere inicialmente una operación autenticada con SCA que es aquella en la que el cliente concede el permiso y acuerda con el comercio las condiciones para que se usen sus datos de pago para cargos posteriores de acuerdo a un servicio prestado continuado en el tiempo. Esta operativa debe también marcarse debidamente siguiendo la especi­ficación Card-on-file (COF) para indicar que los datos de tarjeta se están almacenando para pagos posteriores. Solicitar Manual es­pecífico contactando con el Servicio Técnico de Banco Sabadell.

Transacciones MIT y uso de tokenización (pago por referencia)

En muchos casos se suele utilizar la tokenización de las credenciales de pago del cliente para el almacenamiento seguro de los mismos y asegurar el cumplimiento de los estándares de seguridad de PCI DSS, con el objetivo de generar más tarde pagos iniciados por el comercio sin estar presente el titular de la tarjeta.
En estos casos, en la transacción inicial en la que se solicitar el token o referencia, bajo PSD2 se debe utilizar 3D Secure para aplicar autenticación reforzada y además se debe marcar adecuadamente mediante los parámetros COF el uso que se dará a la misma, de forma que en usos posteriores iniciados por el comercio con el token/referencia, el propio tpv virtual SIS incorpore de forma automática la información de marcaje de uso adecuada e información adicional requerida según la marca de la tarjeta (pej: id transacción original requerido para los pagos COF en Visa “DS_MERCHANT_COF_TXNID”).