SEPA / Learning brief
Request to Pay and e-mandates
Your notes
In simple terms / 01
What this means in plain language
What Request to Pay is as a messaging layer that lets a payee ask a payer to pay while the payer stays in control, and how e-mandates digitise direct-debit authorisations over existing rails.
Request to Pay (RtP) is not a new way of moving money; it is a way of asking for it. A payee sends a structured request to a payer, who receives it in their banking app and decides how to respond: pay now, pay later, pay part, ask a question, or decline. Because the payer chooses to act, control stays with them, unlike a direct debit where the biller pulls the funds. When the payer accepts, the actual payment travels over an existing rail, such as an instant credit transfer, so Request to Pay overlays the rails rather than replacing them. E-mandates address a related need: they digitise the authorisation that lets a biller collect a direct debit. Instead of a paper form and a signature, the payer approves an electronic mandate, often through their bank, creating a verifiable record. Both are messaging and authorisation layers that make familiar payments clearer, more data-rich, and easier to consent to, while the underlying settlement stays the same.
Complete lesson / 02
Understand the full idea, step by step
Most of this course has watched money being pushed or pulled. Here is a third posture: someone simply asks, and you decide how to answer. It is closer to receiving a bill you can reply to than to any automatic charge — and, importantly, it moves no money by itself.
Request to Pay (RtP) — a messaging layer that carries a payment request and the payer's response
Request to Pay sits above the payment rails as a messaging layer. Its job is to carry a structured request from a payee to a payer, and the payer's response back — without itself moving any money. A biller states the amount, reason, and due date; the payer receives it in a trusted app and is offered genuine choices: pay in full now, schedule it, pay part, query it, or decline. Because the payer takes the triggering action, control over whether, when, and how much stays firmly with them.
A request layer, not a rail
When Riya chooses to pay, the money travels over an existing rail — commonly an instant credit transfer — so Request to Pay does not compete with settlement systems. It gives them a richer, consent-based front end and a clear audit trail of what was asked and answered. This is the crucial distinction from a direct debit: a direct debit is a pull the debtor authorised once and then largely forgets; Request to Pay is an ask the payer must actively answer every time. One keeps standing permission; the other renews the decision on each request.
| Request to Pay | Direct debit | |
|---|---|---|
| Who acts to move money | The payer, each time | The creditor, under a standing mandate |
| Payer's per-payment control | Full — pay all, part, later, query, or decline | Limited — set by the mandate; refunds/refusals unwind afterwards |
| What it is | A messaging overlay above the rails | A collection scheme that debits the account |
| How money finally moves | Over a chosen rail, e.g. an instant credit transfer | Interbank collection (pain.008 / pacs.003) to the due-date debit |
E-mandate — an electronic direct-debit authorisation
A direct debit only works because the payer first gave permission through a mandate — traditionally a paper form with a handwritten signature, slow to set up and awkward to verify or amend. An e-mandate digitises that authorisation: the payer approves it electronically, often authenticated through their own bank, creating a structured, verifiable record of who authorised what, for which biller, and within what limits. In SEPA, an electronic mandate flow lets the payer confirm a Direct Debit authorisation through their bank rather than on paper.
The e-mandate does not change how the debit settles
This is the point that keeps e-mandates in their lane: the e-mandate modernises the authorisation step, not the collection. Once Riya approves an e-mandate for Asha Traders, the direct debit still runs over the existing rail on its due dates, exactly as in the SDD Core lesson — pain.008 to the creditor's bank, pacs.003 between the banks, a debit on the due date. What changed is only that the permission underneath it is now a trustworthy digital object rather than a signature in a filing cabinet: faster to set up, easier to amend or cancel, and far less likely to become a dispute about whether consent was ever given.
REMEMBER IT
Hold both as overlays over existing rails. Request to Pay overlays credit transfers — it standardises the asking and agreeing, then hands a confirmed instruction to a transfer to settle. E-mandates overlay direct debits — they modernise the authorisation while the collection mechanics stay put. Neither builds a new settlement system; each makes an existing payment clearer, more controllable, and better documented.
COMMON CONFUSION
“Request to Pay and e-mandates make payments settle faster than before.”
They do not, and are not meant to. Both are consent-and-messaging layers on top of rails that already work; money still moves only as fast as the underlying rail allows. What they improve is intent — clearer consent, better data, more flexibility, fewer failed collections and disputes — not settlement speed. Reading them as overlays is what keeps that expectation honest.
STRICTLY SPEAKING
Strictly speaking, Request to Pay and e-mandate services vary by market in their exact features, availability, and rules, and SEPA's electronic-mandate arrangements are defined in the European Payments Council's scheme documentation. Treat the model here as the shared shape and check the specific scheme and market before relying on any particular capability.
FOR NOW, REMEMBER
- Request to Pay is a messaging overlay: a payee asks, the payer answers, and no money moves until the payer acts.
- It keeps the payer in control every time — pay all, part, later, query, or decline — unlike a direct debit's standing pull.
- An e-mandate digitises the direct-debit authorisation; the collection still settles over the existing rail on its due dates.
- Both are overlays over existing rails: they improve consent, data, and control, not settlement speed.
TRY IT YOURSELF
Asha Traders needs EUR 320.00 from Riya but wants Riya to keep full control of whether and when she pays each time, without granting any standing permission to pull from her account. Which fits, and why?
You have now seen the direct-debit mechanism, its two schemes, how collections unwind, the name checks that guard credit transfers, and the overlays that add consent on top. The SDD Core topic gathers the collection mechanics into one deeper reference.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Request to Pay is a request layer, not a settlement rail; the payer decides whether and how to pay.
- 02
Because the payer initiates the payment, control and timing stay with the payer.
- 03
E-mandates digitise direct-debit authorisation, replacing paper forms with a verifiable electronic record.
Practical use cases / 04
Where you would use this
A utility biller sends a Request to Pay so a customer can approve a variable bill in-app instead of by card.
A payer responds to a request with a partial payment and a message when they cannot pay the full amount.
A biller sets up an e-mandate so future direct debits rest on a verified digital authorisation.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional energy supplier, Northwind Power, sends a Request to Pay for GBP 214.60 due in seven days to a customer, Priya Shah. Priya opens the request in her banking app and chooses to pay in full immediately; her bank then sends an instant credit transfer of GBP 214.60 over the existing rail, and Northwind receives confirmation. Had Priya been short, she could have offered a partial GBP 100.00 with a note, and Northwind could accept or decline, all without any card details changing hands.
Evidence & review / 07
Evidence & review
Request to Pay and e-mandate overlays over existing credit-transfer and direct-debit rails; SEPA and comparable markets.
What this brief simplifies: Market-specific features and availability described rather than enumerated; RtP presented as a generic overlay model rather than one named scheme.
Sources for this brief2
- Scheme-specific rule2025 v1.1 (EPC016-06)
2025 SEPA Direct Debit Core rulebook version 1.1 (EPC016-06) ↗ — European Payments Council · SEPA electronic mandate arrangements
- 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.