SEPA Request-to-Pay
Published on
28/08/2026
Updated on
28/08/2026
Reading time
5 min
Definition
SEPA Request-to-Pay (SRTP) is the process by which a payee requests a payer to initiate a payment. The payee sends a structured payment request; the payer decides whether and when to settle it.
Crucial to understanding this: SRTP is not a payment method. It does not move money; instead, it transmits a message that precedes a payment. The payment itself is subsequently executed as an SCT(opens in new tab) or a real-time transfer (SCT Inst(opens in new tab)). For this reason, the EPC(opens in new tab) does not list SRTP among its payment methods but rather as a separate, parallel scheme—comparable to Verification of Payee(opens in new tab).
Distinction from direct debit
A comparison with the SDD(opens in new tab) (SEPA Direct Debit) is tempting but misleading. While both serve to collect outstanding receivables, control rests with different parties.
With direct debit, the creditor collects the funds based on a mandate; the payer can subsequently object—in the case of the core direct debit, for up to eight weeks without providing a reason. With SRTP, the creditor makes a request, and the payer initiates the payment themselves. The resulting transfer is irrevocable.
For the creditor, this means no mandate management and no R-transactions(opens in new tab) resulting from returned debits—but also no certainty that payment will be made.
The variants of the requirement
The rulebook distinguishes between three basic forms based on the timing of consent and payment:
| Variant | Meaning |
|---|---|
| Accept Now / Pay Now | The payer agrees immediately, and the payment is triggered instantly. |
| Accept Now / Pay Later | The payer agrees immediately, and the payment is made on the agreed date. |
| Accept Later / Pay Later | The payer decides later and pays later. |
This is controlled via two time specifications in the request:
- Expiry Date/Time – by when the payer must accept or reject. The deadline can be up to three months.
- Requested Execution Date/Time – when the payment is to be made (compare Due Date(opens in new tab)).
This combination results in a practical range of options: from immediate payment and invoicing with a set payment deadline to a payment request that the payer can review and schedule at their leisure.
Roles and Process
SRTP follows a four-party model:
1. Payee: Creditor(opens in new tab) making the request
2. Payee’s SRTP Service Provider: service provider/bank
3. Payer’s SRTP Service Provider: service provider/bank
4. Payer: the debitor(opens in new tab) who receives the request and makes the decision
Notably, the service providers involved need not be payment service providers (PSPs). Unlike EPC payment schemes, SRTP is explicitly open to non-PSPs as well—such as invoicing and software service providers.
The EPC Directory Service (EDS) is used to locate the appropriate service provider; this is the same infrastructure employed for Verification of Payee(opens in new tab).
The payer can respond in three ways: a positive response (acceptance), a negative response (rejection citing a specific reason code), or no response at all (in which case the request expires at the designated time). Additionally, the scheme accommodates a “reject” prior to standard processing, a “request for cancellation” initiated by the payee, and a “status request” to check on the processing stage.
Messages
The exchange between service providers is described in the rulebook via data sets (DS-01 for the request from the recipient to their service provider, DS-02 for the transmission between service providers, DS-03 for the presentation to the payer, DS-07 for the payer’s response, and others for cancellation and status inquiries).
From a technical perspective, this is based on the ISO 20022 messages pain.013 and pain.014(opens in new tab): the payment request and the corresponding status report.
Origins and Current Status
The initiative stems from a mandate issued by the Euro Retail Payments Board. The EPC commissioned a working group in November 2020, published the initial rulebook on November 30, 2020, and brought it into effect on June 15, 2021.
As of August 2026, Version 4.0 is in force; it was published on November 29, 2024, and became effective on October 5, 2025—the same day the SCT Inst Rulebook 2025 came into effect. The primary focus of this version was to simplify the scheme.
However, adoption has fallen short of expectations. As of November 2025, only three participants and three technical service providers were listed in the register.
It is highly questionable whether SRTP will gain traction. Banks with large numbers of retail accounts—representing the payers—must not only handle the technical implementation within their core banking systems but also manage communication with their account holders. Since this effort generates no revenue, the banks lack a viable business case.
Use cases
Many companies (and their banks or service providers) see many wonderful opportunities for their own benefit in SRTP:
- Electronic invoice – the payment request includes the invoice reference, facilitating the allocation of incoming payments
- E-commerce – payment directly from the account, bypassing card networks
- Recurring payments – an alternative to direct debit when the payer wishes to retain control