Agentic payment controls: consent, limits and recovery

The minimum control record

1. Turn consent into a bounded authority

AP2 separates user intent from the final payment artifacts and uses mandates to communicate what the user approved. Its authorization guidance says long-lived mandates should be manageable, time-limited and visible to the user. UCP v2026-08-25 adds extensible buyer-consent purposes and richer payment and policy structures.

Whatever the protocol, record constraints in deterministic data:

• allowed merchant or recipient set;
• product, category or task boundary;
• single-payment and aggregate budget;
• currency and permitted instrument;
• start, expiry and renewal rules;
• whether final user confirmation is required;
• what changes force reapproval, such as price, quantity or delivery.

Limit: storing a consent field does not by itself prove informed consent or legal validity. The user experience, authentication, evidence and applicable rules still matter.

2. Separate funding, delegation and execution

AWS's AgentCore Payments guidance treats wallet funding and agent delegation as separate user decisions. It also recommends distinct roles for administration, session management and payment execution, so one identity cannot both raise a budget and spend it.

This separation prevents a compromised agent from widening its own authority. The model may propose an action. A policy engine decides whether the tool call is allowed. A payment session checks amount and time. The wallet or provider signs and settles.

3. Make revocation a normal state

Users can revoke delegated wallet access. Mandates and sessions expire. Credentials rotate. An implementation should expect these events rather than treat them as exceptional.

When authority is revoked:

1. stop creating new payment attempts;
2. invalidate cached authorization state;
3. distinguish revoked authority from a transient provider failure;
4. tell the user what stopped and what remains pending;
5. preserve completed transaction records without retaining reusable credentials.

4. Bind proof to the intended request

MPP supports a request-body digest for paid POST, PUT and PATCH requests. The submitted credential must match that digest. AP2 binds authorization through signed mandate artifacts. The goal is the same: proof for one amount or body must not authorize a changed request.

Also verify amount, currency, recipient and validity window before authorization. Do not let the model invent a wallet address. AWS explicitly places destination-address validation on the application and recommends trusted sources or allowlists.

5. Design retries before the first payment

Network timeouts create an ambiguous state: the client may not know whether payment succeeded. A blind retry can pay twice.

The MPP protocol requires single-use proof semantics and recommends an Idempotency-Key for non-idempotent methods. AWS tells implementers to use idempotency, cap retries and provide fallback behavior. Apply four rules:

1. give each commercial action a stable idempotency key;
2. reject replayed proof;
3. query the receipt or provider state before creating a new payment;
4. stop after a bounded number of attempts and move to reconciliation.

If a payment settles but resource delivery fails, record a compensating action rather than erasing the first event.

6. Connect refunds to the original evidence

Stripe documents refunds for machine payments through its existing Refunds API and Dashboard. UCP's August release adds policy snapshots for returns, refunds and warranties. These are useful building blocks, but neither creates a universal refund rule across all providers and protocols.

A refund record should point to the original merchant order, payment-provider transaction, protocol receipt, user or mandate reference, amount and reason. Partial refunds need item and amount allocation. If access to a digital resource was already delivered, the commercial policy must say how that case is handled.

7. Treat disputes as an evidence problem

The protocol specifications reviewed for this guide do not assign universal liability among the user, agent developer, merchant, issuer, wallet and payment provider. Do not write a product policy as if they do.

Preserve an audit bundle that a support or risk team can understand without replaying a model conversation:

• user authentication and authority reference;
• agent and workload identity;
• merchant and recipient verification result;
• basket or request digest;
• policy decision and applicable limits;
• payment challenge, sanitized result and receipt identifiers;
• delivery, refund and communication events.

Never place raw credentials, private keys or reusable payment tokens in that bundle.

8. Observe the system, not the agent's narration

AWS publishes a concrete metric set for AgentCore Payments: payment requests, successes, failures, latency, spend, active sessions, throttles and validation errors. Its spans include session, connector, instrument, merchant, currency and remaining-budget context.

Alert on events that indicate control drift: recipient changes, repeated failures, rising retry counts, unusual spend velocity, many new recipients, expired-session attempts and reconciliation mismatches. The service generating the payment should generate the audit event. A model's explanation is useful context, not the ledger.

A pre-production control test

1. Change the price after authorization and confirm the payment stops.
2. Replay the same proof and confirm it is rejected.
3. Timeout the response after settlement and confirm the retry does not pay twice.
4. Revoke delegation during a task and confirm later steps stop.
5. Use an unknown recipient and confirm deterministic rejection.
6. Exhaust the budget and expiry separately.
7. Complete a partial refund and reconcile every identifier.
8. Export an audit bundle and verify that it contains no payment secret.

This guide is a technical control model. It does not replace payment-network rules, provider terms, security review or legal advice. For a deployed example, see AWS AgentCore Payments GA. For protocol choice, see x402 vs MPP.