This article is a systems and architecture analysis for engineers. It is not financial, legal, or compliance advice.

Request to Pay and Account-to-Account Payments: An Architecture (2026)

Most people who first meet Request to Pay assume it is a new way to move money. It is not. It is a way to ask for money and to carry the answer back. The distinction is not pedantic — it is the single most important architectural fact about the whole design. Request to Pay (RtP) is a structured request-for-payment message and its matching response, exchanged between a biller and a payer, and it deliberately knows nothing about how the cash actually settles. The settlement happens on a separate account-to-account (A2A) rail underneath, and that rail could be SEPA Instant Credit Transfer, a FedNow-style instant scheme, or a UPI-style overlay, without the request layer changing shape.

This article analyses payment systems and architecture only. It is not financial, legal, or regulatory advice, and it makes no predictions about markets or products.

Teams that miss this decoupling build the wrong system. They fuse the request into the rail, lose the ability to swap rails, and then discover their reconciliation logic cannot tell a “declined request” from a “failed payment” — two states with completely different remediation.

What this covers: the messaging model behind RtP, the ISO 20022 messages that carry it, how it rides on A2A instant rails, the actors and their trust boundaries, consent and open-banking initiation, the status lifecycle, reconciliation, refunds, fraud and Verification of Payee integration, and the failure modes that break naive implementations.

Context and Background

Billers have historically had three ways to collect from a consumer account: card networks, direct debit, and manual bank transfer. Each has a structural weakness. Cards carry interchange and chargeback exposure and were designed for card-present retail, not recurring invoices. Direct debit hands the biller a standing mandate to pull funds, which shifts control away from the payer and creates indemnity and dispute overhead. Manual transfer is cheap but unstructured — the payer types an amount and a reference by hand, so reconciliation breaks constantly.

Request to Pay was designed to fix the control and structure problem at once. It gives the payer an explicit, itemised request they can accept, decline, or ask to pay later, and it carries a machine-readable reference end to end so the money that arrives can be matched to the invoice that asked for it. In Europe the scheme is the European Payments Council’s SEPA Request-To-Pay (SRTP), whose API specifications formally took effect on 5 October 2025 and whose rulebook defines the message set and the roles precisely. In the UK, Pay.UK’s Request to Pay framework provides an equivalent messaging overlay. Both are messaging frameworks; neither is a clearing system.

The timing matters because the settlement layer finally caught up. Instant A2A rails — SEPA Instant Credit Transfer (SCT Inst), the UK Faster Payments Service, FedNow in the US, and UPI in India — now clear irrevocably in seconds, at any hour. A request-for-payment is only compelling if the payer can act on it and see the money move immediately. For a deeper treatment of those rails, see our companion piece on real-time payment infrastructure across FedNow, UPI and SEPA Instant. The European Payments Council SRTP scheme documentation is the authoritative rulebook for the European variant.

The Reference Architecture: A Messaging Layer Decoupled From the Rail

The cleanest way to reason about Request to Pay is as four horizontal layers, each with a single responsibility, stacked over an underlying settlement rail that the top three treat as a pluggable dependency.

Figure 1: The four RtP layers — channel, messaging, consent, settlement — with the A2A rail as a swappable dependency underneath.

Figure 1 shows the channel layer where biller and payer applications live; the messaging layer where the biller service provider, the RtP routing platform, and the payer service provider exchange the structured request and its status; the consent layer where the payer authorises a payment initiation with strong customer authentication; and the settlement layer where an instant credit transfer actually clears. The arrows only cross layer boundaries at defined interfaces, which is what lets you replace the rail without touching the request semantics.

The direct answer: Request to Pay is a request-for-payment message plus a response, sent from a biller to a payer, that rides on top of a separate account-to-account settlement rail. RtP handles consent, presentment, and status; the A2A rail handles the irrevocable movement of funds. The two are deliberately decoupled so the same request can settle over SCT Inst, Faster Payments, or any instant scheme.

The request is a message, not a debit

In direct debit, the biller holds a mandate and pulls. In RtP, the biller sends a request and the payer pushes. Nothing is debited until the payer authorises a credit transfer from their own account. This inverts the control model: the payer always initiates the actual money movement, so there is no standing authority for the biller to abuse and no pre-authorised pull to indemnify against. The request carries the amount, a due date, a payment reference, and biller identity, but it confers no power to move funds by itself.

The rail is a dependency, injected at the edge

Because the request layer never touches settlement, the rail is chosen at the moment of authorisation, at the payer bank. A payer bank in the euro area routes the authorised transfer over SCT Inst; a UK bank routes over Faster Payments. The RtP platform does not know or care which — it only needs the status back. This is dependency injection applied to payments: the request is written once against an abstract “settle this” interface, and the concrete rail is bound late. It is also why an RtP platform can operate cross-border in principle, even when the settlement rails differ by jurisdiction.

The platform is a router and a state machine, not a bank

The RtP platform in the middle holds no funds. Its jobs are routing (get the request from the biller’s service provider to the payer’s service provider and back), identity resolution (turn a biller and payer into addressable endpoints), and lifecycle bookkeeping (track whether a request is requested, accepted, paid, declined, or expired). This makes it far cheaper to operate and to regulate than a settlement system, and it is the reason the layer can be run by a scheme operator rather than a central bank.

Deeper Analysis: Messages, Actors, and the End-to-End Flow

The ISO 20022 message model

Request to Pay is expressed in ISO 20022, the same XML/JSON dictionary used by modern clearing systems, which is what lets the request reference downstream settlement cleanly. In the SEPA SRTP scheme the core messages are pain.013, the Creditor Payment Activation Request, sent by the creditor (biller) toward the payer, and pain.014, the Creditor Payment Activation Request Status Report, which carries the payer side’s response back. The scheme also uses pain.017 for status and cancellation flows. The creditor sends a pain.013 tagged with the service-level code SRTP, and the payer’s service provider answers with pain.014 conveying acceptance, rejection, or a request for more information.

Crucially, pain.013 is an activation request — it asks the payer to activate a payment — not a payment instruction. The actual instruction, once the payer authorises, is a separate credit transfer message (a pain.001 initiation or a scheme-native instant-transfer message) submitted to the rail. The RtP messages and the settlement messages are different documents with different lifecycles, which is the ISO-20022-level expression of the decoupling. Get this wrong — treat pain.013 as if it debits — and you build a system that cannot represent “requested but not yet paid,” which is the most common real-world state.

The actors and their trust boundaries

Six roles matter, and each sits on a distinct side of a trust boundary:

Biller (creditor): the party owed money. Composes the request but cannot move funds.
Biller service provider (creditor RtP SP): connects the biller to the scheme, validates and signs the pain.013, enforces scheme rules.
RtP platform / scheme: routes messages, resolves addressing, tracks status. Holds no money.
Payer (debtor): the account holder. The only party that can authorise a debit from their account.
Payer service provider (debtor RtP SP), usually the payer’s bank: presents the request, captures consent, initiates the credit transfer, and reports status.
The A2A rail: clears and settles the transfer irrevocably.

The trust boundaries are what make the design safe. The biller never sees the payer’s credentials. The RtP platform never sees funds. The payer’s bank is the only actor that authenticates the payer and touches the account. This separation of duties is also why fraud controls live at the payer bank, not at the biller.

Where open banking payment initiation fits

There are two ways the authorised transfer actually gets initiated, and teams routinely conflate them. In the bank-native model, the payer approves the request inside their own bank app, and the bank initiates the transfer directly — no third party involved. In the open-banking model, a Payment Initiation Service Provider (PISP) initiates the transfer on the payer’s behalf under PSD2 (and, as it is drafted, PSD3/PSR), after the payer authenticates at their bank with strong customer authentication.

RtP and open-banking initiation are complementary, not competing. RtP is the presentment-and-consent conversation; PISP initiation is one mechanism for turning an accepted request into a rail-level instruction. A well-factored platform treats the initiation mechanism as another injected dependency behind the “authorise” step. Our deep-dive on open banking under PSD3 and the PSR API architecture covers the initiation and consent APIs in detail; if you are stitching several rails and initiation methods together behind one interface, the payment orchestration platform architecture is the pattern that generalises it.

The end-to-end flow

Figure 2: The request travels biller to RtP platform to payer bank; the payer authorises with strong customer authentication; the bank submits the credit transfer to the instant rail; status returns up the chain.

Figure 2 traces the happy path. The biller composes a pain.013 and hands it to its service provider, which routes it through the RtP platform to the payer’s bank. The bank presents the request to the payer, who authorises it with strong customer authentication. The bank then submits an instant credit transfer to the rail, receives settlement confirmation, and returns a pain.014 marking the request accepted and paid. Note the two distinct network hops: one for the request (RtP messaging) and one for the money (the rail). They can and do return on different timelines — the request may be accepted seconds before the transfer settles, and a robust platform models that gap explicitly rather than collapsing accept and pay into one event.

Consent in RtP is layered, and each layer answers a different question. The request-level consent is the payer accepting the specific request — this invoice, this amount, this due date. The initiation-level consent is the payer authorising a particular credit transfer, which in the open-banking model is a PISP consent object with a defined scope and lifetime. The authentication is strong customer authentication at the bank, binding the human to the action. These are separate objects with separate audit trails, and collapsing them is a compliance and debugging hazard.

Settlement finality is where the decoupling earns its keep. On an instant A2A rail, once the credit transfer clears, it is final and irrevocable — there is no chargeback primitive the way cards have. That is a feature for the biller (funds are good funds) and a risk for the payer (a mistaken or fraud-induced payment cannot be clawed back through the rail). The RtP layer does not change finality; it sits above it. What RtP can offer is a refund flow — a separate, forward credit transfer from biller back to payer — but that is a new payment, not a reversal of the original. Any design that promises “cancel a paid RtP” is really promising a refund, and should model it as such.

Idempotency threads through all of this. Because instant rails are irrevocable, a duplicate initiation is a duplicate payment with real money attached. Every layer therefore needs an idempotency key: the biller assigns a unique request identifier to the pain.013, the payer bank derives an end-to-end identifier for the credit transfer, and the platform de-duplicates on both. A retried request that reuses the same key must return the prior outcome, never trigger a second debit. This is the same discipline you would apply to any exactly-once system, but the cost of getting it wrong is measured in customer refunds rather than log noise.

Trade-offs, Gotchas, and What Goes Wrong

The status lifecycle is where most of the operational subtlety lives, so start there.

Figure 3: A request moves from created to requested, then to accepted, declined, or expired; accepted requests become paid and settled, with refund as a separate forward state.

Figure 3 shows the states a request passes through. The trap is treating this as a simple linear path. In production, requests race against their own expiry, get accepted but never paid, get paid twice, or get paid after they have already expired. A platform that cannot represent every one of these states will silently corrupt its books.

Partial payments. A payer may try to pay less than the requested amount, or a biller may accept installment behaviour. If the request models a single fixed amount but the rail delivers a smaller credit, the platform must decide: reject the underpayment, hold it in suspense, or mark the request partially satisfied. The scheme rules constrain what is legal, but the architecture must have an explicit answer or it will mis-reconcile.

Expiry races. A request has a due date. If the payer authorises at the instant of expiry, the acceptance and the expiry event can arrive out of order across the two network paths. The platform needs a single authoritative clock and a rule for ties — typically, a payment that settles is honoured even if the request nominally expired a second earlier, because the rail’s finality outranks the request’s timer. Encode that rule; do not leave it to whichever event happens to be processed first.

Duplicate requests. A biller retrying a timed-out send can create two pain.013 messages for one invoice. Without idempotency on the request identifier, the payer sees the bill twice and may pay twice. The de-duplication must live at the platform and the payer bank, because either can be the point where the retry lands.

Reconciliation breaks. This is the failure mode that quietly costs the most.

Figure 4: Incoming rail credits are matched to request identifiers; unmatched credits go to a suspense queue for auto or manual repair, then to exception reporting and dispute handling.

Figure 4 shows the reconciliation path. Because the request and the settlement travel separately, the biller receives a credit on the rail that must be matched back to the request that asked for it. The match key is the structured reference carried end to end. When that reference is dropped, truncated, or altered — which happens when an intermediary rewrites remittance data — the credit lands unmatched in a suspense queue. Auto-repair heuristics (amount plus payer plus timing) resolve most, but the residue needs manual investigation, and a persistently unmatched credit becomes a dispute. The single most valuable engineering investment here is guaranteeing the reference survives every hop.

Dispute handling. With no rail-level chargeback, disputes resolve through the refund path and through the scheme’s messaging, not through a network arbitration process. That is operationally lighter but shifts the burden onto biller and payer to communicate — which is exactly what the RtP messaging layer, with its status and request-for-information messages, is meant to carry.

Fraud and Verification of Payee. Because A2A payments are push and irrevocable, authorised push payment fraud is the dominant risk — a fraudster tricks the payer into authorising a transfer to the wrong account. RtP mitigates this structurally because the payer is responding to a request from a known, addressed biller rather than typing an account number, but the platform should still integrate name-checking. Verification of Payee (VoP) confirms the payee name matches the account before authorisation; our Verification of Payee architecture for instant payments covers how that check is wired in without adding latency the payer will notice.

A Decision Matrix: RtP + A2A vs Cards vs Direct Debit

For a biller choosing a collection method, the trade-offs are structural, not cosmetic. The matrix below is a systems comparison, not a recommendation.

Dimension	RtP + A2A	Cards	Direct Debit
Who initiates funds	Payer pushes	Biller pulls via network	Biller pulls via mandate
Control model	Payer approves each request	Standing card credential	Standing mandate
Settlement speed	Seconds (instant rail)	Days (capture then settle)	Days, batch cycle
Reversibility	Final; refund is a new payment	Chargeback primitive exists	Indemnity-based recall window
Structured reference	Native, end to end	Limited	Scheme-dependent
Dominant fraud vector	Authorised push (APP)	Card-not-present, chargeback abuse	Unauthorised mandate
Cost driver	Rail fee + messaging	Interchange + scheme fees	Low per-item, high dispute ops
Rail portability	Rail is pluggable	Locked to card network	Locked to DD scheme

The illustrative pattern — and these are illustrative characteristics, not fee quotes — is that RtP + A2A trades away the chargeback safety net in exchange for instant, final, cheaply-referenced settlement and a payer-controlled consent model. Where the biller values reconciliation quality and finality (utilities, invoices, government, rent), that trade is attractive. Where the buyer expects card-style buyer protection (discretionary retail), the missing chargeback primitive is a real gap that has to be filled by the RtP dispute and refund flow instead.

Capacity, Latency, and Operational Envelope

The capacity story is unusual because the RtP platform is a messaging system, not a settlement system, so its scaling profile looks more like a high-throughput event router than a ledger. Two independent throughput budgets exist: request messages (pain.013/pain.014 traffic) and settlement events (rail confirmations). They spike on different schedules — request volume spikes when billers send monthly runs; settlement volume spikes when payers act, often clustered around paydays and due dates.

Latency targets differ by hop. Request routing should be sub-second because the payer may be waiting to see the bill. Authorisation is gated by human interaction plus strong customer authentication, so it is bounded by the payer, not the system. Settlement on an instant rail is typically designed to complete within seconds and is subject to the rail’s own service level, not the RtP platform’s. A common illustrative envelope — again, illustrative, not a benchmark — is request routing in the low hundreds of milliseconds, authorisation in seconds-to-minutes depending on the human, and settlement in single-digit seconds on the rail.

The dimension that actually stresses the platform is state, not throughput. Every open request is a live state machine with a timer, and the platform holds all of them until they reach a terminal state. A biller sending millions of monthly requests creates millions of concurrently open timers that must fire deterministically at expiry, survive process restarts, and reconcile against asynchronous settlement events. This is a durable-timer and event-sourcing problem. The proven pattern is to persist each request as an event-sourced aggregate, drive expiry from a durable scheduler rather than in-memory timers, and treat every inbound rail event as a command that transitions the aggregate. That gives you replayable, auditable state — which auditors and dispute handlers will demand — and it makes idempotency natural because commands carry keys.

Back-pressure matters at the rail boundary. Instant schemes and their supporting infrastructure enforce rate limits and can reject bursts; a naive platform that fans out a monthly biller run into a thundering herd of initiations will get throttled. Pace initiations, respect the rail’s limits, and treat a throttle response as a retryable-with-backoff condition guarded by the same idempotency key so the backoff never double-pays.

Practical Recommendations

Treat the decoupling as an invariant, not a convenience. Every design review should be able to point at the seam between the request layer and the rail and confirm that no request-layer code assumes a specific settlement mechanism. If it does, portability is already lost.

A short checklist for teams building or integrating an RtP capability:

Model the full state machine, including accepted-but-unpaid, paid-after-expiry, partial, and refunded — not just the happy path.
Assign and preserve a stable request identifier end to end, and de-duplicate on it at both the platform and the payer bank.
Make initiation a pluggable dependency so bank-native and PISP initiation sit behind one interface.
Guarantee the structured reference survives every hop; unmatched credits are the top reconciliation cost.
Model refunds as forward payments, never as reversals, because the rail has no reversal primitive.
Drive expiry from durable schedulers and persist requests as event-sourced aggregates for auditability.
Integrate Verification of Payee before authorisation to blunt authorised push payment fraud.
Respect rail rate limits and back-pressure biller runs so batch sends do not trigger throttling.

Above all, name your states precisely. A “declined request” and a “failed payment” look similar in a naive log and have completely different remediation — one is a customer choice, the other is an operational incident. The whole value of Request to Pay as an architecture is that it gives you the vocabulary to tell them apart.

Frequently Asked Questions

Is Request to Pay a payment rail?

No. Request to Pay is a messaging and consent layer — a structured request-for-payment plus its response — that rides on top of a separate account-to-account settlement rail. RtP carries the request, the acceptance or decline, and the status; the actual movement of funds happens on an instant credit transfer scheme such as SCT Inst or Faster Payments. Conflating the two is the most common architectural mistake, because it destroys the ability to swap rails and blurs the distinction between a declined request and a failed payment.

What ISO 20022 messages does SEPA Request-to-Pay use?

The SEPA SRTP scheme uses pain.013, the Creditor Payment Activation Request, sent from the creditor toward the payer, and pain.014, the Creditor Payment Activation Request Status Report, which carries the response back. It also uses pain.017 for status and cancellation flows. The request is tagged with the service-level code SRTP. Importantly, pain.013 is an activation request, not a debit instruction — the actual credit transfer is a separate message submitted to the settlement rail once the payer authorises.

How is RtP different from direct debit?

Direct debit is a pull model: the biller holds a standing mandate and debits the payer’s account. Request to Pay is a push model: the biller sends a request and the payer authorises a credit transfer from their own account. This inverts control back to the payer, removes the standing authority the biller would otherwise hold, and settles instantly and irrevocably rather than through a batch cycle with a recall window. The payer accepts or declines each individual request.

Can a paid Request to Pay be cancelled?

Not through the rail. Instant account-to-account settlement is final and irrevocable — there is no chargeback or reversal primitive like cards have. What looks like a cancellation is actually a refund: a separate, forward credit transfer from the biller back to the payer. A sound architecture models refunds as new payments with their own identifiers and lifecycle, never as reversals of the original transfer, because the original cannot be undone once it clears.

Where does open banking payment initiation fit in?

Open-banking payment initiation is one mechanism for turning an accepted request into a rail-level instruction. A Payment Initiation Service Provider (PISP) can initiate the credit transfer on the payer’s behalf, under PSD2 and the drafted PSD3/PSR framework, after the payer authenticates with strong customer authentication. The alternative is bank-native initiation, where the payer approves inside their own bank app. RtP is the presentment-and-consent conversation; PISP initiation is a pluggable way to execute the authorised payment.

What are the main failure modes to design for?

The high-value failure modes are reconciliation breaks (an unmatched rail credit because the structured reference was altered in transit), duplicate requests or double payments (mitigated by idempotency keys), expiry races (acceptance and expiry arriving out of order across the two network paths), partial payments, and authorised push payment fraud. Because settlement is irrevocable, each of these has real money attached, so the platform must model every state explicitly and integrate Verification of Payee before authorisation.

Request to Pay and Account-to-Account Payments: An Architecture (2026)

Request to Pay and Account-to-Account Payments: An Architecture (2026)

Context and Background