SEPA Request-to-Pay prototype (Bachelor’s thesis)
SRTP vs SEPA Direct Debit — end-to-end flow simulation with real-time UI
Bachelor’s final project (capstone) designing and implementing an event-driven SRTP prototype: payment-request creation, routing, payer decision, execution, and closure with live notifications.
Context
In Europe, SEPA Direct Debit (SDD) remains a common choice for recurring collections, but it is not always ideal for modern digital flows: transparency, payer control, and real-time interaction are limited.
SEPA Request-to-Pay (SRTP) introduces a digital request layer: the beneficiary sends a payment request, and the payer can accept, reject, or defer it in real time—typically leveraging SEPA Instant Credit Transfer (SCT Inst) rails for execution.
High-level SRTP message flow between payer, payee, and their RTP service providers.
What I built
I designed and implemented a functional prototype that simulates the SRTP ecosystem and its core actors:
- Beneficiary and payer
- Beneficiary PSP and payer PSP
- A full request lifecycle: create → validate → route → validate payer → payer decision → close
The backend is structured as an event-driven flow: each state transition emits real-time notifications so every party sees updates immediately.
System overview
- Backend API (Flask): REST endpoints for each SRTP step plus persistence for actors, requests, and logs.
- Real-time layer (Socket.IO): room-based notifications per actor/role to model how PSPs and customers receive state changes.
- Web UI (static frontend): a live interface to log in as different actors and execute the SRTP flow end-to-end.
Why it matters
This project is a hands-on way to understand the operational differences between Direct Debit and Request-to-Pay:
- clearer payer intent and decision points
- improved traceability across actors
- better UX alignment with instant payment rails