Request to Pay
A request for payment, not a pull: pain.013 asks, pain.014 answers, and a normal credit transfer settles — the payer stays in control.
L0 Explain simply
An everyday analogy: Request to Pay is a polite knock, not a hand in your pocket. A direct debit lets a company pull money from your account on a standing permission; Request to Pay flips that around — the person owed money sends you a request, and you decide then and there to pay it, part-pay it, ask for more time, or say no. Nothing leaves your account until you choose. When Example Supplies Ltd is owed money by Maya Chen, it does not reach into her account; it sends her a request, and her Bank Alfa app shows it like a message awaiting her answer. (SYNTHETIC / TRAINING ONLY — every person and firm named here is fictional.) The request is only a message; if Maya agrees, an ordinary credit transfer does the actual paying — Request to Pay never moves money by itself.
L1 Core concepts
Request to Pay (RtP) is a messaging layer that sits on top of existing credit-transfer rails. In the European scheme, SEPA Request-to-Pay (SRTP), a creditor's payment service provider sends a payment-request — carried as a pain.013 message — through an RtP service to the debtor's PSP, which presents it to the payer. The payer responds — accept now, accept later, decline, or in some rulebooks part-pay — and that answer travels back as a pain.014. Crucially, the request and the response carry no money: if the payer accepts, settlement is a separate, ordinary payment, typically an SCT-Inst instant credit transfer the payer's bank pushes to the creditor. The same pattern appears elsewhere — the UK's Request to Pay and India's UPI-collect are parallels — because the idea is rail-agnostic: standardise the ask and the answer, and let a normal push payment settle it.
L2 Practitioner view
For practitioners the appeal of RtP is control and context without giving up finality. Because the payer pushes the payment, there is no mandate to police and no pull to unwind, so the collection-request model reduces the unauthorised-debit and indemnity-refund exposure that direct debits carry. The request can carry rich remittance data — an invoice reference, a due date, options to pay in full or in part — so reconciliation improves and 'was this the right amount?' is settled before money moves. The trade-offs are honest. Settlement finality cuts both ways: an instant credit transfer is hard to reverse, so consumer protection shifts from an automatic refund right toward dispute-with-the-creditor. Adoption depends on reach — both banks and the RtP service must support the scheme — and on the payer actually responding, since an unanswered request simply expires with nothing paid, which is calm but not collection.
L3 Technical details
Strictly speaking, Request to Pay is a family of scheme-specific rulebooks, not one protocol, and this topic teaches the shared pattern rather than any single rulebook's fields — the detail of the SEPA Request-to-Pay rulebook was not re-verified here. What is stable across implementations is the split of duties: the RtP messaging layer standardises the request and response — in SRTP, the ISO 20022 pain.013 and pain.014 messages — while settlement is delegated to a normal payment scheme, in the euro area an SCT-Inst credit transfer under the EPC rulebook. That separation is the design's point: the request layer can evolve — new statuses, richer data, new channels — without touching how money clears, and the same request could in principle be settled by a non-instant SCT where instant reach is missing. The open question for any deployment is liability wording: because settlement is a push the payer authorised, where a disputed or mistaken payment lands is set by the creditor relationship and local law, not by an automatic scheme refund.
Sources & standards2
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
SEE THE PAYMENT MOVE
Read the steps as text
- 04ProcessingMaya accepts, defers, or declinesMaya Chen (debtor)
Control sits with the debtor. Maya can pay now, ask for more time, pay a different amount by agreement, or decline outright. On the happy path she accepts the request in full.
- 07SettlementThe transfer settles between the banksBank Alfa (debtor agent) → Northstar Bank (creditor agent)
The instant transfer settles across the banks' settlement accounts in central bank money within seconds. Only now has the EUR 120.00 truly moved from Bank Alfa to Northstar Bank.
- DR Bank Alfa settlement account — EUR 120.00
- CR Northstar Bank settlement account — EUR 120.00
- 08PostingNorthstar credits Example SuppliesNorthstar Bank (creditor agent)
Northstar Bank credits the creditor and can reconcile the payment to the original invoice reference from the request. The cycle closes: request raised, accepted, paid, settled, and matched.
- CR Example Supplies account at Northstar Bank — EUR 120.00
Sources for this topic2
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.