AI Agent Payment Controls: Authority, Access and Evidence

An agent can be recognizable to a merchant and still be acting outside the customer's instruction. It can hold a permitted tool and still call it twice. A payment may be approved while the merchant order remains unresolved. Controls work only when they answer these different questions separately.

This is an operator design framework, not a new scheme rule. ACP, UCP, AP2 and Visa TAP define different capabilities. The agentic-commerce overview maps the full purchase evidence. This reference focuses on what an operator should verify before granting a machine the ability to spend or change a payment.

Four evidence questions before execution

The examples are independent, provider-specific mechanisms. They are not four fields in a shared transaction schema and they do not imply these systems interoperate. The Mastercard score is described in its September announcement; the focused reference covers its availability and limits.

Design the spend boundary

Start with a durable instruction: the principal, the agent permitted to act, the goods or task, a maximum amount, allowed sellers or categories where practical, expiry and any point where a person must approve again. Google's AP2 description uses signed Intent and Cart Mandates to illustrate how user instructions can travel through different agent flows. That is a specification pattern; support and enforcement differ by the actual product integration.

An operator can add limits at the credential, PSP and merchant orchestration layers. Per-transaction ceilings constrain one call; period budgets constrain total spend; count-per-window controls constrain repeated small calls. These are complementary design choices, not a claim that every token or scheme enforces each one. Ask each provider which limit is native, whether the agent can alter it and how a declined or partially completed transaction counts. If merchant-category restrictions matter, verify the category actually used in the payment record instead of inferring it from the product description.

Bound tool access separately

An agent that can read a payment balance need not also create charges or refunds. Stripe's MCP documentation describes access granted through OAuth or an agent API key. Connecting the server grants the access configured for that credential; MCP itself does not decide the right business permission. Key-authenticated clients have a stated 31 October 2026 migration to agent API keys. The MCP/API reference owns the integration details.

For a high-impact write, the operator should verify the customer instruction and relevant approval at the business layer as well as the API credential's permission. Record the actor, request, approval and resulting object ID. A tool's successful HTTP response is not evidence that a merchant order was fulfilled.

Treat retries and revocation as operations

An agent may retry when it sees a timeout. Stripe's idempotency rule can return the first result for a matching keyed POST, even when that result was an error; keys can be pruned after at least 24 hours. That guarantee belongs to the specific Stripe request. It does not make an agent instruction, merchant order and payment one atomic transaction. Join those records and query the authoritative state before repeating an uncertain purchase.

Revocation needs the same precision. A platform may remove tool access, a credential issuer may revoke or replace a credential, and a merchant may block an agent account. An operator should test each path and measure how long an already-running operation can still complete. A local “stop” toggle is only one step; the enforcement point and in-flight state decide the actual exposure. These are questions for the provider contract and integration test, not documented universal revocation times.

Preserve the evidence chain

Keep a versioned record of the customer's instruction, the agent request and identity, the configured credential or tool permission, the approval decision, the merchant checkout and order IDs, the processor payment result and the later fulfilment or refund events. Make those records queryable together. The agent checkout lifecycle shows where each outcome is authoritative. An append-only event history can help reconstruct changes, but no source cited here establishes a universal legal retention period or a guaranteed dispute remedy for agent purchases.

Fraud monitoring should evaluate actual agent traffic against its own observed baseline. Some agent flows may carry less browser interaction data than a human checkout; others can include a real user handoff, device information or issuer authentication. Do not assume all agents lack device signals or that an existing risk model always fails. Measure false positives, false negatives and unexpected velocity for the particular flow.

Questions for a launch review

1. Which record states the customer's approved instruction, and how does the merchant test this exact order against it?
2. How is the requesting agent authenticated, and what does the authentication not say about purchase authority?
3. Which credential can create a charge, refund or transfer, and who can change that permission?
4. Which action needs human approval, and how is that decision stored with the resulting order?
5. How are timeout retries, cancellations, revocation races and partial completion reconciled?
6. Which records would support a customer inquiry or dispute, and which party can retrieve them?

Resolve loss allocation and any legal evidence requirements in the relevant scheme rules and provider contracts. Do not infer a liability transfer from an agent signature, mandate, risk score or token alone.