SEPA Request-to-Pay: the payee asks, the payer pays

The distinction decides every design question that follows. SRTP transports a request and an answer. The payment that follows runs over a SEPA credit transfer, usually the instant one, and that transfer is where the money and the finality sit. If the customer accepts an SRTP message and the transfer fails, the request was still delivered correctly and the invoice is still open.

That is why the scheme pairs so naturally with instant payments in Europe. The request gives the payee the invoice data and the certainty that the right person saw it, the instant transfer gives the payee the money in ten seconds with a confirmation. Together they do what a card payment does at a checkout, over bank accounts, which is the subject of account-to-account payments.

The EPC publishes the SRTP scheme rulebook and, beside it, the implementation guidelines and an API specification. The split matters to a developer: the rulebook says what the participants owe each other and what the messages mean, the implementation guidelines say exactly how a field is filled, and the API specification says how the call is made. A participant that reads only the rulebook builds something that does not interoperate.

The scheme describes four roles. The payee and the payer are the businesses or people with the invoice between them. Each has an SRTP service provider, which converts their data into the scheme format and exchanges it with the other provider. An online merchant hands its SRTP provider the buyer name, the IBAN, the amount and the item, that provider builds the request in the format the rulebook defines, and the buyer's provider delivers it into the buyer's app.

Any company can become an SRTP provider if it runs the technical infrastructure and signs up to the scheme rules, as PayTechLaw notes, which puts banks and payment institutions in a favorable but not exclusive position. The request reaches the payer where the payer already is: in a banking app, by push notification, by email or over a messaging channel. That delivery choice is the provider's, and it decides whether the customer sees the request in time to pay on the due date.

The two cases look different in practice. At an online checkout the request is immediate: the buyer picks the method, the request arrives in the banking app within seconds, the buyer approves it with the authentication their bank already requires, and the instant transfer settles before the page reloads. What a merchant gains over a card is a lower cost and no chargeback; what it loses is the card dispute path.

On an invoice the request is deferred, which is the more interesting case for a German company. An SRTP message can carry a due date, so the customer receives it when the invoice goes out and pays it on the day it falls due. The reference travels with the payment, so reconciliation stops being a matching exercise. E-commerce payments in Germany covers the checkout side, corporate treasury the invoice side.

A SEPA direct debit pulls. The payee holds a mandate, initiates the collection, and the money leaves the payer's account whether the payer is paying attention or not. SRTP pushes. The payee can only ask, and every payment needs the payer's own authorization, which means no mandate to collect, store or prove.

That trade is the whole argument. The direct debit gives a subscription business predictable cash and a refund risk of eight weeks. SRTP gives it no refund risk at all, because the payer authorized each payment, and a collection rate that depends on customers answering messages. For recurring amounts that vary, the open banking answer is variable recurring payments, which sits between the two.

A request costs nothing to send, which is the security problem hiding inside the convenience. The scheme guarantees that a message arrived in the correct format; it does not guarantee that the sender is the supplier it claims to be. Supplier impersonation is the pattern to expect: a request that looks like the usual invoice, with a different IBAN behind it.

A company receiving requests therefore needs the same discipline it needs for invoices by email. Validate the supplier account against what the supplier register says, treat a changed IBAN as an event that needs a callback on a known number, and match the request against the purchase order before anybody approves it. Fraud prevention in Germany covers the controls, and verification of payee catches the case where the name no longer fits the account.

The EPC publishes the register of SRTP scheme participants, and adoption has been slower than the scheme's designers hoped. The chicken-and-egg problem is structural: a merchant will not offer a method that few customers' banks can receive, and a bank will not build reception for requests no merchant sends. Wero and the European Payments Initiative work on the same gap from the consumer side, which Wero in Germany covers.

A bank joining as a payer-side provider has to receive requests, present them in its app in a form a customer understands, let the customer accept, decline or ask for a later date, and connect the acceptance to its own payment initiation. A provider on the payee side has to validate the request data, handle the status responses, and tell its merchant what happened. Both sides need the scheme's identification and reachability data, the same routing problem that verification of payee solves with a directory.

SEPA Request-to-Pay is an EPC messaging scheme in which a payee sends a structured payment request to a payer, who accepts or declines it in their own banking app. The scheme carries requests of up to 100,000 euros and moves no money itself: the payment that follows an acceptance is a separate SEPA credit transfer.

No. SRTP is a layer of messages before the payment. A customer who accepts a request still authorizes a credit transfer, and that transfer is the payment. A merchant offering SRTP at a checkout is therefore offering an account-to-account payment with a request attached, and the settlement rules come from the transfer, not from SRTP.

No. An SRTP message carries the data needed to pay, and German and European tax law asks for more than that on an invoice. The request therefore travels beside the invoice, not instead of it, and a company that wants to drop its invoice run still has to meet the invoicing rules separately. Later versions of the scheme are expected to support partial and installment payments, which widens what a single request can settle.