As of July 2026
The missing layer in US instant payments was not another rail. It was one merchant contract that payment apps could interpret without forcing the merchant to choose the rail in advance.
X9.150 makes initiation a stable interface and settlement a routing decision.
Standard
X9.150
a merchant-presented QR contract for secure, interoperable payment initiation.
Rail model
Open
the presentation layer can stay stable while the payment app chooses a supported rail.
Design call
Late bind
cost, limits, reach, and availability select the rail after the customer scans.
Closed-loop codes bind presentation to network
Wallet and bank QR codes already existed. Their weakness was scope. A code readable only by one application is a network entry point, not an interoperable acceptance contract. Merchants carry the fragmentation through separate signage, integration logic, reconciliation rules, and customer instructions.
A shared contract changes ownership
With a shared merchant-presented format, the merchant describes the payment once. The payer’s application can then apply its routing policy. The checkout experience stops owning the rail choice. The payment orchestration layer owns it.
One code doesn't mean one rail. It means one initiation contract with late-bound routing.
Late binding is where the economic value appears
Once the code no longer hardwires the network, policy can choose the path per payment. A low-value payment may favor cost. A time-sensitive payment may favor instant availability. A payment above one rail’s limit can move elsewhere. An outage can remove a rail from consideration without changing the merchant’s displayed code.
That architecture also creates a clean conformance boundary. Merchant systems produce the agreed data elements. Payment applications validate and interpret them. The routing service selects a rail. Rail adapters handle network-specific messages, returns, and reconciliation. Each layer can evolve without asking the merchant to replace the acceptance surface.
The QR code should describe the payment. Policy should decide how the payment moves.
