NOTA IMPORTANTE

Con motivo de la entrada en vigor de la Directiva Europea PSD2, si estuviera interesado en aplicar algún tipo de exención o excepción de la misma, rogamos contacten con nosotros para grabarlo convenientemente en su perfil de comercio en Banco Sabadell a través del tfno. 902365650 (Opción 2) o en el email TPVVirtual@bancsabadell.com

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 :

 

Razon de no aplicar SCA

 

  Modo de informarlo en el TPV Virtual

Operación iniciada por el comercio

MIT: operación iniciada por el comercio (sin estar asociada a una acción o evento del cliente) que están fuera del alcance de la PSD2. Este es el caso de las operativas de pagos de subscripciones, recurrentes, es decir, todas las que requieren el almacenamiento de las credenciales de pago del cliente (COF) o su equivalente mediante operativas de pagos programados tokenizados (uso funcionalidad “pago por referencia” en pagos iniciados por el comercio). Toda operativa de pago iniciada por el comercio (MIT) requiere que inicialmente cuando el cliente concede el permiso al comercio de uso de sus credenciales de pago, dicho “permiso o mandato” se haga mediante operación autenticada con SCA.

 

  Indicador exención (DS_MERCHANT_EXCEP_SCA):

  valor MIT

Operación bajo importe*

 

  Indicador exención (DS_MERCHANT_EXCEP_SCA):

  valor LWV

Operación telefónica/correo

 

  Campo identificación entrada MO/TO

  (DS_ MERCHANT_DIRECTPAYMENT): valor MOTO

Transacciones de validación tarjeta (importe cero)

 

  Según tipo transacción solicitada (DS_MERCHANT_TRANSACTIONTYPE)

Exención por bajo riesgo/TRA*

 

  Indicador exención (DS_MERCHANT_EXCEP_SCA): valor TRA

Exención Protocolo Pago Corporativo Seguro*

 

  Indicador exención (DS_MERCHANT_EXCEP_SCA): valor COR

 

* 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”).