Real-time payments turn waiting into a product failure

Real-time payments reset what waiting means. When a rail is designed to make final funds available within seconds, around the clock, a spinner is no longer a neutral sign that banking takes time. The expected sequence becomes one continuous interaction: choose, authorize, receive an outcome. Saturday night is not an exception. “We will process this on the next business day” is not an explanation. It is evidence that the product surrounding the rail still works to an older clock.12

That is the user-expectation shift: confirmation moves inside the payment action. If an interface takes minutes to reflect a completed transfer, leaves a merchant unable to fulfil after the payer sees a debit, or silently queues an instruction behind office hours, the underlying rail may have succeeded while the payment product has failed. Speed is not decoration added to settlement. It changes what “done” must mean, how long uncertainty may remain invisible and which safeguards have to run before money moves.

The rail changes the meaning of done

The Committee on Payments and Market Infrastructures defines fast payments around two end-user properties: final funds become available to the payee in real or near-real time, and the service operates as close to 24/7 as possible.1 The definition reaches beyond message transmission. A payment is not instant merely because one API responded quickly.

European rules make that boundary unusually explicit. For an instant euro transfer, the payee’s provider must make the amount available and confirm completion to the payer’s provider within ten seconds. The payer’s provider must then immediately say whether the money was made available.2 FedNow likewise describes end-to-end instant payments in which customers can send and receive at any time and gain immediate access to funds.4

Products therefore need to retire “request accepted” as a success condition. HTTP itself calls a 202 Accepted response noncommittal: processing is incomplete and might never occur.10 That response can acknowledge an internal job. It cannot support “Payment complete” unless later evidence establishes the product’s actual completion boundary.

For a person sending money, that boundary is usually confirmation that the recipient can use it. For a merchant, it is an authoritative result safe enough to release the order. Those views should come from one durable payment state, even if they use different words. A green tick in the payer’s app and an unpaid order in the merchant system are not two perspectives. They are a broken product contract.

Confirmation needs a precise state model

Payments standards resist the temptation to call every positive response success. ISO 20022 status vocabularies distinguish technical validation, acceptance for settlement, completed settlement, pending and rejection.6 FedNow adds another useful distinction: a receiver can accept a payment without posting it immediately, while a later confirmation-of-posting message can tell the sender that funds reached the recipient.4

The interface does not need to expose protocol codes. The product model does need to preserve their meaning. A small set of states can do that: ready to send, submitted, confirmed, failed and reconciling. The difficult work is defining the evidence required to enter each one.

Confirmed should mean the chosen business promise has been met, not that the last service call returned without an error. Failed should require an authoritative negative result. Reconciling should mean a payment may exist and the system is actively seeking its status. Each state needs permitted actions. A confirmed payment can produce a receipt. A failed payment can allow a corrected attempt. A reconciling payment should suppress another send and restore the same status after refresh.

The receipt matters because immediate confirmation is brief. It should bind the result to the amount, currency, recipient, time and stable payment reference. Both sides should be able to use that reference when their screens disagree. A transient toast proves little once it disappears.

A spinner is now an exception state

There is still a legitimate interval between authorization and outcome. Real-time does not mean zero latency, and distributed systems can lose a response after processing a request. The product failure is leaving that interval unbounded or treating a missing answer as permission to start again.

FedNow’s operating procedures require a participant that is unsure of a payment’s status to query the service or search its records before sending another message. If the original was processed, the service returns its status; only when no record is found should the participant consider resubmission.4 The product analogue is simple: preserve one payment identity, reconcile by reference and prevent a second click from becoming a second financial instruction.

After the normal response window, the screen should change from “Sending” to an explicit exception: “We are confirming this payment. Do not pay again yet.” It should say where the final result will appear and keep the amount, recipient and reference visible. The W3C Payment Request specification follows the same interaction principle at a browser boundary: after a payment request has been accepted and while completion is pending, the payment UI should not offer cancellation.8

Waiting becomes tolerable only when it is named, bounded and owned. “Pending” without a reconciliation job, next check or escalation deadline is not a state. It is abandonment rendered as copy.

Put safety before speed

Immediate confirmation also shortens the correction window. On The Clearing House RTP network, a submitted payment cannot be revoked or recalled; settlement is final and irrevocable. A return begins with a separate request rather than undoing the original transfer.5 FedNow similarly models a return request that the receiver may accept or reject, followed—if accepted—by a new payment-return message.4

The product consequence is not to add warnings after every send. It is to move high-value checks before authorization and make their outcomes legible. The EU’s verification-of-payee rules require the payer’s provider to compare the account identifier and payee name before offering authorization, then warn when they do not match.2 Pay.UK’s Confirmation of Payee service defines four distinct responses: match, close match, no match and unavailable; “unavailable” can result from a timeout, opt-out or nonexistent account.7

Those outcomes must not collapse into one generic warning. A close match invites correction. No match calls for a stop and independent verification. Unavailable means the safety check produced no conclusion. If the user proceeds, the confirmation screen should make that choice explicit. Faster execution raises the value of a calm pause before commitment.

Round-the-clock rails require a round-the-clock product

The clock disappears at the rail, so it must disappear throughout the service. TIPS settles instant payments in central-bank money with finality on a 24/7/365 basis.3 FedNow expects participants to receive messages and make funds available within seconds on weekends and Federal Reserve holidays as well as working days.4

That promise reaches account checks, fraud decisions, authentication, ledger posting, merchant status, notifications, reconciliation and support tooling. If one dependency runs a nightly batch or an exception queue waits for a weekday operator, the product has recreated business hours above an always-on rail.

Continuous operation does not mean pretending outages cannot happen. FedNow tells unavailable participants to sign off so payments are rejected rather than accepted into delay, and requires monitoring, alerting and reconciliation of messages affected by downtime.4 TIPS reported 99.99% technical availability in 2025 while still recording six minor settlement incidents, lasting from 16 seconds to three minutes.9 The responsible product response is a fast, explicit availability failure before authorization where possible, and a durable reconciliation state where it is not.

Measure time to user certainty

Rail latency is necessary but insufficient. The product measure that matters begins when the user authorizes and ends when every relevant surface reflects an authoritative result. Record the moments when the instruction is created, submitted, accepted, settled or posted, shown to the payer and delivered to the merchant. The gaps reveal whether waiting lives in the network, an internal ledger, a callback consumer or the interface.

Track how many payments reach confirmation within the promised window, how many enter reconciliation, the age of the oldest unresolved payment and the delay between financial completion and user notification. Treat stale “processing” screens as incidents, not cosmetic defects. Test weekends, holidays, dependency degradation and missing callbacks as normal operating conditions.

Real-time rails make a stronger product promise possible: money moves now, and both sides know what happened now. They also remove a familiar excuse. Once immediate, round-the-clock confirmation becomes normal, unexplained waiting no longer feels like the payment system doing its work. It feels—correctly—like the product has lost the payment.

Sources

Fast payments — Enhancing the speed and availability of retail payments (opens in a new tab) — Committee on Payments and Market Infrastructures, Bank for International Settlements.

Regulation (EU) 2024/886 as regards instant credit transfers in euro (opens in a new tab) — European Parliament and Council, EUR-Lex.

What is TIPS? (opens in a new tab) — European Central Bank.

FedNow Service Operating Procedures, Version 3.6 (opens in a new tab) — Federal Reserve Financial Services.

Real Time Payments (opens in a new tab) — The Clearing House.

Exceptions and Investigations — Maintenance 2020–2021 (opens in a new tab) — ISO 20022.

Confirmation of Payee FAQs (opens in a new tab) — Pay.UK.

Payment Request API (opens in a new tab) — World Wide Web Consortium.

TARGET Services Annual Report 2025 (opens in a new tab) — European Central Bank.

HTTP Semantics (RFC 9110) (opens in a new tab) — Internet Engineering Task Force / RFC Editor.