Open Banking & Request to Pay / Learning brief
Request to Pay, explained
Your notes
In simple terms / 01
What this means in plain language
Request to Pay flips the direction of a bill: instead of pulling money on a mandate, the payee sends a request and the payer decides to accept, defer, decline, or part-pay. Follows a pain.013 request and a pain.014 response, then shows the money still moving as an ordinary instant credit transfer.
Request to Pay (RtP) flips the direction of a bill. Instead of a creditor pulling money on a standing mandate, the payee sends a request and the payer decides, each time, to accept and pay, defer, decline, or in some rulebooks part-pay. The request is only a message: nothing leaves the payer's account until they choose to pay. In the European scheme, SEPA Request-to-Pay (SRTP), the creditor's payment service provider sends a request carried as a pain.013 message through an RtP service to the payer's bank, which presents it; the payer's answer travels back as a pain.014. If the payer accepts, settlement is a separate, ordinary payment — typically an instant SEPA credit transfer the payer's bank pushes to the creditor. The same idea appears as the UK's Request to Pay and India's UPI-collect, because the pattern is rail-agnostic.
Key takeaways / 03
Three things to remember
- 01
Request to Pay is a request, not a pull: no money moves until the payer actively answers.
- 02
The request travels as a pain.013 and the payer's response as a pain.014; neither message carries money.
- 03
Settlement is a separate credit transfer, usually an instant one, so finality is high and there is no automatic mandate refund.
Practical use cases / 04
Where you would use this
A biller offers Request to Pay so the payer confirms the amount before any money moves, cutting unauthorised-debit disputes.
An operations team reconciles a pain.014 acceptance against the instant credit transfer that follows it.
A support agent explains to a payer that an ignored request simply expires with nothing paid, unlike a direct debit.
Worked example / 05
Put the idea into a real situation
(SYNTHETIC / TRAINING ONLY) Example Supplies Ltd is owed EUR 120.00 by Maya Chen. Instead of pulling the money, its bank Northstar Bank raises a payment request carried as a pain.013, routed through an RtP service to Maya's bank Bank Alfa, which shows it in her app. Maya accepts, and the acceptance returns as a pain.014. Only now does money move: Bank Alfa pushes an instant SEPA credit transfer to Northstar Bank, which credits Example Supplies. Had Maya declined, the pain.014 would have carried the refusal and no payment would have followed. The request layer asked; a normal credit transfer did the paying.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageExample Supplies raises a payment requestExample Supplies Ltd (creditor) → Northstar Bank (creditor agent) · pain.013
Instead of pulling by direct debit, the creditor asks to be paid. It submits a pain.013 request for EUR 120.00 with an invoice reference and a due date through Northstar Bank, its bank.
- 02MessageNorthstar routes the request via the RtP serviceNorthstar Bank (creditor agent) → Request-to-Pay service · pain.013
The Request-to-Pay service is a messaging layer, not a money mover. It carries the request from the creditor's side towards the debtor's bank; no funds move at this stage.
- 03MessageThe request is delivered to Maya's bankRequest-to-Pay service → Bank Alfa (debtor agent) · pain.013
The service delivers the request to Bank Alfa, which presents it to Maya in her banking app — showing who is asking, how much, and by when.
- 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.
- 05MessageBank Alfa returns Maya's acceptanceBank Alfa (debtor agent) → Northstar Bank (creditor agent) · pain.014
A pain.014 response travels back to tell Example Supplies that Maya accepted and payment is coming. The response answers the request; it is not itself the money.
- 06MessageBank Alfa sends a SEPA Instant transferBank Alfa (debtor agent) → Northstar Bank (creditor agent) · pacs.008
Acceptance triggers an ordinary payment. Bank Alfa debits Maya and submits a SEPA Instant credit transfer (a pacs.008) to Northstar Bank — the request has become a normal push payment.
- DR Maya Chen's current account at Bank Alfa — EUR 120.00
- 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
Evidence & review / 07
Evidence & review
Request-to-Pay as a messaging pattern layered over an instant credit transfer, illustrated with SEPA; UK Request to Pay and UPI-collect are parallels with their own rulebooks.
What this brief simplifies: Request to Pay is taught as a general pattern using pain.013 request and pain.014 response messages over an SCT Inst settlement leg. Scheme-specific SEPA Request-to-Pay (SRTP) rulebook detail — message versions, timers, and participant obligations — was not re-verified against a dedicated registered source and should be checked before implementation.
Sources for this brief2
- 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.