Visa's developer FAQ contains one sentence that explains the entire agentic commerce stack. The agent does not make payment decisions. It executes payments the buyer has already approved.
Read it twice. That is not a product description. That is a liability assignment wearing a feature's clothes.
In October, four payment stacks published agentic checkout designs. Visa, Mastercard and Amex on the network side. PayPal and Stripe on the wallet and acquiring side. BILL, Billtrust and Sierra in orchestration. Crossmint and Robinhood as non-card comparators. Mastercard's public demonstration: an agent completed nine payments inside a single pre-approved budget.
Nine executions. Zero decisions. Nine is not a scale figure โ it is a proof of the absence of a decision branch in the loop. Strip the branding and the demo is a for-loop with a spend cap and no conditional. Everything below is downstream of that missing branch.
The October releases share a shape that is easy to miss, because each vendor framed it as a capability. Read the deployment status instead of the feature list. Every one of the four primary stacks sits behind a pilot gate or a sales gate. None published a general availability date. Admission is application-only, and not one vendor published the criteria used to judge applications.
That is the tell. A capability launch ships with documentation and an SLA. A liability launch ships with a gate, an application form, and a lawyer reading the terms.
The functional claim across all four is narrow and defensible. An agent receives a scoped authorisation โ a budget, a merchant category, a time window, sometimes a single-use credential โ and executes against it. The buyer approves first. The agent acts second. No stack lets the agent choose the funding instrument, open a new account, or initiate an account-to-account transfer.
This is why the compliance picture comes back clean. No new licence, no regulatory filing, no PISP or PSP registration appears anywhere in the four designs. The agent was classified as an executor of an already-authorised instruction, which drops it inside the existing sponsored-access framework: issuer and acquirer sponsorship, existing card network rules, existing chargeback machinery. Amex has not finished defining what a registered agent even is; its definition is still in development, which means the classification is currently a placeholder rather than a specification.
The word "executor" is doing more regulatory work than any circuit in the stack. It is a deliberate classification, not an engineering description. Call the agent an executor and it inherits the merchant's and the issuer's licences. Call it an initiator and it needs its own. The entire October cohort chose the first word.
That choice has a shelf life. The moment an agent gains the ability to select among funding instruments, or to route an account-to-account payment across institutions, the licence gap opens immediately and the classification collapses. Every stack I examined is engineered to stay on the safe side of that line โ which is why the agent's authority is scoped by a budget rather than by a goal. A budget is a constraint you can audit. A goal is not.
Then the data architectures. Two of them, and they are not equivalent.
PayPal's design surfaces the merchant's product catalogue to the agent. The agent has to see the catalogue in order to shop inside it. Stripe and Sierra invert this: the agent never sees card data at all, and operates against an opaque credential that resolves at the issuer.
The first architecture is a prompt-injection surface. A merchant controls catalogue text; a merchant therefore controls text an agent will read and act on. The second is cleaner on card-data exposure but does not remove the problem, because the agent still holds a live, scoped authorisation. Authorisation is the attack surface, not the defence. An agent that cannot see a card number but can spend forty thousand ringgit inside an approved budget has a very specific and very tradable capability.
The orchestration vendors sit at a different point on the gradient. BILL, Billtrust and Sierra hold neither the credential nor the rules; they sit between the buyer's intent and the issuer's authorisation, which makes them the most exposed and least protected party in the chain. When the first dispute lands, the orchestrator will be the defendant with the thinnest contractual cover โ because the network's rules bind issuers, the issuer's terms bind the buyer, and nobody's rules bind the orchestrator except its own sales contract.
Now the number. Across the public material I could obtain from all four stacks, exactly one quantified figure appears: 71.3%. No denominator. No methodology. No sample date. I am not going to pretend that is evidence of anything. Math doesn't read press releases. In audit work, a statistic that arrives without a sampling frame is a marketing artefact; treat it as decoration until someone publishes how it was produced.
What no vendor published is the liability schedule. When an agent mis-executes โ wrong merchant, wrong amount, wrong currency, duplicate settlement โ the loss lands somewhere. On the buyer, on the issuer, on the acquirer, on the orchestrator, or on the merchant. Four stacks, four gates, zero public allocation. That silence is the actual reason there is no general availability date. The technology works. The loss waterfall does not exist yet.
Then cross-border. The source material does not touch it, and neither does any vendor document I could locate. This is the largest compliance vacuum in the design. An agent that selects currency, merchant jurisdiction and settlement rail simultaneously triggers foreign-exchange rules, sanctions screening, and VAT or GST withholding โ three obligation sets, three different regulators, no assigned owner. In my own contract reviews of agent-authorisation flows, this is consistently the paragraph nobody has drafted. My working prediction: cross-border agent payments land twelve to twenty-four months after domestic ones, and they land as named corridors with whitelisted merchants, not as an open rail.
Which brings up the structural point. The networks are performing regulatory functions under a private label. Application-only admission with unpublished criteria is rulemaking. It is efficient in the absence of incidents. It will not survive the first one.
The consensus blind spot is security โ reentrancy, key management, prompt injection. Fine. But the deeper exposure is substitution.
Mastercard's nine-payment demo is a programmable-money use case executed on a card rail. Budget-constrained conditional payment is the textbook definition. If a wholesale CBDC or an e-CNY smart contract exposes native programmable authorisation, the intermediate layer โ tokenised credential plus pre-authorisation instruction plus orchestration vendor โ loses most of its value, and the networks drop from rule-setter to optional channel. None of the four October designs addresses this. They are optimising a toll booth on a road that may be rerouted.
The second blind spot is dispute resolution. Card rails work because chargebacks exist. An agent executing inside a buyer-approved budget is, by construction, an authorised transaction. Authorised transactions do not charge back. So the dispute layer that makes card payments safe has been engineered out of the agentic flow by the very scoping that makes the flow compliant. Nobody in the cohort has published an arbitration model for the sentence every buyer will eventually say: the agent did what I approved and I did not mean it.
The stack is coherent, conservative, and honest about its own boundaries โ rarer than it should be. But it is a firewall dressed as a feature set, and firewalls get tested.
The question worth holding through this bull market is not which network ships agentic checkout first. It is who writes the loss waterfall, and whether they write it before or after the first nine-figure agent mispayment. Privacy is a protocol, not a policy. So is liability.