Name checkout authority before the agent may charge.

The cart is not the charge

Someone demos a shopping agent. It finds a product, fills contact and shipping, and the checkout tools are right there—read the cart, update the fields, complete the order. The room applauds. Nobody asks what ceiling the agent was given, what credential it held, or who had to approve before money moved.

That gap is the whole note.

October 2026 coverage makes the capability plain without turning this into a product roundup. Shopify exposed browser-agent checkout tools—get checkout, update checkout, complete checkout—so an agent sitting in the buyer’s tab can operate the open order. Mastercard and Google open-sourced Verifiable Intent as a trust layer for Agent Pay: cryptographic proof of what a person actually authorized when an agent buys for them. Operators and networks talking about live agent payments keep returning to the same boring controls: spend limits, scoped credentials, and human approval for consequential purchases.

Treat those headlines as a hook. The operating question for anyone shipping ecommerce with agents is older than any tool name. Can your agent complete a charge—and if so, under what written authority?

This is a walk-through. We name the fields before complete_checkout (or your stack’s equivalent) is allowed. Not identity provisioning for ledger writes. Not who may speak a refund after the sale. This is spend and checkout-completion authority.

What you walk through before complete_checkout

Pull one real agent job that can buy—or will buy soon. Walk these fields in order. Later you can keep them on one Agent Checkout Authority Card if that helps the team; the names matter more than the stationery.

Agent job. Stable id for the shopping job: buyer.replenish.office, concierge.gift.under-budget. If the only name is a Slack channel, you cannot revoke the right job when something goes wrong.

Spend ceiling. Currency amount the agent may not exceed per purchase and, separately, per day or per period if you need both. Write the number you will defend in a dispute—not a vibe (“reasonable”) and not an invented percentile of AOV.

Merchant and category scope. Named merchants, allowlists, or category restrictions the credential and the policy both respect. “Anywhere on the open web” is not a scope; it is a refusal to define one.

Payment credential shape. Tokenized one-time or limited-use credential, virtual card with hard limits, or network agent-pay credential—never a raw primary account number pasted into a prompt. Prefer credentials that die after use or after a window, and that an issuer can restrict by amount and merchant.

Intent proof. What evidence must exist before complete is allowed: a signed or attested intent record (the Verifiable Intent idea—constraints such as amount, merchant, payee), an approval artifact from a named human, or both. A chat message that said “sure” in another channel is not proof unless you designed it to be.

Human gate. Which purchases the agent may propose only, which it may complete inside the ceiling, and which still require a named person after the proposal. Consequential purchases—high amount, new merchant, unusual category, first run in production—default to human approval until you widen on purpose.

Complete permission. Explicit: may call complete / may not. Read and update can be wider than complete. Many teams grant all three tools together because the docs list them together. Split them.

Forbidden paths. Unrestricted card access, standing credentials without a ceiling, complete without intent proof, complete when the cart total exceeds the attested intent, and “just this once” overrides in the agent channel with no expiry.

Owner and revoke path. Who may raise the ceiling, who may revoke the credential, and how fast complete stops when they do. If revoke only works by changing a human’s personal card, you never scoped an agent—you lent a wallet.

Walk one dry run with a planted over-ceiling cart. If the agent can still complete, you do not have a gate—you have a story about one.

Intent proof is not a polite prompt

People confuse three different things.

Capability. The agent can call get, update, and complete on a checkout surface—browser WebMCP tools, a merchant MCP, or a network agent-pay API. Capability answers: is the button reachable?

Policy. Your fields say the agent may complete only inside a ceiling, scope, and credential shape. Policy answers: is the button allowed?

Intent proof. A tamper-resistant record that the human authorized this purchase under those constraints—amount, merchant, payee, and whatever else you bind. Proof answers: can issuer, merchant, and operator agree later on what was authorized?

A system prompt that says “always confirm with the user” is none of those three by itself. Soft instruction fails the moment the model is wrong, the tool is invoked from another path, or a second agent inherits the credential.

Verifiable Intent and similar rails matter because they move authorization from vibes into evidence networks can use. You do not need to adopt one vendor’s stack tomorrow to apply the discipline. You do need to refuse complete when proof is missing, when the cart total exceeds the attested amount, or when the merchant falls outside the attested scope.

If you are building the agent side of that gate—not only the storefront—pair this walk-through with AI applications & agents.

How open checkout goes wrong

Composites—not client charge rates, not network KPIs, not invented conversion lifts.

The demo credential that never died. A virtual card minted for a pilot sits in the agent config with no ceiling. Six months later it buys something nobody remembers approving.

The three tools as one. Get and update are useful for helping a human finish checkout. Complete was granted in the same PR because the changelog listed them together. The agent “helpfully” finished while the buyer was still comparing options.

The ceiling in the prompt only. The model was told not to spend over $200. The credential allowed $5,000. The model lost the thread. The card did not.

The soft yes. Someone typed “ok” in chat about a different SKU. The agent treated it as intent for the current cart. No amount, no merchant, no artifact.

The category blind spot. Replenishment was approved for office supplies. The agent found a “deal” in another category the credential did not block.

The after-hours complete. Human gate existed on paper. On-call was empty. The agent completed because the policy said “escalate if unsure” and nobody answered.

When you see these, do not add another courtesy phrase to the system prompt. Close the walk-through: ceiling on the credential, complete split from update, intent proof required, human gate named, revoke path drilled. Coverage can summarize agent checkout tools and Verifiable Intent. It cannot name your ceilings, your scopes, or your planted over-ceiling fail.

Not identity provisioning, not refund speech

Keep the layers separate so reviews stay honest.

Agent identity answers: which IdP principal holds scopes for tools, and how you disable that principal. Needed before serious writes. It does not set how much money a shopping agent may spend.

Refund authority answers: who may approve money back after the sale, and what macros may say. Needed so sympathy does not invent policy. It does not authorize the original charge.

Checkout authority answers: whether the agent may complete a purchase, under what ceiling and scope, with what credential and intent proof, and who still approves consequential buys.

An agent can have a clean IdP identity and still hold an unrestricted card. A team can have a careful refund ladder and still let a shopping agent complete with no spend limit. Fixing one does not fix the others.

If your review board only asks “does the agent have its own login?” you will miss the open charge path. If it only asks “who may refund?” you will miss the agent that should never have completed in the first place.

Marketplace work makes the same point from the other side of the transaction: a completion path has to stay aligned with availability, payment, and what both sides were promised. That discipline is why Paddle8 still matters when you talk about who may finish a charge—not because that build was about shopping agents, but because unchecked completion still breaks trust.

Put this into practice

1. List every agent (browser, in-store, or concierge) that can call complete on a checkout—or that will within a quarter.
2. Walk the authority fields for each job: spend ceiling, merchant/category scope, credential shape, intent proof, human gate, complete permission, forbidden paths, owner and revoke.
3. Split tools so complete is not granted whenever update is. Plant an over-ceiling cart and confirm complete fails.
4. Bind ceilings and scopes on the credential and in policy—not only in the prompt. Require intent proof before complete; refuse when cart and attestation disagree.
5. Default consequential purchases to human approval until you widen on purpose. Drill revoke once before go-live.
6. If the gap is ecommerce checkout you can defend when agents sit in the buyer path—not another demo of an agent filling a form—bring the named fields into a scoping conversation for ecommerce and AI applications & agents.

A shopping agent that can complete without a ceiling is not convenience. It is an unsigned charge with a friendly UI. Name the authority before the agent may charge.