Técnico

Request to Pay

SEPA Request-to-Pay (SRTP) — solicitud de pago

Scheme del EPC que estandariza las solicitudes de pago entre PSP. Permite que un beneficiario (comercio, acreedor) envíe una solicitud de pago al pagador, que decide si la acepta y la ejecuta (normalmente como un SCT Inst). Es el componente subyacente de Wero merchant y de los pagos de comercio electrónico en SEPA Instant.

Definición

Request to Pay (solicitud de pago), o SRTP por su nombre completo en el EPC, es un scheme estandarizado por el European Payments Council (rulebook v1 en noviembre de 2020, en vigor desde el 15 de junio de 2021).

Permite que un beneficiario (comercio, acreedor o particular) envíe una solicitud de pago a un pagador, que decide aceptarla o rechazarla y, a continuación, inicia un pago (normalmente un SCT Inst). Es la capa de solicitud que complementa la capa de ejecución (SCT / SCT Inst): la solicitud pasa a ser digital, estructurada y trazable, donde antes el beneficiario tenía que comunicar sus datos bancarios por fuera. El SRTP es el componente subyacente de Wero merchant, del pago contra entrega, del cobro digital y de las facturas B2B.

Cómo funciona

Cinco acciones componen el scheme: creación de la solicitud, entrega al pagador, decisión (aceptar, rechazar o aceptar con modificación), ejecución (normalmente SCT Inst) y confirmación al beneficiario.

Características técnicas

  • Mensajería: ISO 20022 (pain.013 para la creación, pain.014 para la respuesta).
  • Transporte: libre (API REST, AS4, mensaje MX).
  • Sin transferencia de dinero: el SRTP es solo la capa de solicitud; la ejecución es independiente.
  • Sin obligación de aceptar: el pagador mantiene el control (a diferencia del SDD).
  • Multicanal: web, app, correo electrónico, código QR, NFC.

Arquitectura del EPC

El EPC publica el rulebook; existen varios operadores de enrutamiento (EBA Clearing desde 2021, Wero/EPI, hubs privados). La adopción sigue siendo lenta, pero debería acelerarse con el IPR (SCT Inst gratuito obligatorio en octubre de 2025), el despliegue de Wero merchant y la presión de los comercios para reducir los costes de adquirencia.

Casos de uso

  • Comercio electrónico: un botón "Pay with Wero" o "Pay by Bank"; un SRTP enviado al banco del cliente, confirmación + SCA y, después, SCT Inst. Coste esperado para el comercio del 0,1 al 0,5% frente al 1–3% de la tarjeta.
  • Cobro: empresas de energía, telecomunicaciones y aseguradoras envían solicitudes estructuradas en lugar de recordatorios por correo, reduciendo el DSO y la dependencia del SDD.
  • B2B: facturas con SRTP integrado, pagadas en un clic — competencia directa al SDD.
  • Pago contra entrega: inmobiliario, automoción, mobiliario de gama alta.
  • P2P evolucionado: pedir dinero a un allegado sin intercambiar datos bancarios (Wero P2P usa SRTP).

Ventajas

  • Beneficiario: coste casi nulo (SCT Inst), sin contracargo (irrevocable), abono en menos de 10 segundos, conciliación mediante un end-to-end ID.
  • Pagador: autenticación en su propia app bancaria, control de la decisión, sin necesidad de tarjeta.
  • PSP del pagador: mayor implicación del cliente, con VoP y contexto integrados en la prevención del fraude.

Límites y retos

  • Sin protección al comprador tipo contracargo (un freno en el B2C).
  • Cobertura de bancos todavía parcial.
  • La UX del checkout debe alcanzar el nivel del pago en un clic de las tarjetas.
  • Notificación push que presupone una app bancaria activa.
  • Fuerte inercia del ecosistema de tarjetas.

Comparación internacional

País / SistemaSolicitud de pago
UE SEPASRTP (EPC)
Reino Unido Pay.UKRequest to Pay (2020)
Brasil PixPix Cobrança / Cob Garantido
India UPIUPI Collect Request
SueciaSwish

La UE va por detrás de Brasil y la India, pero el IPR y Wero están acelerando el ritmo.

Lo que Request to Pay no es

  • No es una transferencia de dinero: es una solicitud; la ejecución es independiente.
  • No es un adeudo SDD: no hay autorización previa, sino consentimiento explícito en cada solicitud.
  • No es obligatorio para el pagador, que puede rechazarlo sin penalización.
  • No es una API PIS de la PSD2: el SRTP es un scheme entre PSP, mientras que el PIS es una API expuesta por los ASPSP — aunque ambos convergen.
  • No es una wallet: Wero lo usa como rail, pero el SRTP no es una wallet.

En el ecosistema PSD2 / Open Finance

El SRTP es el complemento natural del IPR y del PIS: el PIS inicia del lado del pagador (a través de un TPP), mientras que el SRTP envía una solicitud del lado del beneficiario (validada en la app bancaria). Ambos coexisten y pueden combinarse — la visión "Open Banking 2.0": transferencias instantáneas, gratuitas, push o pull, integradas en la experiencia del cliente.

Ejemplos concretos

  • EBA Clearing SRTP: en producción desde 2021, con varias decenas de bancos participantes.
  • Wero merchant: envía el pago al pagador en el checkout, que responde con un SCT Inst.
  • Crédit Agricole / BPCE: pilotos de 2024–2025 en cobro.
  • iDEAL (NL): un modelo parecido pero nacional, que Wero irá sustituyendo de forma progresiva.
  • Pix Cobrança (Brasil): un modelo dinámico con código QR para los pagos a comercios.
  • BNPL: enviar un SRTP en cada vencimiento, en lugar de un adeudo, mejora la UX y la tasa de éxito.
  • B2B: una factura emitida por Pennylane o Sage con SRTP integrado, pagada en un clic desde el banco.

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.