3DS

PSD2

La segunda Directiva de Servicios de Pago (PSD2) será de cumplimiento obligatorio a partir del 31 de Diciembre de 2020. Esta directiva afecta a los pagos realizados en la zona económica europea y obliga a que todos los pagos en los que el usuario esté presente se lleven a cabo de forma segura mediante 3DS. Adicionalmente, ya no podrán lanzarse pagos no seguros sin la presencia del usuario salvo que la tarjeta haya realizado al menos un pago seguro mediante 3DS anteriormente.

Los siguientes tipos de servicios de pago se verán afectados por a PSD2 a partir del día 31 de Diciembre de 2020:

• REDSYS
• EVOSNAP
• CREDORAX
• CLEARHAUS

Normativa

La PSD2 será de obligado cumplimiento siempre y cuando se cumplan dos condiciones:

• El servicio de pago está localizado dentro de la Eurozona.
• La tarjeta ha sido emitida desde un país dentro de la Eurozona.

La primera condición se cumplirá siempre en los servicios de pago mencionados anteriormente, por lo que el único factor que puede influir a la hora de aplicar la normativa PSD2 es el país de procedencia de la tarjeta. Las tarjetas procedentes de un país fuera de la Eurozona están exentas de cumplir la PSD2. Sin embargo, al no poder conocer hasta el momento del cobro si la tarjeta está exenta o no, recomendamos que todos los pagos se realicen de forma segura mediante 3DS cuando el usuario esté presente.

Si se intenta realizar un pago no seguro y éste no puede llevarse a cabo debido a la PSD2:

• Si el usuario está presente (pago a través de la carta de pago) el usuario será redirigido al 3DS.
• Si el usuario no está presente (pago directo) la API devolverá un enlace al que el usuario deberá ser redirigido para que lleve a cabo el 3DS. Este tipo de pagos también se conocen como pagos por webservice o pagos MIT (Merchant Initiated Transactions)

Recomendamos utilizar pagos tokenizados una vez se haya tokenizado la tarjeta, ya que éstos siempre utilizan 3DS y permiten aprovechar todas las ventajas que ofrece la PSD2. Los pagos no seguros a través de webservice deben utilizarse solo cuando el usuario no está presente, por ejemplo, para cobrar una subscripción.

Ventajas

Hasta ahora los pagos seguros utilizaban siempre la versión 3DS 1.0, la cual obliga a que el usuario introduzca una código que recibe en su teléfono móvil, dando lugar a una fricción que podía resultar en que el usuario abandonase el proceso de compra. Las nuevas versiones del protocolo 3DS versión 2 permiten saltarse este paso en determinadas circunstancias:

• El importe de la operación es bajo (menos de 30€) o el importe total de las últimas 5 operaciones no supera los 100€.
• El umbral de fraude del comercio es bajo y la operación no supera los 100, 250 o 500€.
• Se proporcionan suficientes datos personales del usuario como su nombre y apellidos, email, dirección de envío, teléfono móvil de contacto...

Las anteriores circunstancias reciben el nombre de exenciones y Paylands las solicita siempre que sea posible para reducir la fricción al mínimo durante el 3DS.

Si alguna de las anteriores condiciones se cumple, es posible que el pago finalice sin necesidad de que el usuario intervenga. A esto se le conoce como pago 3DS frictionless. Si por el contrario las condiciones anteriores no se cumplen el usuario deberá llevar a cabo un challenge, el cual es una de las siguientes acciones:

• Introducir un código que recibe en su teléfono móvil, conocido como OTP (One Time Password).
• Confirmar el cobro desde la aplicación móvil de su banco.

Independientemente de lo que suceda, el pago se considerará autenticado mediante 3DS.

Pagos sin la presencia del usuario

En general, el usuario debe estar presente en el momento del pago y éste debe realizarse obligatoriamente de forma segura con 3DS. Entonces, cómo se pueden realizar pagos sin que el usuario esté presente, como por ejemplo subscripciones? La PSD2 contempla excepciones siempre y cuando la tarjeta haya sido utilizada antes en un pago seguro.

Solo algunos pagos pueden llevarse a cabo sin la presencia del usuario:

• Pagos recurrentes o a plazos (subscripciones, préstamos...)
• No-show en hoteles

Estos pagos se llevarán a cabo por WebService. Recomendamos indicar el motivo del cobro al crear la orden en el parámetro extra_data.cof.reason. Estos son los posibles valores de ese campo:

• RECURRING (pagos recurrentes, subscripciones...)
• INSTALLMENTS (pagos a plazos, préstamos...)
• NO_SHOW (cuando una persona no se presenta el día de la reserva en el hotel)
• DELAYED (pagos por servicios ofrecidos cuya cantidad se desconoce al principio: minibar, reparaciones, multas...)
• OTHER (cuando no se sabe a priori el motivo del cobro. Por ejemplo, en el caso de un hotel que no sabe si tendrá que cobrar la reserva cuando se presente el usuario, lo cual sería RECURRING, o un NO-SHOW si no se presenta)

Si las condiciones mencionadas se cumplen, el pago finalizará normalmente sin necesidad de que intervenga el usuario. Si por lo contrario alguna de esas condiciones no se cumple o es imprescindible que el usuario se autentique, la API devolverá un enlace de pago el cual puede enviarse al usuario para que finalice el pago mediante 3DS. Esta decisión de si el usuario debe autenticar una operación MIT es 100% del banco, y la toma en base a sus propias reglas internas. Desde Paylands siempre se enviará el máximo de información posible al banco emisor para que intente finalizar la operación sin que se requiera intervención del usuario, pero la decisión final será del propio banco del usuario.

El primer pago con una tarjeta siempre se deberá realizar a través de la carta de pago o de forma tokenizada para que el usuario se autentique por primera vez y poder optar a esta modalidad en pagos posteriores. Los pagos sin la presencia del usuario están reservados únicamente para pagos que inicia el comercio, también conocidos como MIT (Merchant Initiated Transaction).

Cómo adaptarse a los cambios

Si tu comercio realiza únicamente pagos seguros mediante 3DS no es necesario que hagas nada. Una vez llegue la fecha, Paylands cambiará la forma en la que se procesan los pagos. Los clientes notarán que el proceso es ligeramente distinto en función del banco emisor de su tarjeta, sin embargo como comercio no notarás ninguna diferencia.

Si por el contrario realizas pagos no seguros mediante WebService cuando los usuarios no están presentes en el momento del pago, será necesario que soportes modalidades de pago seguras, como la carta de pago o pago tokenizado. También deberás tratar correctamente la respuesta del pago mediante WebService cuando se devuelve el enlace de pago.

Todos los comercios empezarán a operar con la nueva normativa a partir del día 1 de Enero, sin necesidad de llevar a cabo ninguna acción. Sin embargo, si quieres adelantarte y que tu comercio empiece a operar con PSD2 antes de la fecha límite, puedes enviar un correo a soporte@paylands.com indicando tu FUC (Código de comercio de 8-9 cifras) y el banco a través del cual opera tu comercio.

Datos extra

Para aumentar las probabilidades de que no sea necesario que el usuario se autentique para finalizar el pago, se pueden enviar opcionalmente datos extra. Estos datos deben incluirse en el campo extra_data al crear una orden con el formato detallado en la sección "Pagos > Orden de pago".

Preguntas frecuentes (FAQ)

Podré realizar pagos sin la presencia del usuario si el pago seguro tuvo lugar antes de la entrada en vigor de la normativa?

Sí, en los servicios REDSYS y EVOSNAP. En los otros servicios sí será necesario volver a realizar un cobro seguro antes de poder volver a lanzar cobros sin la presencia del usuario.

Puedo lanzar un pago 3DS para autenticar al usuario en un servicio y luego lanzar un pago sin la presencia del usuario por otro?

No. Es necesario autenticar al usuario al menos una vez por servicio de pago. Los servicios pueden ser diferentes siempre y cuando sean del mismo tipo.

Exenciones

Actualmente soportamos las exenciones de Análisis de Riesgo (TRA) y de Bajo importe (LV) en el servicio de pago Redsys. Para solicitarlas, basta aportar la siguiente información en el campo extra_data al crear la orden:

"extra_data": {
        ...
        "sca": {
            "exemptions": ["TRA", "LV"]
        },
    }

También es posible solicitar que no se aplique ninguna exención dejando el valor de exemptions como una lista vacía:

"extra_data": {
        ...
        "sca": {
            "exemptions": []
        },
    }

Si el valor de exemptions no se indica explícitamente, por defecto se solicitará la exención de Bajo importe (LV) si ésta cumple los requisitos establecidos. Tras el pago, si se ha llegado a solicitar alguna exención, su nombre se incluirá bajo la clave order.threeds_data.exemption. Si no se solicitó, o no se pudo solicitar ninguna exención, su valor será null.

"threeds_data": {
      "version": "...",
      "flow": "...",
      "sca_requested": ...,
      "status": "...",
      "eci": "...",
      "exemption": "TRA"
  }

Finalmente, que una exención sea solicitada no implica que haya sido aceptada. Para poder entender mejor si una exención fue aceptada o no, puede verse el campo threeds_data.flow. Si la exención fue solicitada pero su valor es CHALLENGE_ONLY o FULL, significa que no se aceptó. Si su valor es FRICTIONLESS o FINGERPRINTING_ONLY, significa que puede que sí fuera aceptada. No hay forma de conocer al 100% si una exención fue aceptada, solo si fue rechazada.

Tampoco puede saberse si una exención fue aceptada por el issuer (banco del usuario) o el acquirer (banco del comercio).

Requisitos

Las exenciones deben cumplir ciertos requisitos antes de poder ser solicitadas. Se pueden solicitar hasta 2 exenciones, de las cuales como mucho se solicitará una. Las exenciones se solicitan en el orden en el que se indican en la petición. Los requisitos para solicitar cada exención son:

Requisitos generales

• La tarjeta debe pertenecer a la zona económica europea (EEA).
• El servicio de pago debe soportar la solicitud de exenciones (por ahora solo lo soporta Redsys).
• El terminal asociado al servicio de pago empleado debe tener activa la exención a solicitar.
• La moneda empleada debe ser el Euro.
• El pago debe ser seguro y la versión del 3DS debe ser 2.1 o 2.2.
• La tarjeta debe tener al menos un pago exitoso en el último año.

Análisis de riesgo (TRA)

• El importe debe ser igual o menor a 500€, 250€ o 100€ dependiendo de la tasa de fraude medio del comercio igual o inferior a 0.01%, 0.06% o 0.13%, respectivamente.
• Para aprovechar al máximo esta exención se recomienda indicar la siguiente información en el campo extra_data:
  • Email
  • Número de teléfono
  • Dirección de cobro y de envío (pueden ser la misma).

Bajo importe (LV)

• El importe debe ser igual o menor a 30€.