What Breaks When an Agent Buys Goods Instead of API Calls

Why API access was the easy case

Nearly all working machine payment infrastructure was built around one shape: an agent requests a resource, receives a payment challenge, settles, retries, and gets the response.

That shape has properties that make it tractable. Payment and delivery happen together, so there is no window in which one has occurred and the other has not. The thing purchased is verifiable immediately, since the response either parsed or it did not. There is no post-settlement state, because once the response is served the transaction is closed forever. And there is no third party, only the client, the server, and the network.

Buying a physical good, a booking, or a service breaks all four.

Payment happens now, delivery happens later, and the gap can be days. Verification is not possible at settlement time, because whether the right thing arrived is unknown until it arrives. The order carries state that changes after payment: confirmed, delayed, substituted, partially shipped, cancelled. And there are third parties, including a merchant, a carrier, and eventually a person who physically receives it.

So the useful framing is not that agentic commerce needs a new payment layer in the sense of a new settlement rail. Settlement is the part that already works. What is missing is everything that happens after settlement, which the API case never required anyone to build.

The consequences, in order of how much they hurt

Finality removes the buyer's lever. Card rails give a buyer recourse after the fact through a dispute process, and that mechanism is doing more work in consumer commerce than most people notice. It is what makes it safe to pay a merchant you have never dealt with. Stablecoin settlement is final, which is precisely why it works for machine payments and precisely why it is uncomfortable for goods.

The protection has to move earlier. In practice that means one of: escrow with release on delivery confirmation, staged payment against milestones, a holdback retained until a return window closes, or restricting purchases to counterparties with something at stake. Each has costs, and picking none of them means the agent is sending final payments to strangers.

Order state has to live somewhere. The chain records that value moved. It has no concept of a shipment that is late. The agent needs its own durable record binding the payment to an order identifier, an expected fulfilment window, and a current status, or it cannot tell a delayed order from a completed one, and cannot answer what it bought when asked.

A human reappears. Someone receives the goods. That means a delivery address, which is personal information, and often a name, a signature, or an account with the merchant. An architecture that was cleanly machine to machine acquires an identity layer the moment the purchase is physical.

Jurisdiction arrives with it. Tax treatment, consumer protection rules, import duties, and restrictions on what may be sold to whom all attach to a physical delivery in a way they do not attach to an API response.

Substitution and partial fulfilment need a decision rule. A merchant ships a different size, or two of three items. A human shrugs and decides. An agent needs a stated rule for what counts as acceptable, and the default should be escalation rather than acceptance.

What to require before letting an agent buy things

A workable minimum, given none of the above is solved by settlement alone.

A cap sized to total loss. For API calls a spending limit bounds cost. For goods it should bound what you are willing to lose entirely, because recovery from a merchant who does not deliver is a negotiation rather than a mechanism. If that number is uncomfortably small, that is the correct signal about the current state of the problem.

A counterparty policy rather than an open market. Allowlisted merchants, or a requirement that the counterparty has a return path and a reputation to lose. Deny by default and allow by explicit rule applies here more strongly than it does for API access, because a bad API call wastes a fraction of a cent and a bad purchase is gone.

An order record the agent maintains. Payment reference, order identifier, expected delivery, current status, and a deadline after which the order is treated as failed and escalated.

A defined escalation path to a person. For substitutions, non-delivery, and anything outside the stated rules. The goal is not to keep a human in the loop for every purchase, which would defeat the point, but to guarantee one is reachable when the exception occurs.

A return path decided in advance. Who initiates it, where the refund goes, and what the agent does with a partial refund. This is routinely left until the first return happens, at which point there is a payment out and no process.

The honest summary: settlement for autonomous purchases is solved, and the commerce around it is not. Building on the assumption that a payment rail delivers the rest is the mistake worth avoiding.