SEPA Request-to-Pay
Request-to-pay lets a business send a payment request straight into a customer's banking app. The customer accepts it there, with strong authentication, and the money moves as an instant transfer, bank to bank. No card, no card network, no paper mandate.
It is a European scheme: run by the European Payments Council, the body that defines SEPA, at the request of the ECB's Euro Retail Payments Board. The rulebook was first published in 2020, went live in June 2021 and is now at version 4.0. The EU's Instant Payments Regulation obliges banks across the euro area to send and receive instant transfers, which is the rail request-to-pay rides on.
How a request travels
- The request is createdThe merchant builds a payment request: amount, reference, due date and its account. It goes to its own request-to-pay provider.
- Validated and routedThe provider checks format and identity, stamps it and routes it to the customer's provider. Everything travels as ISO 20022 messages.
- Presented to the customerThe request shows up inside the customer's banking app, with all the details, before any money moves.
- The customer decidesAccept, reject or pay later, confirmed with strong customer authentication. No paper mandate, no card number typed anywhere.
- The answer travels backThe status report returns through the same path with a reason code, so the merchant knows at once where it stands.
- The money movesAn instant credit transfer settles bank to bank in under ten seconds. Irrevocable: no chargeback window to reserve for.
request and status messages money
Why it replaces cards
A card payment has four parties and a network in the middle, each taking a fee and adding a day. A request-to-pay settles between the two banks directly. Same start, same finish, two fewer intermediaries.
Versus direct debit
In Spain, recurring collections still run on SEPA Direct Debit, a scheme designed for an offline world. These are the five problems my thesis set out from, and what request-to-pay does with each.
| Direct debit | Request-to-pay | |
|---|---|---|
| Authorisation | A paper or PDF mandate, signed once, kept for 14 months after the last charge | Digital consent on each request, with strong customer authentication |
| Refunds | No-questions-asked for 8 weeks; 13 months if the mandate is disputed | None. The transfer is irrevocable once the customer accepts |
| Money available | 5 to 8 calendar days | Under 10 seconds |
| Failed collections | R-transactions with their own codes, fees and manual follow-up | A reason code in the status report, before any money moves |
| Online checkout | Awkward: paper mandates don't fit a checkout | Native: QR codes, deep links, APIs |
| Fraud exposure | Friendly fraud through late refunds | Low: authenticated consent and no chargeback window |
What I built
My degree thesis at the University of Valladolid (June 2025, highest honors) explains the scheme and demonstrates it: a prototype that runs the whole life of a request across the four corners. A Flask API with a state machine for every request, timeouts and rejection paths included; SQLAlchemy for persistence; a web interface where each actor logs in and sees requests change state live over Socket.IO. It follows the EPC rulebook flow step by step, and leaves out what a prototype can't do: the real directory of participants and ISO 20022 exchange with live banks. I wrote it while working on payments R&D at Innopago.