PSD3 y PSR: lo que los comercios realmente tienen que cambiar

Con la PSD2, las normas de conducta del día a día —plazos de reembolso, responsabilidad por fraude, gestión de reclamaciones— las fijaba una directiva. Las directivas no se aplican directamente. Cada uno de los 27 estados miembros tuvo que trasponer la PSD2 a su propia legislación nacional, y cada uno lo hizo con sus propios plazos, sus propias lagunas y su propia interpretación local. Un comercio que operaba en cinco países de la UE operaba, en la práctica, bajo cinco reglamentos ligeramente distintos, aunque todos afirmaran aplicar "la misma" directiva.

El nuevo paquete divide el trabajo de otra manera. La PSD3 sigue siendo una directiva y cubre principalmente la concesión de licencias, la supervisión y el acceso al mercado de las entidades de pago: el tipo de cuestiones que afectan al estatus regulatorio de su PSP, no a su checkout. Las normas de conducta que sí afectan a los comercios —responsabilidad por fraude, obligaciones de reembolso, requisitos de autenticación, gestión de reclamaciones— pasan al PSR, un reglamento. Los reglamentos se aplican de forma directa e idéntica en todos los estados miembros, sin trasposición nacional y sin margen para peculiaridades de redacción local.

Según el análisis jurídico de los textos acordados, se trata de una respuesta deliberada al problema de fragmentación que generó la PSD2: el PSR está diseñado para dar a comercios y PSP un único reglamento uniforme en lugar de 27 variantes locales (el análisis de Freshfields sobre los textos acordados). Para los comercios, esto significa que la revisión de cumplimiento que hace para su entidad alemana debería, una vez que se aplique el PSR, dar los mismos resultados que la revisión para su entidad irlandesa o portuguesa. Es una simplificación real, pero también significa que ya no existe el argumento de "el regulador local es más permisivo con esto" al que recurrir.

Las normas de responsabilidad de la PSD2 se construyeron alrededor de una idea bastante estrecha de transacción "no autorizada": la que el cliente no aprobó. El fraude ha evolucionado desde entonces. Las estafas de ingeniería social, en las que un estafador se hace pasar por un empleado del banco o convence al cliente para que autorice directamente una transferencia, generan técnicamente una transacción "autorizada" según el marco antiguo, lo que históricamente dejaba al cliente (y, por extensión, al comercio que dependía de ese pago) con menos vías de recurso.

El PSR amplía la responsabilidad en varias direcciones que importan a los comercios:

• El fraude basado en suplantación —cuando un estafador se hace pasar por el personal o la marca de un PSP— traslada más responsabilidad hacia los proveedores de servicios de pago, en lugar de dejar que el cliente absorba la pérdida.
• Los fallos al ofrecer o aplicar correctamente la autenticación reforzada del cliente (SCA) hacen responsable a la parte de la cadena que no la aplicó correctamente, lo que incluye a los acquirers y, en algunos flujos, a los comercios que eluden la autenticación.
• La gestión lenta de las notificaciones de fraude por parte de un PSP puede generar responsabilidad por sí misma, lo que busca empujar a bancos y PSP hacia una resolución más rápida de los informes de fraude en lugar de tratar cada reclamación como una investigación larga.

Para un comercio, el efecto práctico es que las disputas por fraude dependerán cada vez más de la evidencia de lo que ocurrió durante la autenticación, no solo de si el cliente dice que no autorizó el pago. Eso convierte sus registros de autenticación y sus datos de resultados de SCA en parte de la evidencia de la disputa, no solo en un registro de cumplimiento que se guarda y se olvida.

Uno de los cambios más concretos para los flujos de checkout tiene que ver con verificar que el nombre asociado a una cuenta coincide realmente con la persona a la que el pagador cree estar enviando dinero. Esto se apoya en el mecanismo de Verificación del Beneficiario (VoP, por sus siglas en inglés) ya exigido para las transferencias instantáneas en virtud del Reglamento de Pagos Instantáneos de la UE, y el nuevo paquete de pagos extiende esa lógica a más servicios de pago.

En la práctica, VoP significa que el banco del pagador comprueba el nombre del titular de la cuenta frente al IBAN antes de completar una transferencia, y señala al pagador cualquier discrepancia —"sin coincidencia" o "coincidencia parcial"— antes de que confirme el pago. Está dirigido directamente contra el fraude de transferencias autorizadas mediante engaño, en el que se engaña a un cliente para que transfiera dinero a una cuenta que no es la que cree.

Para los comercios, esto afecta a cualquier flujo en el que un cliente inicie una transferencia bancaria para pagarle: métodos de pago de cuenta a cuenta, pagos iniciados mediante banca abierta, o cualquier paso del checkout en el que muestre sus propios datos de beneficiario para que el cliente complete una transferencia:

• El nombre legal registrado en su cuenta bancaria de comercio debe coincidir exactamente con el nombre comercial que ven los clientes en su página de checkout, o los clientes empezarán a ver avisos de discrepancia que parecen señales de fraude aunque no haya ningún problema.
• Si opera bajo un nombre comercial distinto del de su entidad legal, este es el momento de alinearlos o de asegurarse de que su checkout explica claramente la discrepancia antes de que un cliente se encuentre con un aviso de VoP a mitad del pago.
• Cualquier documentación interna que recoja los datos de su cuenta de liquidación para fines de conciliación debe comprobarse frente a lo que realmente está registrado en su banco, ya que un registro obsoleto aparecerá como discrepancia para todos los clientes que usen un método basado en transferencia.

Este es un caso en el que una comprobación administrativa de cinco minutos —confirmar que el nombre registrado en su cuenta bancaria coincide con la marca de su tienda— evita una oleada de confusión en los clientes cuando las comprobaciones tipo VoP estén ampliamente en vigor.

La PSD2 daba a los bancos gestores de cuentas dos opciones para exponer datos de cuenta a terceros: una API dedicada o una interfaz alternativa (fallback) construida sobre sus propias pantallas de banca online de cara al cliente. En la práctica, las interfaces alternativas eran a menudo más lentas, menos fiables y de mantenimiento irregular, lo que hacía que los flujos de checkout basados en banca abierta —opciones de pago por banco, información de cuenta para evaluación de riesgo y funciones similares— fueran menos fiables que los pagos con tarjeta.

El nuevo marco endurece esto. Los bancos se enfrentarán a obligaciones más claras y ejecutables sobre el rendimiento de la interfaz dedicada, más cercanas a la paridad con la fiabilidad de sus propios canales de cara al cliente, con expectativas definidas de disponibilidad y tiempos de respuesta, en lugar del estándar de "esfuerzo razonable" laxamente aplicado que caracterizó parte de la implementación de la PSD2 (el análisis de MoFo sobre los desarrollos de PSD3/PSR).

Para los comercios que ofrecen o están valorando opciones de checkout de pago por banco u otras de cuenta a cuenta, esto importa de dos maneras:

• Menos intentos de autorización fallidos o con tiempo de espera agotado debería significar menos carritos abandonados en métodos de pago basados en transferencia, que históricamente tenían peor tasa de finalización que las tarjetas en parte por la fiabilidad de la interfaz.
• Si depende de servicios de información de cuentas para decisiones de riesgo —verificar la titularidad de la cuenta o comprobar saldos antes de enviar pedidos de alto valor—, esos flujos de datos deberían volverse más consistentes como base sobre la que construir procesos, en lugar de algo para lo que hay que construir lógica de reintentos y gestión de fallback.

Nada de esto elimina la necesidad de probar su integración contra el comportamiento real de los bancos una vez que las normas estén en vigor. Sí significa que la fiabilidad base contra la que está probando debería mejorar.

Esta es la parte que se omite en la mayoría de los resúmenes jurídicos. Esto es lo que se mueve en su lado del tablero.

Sus contratos con el PSP y el acquirer. Revise las cláusulas de asignación de responsabilidad en sus acuerdos de servicios de pago actuales. En los contratos de la era PSD2, el lenguaje de responsabilidad a menudo asumía la definición antigua y más estrecha de "transacción no autorizada" y las antiguas normas de exención de SCA. Una vez que se apliquen las disposiciones de responsabilidad del PSR, los contratos que no se hayan actualizado pueden referirse a estándares que ya no coinciden con la ley, lo que genera ambigüedad justo cuando necesita claridad: en medio de una disputa. Pregunte directamente a su PSP si sus condiciones estándar para comercios se actualizarán para reflejar la asignación de responsabilidad del PSR, y obtenga la respuesta por escrito en lugar de asumir que ya está resuelto.

• Su flujo de checkout. Tres cambios concretos que revisar:
• Confirme que el nombre legal vinculado a su cuenta de liquidación coincide con la marca de su tienda, para evitar avisos de discrepancia de VoP innecesarios en los métodos de pago basados en transferencia.
• Asegúrese de que su flujo de desafío de SCA (3DS o equivalente) se degrada de forma correcta: un cliente que abandona una compra porque un paso de autenticación falló técnicamente, en lugar de porque lo rechazó, es exactamente el escenario que las nuevas normas de responsabilidad están diseñadas para detectar, y no querrá estar en el lado equivocado de eso cuando se revise una disputa.
• Si ofrece pago por banco u otras opciones de cuenta a cuenta, planifique volver a comprobar las tasas de finalización una vez que las nuevas obligaciones de rendimiento de la API estén en vigor: los supuestos de fiabilidad sobre los que construyó su lógica de fallback pueden dejar de ser la restricción vinculante.

• Su proceso de disputas. La evidencia que decide una disputa de fraude o un contracargo está cambiando. Mientras que las disputas de la era PSD2 solían depender de si se aplicó SCA o no, las disputas de la era PSR dependerán con más frecuencia de cómo se aplicó, de si se ejecutó una comprobación de VoP y qué resultado dio, y de la rapidez con la que se escaló un informe de fraude. Eso significa que:
• Su equipo de soporte necesita acceso a los registros de resultado de autenticación, no solo al estado de la transacción, al responder a una disputa.
• Su documentación para la presentación de evidencia debe actualizarse para incluir los resultados de coincidencia/no coincidencia de VoP como campo estándar, una vez que esos datos existan en sus registros de transacción.
• Los acuerdos internos de nivel de servicio para escalar sospechas de fraude a su PSP deben endurecerse, ya que el retraso se está convirtiendo en un factor de responsabilidad y no en un paso administrativo neutro.

El paso de la PSD2 al PSR tiene menos que ver con la aparición de obligaciones nuevas de la nada y más con el cierre de lagunas ya existentes.

Los comercios que trataban la responsabilidad por fraude, la SCA y la evidencia de disputas como "lo que diga el banco local" descubrirán que esa respuesta ya no vale una vez que el mismo texto reglamentario se aplique en todos los estados miembros. El trabajo es administrativo —actualizar contratos, textos del checkout y plantillas de evidencia—, pero tiene que ocurrir antes de la aplicación general, no después de que la primera disputa bajo las nuevas normas revele el hueco.

Nada de esto exige rehacer su checkout desde cero. Exige tratar el contrato con su PSP, los datos registrados de su cuenta y las plantillas de evidencia de disputas como documentos vivos que necesitan una revisión en un calendario concreto, que es precisamente el objetivo de la lista de verificación siguiente.

La fecha exacta de aplicación general depende de cuándo publique el Diario Oficial el texto final, pero la secuencia está fijada. Utilice esto como un calendario de trabajo y no como una fecha límite fija, y confirme las fechas una vez se confirme la publicación en el Diario Oficial.

• Antes del cuarto trimestre de 2026 — Se espera la publicación en el Diario Oficial (junio-julio de 2026). Una vez publicada, calcule su fecha firme de aplicación general a 21 meses y añádala a su calendario de cumplimiento. Empiece ya la revisión del contrato con el PSP en lugar de esperar a la fecha límite.
• Durante 2027 — Confirme el plan de su PSP para actualizar las condiciones de comercio y reflejar la asignación de responsabilidad del PSR. Auditar el nombre legal registrado de su cuenta de liquidación frente a la marca de su checkout. Mapear qué flujos de checkout usan SCA y documentar la lógica de exención actual para poder compararla con los requisitos definitivos del PSR.
• Principios de 2028 — Pruebe su proceso de evidencia de disputas de extremo a extremo: ¿puede su equipo de soporte recuperar realmente los datos de resultado de SCA y de coincidencia de VoP de una transacción a petición, o requiere abrir un ticket de ingeniería? Resuelva ese hueco antes de que lo compruebe una disputa real.
• En la aplicación general (estimada marzo-abril de 2028) — Confirme que los contratos actualizados con el PSP están firmados, que el texto del checkout refleja cualquier requisito sobre el nombre del beneficiario, y que su documentación de disputas incluye los nuevos campos de evidencia. Trate la fecha de aplicación general como el momento en el que todo lo anterior ya debería estar funcionando, no como el momento en el que empieza a hacerlo.

Cost+ funciona con precios IC++ (Interchange Plus Plus) precisamente porque creemos que los comercios toman mejores decisiones cuando los componentes de un pago —interchange, scheme fee y nuestro margen— son visibles en lugar de estar agrupados. El mismo principio se aplica al cambio regulatorio: cuanto antes pueda ver qué está cambiando realmente en los requisitos de responsabilidad y evidencia, menos disruptiva será la transición. Si quiere hablar sobre cómo se ajusta su configuración actual de checkout y disputas al calendario del PSR, contacte con nuestro equipo o compruebe su estructura de tarifas actual frente a los precios low-risk publicados en nuestra web mientras revisa sus contratos.