Advertisements

En Septiembre se implanta PSD2/SCA. ¿Cómo afectará eCommerce?

En Septiembre se implanta PSD2/SCA. ¿Cómo afectará eCommerce?


Legal

PSD2 es la nueva regulación europea para el entorno de pagos. Abarca desde la creación de figuras para la desintermediación de los bancos, como AISP (agregadores de información bancaria) o PISP (iniciadores de pagos), hasta cómo se gestionan los fondos en plataformas que actúan como “agentes comerciales de terceros”, como por ejemplo, Marketplaces. No obstante, una de las normas que más impacto tendrá en el sector eCommerce es la regulación  SCA, con fecha implantación 14 de Septiembre de 2019

Sé que es un tema muy técnico y complejo. Intentaré explicarlo sin aburrir en los detalles. No obstante, justamente conociendo los matices de la norma el responsable de un negocio eCommerce podrá implantar la mejor estrategia para sus pagos en el entorno que ha de llegar. 

SCA (Strong Costumer Authentication) aplica a todos los canales de pagos (eCommerce, pagos presenciales, tokenización, transferencias, …) de cualquier sistema de pago (tarjetas, cuentas financieras, X-Pay –grandes plataformas de pagos alternativos a Tarjetas –, …)   que se realizan dentro del Espacio Económico Europeo. Hay una parte, quizás la más conocida, que se refiere a cómo se autenticarán los compradores en pagos “seguros”. Con la nueva norma se requerirá que sea por dos de los siguientes tres factores: algo que sé (PIN, password, …), algo que tengo (un teléfono móvil, un token, …) o algo que soy (biometría). ¿Deben hacer algo los comercios acerca de como se autenticarán los clientes? Realmente no. Ya son las entidades que emiten los sistemas de pago las que están ocupadas adaptando protocolos para que sus usuarios conozcan y tengan disponible el doble factor para Septiembre.

Entonces, ¿dónde han de centrar su atención los comercios virtuales? Pues muy especialmente en el requerimiento, de obligado cumplimiento, por el que todas las transacciones eCommerce europeas han de estar autenticadas a partir del 14 de septiembre. Como que la tipología de comercios y empresas que reciben pagos es muy amplia, desde que se publicó la norma se han ido realizando consultas y peticiones al Regulador, por las que se ha configurado el ámbito de actuación de SCA, así como ciertas excepciones en su aplicación.

Operativa “excluida” de aplicación de autenticación SCA:

  • “One leg transactions”, es decir, operaciones en las que o el sistema de pago (tarjeta, cuenta, …) o el de cobro (TPV, …); uno de los dos queda fuera del Espacio Económico Europeo.
  • Operaciones en las que el pago se ha iniciado por Teléfono, correo o email.
  • Pagos realizados por Tarjetas Prepago Anónimas.
  • MIT (Merchant Initiated Transactions). Se considerarán excluidas las operaciones iniciadas sólo por el comercio (el pagador está “ausente” en el momento del pago) y, siempre y cuando, haya un acuerdo preexistente entre comercio y comprador. Para MIT, no obstante, es requerida una autenticación SCA en el pago inicial, en la primera compra.

Según lo anterior se pueden considerar MIT los pagos repetitivos, iniciados por el comercio en procesos tipo “batch” y en los que el importe es variable. También en suscripciones digitales sin importe fijo (p.ej.; facilitar una tarjeta para el cobro de campañas SEM), o en cargos extras en el alquiler de un coche, … 

Las operaciones “excluidas”, son enviadas por el comercio como Compra No Segura (técnicamente No-3DS). Ante ellas, el receptor, la entidad emisora del pago, solo puede aceptarlas o denegarlas; pero nunca requerir una autenticación de su cliente.

SCA, también ha definido operaciones que considera como “excepciones”. A diferencia de las “excluidas”, en las “excepciones” el comercio solo las puede enviar en un canal de Compra Segura (3DS). Ante ellas, el receptor, la entidad emisora del pago, puede aceptarlas, denegarlas, pero también, requerir una autenticación de su cliente antes de responder.

Operativa por la que el comercio puede solicitar una “excepción” al emisor del sistema de pago:

  • Transacciones de ≤ 30 €. No obstante, en esta excepción la entidad emisora también está regulada y solo la aceptará sin autenticar a su cliente si, des de la última vez que lo autenticó, el importe exento acumulado de su cliente en compras anteriores es ≤ 100 € o el número transacciones exentas ≤ 5.
  • Transacciones recurrentes, es decir, operativa periódica con mismos importe, sistema de pago, periodicidad y beneficiario. En esta excepción, no obstante, se requiere autenticación en la primera transacción. 

Quedaba la duda de lo que sucedería en operaciones recurrentes iniciadas antes del 14 de Septiembre. Recientemente el Regulador ha dictaminado que, en estos casos, no se aplique la autenticación en el primer pago de la subscripción.

  • Excepción por TRA (Transaction Risk Analysis). Para operaciones claramente de bajo riesgo de fraude, se puede enviar bajo exención por TRA, siempre y cuando el ratio global de fraude de la Entidad de Pago (p.ej. el banco o plataforma propietaria del TPV Virtual) que procesa el pago del comercio, esté acotado y certificado por el Regulador. 

Los importes de las operaciones acogidas a esta excepción, deberán ajustarse el nivel de fraude global de la Entidad de Pago: operaciones < 500 € si ratio <0’01%, operaciones < 250 € si ratio <0’06% y  operaciones < 100 € si ratio <0’13%. 

  • Lista blanca de beneficiarios. Esta excepción es la única que no la puede solicitar el comercio. Solo afecta a entidades emisoras de sistemas de pago, que han habilitado protocolos por los que sus clientes les han reportado sus “comercios de confianza” y les han autorizado para que no se aplique autenticación cuando compren en ellos.

Y ¿Cómo se enviarán las operaciones en el nuevo entorno de pagos?

EMVco es la asociación que, entre otros, estandariza los pagos eCommerce autenticados según protocolo 3D-Secure. Este protocolo es el utilizado, por ejemplo, por las principales Marcas de tarjetas (Verified by Visa, Mastercard Secure Code, …). EMVco ha emitido nuevas especificaciones del protocolo 3DS adaptado a los requerimientos de PSD2/SCA. Se incluyen nuevos campos que obligatoriamente hay que enviar como, por ejemplo, los referidos a ciertos parámetros del navegador del comprador. También hay campos que solo se enviarán si el comercio se acoge a solicitar alguna excepción. 

Ya conocemos todas las normas y requisitos … ¿Y ahora qué?

Referido a autenticación por norma SCA, el plan de acción del gestor de un eCommerce dependerá de como se estén procesando actualmente los pagos en tienda:

  • En comercios que actualmente ya estén enviando todas las operaciones en Compra segura, las acciones han de ser mínimas o, en función de quien le provea el servicio de cobro, serán nulas. Tan solo le afecta la obligatoriedad de ampliar la información que envía en cada orden de pago. No obstante, si la plataforma o banco que le facilita el TPV Virtual, tiene la habilidad de obtener y auto-completar dicha información; no será necesaria ningún desarrollo ni acción por el comercio para estar preparado en Septiembre.
  • En cambio, aquellos comercios que actualmente envían todas o ciertas operaciones en Compra No Segura, sí que deberán implementar una estrategia de pagos. Deberán analizar “exclusiones” y “excepciones” a SCA y, si consideran que pueden aplicar alguna de ellas, deberán programar para envío de pagos a TPV Virtual, los campos condicionales según manual técnico que le facilite su plataforma o banco.

Toda operatoria que no esté “exenta” o se pueda acoger a una “excepción”, deberá enviarse obligatoriamente con autenticación. 

En ambos casos, es muy recomendable intensificar durante las primeras semanas después del 14 de Septiembre, los controles sobre la conversión de los pagos en sus tiendas online. Si se detectan incrementos inusuales en los ratios de denegaciones, deberían contactar con banco o plataforma de pagos para que les asesore.

Impacto

¿Qué te pareció este artículo?

Recomendar

Recomendar

Si te pareció interesante este artículo, sé el primero en recomendarlo.



Source link

Advertisements

Leave a Comment

Your email address will not be published. Required fields are marked *

*
*