Claude Commerce Agents vs ACP: Who Charges?

Anthropic's commerce-agents repository gives its shopping agent 23 tools. Not one of them can take money. The StorefrontBackend you implement has eleven required methods covering search, cart, orders, policies and fulfilment, and no method that places an order.

That absence is the whole design. Every other agentic commerce effort this year has worked on making the agent pay. This one works on making sure it cannot.

What Is Anthropic's commerce-agents Repository?

It went up in early September under Apache-2.0, and the README is blunt: "This is a reference implementation; it is not maintained and does not accept contributions." A worked example, not a dependency. CI even checks the seven package names stay unregistered on the public index, so you cannot accidentally pip install shopping-agent-core and inherit an unaudited supply chain. After August's arrayref incident, that reads as deliberate.

Those packages split agent logic from transport and SDK surface across both roles: commerce-common for shared streaming, execution and fencing, then core, runtime and sdk for each of shopping-agent and merchant-agent.

Four demo verticals run on fixed ports, retail on :3000 through entertainment on :3003, against a shared API on :8000. Python 3.11+, Node 22.

Three runtimes carry the same agent: a Messages API loop, the Agent SDK, and Managed Agents fronted by an MCP server. The event union in commerce_common/streaming.py is what you build a UI against, and it has ten members, not the five the README comment shows:

EventType = Literal[
    "text_delta", "tool_call", "tool_result", "ui", "ui_partial",
    "cart_update", "change_update", "progress", "turn_complete", "error",
]

What the Checkout Tool Actually Does

Here is the tool description, verbatim from shopping_agent/tools/registry.py:

Stage the current cart as an order summary the customer confirms in the app; it places no order and charges nothing.

Its input schema is the detail a press release would never print:

{"type": "object",
 "properties": {
   "note": {"type": "string", "maxLength": 300},
   "fulfillment_method": {"type": "string",
     "enum": ["delivery", "pickup", "shipping"]}},
 "additionalProperties": false}

No amount. No currency. No payment method. The model cannot express a charge because the schema gives it no field in which to say one. The hosted checkout URL comes back from the optional checkout_handoff backend method, the host renders it, and per the repo's safety notes it never passes through the model's context.

That is a stronger guarantee than a system prompt saying "do not complete purchases". Prompt instructions are advisory. An input schema with additionalProperties: false is enforced by the parser.

Claude Commerce Agents vs ACP: Who Performs the Charge?

The Agentic Commerce Protocol, maintained by OpenAI and Stripe, answers the same question in the opposite direction. Its stable release is dated 2026-04-17, though OpenAI's hosted docs still carry earlier API versions, so pin whichever you cite.

ACP puts a real checkout API on the merchant: POST /checkout_sessions to create, POST /checkout_sessions/{id} to update, and .../complete to finalise, with order updates arriving by webhook. Payment moves through one delegation endpoint, POST /agentic_commerce/delegate_payment, called from OpenAI to the merchant's PSP. The constraint lives in an allowance object: reason fixed to one_time, max_amount capped at the checkout total, an RFC 3339 expires_at, and a binding to a specific checkout_session_id.

Both keep the merchant as merchant of record and both leave the merchant's PSP executing the charge. The difference is scope. ACP hands the agent a token that moves a bounded amount once, buying a purchase completed inside the assistant. Anthropic's repo declines to define the payment step at all, buying a hard boundary at the cost of a handoff the user finishes themselves.

Where AP2 and UCP Put the Payment Authority

Google's AP2 takes a third position: authority is a signed artefact. An Intent Mandate records constraints before shopping starts, a Cart Mandate binds the exact SKU, price, tax and total, and each travels as a signed verifiable credential. UCP, from Shopify and Google in January 2026, negotiates capabilities from a profile at /.well-known/ucp and separates PSPs from credential providers through a Payment Token Exchange capability. Its spec did not tell me who executes the payment, so I will not claim it.

Set beside NPCI's UAP and UPI Circle, where the cap sits at the issuer bank, the pattern is clear. There are three places to put the brake: the agent's own wallet, as x402 does; a mandate it carries but cannot forge, as AP2 and ACP do; or outside the agent entirely. Anthropic picked the third and paid for it in user experience.

How the Merchant Agent Stages Every Write

The seller-side agent is the more instructive half, because it mutates real state. Every write returns a StagedChange rather than applying anything: stage_listing_update, stage_price_update, stage_inventory_action, stage_promotion, stage_campaign. A lifecycle of get_pending_changes, apply_change and discard_change moves them, and with require_host_approval on by default, apply_change succeeds only for IDs a person approved. On the Agent SDK path that approval is a y/N prompt.

Provenance gates sit underneath. merchant_agent/gates.py accepts a staged write only for listing or campaign IDs that appeared in earlier tool results in the same session. The buyer-side equivalent restricts cart writes to product IDs the catalogue actually returned. Third-party text is sanitised, wrapped in a fixed label and capped before the model reads it. All of it runs inside the tool call, which is why it holds identically across all three runtimes.

Why Checkout Should Stay Out of the Model's Context in 2026

My view, and it is a view: schema-level exclusion will outlast prompt-level policy, and most teams have this backwards.

Agentic commerce has no chargeback story. An agent that misreads an instruction and buys the wrong item inside its allowance has made an authorised payment. ACP's allowance caps the loss at one transaction, a real improvement over an unbounded credential, but it bounds the size of the mistake rather than preventing it. A checkout tool with two optional string fields cannot make that mistake at all.

The prediction: delegated tokens win consumer retail on convenience within a year, and staged approval becomes the default wherever the transaction is large, regulated or business-to-business. Nobody will let an agent reprice a catalogue without a human clicking approve, and StagedChange expresses that more cleanly than anything else published so far.

What This Means for Payment Engineers in the UK

1. Decide where your brake lives before choosing a protocol. Agent wallet, signed mandate, or outside the model entirely. Retrofitting that means rewriting your trust boundary, not swapping a library. 2. Copy the schema discipline even if you skip the repo. If your agent must not do something, remove the field rather than adding a prompt line. additionalProperties: false is enforced; prose is not. 3. Steal the provenance gate. Restricting writes to IDs seen in prior tool results is roughly twenty lines, and it closes the injection path where scraped page text names an ID the agent never saw. 4. Match the pattern to the UK rail you already run. A capped standing consent enforced at the payer's bank is what a VRP consent with PeriodicLimits gives you, enforced where the agent's runtime cannot reach. 5. Do not deploy the demos. They ship with no authentication and loopback-bound MCP servers. It is a teaching repo and says so.

Key Takeaways

• commerce-agents is an Apache-2.0 reference implementation, unmaintained by design, with seven packages kept off the public package index.
• Its checkout tool stages an order summary and charges nothing; the hosted checkout URL never enters the model's context.
• ACP does the opposite, delegating a single-use token bounded by max_amount and expires_at through POST /agentic_commerce/delegate_payment.
• Merchant writes stage as StagedChange objects behind require_host_approval, with provenance gates restricting writes to previously seen IDs.
• Enforce limits in schemas and gates inside the tool call, not in prompt text.