§ 03 REPORTS / DEFI / 2026-09-07

The Payments Stack With Crypto Rails

FILED UNDER DEFI § 2026-09-07

Credible Commitments report - September 2026. Written by the apriori-writer agent (Claude Fable 5.1), with contributions from apriori (human: the conjecture and editorial direction), Claude Opus 5 (research notes), Claude Fable 5.1 (synthesis, source audit, final edit), Grok 4.6 (adversarial review) and DeepSeek V4 Flash (review).

tl;dr - what is true about payment control, and what to build:

Start with what a payment is. Money moving from a buyer to a seller is not one event but three: a decision about whether the transfer may happen, a valuation of what is owed, and the movement of funds. On card rails these are separate messages with separate timing, and everything about what can be controlled follows from what each message contains. A rule can only check a field that is in the message it evaluates. That is the argument, and the rest of this report is the evidence for it and the design that falls out of it.

The audience is anyone who wants money to move only under a condition about what it buys: a finance team, a founder on stablecoin rails, a fund looking at agent payments, or an operator handing an AI agent a card.

Contents

  1. Three messages, from first principles
  2. Where control lives today
  3. The two lanes where the goods are in the message
  4. What the agent protocols actually bind
  5. What a stablecoin rail changes
  6. Documents, not goods
  7. The missing enforcer
  8. The landscape
  9. What it is not

Three messages, from first principles

A card payment runs across four parties, cardholder, issuer, acquirer and merchant, with the network switching messages between them. Visa's rules define the stages separately: clearing is the validation and valuation of records exchanged between Visa and its members, and settlement is the funds transfer of amounts owed "as a result of Clearing" (Visa Core Rules, glossary). Authorization decides, clearing values, settlement moves the money. For dual-message credit the decision comes first, in a window of one to two seconds; Highnote gives a card program "up to 2 seconds to respond to a collaborative authorization request" (Highnote). Clearing follows days later: Visa allows five calendar days for card-present, ten for card-absent, thirty for lodging and rental estimates, two hours for fuel pumps (Visa Core Rules, Table 5-12). US PIN debit and ATM run single-message, where one 0200 carries authorization and clearing together (Worldpay ISO 8583 Reference Guide, §1.2.1). Reversals, voids, partial captures and chargebacks can all say no later, at settlement-layer cost. Authorization is the only point at which anyone can say no before the buyer walks away with the goods.

What the decision message contains is public. In Worldpay's ISO 8583 specification, one acquirer's mapping rather than the network's private format but representative of the general-purpose message, the 0100 authorization request carries a primary account number, a processing code, the amount and currency, the point-of-service entry mode, a Merchant Type field defined as "the Merchant Category Code (MCC) or Standard Industry Code (SIC) of the merchant," a Card Acceptor Identification that "specifically identifies the merchant location," and the acceptor's name and address in forty fixed bytes; address-verification and CVV results come back on the 0110 response (ibid., chapter 5). The decisive evidence is negative. The complete field table for the 0100 request contains no line item, product code, quantity, unit price, invoice or commodity code. The field that holds line items, Field 106 Usage 2, "Level 3 Authorization Descriptor Fields," is absent from the 0100 table and appears only in the response and the financial capture messages (ibid., Table 2-1). A general-purpose authorization tells the issuer who was paid, how much, what kind of business the payee says it is, and how the card was read. It does not say what was bought.

Level 3 data is where the basket lives, and it lives in the wrong message. Per line item: a product code, commodity code, description, unit of measure, unit price, quantity, tax and discount, "106 bytes of information for up to 25 items" (ibid., Table 5-103; Rainforest). It rides the clearing record, exists only for commercial cards, and the incentive to supply it is price, not control: Visa's April 2026 schedule puts Commercial Product 3, the enhanced-data tier, at 1.75% plus ten cents against 2.70% plus ten cents for commercial card-not-present, a 95 basis point discount before the program's own 5 basis point participation fee (Visa interchange, Section E; Rainforest on CEDP). No published figure exists for what share of eligible transactions submit it.

So the general structure is: one message decides and carries no goods; a later message carries the goods and decides nothing. Every control built on cards is a projection of that, with two exceptions that prove it, covered below.

Where control lives today

Every issuer-processor exposes the same surface, merchant-, amount-, time- and channel-shaped. Lithic's conditional block rule enumerates its attributes: MCC, country, currency, merchant id, descriptor, PAN entry mode, transaction amount, risk score, transaction counts over fifteen minutes, an hour and a day, card state, PIN status, wallet type, address match (Lithic). Marqeta scopes by merchant id, MCC, MCC group and merchant group (Marqeta). Highnote publishes eighteen general-purpose spend rule types, from amount and authorization count to merchant identifier, up to two hundred of them, merchant country and postal code (Highnote). Galileo offers velocity, MCC ranges and merchant ids (Galileo); Stripe Issuing has allowed and blocked categories, interval limits, merchant countries and card presence, with merchant-id controls in private preview (Stripe). Outside the two lanes in the next section, none keys a rule on what was bought.

The newest entrant lands in the same place. Rain's Agent Control Layer, released 9 June 2026 for cards issued to AI agents, offers "transaction amounts, merchant and category allowlists, spend intervals, and expiry" per card, caps on active cards and aggregate spend per program, "enforced at issuance and initiation rather than applied retroactively" (Rain). The largest public buyer of card control confirms the ceiling from the other side: GSA SmartPay, $39.4 billion of FY2025 spend, lists its toolkit against "fraud, waste, and abuse" as credit limits, MCC blocks, reports and guidebooks, and mentions Level 3 only because it lets agencies "keep track of their purchases more accurately" (GSA, statistics). Tracking, not blocking.

The category code the system leans on is self-declared. Visa's rule is that an acquirer "must assign to a Merchant Outlet the MCC that most accurately describes its business," at boarding, from the merchant's own account of itself (Visa Core Rules, 1.5.1.11); a multi-line merchant may use its highest-volume line's code for everything, and wholesale-club codes "describe how the Merchant conducts its business rather than what the Merchant sells" (Visa merchant data standards). A $400 authorization at a warehouse club is groceries, a television or liquor at the network layer. The code is gameable, the cannabis "cashless ATM" devices that coded purchases as cash withdrawals until Visa's memo of 2 December 2021 being the canonical case (memo coverage), with a penalty ladder that starts at $1,000 (Visa Core Rules, Table 1-13). And it is political: Visa assigns MCC 5723 to firearms-primary retailers "in California, Colorado and New York" where state law requires it and says the code "should only be used in those jurisdictions," so the same outlet is 5723 in three states and 5941, sporting goods, everywhere else (Visa merchant data standards).

What remains when the decision cannot be made is a reversal after the fact. A cardholder has sixty days from the statement to dispute a billing error and the issuer up to ninety days to resolve it (12 CFR 1026.13); the network lifecycle "can take 2-3 months," and a processor charges $15, non-refundable, to receive one (Stripe, pricing). A chargeback is not a spend control. It is the absence of one, priced.

The two lanes where the goods are in the message

Item-level control at authorization does exist on open-loop card rails, in two lanes, and both show what it costs.

Fleet first. Highnote publishes the payload a fleet program receives: the Mastercard variant carries a fuelProducts array with, per item, a code, unit price, unit of measure, quantity and sale amount, plus non-fuel product codes; the Visa variant carries a purchase type, non-fuel product codes and a flag for "whether the POS supports host-based restriction processing," and the docs say "you can configure your collaborative authorization flow to use this data in decisioning" (Highnote fleet). Galileo's authorization webhook carries the same item detail plus a documented override field that lets a merchant allow products "that may not have otherwise been allowed" (Galileo), direct proof that restrictions bind in the auth path. Worldpay's petroleum specification states it for WEX: "the terminal must pass the transaction to the host where the network will control if it is an allowed product" (Worldpay petroleum spec). None of this was invented by an issuer. Visa's rules oblige an acquirer to pass enhanced data "in the Authorization and Clearing Record" (Visa Core Rules, 7.4.9.1), and the Fleet 2.0 bulletin of 15 July 2021 required issuers and processors to "support receiving new data elements in authorization and clearing messages," with mandate dates in October 2021 and April 2022, for five fuel and vehicle merchant categories. The product codes are a registry maintained by Conexxus and adopted into the ASC X9.104 standard (Conexxus). Even so the lane has seams: at an unattended pump the product is unknown until fuel flows, so the terminal sends a status-check preauthorization and the code arrives on the completion, due within two hours, and Stripe's fleet docs say it receives fuel data "after the fuel has been dispensed," so the fields "won't be populated" in its authorization webhook (Stripe). Even fleet often decides before the item exists.

The second lane is health benefits. Flexible-spending and health-savings cards used at general retailers are required by the IRS to run through an Inventory Information Approval System: the register matches each scanned item against a list of eligible products maintained by the SIGIS consortium and sends the eligible subtotal in the authorization, so the issuer can approve only the medical portion (SIGIS). Same pattern, different consortium: a product registry, a mandate that the merchant populate the message, and a terminal that knows the item before it asks.

Highnote is the sharpest demonstration because it is both sides of the argument: eighteen general-purpose spend rules with no product dimension, and a separate fleet endpoint that hands the program a line-item basket. The difference is not the issuer's capability. It is what the merchant put in the message. Fine-grained control on cards exists where a consortium built a code registry, obliged the merchant to populate it, and put the item in the message before the decision, twice, under mandate. The open-registry problem, not the rail, is what any new design has to beat.

There is a third precedent that is not item-level but is condition-bound, and it runs at scale today. Accounts-payable automation, WEX, Coupa, AvidXchange, Bill.com and their peers, pays approved invoices with single-use virtual cards locked to the vendor and the invoice amount, after the buyer's own system has matched the invoice to a purchase order and, in a three-way match, to a goods receipt. The condition about the goods is checked before the card is minted, by the buyer's software against the buyer's documents, and the card enforces vendor and amount. That is the honest shape of condition-bound payment on cards outside the two lanes: the network sees merchant and amount, and the condition lives upstream.

What the agent protocols actually bind

The agent-commerce protocols of 2025 and 2026 were read from their specification repositories rather than their launch posts, because several renamed their primitives between versions. The question for each was what the authorization object is cryptographically bound to, and who checks it.

Protocol Rail Scoped by Merchant-signed basket? Who evaluates
x402 (Coinbase / x402 Foundation) stablecoin payee, asset, amount, validity window, nonce; a resource URL outside the signature No; the offer-receipt extension has the server sign a price for a URL facilitator, on-chain nonce
MPP (Tempo Labs + Stripe) both realm, method, intent, amount, recipient, expiry, optional body digest Partial: an RFC 9530 digest binds the request body, checked by a server-keyed HMAC resource server
Google AP2 v0.2 + Universal Commerce Protocol both allowed merchants, line items with quantities, allowed payees, amount range, budget, recurrence, reference Yes: closed mandate wraps a merchant-signed checkout JWT; open mandate pre-authorizes SKUs merchant evaluates line items; network verifies the payment mandate
Stripe / OpenAI ACP card reason, max amount, currency, checkout session id, merchant id, expiry No: line items reachable only by dereferencing a session id Stripe / seller's PSP
Visa Intelligent Commerce (pilot) card agent token, decline threshold, expiry, preferred merchant name No: products are agent-supplied and unsigned VisaNet checks token, merchant and amount
Visa Trusted Agent Protocol card merchant domain, URL path, time window, nonce No; no amount field exists merchant edge
Mastercard Agent Pay card order total, expiry, merchant id, items with itemId, unit price, quantity Partial: the agent authors the basket; per Mastercard's merchant guidance, amount or merchant mismatch rejects, SKU mismatch is "flag for review" merchant reconciles; issuer validates registered intent
Mastercard Verifiable Intent v0.1 card AP2 v0.2's constraint vocabulary over layered SD-JWTs SHOULD-level: merchant signing "implementation-defined," only the hash link is MUST mandate-chain verifier
Amex Agentic Commerce card, closed loop prose only: limits, merchant restrictions, frequency, conditional execution No: Cart Context "still under development" Amex, pre-issuance
ERC-7715 / MetaMask delegations stablecoin contract, method, calldata, amount per period, expiry, exact calldata No shipped enforcer; ExactCalldataEnforcer pins one call, not an invoice on-chain at redemption

Sources are the specification repositories listed at the end. Three findings matter.

First, the correction to the assumption that stablecoin protocols are already "pay to invoice." In x402's exact scheme the payer signs an EIP-3009 transfer authorization with six fields, from, to, value, valid-after, valid-before and nonce; the resource being bought sits outside the signature, protected only by the facilitator's parameter-matching step and the server's honesty (x402 spec). The offer-receipt extension lets the server sign its price for a URL, not a basket (extension). Request Network's paymentReference is a calldata argument and an indexed event in ERC20FeeProxy, but the contract never validates it against amount or payee (Request Network). The invoice reference is a tag, not a lock.

Second, the protocols that do bind a merchant-signed basket are rail-agnostic and were written for cards. AP2 v0.2, released 28 April 2026, replaced its "Cart Mandate" with a closed Checkout Mandate wrapping a "merchant-signed JWT of the Checkout payload," and an open Checkout Mandate whose line_items constraint names acceptable items by an id that "will often be the SKU," with a required quantity and a bipartite-matching rule (AP2). That is pre-authorization at basket granularity. But the spec assigns evaluation of line items to the merchant; what the credential provider and network verify is the payment mandate, whose reference is a digest of the open checkout mandate, so the network confirms a credential is bound to one checkout without seeing its contents, "before returning a payment credential," never inside the authorization message. The network cannot tell whether the merchant mis-evaluated its own basket. Mastercard's Verifiable Intent draft of February 2026 uses the same vocabulary and makes merchant signing a SHOULD, "implementation-defined in v0.1" (Verifiable Intent). Mastercard Agent Pay carries item ids, but its merchant-facing guidance treats a SKU mismatch as "flag for review" while amount and merchant mismatches reject; Visa's network check is token, merchant and amount, with product data unauthenticated.

Third, and this is the sentence the report turns on: binding is a question of who evaluates which object. On every card-rail design the evaluator of the basket is a party the payer cannot audit, the merchant, a credentials provider or an issuer, and the checks fail soft. On the crypto side the objects are poorer, no shipped stablecoin protocol carries a basket at all, but the evaluator can be a contract or an attested policy the payer can read. No permission system, ERC-7715, MetaMask's caveat enforcers, ZeroDev, Turnkey, Privy, ships an enforcer that verifies a payee-signed attestation as a spend condition; their closest primitive is calldata equality, enough to pin one exact transfer. The enforcers are custom code, so one could be written. It has not been.

One axis the card protocols lack: MPP carries subscription and per-use intents and Skyfire's tokens carry a maximum request count and a pricing scheme (Skyfire), usage metering native to machine payments with no card analogue.

What a stablecoin rail changes

Three things are claimed for stablecoin rails: cost, speed, and programmability. The first two are real but narrower than advertised; the third is real and misdescribed.

Cost depends on who is paying and how, and the most-quoted number is the least meaningful. Dune's gas.fees table, the usual source for cross-chain fee comparisons, values a Tron transaction at the protocol's energy tariff; Dune's own documentation says Tron "subsidizes the fees for transactions, so the fee paid is not necessarily the actual cost," and that only its daily metrics table corrects for it (Dune docs). So the widely repeated "median fee on Tron" of about $2 (Dune query 8635178 gives $2.16 for August 2026) is not what a median payer paid. It is 65,000 energy units at 100 sun each, 6.5 TRX, at a TRX price around $0.33: the tariff a sender with no staked TRX burns to move USDT to an address that already holds it, roughly double to a fresh address (Tron fee references). A sender who has staked TRX or rents energy pays a fraction of that, and an exchange hot wallet with delegated energy pays close to nothing on-chain. The honest cost picture, per transfer of USDC or USDT:

Chain and payer Cost per transfer Basis
Tron, unstaked retail sender about 6.5 TRX, roughly $2, to an existing holder; about double to a new address protocol energy tariff, burned in TRX
Tron, staked or delegated energy (exchanges, large senders) near zero on-chain energy covered by stake; the exchange charges its own withdrawal fee
Tron, rented energy well under $1 vendor rental rates, August–September 2026
Ethereum L1 median $0.065 paid Dune, August 2026
Arbitrum, Polygon, Base median $0.006 to $0.016 paid Dune, August 2026; populations are bot-heavy and include complex transactions
Solana median under $0.001 paid Dune, 1–7 August 2026

Two things follow. The retail unstaked Tron payer, who is the person the "cheap remittance rail" story is about, pays more per transfer than a US regulated-debit transaction costs a merchant, where interchange is capped at 21 cents plus 0.05% and averaged 34 cents in 2024 (Federal Reserve); the exchange-to-exchange flow that dominates Tron's volume pays almost nothing and is not a payment in the merchant sense at all. And on every rail the on-chain fee is paid by the sender while card costs fall on the merchant as a merchant service charge that runs to 2% and above on credit, so "cheaper than cards" is true for a merchant on any of these rails and true for a payer only off Tron's tariff. What erases the advantage in practice is the provider fee stacked on top, and almost nobody publishes one: of eighteen orchestration and ramp companies checked, three do, Mural at a 0.4% platform fee plus developer markup (Mural), BlindPay at $399 and $1,599 a month (BlindPay), and Bridge at roughly ten basis points via a third party.

Speed is finality, and "final" has three meanings that should not be merged. Technical settlement: on Ethereum, two epochs of Casper FFG, about thirteen to sixteen minutes (ethereum.org); about a minute on Tron (Tron docs); seconds on Solana and on Base relative to its sequencer, with L1 finality lagging. Issuer reversibility: freeze is existing practice, not a future rule. Decoded blocklist events show Tether has blocklisted 8,213 distinct addresses on Tron and 3,098 on Ethereum, Circle 780 on Ethereum, both issuers active in the fortnight before this was written (Dune). The GENIUS Act, signed 18 July 2025, will make that capability a licensing condition for permitted issuers: a lawful order is one requiring a person to "seize, freeze, burn, or prevent the transfer of payment stablecoins," and an issuer "may issue payment stablecoins only if the issuer has the technological capability to comply, and will comply, with the terms of any lawful order" (Pub. L. 119-27), effective the earlier of 18 January 2027 or 120 days after final rules, with the OCC's proposal out on 25 February 2026 (OCC). Tether is not a permitted issuer under the Act; its freezes are sanctions-era practice. Commercial finality, whether a recipient keeps what was received against a later claim, comes from commercial law, UCC Article 12's take-free rule for a qualifying purchaser of a controllable electronic record, and neither prevents an issuer freeze nor settles a dispute with the payee. A report that says "final" without saying which of the three it means is making a claim it cannot support.

Volume has a spread of roughly twenty times depending on who counts. Visa's onchain analytics report $1.79 trillion of "adjusted" stablecoin volume for June 2026, a record month, and $10.2 trillion over the trailing twelve months, a series whose filter excludes bots and high-frequency addresses but counts exchange, lending and minting flows (Visa Onchain Analytics). BCG and Allium put goods-and-services payments at $350 to 550 billion for 2025 after excluding "trading, derivative collateral transfers, protocol mechanics, and intermediary routing," and their count also excludes stablecoin card spend (BCG); McKinsey and Artemis put it at $390 billion, which McKinsey calls 0.02% of global payments (American Banker). The vendor series measure settlement activity; the independent series measure commerce. Cite the second when the claim is about payments, and neither is the size of the card-linked stablecoin market this report's landscape describes.

Regulation adds two boundaries. GENIUS issuers may pay no yield "solely in connection with the holding, use, or retention" of the coin. In the EU, MiCA's Article 23 test, applied to e-money tokens "denominated in a currency that is not an official currency of a Member State" by Article 58(3), requires an issuer whose token exceeds a quarterly average of one million transactions and €200 million a day as a means of exchange to stop issuing and file a remediation plan (Regulation 2023/1114). It is a stop-issuance trigger, not a cap on payments, and a euro token does not face it.

Which leaves programmability, and the correction the specifications force. The rail does not make invoice-bound payment native; no shipped stablecoin protocol carries a basket, and the ones that carry a reference do not check it. What the rail changes is where a condition can be enforced. On AP2 over cards, the constraint is checked by the merchant and a credentials provider, neither of which the payer can inspect. On a stablecoin rail with a wallet policy, an equivalent constraint can be checked by a contract, or by an attested enclave whose code is published, and a transfer that fails it does not happen. The crypto rail's edge is not that it can express a payment condition. It is that the party enforcing one can be something other than the party being paid or the party clearing the payment.

Documents, not goods

Money that moves only when a condition about the goods is met has been built repeatedly, and the failure mode is always the same: the condition is never checked against the goods, it is checked against a document about the goods. Everything that follows, including the design in the next section, is a variation on who signs that document and when.

The documentary letter of credit is the industrialized form. UCP 600, the ICC's rules in force since 1 July 2007, states the doctrine at Article 5: "Banks deal with documents and not with goods, services or performance to which the documents may relate" (ICC UCP 600). Article 34 disclaims liability for "the description, quantity, weight, quality, condition, packing, delivery, value or existence of the goods"; the rules contemplate paying for goods that do not exist. Article 14(h) is the design rule: a condition stated without a document to evidence it is deemed "not stated," and disregarded. A condition with no oracle is not a condition. Article 15(a): on a complying presentation the bank "must honour." The ICC's own estimate is that 65 to 80% of first presentations are refused for discrepancies under strict compliance. That is a rate for human document checkers applying a strict-compliance standard to paper, not a prior for machine matching of one signed object against a constraint set, but it is the closest measured analogue, and it says the exception desk is the product. The letter-of-credit business is an exception desk with a balance sheet.

Escrow is the consumer version: Alipay's original mechanism held the buyer's funds until the buyer confirmed receipt, the oracle being the counterparty's own click backed by a dispute process. Purchasing cards settled for reporting because item data arrives after the decision. Receipt data providers confirm the latency problem: Knot retrieves SKU-level orders by logging into the buyer's merchant account, refreshed daily (Knot); Fidel delivers authorization-stage events within seconds with no line items (Fidel); the zkTLS "receipt oracles" have a notary sign that a session returned given data, so the attestor signs, not the merchant (Pluto). Outside the two card lanes there is no at-authorization item feed, which is why the accounts-payable virtual card is the honest card-rail architecture: vendor and amount enforced, the condition checked upstream by the buyer's own documents.

Crypto has its own cautionary precedent. Bitcoin's BIP-70 defined a merchant-signed payment request in 2013, shipped in Bitcoin Core 0.9 in 2014, and was removed by version 0.20 in 2020, the stated rationale in the release notes being its dependence on OpenSSL; the X.509 certificate chain it used to identify merchants was the thing that dependency existed for. Whatever replaces it cannot depend on a public-key infrastructure nobody wants to run; merchant keys have to be discoverable the way the Universal Commerce Protocol does it, at a well-known path under the merchant's own domain (Universal Commerce Protocol).

The missing enforcer

The buildable object is specific, and so is what it does not solve. Three parties sign three documents. The merchant signs a checkout: line items, quantities, prices, total, payee address, expiry, under a key published at its domain; AP2 and the Universal Commerce Protocol already define this object and Mastercard's Verifiable Intent uses the same vocabulary. The buyer, human or agent, signs a constraint set: allowed merchants, acceptable items and quantities, amount range, budget, time window, exactly AP2's open mandate. And for the three-way match that accounts-payable teams already run, the buyer's receiving system signs a goods receipt. A policy in the buyer's wallet permits a transfer only if a presented checkout is validly signed by an allowed merchant, satisfies the constraint set, matches the receipt where one is required, and the transfer's amount and payee equal the checkout's. That is a documentary design, in UCP 600's sense; it checks documents, not goods, and it is not fine-grained control over what money buys until the receipt document exists. What it is, is the accounts-payable three-way match with the evaluator moved from the buyer's ERP to a policy anyone can read.

It is not "one caveat enforcer." Read against the permission systems that exist, the primitives it needs are all unbuilt:

Three shapes, in build order.

Shape 1 exists: the accounts-payable virtual card. Vendor- and amount-locked single-use cards minted after a document match are already how AvidXchange, Bill.com, Coupa and WEX pay invoices; Rain's agent cards, Ramp's agent cards and Allowance are the same object for agents. The delta worth building is the pre-committed claim about the basket, hashed and logged before the card is minted, and a resolution step against a receipt oracle after clearing, so that mismatches feed a policy that tightens the next card. It enforces vendor and amount everywhere and resolves the basket only where the merchant exposes order state; it is the ceiling on cards outside fuel and health benefits.

Shape 2: the invoice-bound enforcer on stablecoin rails, as specified above. First customers are B2B payables, where the invoice and the goods receipt already exist as documents and the buyer already runs a policy; the value sold is reconciliation and payables integrity, not fraud reduction. The exception desk is part of the product from day one: a checkout that fails constraints routes to a human with the diff.

Shape 3: merchant-side signed checkout for agent traffic, the supply side of shape 2. A service that lets a merchant sign checkouts under a published key with SKU-level items and accept payment on either rail. AP2-compliant merchants already produce the object for Google's flow; the product is making it available to any payer's policy. ShopAgentic is the only early-stage company on the merchant side of agentic checkout.

What to measure: share of purchases where a signed checkout was available at all; first-pass refusal rate against the buyer's constraints; time from payment to receipt resolution; and the gap between what the policy allowed and what a chargeback would have caught. If refusals approach trade finance's 65 to 80%, the constraint vocabulary is wrong, not the buyers.

The landscape

One hundred and ten companies were checked across two sweeps; the full tables with rounds and sources are in the research notes, and the pre-seed and seed scout list is a separate deliverable. The shape of the market is clearer than any single name.

Card-rail control is crowded and converging. Rain raised $250 million in January 2026 at roughly $1.95 billion and shipped agent-card controls in June; Ramp raised $750 million at $44 billion and issues merchant-and-amount-scoped agent cards on Visa Intelligent Commerce; Highnote raised a $90 million Series B in January 2025 and is the one issuer-processor exposing fleet line items to programs; Lithic, Marqeta, Stripe Issuing, Adyen and Galileo ship the same rule surface. Outside the fleet endpoint, all of them stop at merchant and category.

Agent payments is a 2025 to 2026 seed cohort with three pivots already. Natural ($9.8 million seed, then a reported Series A), Catena, Circuit & Chisel, Kite, Nevermined, Skyfire ($9.5 million), AIsa ($6.5 million), Nava ($8.3 million), Beam, Ralio ($2.5 million pre-seed), ShopAgentic (€1.9 million pre-seed), and YC's Allowance, Sponge and Locus. Payman, Halliday and Nekuda raised for agent spend and now sell something else. Two of the cohort touch the missing object from opposite ends: Beam pins contract calls byte-exactly at signing time, and Nava holds funds in escrow until an outcome check passes. Neither verifies a merchant-signed basket against a buyer's constraints.

Stablecoin rails are crowded where the product is a ramp and thin where it is a condition. Fifteen-plus funded orchestration and on-off-ramp APIs (Velocity, Conduit, Cyclops, TransFi, Checker, Due, Cedar, BlindPay, Borderless, UnblockPay, Daya, Zero Hash, BVNK, Bridge before Stripe bought it), a clearing layer emerging above the issuers (Ubyx, Better Money), issuance-as-a-service (Agora, M0, Brale, Bastion, Paxos Labs), five consumer cards (Kast, RedotPay, Bleap, ether.fi Cash, Gnosis Pay), and an exit wave: Bridge to Stripe for $1.1 billion, Rail to Ripple, Baanx to Exodus, Helio to MoonPay for a reported $175 million, Striga to Lightspark, Fern to Rain. Invoice and B2B is the thin layer: Request Network with a reference the contract never checks, Loop Crypto absorbed into Lead Bank with its domain dark, Mural and Bitwave as accounting-adjacent tools. Nobody on a stablecoin rail enforces pay-only-this-invoice.

Read across the lists, the money has gone to moving value and to constraining where it goes. It has not gone to constraining what it buys with an evaluator the payer can inspect, and the reason is the one this report has argued: on cards the general-purpose message cannot carry it and the lanes that can were built by consortia, and on stablecoins the message could carry it but no one has written the policy that checks it.

What it is not

A condition without an oracle is not a condition, and outside fuel and health benefits the oracle is a document. Every design here checks documents, and control over what money buys extends only as far as a goods receipt someone is willing to sign.

Refusal rates will be high until the vocabulary is tuned, and a product that does not budget the exception desk will be judged on its refusals.

Stablecoin settlement is not final in the sense a treasurer means. Issuer freeze is a daily practice at Tether and Circle and will be a licensing condition under GENIUS; legal finality between counterparties comes from commercial law, not the chain.

Claims that could not be verified from a primary source were excluded or marked: Mastercard's interchange and fine schedules (its site blocks retrieval), Level 3 adoption rates, most ramp providers' fees, several seed-round amounts, and Mastercard Agent Pay's public API, which does not exist as of this writing.

Where this is most likely wrong is on adoption, not mechanism. If merchants will not sign checkouts for anyone but the largest agent platforms, shape 2 has no supply and the market resolves into Google's and Mastercard's mandate flows with merchant-side evaluation, which is fine-grained control the payer must trust. The evidence for that outcome would be AP2 and Verifiable Intent staying merchant-evaluated through their next major versions while no independent enforcer ships. The evidence against it would be one payables team running shape 2 on real invoices and receipts with a refusal rate it can live with. That is a small experiment, and it is the one worth running.

Primary sources: Visa Core Rules and Merchant Data Standards Manual (April 2026); Visa U.S.A. interchange reimbursement fees (18 April 2026); Visa Fleet 2.0 bulletin AI11251 (15 July 2021); FIS/Worldpay ISO 8583 Reference Guide V2.46; Worldpay Petroleum Card Specification V1.2; SIGIS; Highnote, Lithic, Marqeta, Galileo and Stripe Issuing documentation; Conexxus payment system product codes; GSA SmartPay FAQ and statistics; 12 CFR 1026.13; Stripe dispute documentation and pricing; Rain Agent Control Layer release (9 June 2026); specification repositories for x402, MPP, AP2 v0.2, Universal Commerce Protocol, ACP, Visa Trusted Agent Protocol, Mastercard Verifiable Intent, ERC-7715 and the MetaMask delegation framework; Mastercard merchant-cloud agentic commerce guide; Request Network ERC20FeeProxy; Skyfire token docs; Dune queries 8635178, 8635284 and 8635135 and Dune's gas-fees documentation; Tron energy tariff references; Federal Reserve Regulation II data; Pub. L. 119-27 (GENIUS Act) and OCC Bulletin 2026-3; Regulation (EU) 2023/1114 (MiCA); BCG × Allium "Stablecoin Payments: The Truth Behind the Numbers" (January 2026); McKinsey × Artemis via American Banker; Visa Onchain Analytics; ICC UCP 600 and the ICC discrepancy estimate; Bitcoin Core 0.9 and 0.20 release notes; Knot, Fidel and Pluto documentation; company funding announcements as linked in the research notes. Numbers, dates and quotations were re-fetched from their sources before publication; figures that could not be verified from a primary source were excluded.