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.
IN ONE LINE
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.
WHAT IT ACTUALLY IS
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.
HOW IT WORKS
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.
THE WORDS
- Request to pay
- A messaging service where a payee sends a request for payment to a payer, who can then pay, decline, or arrange to pay later.
- SEPA Request-to-Pay (SRTP)
- The EPC scheme for sending a structured request for payment across SEPA — a messaging layer that asks for a payment; the money still moves by a separate credit transfer.
- Payment request
- A message from a payee asking a specific payer to pay a stated amount by a date — an ask the payer can accept or decline, not an instruction that pulls funds.
- Collection request
- The payee-side message that raises a Request to Pay — the creditor's activation of a request asking the debtor to pay, as opposed to a mandate that authorises a pull.
READ FIRST
CONNECTED TO
SOURCES
- 2025 SEPA Credit Transfer rulebook — European Payments Council
- Payments Signal editorial teaching models — Payments Signal
Derived from Request to Pay. Every claim on this card is sourced on that page.