Under the Hood🛠 - How SEPA Request to Pay works

A deep dive on a new layer that leads the way for Programmable Payments, the three big use cases, and how it works under the hood.

• What are the different payment rails under SEPA?

• How can SEPA Request to Pay compete with Stablecoin rails?

• What are my top 3 use cases for SEPA Request to pay?

• What’s the difference between Programmable Money and Programmable Payments?

These questions and more will be answered in this week's edition.

---

Hey Fintechers and Fintech newbies 👋🏽

I’ve been thinking about a term that’s becoming more prominent with the rise of Stablecoin and AI, and that’s Programmable Payments.

It also came up multiple times in the London edition of the Stripe Sessions tour last month, so it’s clear that they are placing a big bet on that being the next innovation in payments enabled by Stablecoin.

Programmable Payments is defined as “Money that moves based on predefined rules or workflows, but the money itself isn’t inherently restricted.”

That’s different to Programmable Money, which is “Money that is itself encoded with logic or rules that not only impacts payment initiation but also how the money behaves.” and that is directly enabled by stablecoins. More on Programmable Money later…

There are numerous broad use cases for Programmable Payments. Things like an escrow account holding funds until a specific condition, like a delivery confirmation or contract, is met. Or the overpayment of a mortgage triggered by having an excess of funds in a current account.

While Programmable Money adoption is tightly coupled to Stablecoin and digital currency issuance, Programmable Payments are already possible on existing rails.

Using Variable Recurring Payments built into UK Open Banking rails, customers can set rules and trigger payments based on things like the amount remaining in an account and use the sweeping functionality to make programmable account transfers.

There isn’t native programmability baked into the rail, but it still makes Programmable Payments possible.

VRP on UK Open Banking is one example of a layer that can enable programmable payments. There are many, many more.

One example of a payments rail that could be the programmable payments layer for Europe is SEPA, and it’s SEPA’s Request to Pay, which is a message layer that sits on top of SEPA, that I’m diving Under the Hood of today.

Here’s what to expect:

• What SEPA is and a quick overview of the SEPA payment rails

• A glossary of key terms

• How SEPA Request to Pay works

• Three major use cases of SEPA Request to Pay

  • QR Code Powered merchant payments

  • Payment Requests Embedded in Invoices

  • Subscriptions & Recurring Payments

Now let's get into it 💪🏽

---

What is SEPA Request to Pay? 📢

SEPA stands for the Single Euro Payments Area and is an EU initiative that has set a framework of rules and standards to simplify and harmonise euro-denominated bank transfers across Europe.

It’s a framework that allows individuals, businesses, and governments to send and receive euro payments across Europe as easily and cheaply as within their own country, standardising how bank transfers and direct debits work across participating countries. The aim is to achieve speed, low cost, and interoperability.

All 27 EU countries are part of SEPA, plus Iceland, Norway, Liechtenstein, Switzerland, and other non-EU members likethe UK, Andorra, San Marino, Monaco, and Vatican City (thankfully, the UK hasn’t withdrawn post-Brexit).

When folks talk about SEPA as a payments rail, they are mostly referring to SEPA Instant (SEPA Inst), which is SEPA's Real-Time Payments rail, comparable to Faster Payments here in the UK which facilitates the majority of bank-to-bank transfers, or to FedNow in the US. Under SEPA, there is also SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD).

Hopefully this visual helps.

SEPA Request to Pay (SRTP) is not one of the payment rails, but rather a messaging layer that sits atop SEPA Inst and SCT, adding an extra ‘smarter payments’ capability. It allows a payee to send a structured request for payment to a payer, who can then approve, reject, or defer it.

Where SRTP fits in will become clearer with this step-by-step and accompanying signature infographic, but first, an important clarification of terms.

Glossary of Terms 📚

SEPA - Single European Payments Area

The EU initiative that has set a framework of rules and standards to simplify and harmonise euro-denominated bank transfers across Europe.

SCT - SEPA Credit Transfer

The standard “push” euro bank transfer, typically used for one-off payments. Settles in 1 business day via traditional SEPA clearing infrastructure.

SEPA Inst - SEPA Instant Credit Transfer

SEPA’s real-time payments rail (like Faster Payments or FedNow), enabling euro transfers that settle 24/7/365 in under 10 seconds, currently capped at €100,000 (expected to increase to €1 million). Not universally supported by all PSPs yet.

SRTP - SEPA Request to Pay

A messaging overlay (not a payment rail) that enables payees to send structured payment requests to payers. It enhances UX by introducing pre-authorised or event-triggered payment flows, often settled via SCT or SEPA Inst.

SPL - SEPA Proxy Lookup

A lookup service that allows users to initiate payments using a proxy identifier (like a phone number or email address) rather than an IBAN. Helps simplify person-to-person payments while preserving privacy.

Payee

The individual or business requesting a payment, typically the recipient of funds for goods or services provided.

Payer

The individual or business receiving the payment request and sending funds, typically the customer or buyer.

PSP - Payment Service Provider

A licensed entity (e.g. bank, fintech, or e-money institution) that enables customers to initiate, receive, or process payments. PSPs connect to SEPA infrastructure and facilitate access to SCT, SEPA Inst, and SRTP schemes.

IBAN - International Bank Account Number

The standardised format for identifying bank accounts across Europe and internationally. Required for all SEPA transfers.

EPC - European Payments Council

The organisation responsible for managing the SEPA schemes (SCT, SEPA Inst, SRTP, etc.) and ensuring interoperability across payment providers in Europe.

RT1 / TIPS - SEPA Clearing Mechanisms

Real-time infrastructure providers used for SEPA Inst payments. RT1 is operated by EBA Clearing; TIPS (TARGET Instant Payment Settlement) is run by the European Central Bank.

SEPA Request to Pay: Step-by-step

Step 1 - Payer information identified

Payee identifies and captures information from the payer such as IBAN through an entry screen/portal or directly from the payer.

If SEPA Proxy Lookup (SPL) is supported, the payer can provide a proxy identifier like a phone number or email address, which is then resolved into an IBAN via the SPL service meaning the payer can just use their email address or phone number to initiate the request.

That can be the Payee presenting a screen, a company sending an email.. And the payer sending identification details in response.

Step 2 - Initiation of Request to Pay

The Payee initiates the payment request using the Payer information adding this to the standard message format and pushed to the SRTP layer via the Payees Payment Service provider.

The request includes:

• Amount to be paid

• Purpose/reference

• Payee’s IBAN

• Expiry or due date for the request

Note: This part isn't a debit or transfer, it’s a structured message.

Step 3 - SRTP forwards the request to the payer's PSP

The payer’s bank (or PSP) receives the SRTP request and notifies the payer. This could be via:

• Banking app push notification

• Embedded API in third-party wallet/app

• Email or SMS

• In-app message

The payer sees who’s requesting the money, the amount, a due date, and Accept/Reject/Defer options.

Step 4 - The payer responds to the Request

Now the payer sees the request in their respective application, they can action the request.

The payer can:

• Accept and pay now

• Accept but schedule for later

• Decline the request

If the payer accepts, their PSP initiates a payment via SEPA, usually via SCT if supported by both PSPs, using:

• Payer’s IBAN

• Payee’s IBAN

• Amount

• Reference from original request

Step 5 - Payment is submitted and routed via SEPA Inst

The PSP validates the request and submits the payment to the SEPA Inst network, where it is:

• Cleared and settled in real-time

• Funds are moved within seconds

SEPA Inst ensures:

• Irrevocable settlement

• 24/7/365 processing

• Instant credit to the payee

Step 6 - Confirmation Sent

The payer gets a notification: Payment successful.

The payee gets an alert: Funds received, and the SRTP request is marked complete or closed.

If the payer had chosen to defer, the message would remain pending, and the request might be re-notified later (based on the PSP's UI and the payee’s retry settings) until it expires.

The request and payment is now complete.

The simplified end-to-end happy path is that the payee sends the payer a request, the payer accepts the request and the payment is actioned and credited via SEPA instantly, as my below diagram shows a bit more clearly.

The most interesting thing about the SRTP isn’t how it works, although that’s very useful. It’s the use cases it solves for and fintech innovation it can spark.

Three use cases for SEPA Request to Pay

🛍️ QR Code Powered Merchant Payments

In a retail setting, both online and in-store SRTP can replace traditional card or manual bank transfer payments with a frictionless, instant, and bank-account-based experience. Instead of keying in IBANs or pulling out a debit card, the customer simply approves a Request to Pay in their mobile banking app.

This allows merchants to cut costs, improve checkout conversion, and reduce fraud, all while settling in real time via SEPA Inst.

💡 Imagine this…You’re at a quaint art shop on the coast and you see a lovely seaside painting. At checkout you’re given the option to pay via a dynamic QR code that you scan and are taken to a bespoke payment page where you can submit your email (to subscribe to the stores newsletter) and your IBAN to initiate the payment, already prefilled with the amount, with a 1% discount subtracted for paying via bank. You hit submit, the payment request is initiated, you approve the request in your banking app and the merchant sees it come through on their side.

Benefits of SRTP in Retail:

• Frictionless checkout: No need to enter card details or IBANs — payer just approves a request.

• Instant settlement: Funds arrive in seconds via SEPA Inst, improving cash flow.

• Lower transaction costs: Avoid card scheme fees and chargebacks.

• Reduced fraud: Strong Customer Authentication (SCA) is handled via the payer's banking app.

• Works in-store or online: Can be embedded as a QR code at POS or a button at checkout.

🧾 Payment Requests Embedded in Invoices

In a B2B context, SEPA Request to Pay can streamline how businesses handle invoicing and collections. Instead of sending static PDFs or relying on customers to initiate manual transfers, suppliers can send real-time payment requestsembedded directly within e-invoices or accounting systems. Buyers approve payments through their bank or treasury platform, triggering instant settlement via SEPA Inst.

This removes friction, reduces reconciliation errors, and improves working capital cycles on both sides.

💡 Imagine this…You send an invoice to someone for work you’ve done with them (I face this specific example multiple times a month) and instead of sending an email with the invoice and bank details which the payer then needs to manually input into a banking portal, the payment link is embedded directly into the invoice which when clicked will take the individual to the payment page where the request can be actioned, and in addition, when the invoice is generated, you generate a payment request with the PO as a reference which is immediately sent. The payer can defer the payment to the relevant payment cycle but the payee is notified.

Benefits of SRTP in B2B Invoicing:

• Faster time-to-cash: Payments can be approved and settled instantly, improving liquidity.

• Automated reconciliation: Structured payment data aligns with invoice IDs, reducing manual matching.

• Seamless e-invoicing: Payment requests can be embedded in digital invoice workflows.

• Reduced admin overhead: No need to chase late payments or manually verify incoming transfers.

• Clear audit trail: Both parties have transparent, timestamped records of requests and responses.

🔁 Subscriptions & Recurring Payments

SEPA Request to Pay offers a more flexible alternative to direct debits for managing subscriptions and recurring billing. Instead of granting an open-ended mandate, the customer receives a payment request before each billing cycle, allowing them to review, approve, or defer payment with full transparency.

This model gives users more control, while still enabling businesses to automate billing and receive funds instantly via SEPA Inst.

💡 Imagine this…You’ve just signed up for a language-learning app that charges €9.99 per month. Rather than committing to an open-ended direct debit, you opt into SRTP-powered billing. Each month, you receive a notification from your banking app with a payment request — “Your French fluency journey continues. Ready to pay for another month?” 

You review the charge, see the amount and reference, and tap Approve. The funds are transferred instantly via SEPA Inst. You stay in control of your subscription, avoid surprise charges, and can pause or skip a month without calling customer support or navigating dark UX patterns. 

Meanwhile, the app provider gets instant confirmation, clear payment metadata, and lower transaction fees, no cards, no chargebacks, no drama.

Benefits of SRTP in Subscriptions:

• Customer control: Users stay in charge of recurring payments, no hidden renewals or hard-to-cancel mandates.

• Flexible billing: Requests can be sent per cycle or dynamically based on usage tiers.

• Strong authentication: Payments are authorised in the payer's banking app with SCA compliance.

• Reduced churn: Fewer payment failures due to expired cards or mandate errors.

• Instant cash flow: Funds settle immediately via SEPA Inst, not days later like with SEPA Direct Debit.

These are just three of the major use cases for SRTP that would benefit both the payer and payee and improve the overall payment experience. Here are a few others I thought of:

🏢 Rent and property management – Landlords or property platforms can send structured payment requests to tenants each month, reducing missed payments and easing reconciliation.

🚕 Gig and platform economy – Ride-hailing, food delivery, or freelance marketplaces can automate SRTP flows to collect fees, commissions, or reimbursements in real time.

🧾 Tax and public sector payments – Governments or municipalities can issue pay-by-link or push-based SRTPs for taxes, parking fines, or licensing fees, improving compliance and lowering costs.

🏥 Healthcare co-pays and clinic fees – Clinics can send SRTPs post-visit for outstanding balances or insurance gaps, reducing time at checkout.

🛠️ Trade and construction payments – Subcontractors and vendors can issue SRTPs with invoice metadata for materials or milestone payments, simplifying payouts and audits.

Summary

The point of this edition wasn’t to blow you away with what could happen in 5 years and how it could transform numerous payment journeys. It was to demonstrate what is possible today.

Stablecoin payments are inevitable, but the mainstream adoption will likely be gradual. In SRTP, there is the semblance of a blueprint for how traditional rails can compete with greenfield stablecoin payment platforms.

The SRTP messaging layer demonstrates how, by adding smart and secure messaging layers atop traditional trusted rails, payments can become smarter and more programmable without needing to shift consumers onto new networks or forcemerchants to adopt new infrastructure.

With enough impetus, it could pave the way for smarter layers atop other payment layers, similar to what UPI is stirring for in India and the innovations Brazil’s Pix is making in LATAM.

Coming back to today, for developers and fintech product teams, this opens up real, near-term opportunities to rethink common payment flows:

• What if a utility bill wasn’t just emailed, but came with a structured request you could approve with a tap?

• What if subscriptions respected your control by nudging you before billing, not just apologising after?

• What if invoices, QR codes, and checkouts all came with embedded payment logic, powered by SRTP and settled instantly via SEPA Inst?

SRTP officially went live in 2021 with its newest rulebook (guidelines for using the layer) set to go live in October, and I think we’re in the Goldilocks period. That window is 3-4 years after a technical rail or regulation goes live, when we start to see the green shoots of innovation.

The announcement in May of the partnership between Caixabank and BBVA powering Europe's first RtP transaction is anecdotal evidence of that.

We’re still early, and adoption will take time, from standardisation, to PSP support, to merchant readiness. But the foundational capabilities are already there. All that’s missing is thoughtful design and bold implementation.

If you’ve just learnt about SRTP and are curious about using it, or if you’re already in the process of leveraging it, I'd love to chat.

I hope you enjoyed this classic Under the Hood deep dive.

As I’m busy on a couple of projects (yes, I do write this entire newsletter and create supporting infographics in my rare evenings off), it might be three weeks before the next edition, so keep your eye on your inbox for the last couple of Friday’s in July for the next edition.

It'll be worth your while 👋🏽

J.

---

Fintech Spotlight🔦: WollettePay by Wollette

WollettePay is a new one-tap, account-to-account A2A payments solution launching from UK-based fintech Wollette, founded by Henry Orunkoya. Designed to deliver the instant, low-cost benefits of open banking with the seamless UX of card payments, WollettePay aims to close the gap between A2A infrastructure and real-world merchant and consumer expectations.

At its core, it’s a frictionless, tokenised A2A checkout experience, no redirects, no card forms, and no clunky handoffs to banking apps. With strong biometric authentication and real-time payment confirmation, WollettePay makes open banking feel like a natural part of the checkout journey.

But this isn’t just about UX. WollettePay is built to support omnichannel commerce, with integrations across in-store POS, online storefronts, accounting tools, and loyalty systems. The company also plans to provide merchants with automated settlement and reconciliation and an ecosystem of features like refunds, tipping, and future recurring payments, all within the A2A framework.

I also had a long chat with Henry at the beginning of last year. You can tell a lot about a founder when they talk passionately about payments, and he was positively buzzing about what he was building, so watch this space. 🚀

Interesting News 🗞: Monzo gets £21m fine

Monzo has been fined £21.1 million by the UK’s FCA for serious anti-financial crime failures between 2018 and 2022, including allowing customers to open accounts using obviously false addresses such as Buckingham Palace and 10 Downing Street. The FCA found that Monzo’s fraud detection systems failed to keep pace with its rapid customer growth (from 600,000 in 2018 to 5.8 million by 2022) and that it breached regulatory requirements by onboarding over 34,000 high-risk customers during that period. The original fine of £30.1 million was reduced after Monzo agreed to settle. CEO TS Anil acknowledged the historical shortcomings but emphasised that the bank has since made “substantial improvements” and is now serving nearly 13 million customers.

The below breakdown from Caleb Hogg is a great comparison of recent AML fines and how they compare.

Caleb Hogg