AI Shopping Agent Checkout: The Pre-Authorization Checklist to Sign Before the Card Runs

The agent can pay now. In September 2026 Stripe and the card networks shipped the rails for AI shopping agent checkout, and six banks published a paper on how to trust it. Every one of those rails assumes a person authorized the purchase first, and none of them tells that person what to check before saying yes.

That gap is yours to close. What follows is a pre-authorization checklist of seven lines that the human signs before an agent carries any spending mandate: the all-in total, the caps, the merchant allowlist, the expiry, the card scope, the receipt and the revoke switch.

It comes with a decision table that splits every purchase into two kinds. When the human is present, they approve the exact total in the chat. When they are not, the agent carries a capped, expiring, allowlisted mandate, or it doesn’t buy.

The goal is boring on purpose. The number a person approves is the number the card is charged, fees included, and every mandate that runs without a person watching can be switched off in under a minute.

September 2026: what shipped for AI checkout agents

Stripe went first. On Sep 8 it said Meta’s new Muse agent can buy through Link, Stripe’s wallet, and spelled out the approval model: “For every purchase, consumers are asked to approve the transaction total directly in the chat interface, and Muse never sees their underlying payment details.” At the more than one million businesses that accept Link, Muse pays with the shopper’s saved method. For everyone else, “Link issues Muse a single-use virtual card scoped to the approved purchase” (Stripe).

Screenshot: Stripe Newsroom, “Stripe helps Muse, Meta’s new personal AI agent, shop across the internet with Link” (Sep 8, 2026), captured Oct 5, 2026.

The networks moved the next day. Mastercard launched Agent Connect as a single integration point for merchants and said its Agent Pay uses Verifiable Intent to “help ensure purchases are completed securely with the consumer’s authorization” (Mastercard). On the same day Ant International, Mastercard and Visa began a Know-Your-Agent interoperability effort that ties each agent to a validated operator or cardholder and monitors it continuously (Business Wire).

Then came the first fight. On Sep 21 Amazon blocked Muse, saying third-party purchasing apps “should operate openly and respect service provider decisions.” Its complaints were that Muse doesn’t identify itself and appears to capture shopper credentials; Amazon held up its own Buy for Me agent, which identifies itself and lets brands opt out, as the contrast (GeekWire). Credential handling has its own playbooks in cookie custody and unofficial AI wrappers. The lesson for checkout is simpler: a merchant can refuse your agent at the door.

The month closed on governance. Six banks (ASB, Bank of America, Capital One, CBA, ING and NatWest) published a paper titled “Building Trust in Agentic Commerce” on Sep 22–23 (CommBank). On Sep 30 Mastercard announced a probability score that asks whether an agent was behind a transaction at all, in US-only testing with no thresholds or API published (Yahoo Finance).

Two corrections to things you may have read. OpenAI scaled back Instant Checkout in March 2026, saying its first version “did not offer the level of flexibility that we aspire to provide”; merchants now run their own checkout inside ChatGPT apps, and the Agentic Commerce Protocol carries on as a protocol (TechCrunch).

And the FTC’s fees rule is narrower than its headlines. 16 CFR Part 464 makes it unlawful “to offer, display, or advertise any price of a covered good or service without clearly and conspicuously disclosing the total price,” but it covers live-event tickets and short-term lodging only, and its total price leaves out government charges and shipping (eCFR). The broad all-in pricing duties come from states: California since July 1, 2024, then Minnesota, Virginia, Massachusetts, Colorado and Oregon, with Connecticut from July 1, 2026 (Mondaq).

Why a chat approval is not yet a payment mandate

A shopper tapping approve on a total is a good control while the shopper is looking at the screen. It says nothing about the purchase the agent makes at 2 a.m. under a standing instruction, the fee a merchant adds on the last page, or the card that stays live after the person meant to stop. Agents that act turn a single click into standing authority, and standing authority needs the paperwork you’d demand for any delegated spend: a limit, an end date, a list of counterparties and a way to take it back.

The AP2 specification already names the two cases. A Cart Mandate covers a purchase with the human present, an Intent Mandate covers one where the human is not present, and a Payment Mandate travels to the network so it can see an agent was involved (AP2). Borrow that vocabulary even if your rail isn’t AP2. It forces the one question every checklist line depends on: was a person watching when the money moved?

The pre-authorization checklist runbook for AI checkout agents

Run these six steps once for every agent that can spend, and again whenever its rail, merchant list or cap changes.

Step 1: Inventory every agent that can spend, and its rail

List each agent with purchase ability. For each, write down the rail it pays on, who approves, what the agent can see of the card, and whether a merchant can tell an agent is buying. The rows below are the rail patterns that existed by the end of September; fill in your own agents against them.

Rail pattern	September 2026 example	Approval to record	Check before you allow it
Agent wallet	Link for Muse (Stripe, Sep 8)	Total approved in chat, per purchase	Agent never sees the card; single-use virtual card where the merchant doesn’t take the wallet
Network agent program	Agent Pay through Agent Connect (Mastercard, Sep 9)	Consumer authorization captured as Verifiable Intent	Your issuer’s terms for agent tokens and disputes
Mandate protocol	AP2 Cart, Intent and Payment Mandates	Cart Mandate (present) or Intent Mandate (not present)	That the Payment Mandate reaches the network
Merchant checkout in a chat app	Merchant-run checkout in ChatGPT apps after Instant Checkout was scaled back	The merchant’s own checkout	Which card the merchant stores, and for how long
Browser driving a stored card	Any agent typing a saved card into a web form	Whatever the agent decides	Nothing passes: retire it

The last row is the one to delete. An agent typing a saved card number into a form is invisible to the merchant, the network and you, and Amazon’s block shows merchants will refuse it. A rail that can’t present a self-identifying agent and a scoped card fails lines 3 and 5 of the checklist before the first purchase.

Each September launch assumes a human authorized the purchase; the checklist decides what that authorization has to contain. Sources as cited above.

Step 2: Sort every purchase path into human-present or human-not-present

Every purchase falls on one side of the line, and the controls differ by side. The table is the rule; the diagram is the flow your agent’s runtime should follow before any card is charged.

Situation	Human present?	Required before the card runs	Otherwise
Person is in the chat and sees the final all-in total	Yes	Person approves that exact total; single-use or scoped card	Block
Total rose after approval (fee, tax or shipping recalculated)	No longer	Fresh approval of the new total	Block and re-ask
Standing instruction (weekly reorder, buy when the price drops)	No	Signed Intent Mandate: caps, expiry, allowlist, self-identifying agent, scoped card	Block and queue for the owner
Mandate expired, cap reached or merchant not on the list	No	Nothing covers it	Block and queue for the owner
Merchant refuses agents	Either	Nothing covers it; don’t route around the refusal	Block; the person buys by hand

Human present or not: the mandate decision flow, the same on any rail.

Two habits keep the split honest. “Present” means present for this purchase at this total; a person who approved a cart an hour ago and walked away is not present when the merchant recalculates shipping. And there is no third column. A purchase that is neither approved in the moment nor covered by a signed mandate is blocked and queued, never attempted.

Keep the approval itself as evidence. For a human-present purchase, store the total the person saw, the merchant, the item list and the time of the tap. If the rail doesn’t hand those back, capture the confirmation screen the person approved, because “the agent says I approved it” won’t settle a dispute.

Step 3: Sign the seven-line pre-authorization checklist

This is the sheet. The person who owns the budget signs it once per mandate, and the agent’s runtime checks it on every purchase.

#	Line the human signs	Pass when	Evidence kept
1	All-in total (mandatory fees, taxes, shipping) equals the signed amount	Total on the merchant’s final page is at or under the signed figure	Final-page total captured per order
2	Per-mandate cap and per-day cap	Purchase under the mandate cap, day’s sum under the daily cap	Running daily total per agent
3	Merchant allowlist, self-identifying agents only	Merchant is listed and reached through a rail it accepts	Merchant and rail on the receipt row
4	Expiry on every human-not-present mandate	Purchase time is before the expiry	Expiry stored in the mandate record
5	Single-use or scoped card	New card or token per purchase, or one merchant-locked card	Card token ID per receipt
6	Receipt evidence reconciled against the statement	Weekly reconcile shows no unmatched rows	Order ID, total, fee lines, mandate ID
7	Revoke switch tested end to end	A revoked mandate blocks the next attempt within a minute	Drill log with timestamps

Line 1 is the one that catches agentic commerce hidden fees. They rarely look like fraud. They look like a service charge that appears after the agent has committed, a convenience fee on the final page, or shipping recalculated after the address step. Make the agent read the all-in total from the merchant’s final confirmation page, compare it with the signed figure, and stop on any upward difference, even a cent. Downward differences, such as a coupon, can pass; log them anyway.

Show taxes and shipping in that total too. The FTC rule and most state laws let a seller leave government charges and shipping out of the price they must disclose, but the person’s card statement will include both, so the signed figure must as well. Treat that as your operator rule, not as a reading of what the law requires.

Lines 2 and 4 make a mandate finite. Set a cap per mandate and a cap per day for each agent, and put an expiry on every human-not-present mandate. AP2 builds this into the Intent Mandate as a time-to-live, “an expiration time for the mandate’s validity”; on rails that don’t, store your own expiry and refuse after it.

Keep it short. A weekly grocery reorder gets seven days. A one-off “buy the tickets when they drop” gets the drop date plus one day.

Line 3 is an allowlist, never a blocklist. Name the merchants the agent may buy from, then add a second condition: the agent reaches them as a self-identifying agent through a rail the merchant accepts. That rules out browser automation on sites that refuse agents, which is the behaviour Amazon objected to, and it keeps you on the right side of whatever the networks’ Know-Your-Agent checks end up enforcing.

Line 5 limits the damage. A single-use virtual card scoped to one approved purchase, as Link issues for Muse at merchants outside its network, can’t be charged twice or reused by a breached merchant. Where single-use isn’t offered, use a token locked to one merchant with its own limit. Never hand an agent the person’s primary card number.

Line 6 makes disputes a lookup. For each purchase store the order ID, the charged total, every fee line, the mandate ID, the merchant and a timestamp. Without that row a disputed charge becomes a conversation about what the agent probably did.

Line 7 is the only line you prove by doing it. Step 6 is the drill.

Step 4: Write each mandate down as a record the runtime reads

Keep the signed checklist as data, not as a PDF in someone’s inbox. The shape below is illustrative; map the field names to your rail.

mandate_id: m-2026-10-05-grocery-weekly
mode: human_not_present          # or human_present
owner: budget-holder
agent: household-shopper
rail: wallet-agent-card
cap_per_purchase: 120.00
cap_per_day: 150.00
currency: USD
expires_at: 2026-10-12T23:59:00Z
merchants_allow:
  - grocer.example
  - pharmacy.example
self_identifying_agent_required: true
card_scope: single_use_per_purchase
all_in_total_includes: [mandatory_fees, tax, shipping]
on_total_above_signed: block_and_requeue
receipt_fields: [order_id, total, fee_lines, mandate_id, merchant, card_token, ts]
revoke_paths: [wallet_console, runtime_flag]
signed_by: budget-holder
signed_at: 2026-10-05T09:00:00Z

Two rules go with the record. A change to any field is a new mandate with a new ID and a new signature; nobody edits the cap of a live one. And the runtime reads the record at purchase time, so flipping the runtime flag stops the next attempt even if the rail’s own revoke is slow to propagate.

Step 5: Reconcile receipts against the card statement every week

The receipt ledger only earns its keep if someone compares it with what the card actually shows. Once a week, join the two on amount, merchant and date, and route every unmatched row to the mandate owner.

Receipt field	Matched against	A mismatch means
Order ID	Merchant’s order confirmation	The agent logged an order that didn’t happen, or missed one that did
Charged total	Card statement line	A fee or tax added after approval, or a partial refund
Fee lines	Signed all-in total	A fee the human never saw
Mandate ID	Mandate register	A purchase with no mandate behind it: treat it as an incident
Card token	Rail’s list of issued cards	A single-use card used twice

Most weeks the report is empty. The rows that do appear are the expensive kind: a duplicate charge after the agent retried a checkout that timed out, a refund that never posted, a subscription the agent accepted while buying something else.

Step 6: Run the revoke drill end to end

Revocation fails quietly. The wallet shows “revoked” while a card issued before the revoke still works, or the runtime keeps a cached copy of the mandate. Drill it every quarter and after any change of rail:

1. Create a test mandate with a small cap and one allowlisted merchant.
2. Let the agent complete one purchase and confirm the receipt row exists.
3. Revoke in the place the person would actually use, the wallet app or console, not your own database.
4. Start a timer and have the agent attempt a second purchase within a minute.
5. Pass if the runtime refuses the attempt and any card issued under the mandate declines when presented directly.
6. Record the time from revoke to first refused attempt. Anything over a minute is a finding with an owner and a date.

A mandate usually has more than one off switch, and the drill should touch each of them:

Revoke path	What it should stop	How the drill checks it
Wallet or agent-program console	New purchases under the mandate	The second attempt is refused
Runtime flag in the mandate record	The agent trying at all	The agent logs “mandate revoked” and never opens checkout
Card or token freeze at the issuer	Cards already issued under the mandate	A direct charge on the old token declines
Merchant account settings	Recurring charges the agent started	The subscription shows as cancelled

The last row is the one people forget. A mandate can expire cleanly while a subscription the agent accepted keeps billing every month, because revoking the agent doesn’t cancel what it already bought. Add a line to the drill log for each recurring charge the agent created, with the date someone confirmed it was cancelled.

Checkout agent failure modes and the signal for each

Most of these show up in the weekly reconcile first. Wire each signal into whatever alerting already pages your team, so nobody has to notice it by reading statements.

Failure	Signal	First move
Fee appears after the agent commits	Charged total above the signed total on the same order	Pause that merchant; confirm line 1 reads the final page
Mandate outlives the intent	Purchases after the event, or after the owner said stop	Check the expiry was set; shorten it; rerun the drill
Merchant refuses the agent	Block page, login wall or a request for credentials	Queue for a human; never fall back to a browser with stored credentials
Retry double-charges	Two charges for one order ID	Add an idempotency key per order; reconcile and refund
Single-use card isn’t	A second charge on the same card token	Suspend the rail and escalate to the provider
Approval becomes a reflex	Totals approved in under two seconds, every time	Fewer prompts, each showing the full total and fee lines
Cart rewritten by page content	Items in the cart that the instruction never asked for	Block, then review the page the agent read

Two of these deserve a longer look. Reflexive approval is the human-present version of a blank cheque, and the fixes for approval fatigue in approval queue hygiene apply unchanged: fewer prompts, each carrying the number that matters. A cart rewritten by page content is prompt injection with a card attached, and agentic browsers covers why that won’t be fully solved inside the agent; your defence is that line 1 compares the cart total against a figure the page can’t edit.

Spend authority belongs in the fleet register

An agent that can spend is still an agent in your fleet, and it needs to show up wherever you already see the others. The same Stripe post notes that Link’s agent wallet also powers payments for Grok Bot, which puts a card behind the one-boss question: the assistants you already supervise are acquiring wallets. Keep the mandate register next to the rest of your agent inventory, so the person who can stop a coding agent from a single command center can also see which agents can spend, how much, and until when.

Consent to spend is one more row in the consent state machine: anything other than a signed, unexpired, unrevoked mandate is a hard stop. And when a merchant closes the door on agents, treat it the way you’d treat a platform closing its API. Climb the access ladder to a rail the merchant accepts, or buy by hand.

FAQ

Can an AI shopping agent buy without asking me every time?

Yes, if you sign a human-not-present mandate for it. In AP2 terms that’s an Intent Mandate. Before signing, set a per-purchase cap, a daily cap, an expiry date, a named merchant list and a single-use or scoped card. Anything outside those limits should be blocked and queued for you, not attempted.

Does the FTC junk fees rule cover AI agent purchases?

Only for live-event tickets and short-term lodging. The FTC’s rule, 16 CFR Part 464, covers those two categories, and its total price excludes government charges and shipping. Broader all-in pricing duties come from state laws such as California’s. For an agent, show taxes and shipping anyway, because the card statement will.

What should happen when a merchant blocks my shopping agent?

The purchase stops. Don’t route around the block with a browser that types your saved card or password into the site; Amazon’s complaint about Muse was that it didn’t identify itself and appeared to capture credentials. Queue the purchase for a human, buy it by hand, and drop the merchant from the allowlist.

Sources

• Stripe: Stripe helps Muse, Meta’s new personal AI agent, shop across the internet with Link (Sep 8, 2026)
• Mastercard: Agent Connect and Agent Pay with Verifiable Intent (Sep 9, 2026)
• Business Wire: Ant International, Mastercard and Visa initiate Know-Your-Agent interoperability (Sep 9, 2026)
• AP2: Agent Payments Protocol specification (current)
• eCFR: 16 CFR Part 464, Rule on Unfair or Deceptive Fees (current as of Oct 1, 2026)
• CommBank: Building Trust in Agentic Commerce paper launch (Sep 23, 2026)
• GeekWire: Amazon blocks Meta’s Muse AI assistant (Sep 21, 2026)
• TechCrunch: OpenAI’s plans to make ChatGPT more like Amazon aren’t going so well (Mar 24, 2026)
• Yahoo Finance: Mastercard probability score for agent transactions (reported Oct 5, 2026)
• Mondaq: 2025 year in review, junk fee laws (Dec 16, 2025)