SEPA Request to Pay: asking for a payment instead of pulling it

SEPA Request to Pay, SRTP, is the European Payments Council scheme that lets a payee ask a payer for a payment, instead of pulling the money by direct debit or waiting for the payer to remember to send it. The payee, for example a utility company, sends a request for EUR 120 to the payer bank, the payer sees the request on their banking app, checks the amount and the due date, and approves or rejects it, and only then does the payment travel, as a SEPA Credit Transfer or a SEPA Instant Credit Transfer. The scheme launched in June 2021, and it is not a payment instrument itself, it is a request that leads to a payment. Source: European Payments Council, SEPA Request to Pay Rulebook. Why SRTP exists is that the existing ways to collect money each had a weakness. A direct debit pulls the money, which the payer may not want, and which can be refunded for eight weeks, so the payee bears refund risk. A credit transfer depends on the payer remembering to send it, which the payer often does not, so the payee chases late payments. A card payment costs the payee interchange and can be charged back. SRTP answers by letting the payee ask, the payer approve, and the payment travel as a credit transfer, which is final and cannot be refunded like a direct debit, so the payee gets certainty and the payer keeps control, and both sides know where they stand. The parties are the payee, which sends the request, the payer, which approves or rejects it, the payee bank and the payer bank, which carry the request and the payment, and the scheme, which sets the rules. The request travels from the payee bank to the payer bank, the payer sees it in their own banking app, and the approval triggers a credit transfer from the payer account to the payee account. The payer bank must show the request clearly, with the amount, the due date, the payee name and the reference, because a payer who approves a request they did not understand will complain, and the complaint will be about the request, not the payment. How it works is shown by a worked example. A utility company in Lyon bills a customer EUR 120 for electricity, due on 15 November, and sends a SEPA Request to Pay on 10 November. The customer sees the request on their banking app on 10 November, checks that EUR 120 matches the bill, and approves it for payment on 15 November. On 15 November the customer bank sends a SEPA Instant Credit Transfer of EUR 120, the utility account is credited within seconds, and the utility reconciles the payment against the invoice automatically, because the request carried the invoice reference. Without SRTP the customer might have forgotten to pay, the utility would have sent a reminder, and the payment would have arrived late, with a late fee and a customer complaint. On success the payee is paid on time, the payer controls the payment, and the payment is final, so neither side bears the refund risk of a direct debit. On failure the payer can reject the request, or ignore it, and then the payee must chase the payment by other means, which is the same as a forgotten credit transfer, so SRTP does not guarantee payment, it only makes payment easy. The failure that matters most is a request for the wrong amount, because a payer who approves EUR 1,200 instead of EUR 120 has made an irrevocable credit transfer, and the recovery is a request to the payee to return the excess, which depends on the payee cooperation. The data in a SRTP request is the payee identification, the payer identification, the amount in euros, the due date, the remittance information and the reference, plus the requested execution date. The amount and the due date are the fields that matter most, because a request with the wrong amount or the wrong date will be approved in error or rejected in confusion, and the payee must get them right. A BA must specify the request display, the approval and rejection flows, the execution date handling, the reference, and what happens when a request is ignored, because each of those is a customer experience and a source of complaints. Edge cases show the limits. A request that is sent to a payer whose bank does not participate in SRTP cannot be delivered, and the payee must fall back to a direct debit or an invoice, so the payee must know which of its customers are reachable by SRTP. A request that is approved but the payer account has insufficient funds on the execution date will fail, and the payee must be told, because a silent failure is a late payment the payee discovers too late. A request for a recurring payment, such as a monthly subscription, can be sent each month, but the payer must approve each one, so SRTP is not a substitute for a direct debit mandate where the payer wants the payment to happen automatically. The effect on the bank is a service it can offer to billers, which reduces late payments and customer service calls, and a new flow to support in the banking app, which must show the request clearly and record the payer decision. The effect on the customer is a payment they control, with the amount and date shown before they approve, which builds trust and removes the fear of a direct debit they did not expect. The effect on the payee is fewer late payments, fewer reminders, and automatic reconciliation, because the payment carries the invoice reference from the request. What a BA, PO or SME must understand is that SRTP is a request, not a payment, and the payment that follows it is a credit transfer, with all the finality and irrevocability that implies. The requirement must name the request display, the approval and rejection flows, the execution date, the reference, the fallback when the payer bank does not participate, and the handling of insufficient funds. The test is to send one request, approve it, and check that the payment arrived on the due date with the invoice reference, because if the reference is lost, the reconciliation fails. Further reading: European Payments Council, SEPA Request to Pay Rulebook; European Payments Council, SCT and SCT Inst Rulebooks 2025. Last reviewed 7 November 2026.