SEPA Request-to-Pay (SRTP) is a scheme managed by the European Payments Council that sets common rules and message formats for requesting a payment. A payee, such as a merchant, utility or public body, sends an electronic request through a service provider to a payer. The payer sees the amount, the payee and the reason for the request in their banking app or another channel and chooses to accept or refuse. If the payer accepts, a payment is made, normally by credit transfer.
SRTP is a messaging scheme, not a payment instrument. It carries the request and the response but does not move money. The payment that follows travels over an existing rail, typically a SEPA Credit Transfer or a SEPA Instant Credit Transfer. It is the European scheme-level implementation of the general idea of request to pay, and it covers the whole Single Euro Payments Area.
History
The scheme grew out of work by the Euro Retail Payments Board, a forum chaired by the European Central Bank, which identified request to pay as a missing piece for making instant credit transfers usable in shops, online and for invoices. The European Payments Council published the first SRTP rulebook in November 2020, and the scheme became operational on 15 June 2021. The rulebook has been revised regularly since then to add functions and to refine the conditions for participants.
How it works
The scheme uses a four-corner model. The payee and the payer each have a request-to-pay service provider, and the two providers exchange messages either directly or through a routing network.
- The payee creates a request stating the amount, the account to be paid, a reference and an expiry time, and passes it to its provider.
- The payee's provider validates the request and sends it to the payer's provider, which presents it to the payer.
- The payer accepts or refuses. The response travels back along the same path, and the payee is told the outcome.
- On acceptance, the payer's payment service provider initiates the credit transfer, with the payee's details and reference already filled in.
The messages follow ISO 20022. The request is a creditor payment activation request, known as pain.013, and the response is its status report, pain.014. A payee can also ask to cancel a request, and either side can send status enquiries.
The rulebook separates the moment of acceptance from the moment of payment, giving four combinations. A request can require the payer to accept now, as at a checkout, or allow acceptance later, as with a monthly bill. Payment can follow immediately on acceptance or on a later date. A shop purchase uses accept now and pay now with an instant transfer, while an invoice might use accept later and pay later, letting the payer approve today for payment on the due date.
Participants
Unlike the SEPA payment schemes, SRTP is open to providers that are not payment service providers. Banks, payment institutions, e-invoicing platforms and technology companies can join, provided they meet the scheme's legal, operational and security conditions and pass an independent assessment. A provider may act for payees, payers or both. The payer's provider must authenticate the payer, and because the eventual transfer is an electronic payment, strong customer authentication applies when it is initiated.
Use cases
- Bills and invoices. A biller sends a request in place of a paper invoice, and the payer approves it with the correct reference attached, which simplifies reconciliation. The scheme is designed to work with e-invoicing.
- E-commerce and point of sale. A merchant requests payment at checkout and receives an instant transfer, a form of pay by bank that avoids card fees.
- Government collections. Tax and fee demands can be delivered as requests.
- Person to person. One individual can ask another for money.
Comparison with direct debit
A SEPA Direct Debit also starts with the payee, but it works by pulling funds under a standing mandate, and the payer can claim a refund afterwards. With SRTP the payer approves each payment, and the resulting credit transfer is a push payment that cannot be refunded on demand. This gives the payee certainty and the payer control, at the cost of requiring action each time, though the rulebook allows for recurring arrangements.
Adoption and limitations
Take-up has been gradual. The scheme is optional, and its value depends on both the payee's and the payer's providers taking part, so reach was limited in its early years. National request-to-pay services in some countries developed separately. The Instant Payments Regulation, which obliges payment providers in the euro area to send and receive instant credit transfers and to offer verification of payee, is expected to strengthen the case by making the underlying instant payment universally available.
Fraud is a recognized concern. A request that appears in a trusted banking app could be used to trick a payer into approving a payment to a criminal, a variant of authorized push payment fraud. The rulebook therefore requires providers to identify and vet payees before they can send requests.