Agentic payments are turning purchase authority into a machine-readable mandate

Traditional checkout often combines several decisions in one human session. The buyer selects an item, sees the final amount, authenticates and submits a payment credential. Agentic commerce separates those moments. A person may state a goal on Monday, the agent may find a qualifying product on Friday, and a merchant may present a final price seconds before execution.

That separation creates a new engineering requirement: the system must carry the user's authority across time and across organizations without turning a broad natural-language request into unlimited spending power. A card token proves access to a payment method. It does not prove that the agent chose the right item, respected the budget, used an approved seller or preserved the user's latest instruction.

The safest design treats payment data, commercial intent and authorization as related but independent objects. Each has its own issuer, scope, expiry, verifier and failure path.

A commerce protocol describes products, carts, taxes, fulfillment, order state and merchant capabilities. An authorization protocol describes who delegated what power to which agent and under which conditions. A payment protocol or network moves value using a credential and risk controls. These layers may integrate tightly, but they answer different questions.

Universal Commerce Protocol and Agentic Commerce Protocol focus on machine-readable interaction between a platform and a business. Agent Payments Protocol adds mandates and receipts intended to prove user-approved authority. Visa Trusted Agent Protocol helps a merchant recognize signed agent traffic and its asserted purpose. Network token and shared-token systems constrain how a credential can be used. None of these layers alone proves the complete business outcome.

Product teams should keep adapters explicit. A merchant can change its checkout protocol without redefining the company's approval policy. A payment processor can change without rewriting the meaning of the mandate. This separation also makes disputes easier to investigate because the team can identify whether the failure began in discovery, authorization, credentialing, payment or fulfillment.

When the user is present, the trusted surface can display the exact merchant, cart, total, delivery terms and payment method immediately before approval. The signed authority can be narrow and short-lived. The main risks are misleading presentation, stale checkout data, credential substitution and a mismatch between what the user saw and what the merchant charged.

Human-not-present execution is harder. The user approves constraints rather than a final cart: a maximum price, allowed brands, seat location, refundable status, delivery deadline or approved supplier list. The agent later closes that open mandate against a specific checkout. Every verifier must be able to evaluate the constraints without asking the language model whether they were satisfied.

Ambiguous or unsupported conditions should return the user to the loop. A merchant price increase, unavailable refundability, changed delivery date or product substitution is not a reason for the agent to reinterpret the mandate generously. It is a reason to request fresh authority.

A digital signature proves that a key signed particular bytes. The application still decides whether those bytes describe the transaction it intends to authorize. Merchant identity, request method, target URI, checkout digest, amount, currency, timestamp, nonce, mandate version and key identifier may all be necessary parts of the security context.

Replay is especially dangerous in agent workflows because orchestration systems retry automatically. A valid request can be harmful when accepted twice. Fresh nonces, creation and expiry times, idempotency keys, sender-constrained tokens and consume-once mandate state address different parts of that problem. They should be designed together rather than added as unrelated headers.

Intermediaries can also rewrite HTTP messages. Implementations using HTTP Message Signatures need a precise covered-component policy and canonicalization tests. Verification should fail when a proxy, agent or merchant changes a security-relevant field after signing.

Merchants need to distinguish a credentialed shopping agent from a crawler, scraper or attack bot. A signed request can identify an agent provider and declared purpose, allowing the merchant to apply an agent-specific rate limit, catalog path or checkout flow. That is useful, but identity is only one input to risk.

A legitimate agent can be compromised, misconfigured or acting under an overbroad mandate. A familiar provider can carry an unfamiliar delegated user, payment credential or merchant relationship. The verifier therefore needs trust policy for the agent issuer, the user authentication method, the mandate signer, the credential provider and the particular transaction.

Trust registries and provider allowlists should be governed like production dependencies. Teams need onboarding evidence, key-rotation procedures, incident contacts, revocation, version support and an exit plan. A global allow decision based only on a vendor name is too broad for money movement.

Agentic payment tokens are designed to avoid handing raw card or bank credentials to the agent or merchant integration. Useful scopes include seller, amount, currency, expiration, transaction identifier and sometimes product or mandate context. Network or processor enforcement is stronger than a prompt instruction because an out-of-scope charge can be declined independently of the model.

Token scope does not remove custody risk. The agent platform may still hold a reusable wallet relationship, signing key, refresh capability or authority to request new tokens. Those assets need hardware-backed or managed key storage, least-privilege services, separation between planning and payment execution, and auditable administrative access.

The system should also know what happens when the token cannot express a mandate condition. A credential may limit amount and seller but not refundability, delivery date or an excluded item category. Those conditions remain the responsibility of the commerce and authorization layers.

A payment authorization can succeed while the order fails, inventory disappears or fulfillment never begins. Conversely, a merchant may create an order and later receive a payment decline. Agentic systems need explicit state machines and receipts for checkout acceptance, payment result, fulfillment, cancellation and refund rather than one optimistic success message.

Dispute evidence should show what the user approved, which agent acted, the exact merchant-confirmed cart, which credential was used, what each verifier accepted and what the merchant delivered. The evidence trail should be tamper-evident and privacy-minimized. Keeping every conversation token forever is neither necessary nor responsible.

Returns and refunds need the same rigor as purchase. The agent must not invent a return reason, accept a store credit when the mandate requires a refund to the original method, or treat a refund request as complete before the payment and order systems confirm it.

A sensible rollout begins with a narrow merchant set, low spending ceilings, human-present approval and products with uncomplicated fulfillment and refund rules. The objective is not to demonstrate maximum autonomy. It is to prove that identity, mandate, checkout, token, payment and receipt records remain consistent under retries, delays and failures.

Operational dashboards should separate agent discovery traffic, mandate creation, authorization failures, token declines, duplicate attempts, order mismatches, refund exceptions and user escalations. A single conversion rate can hide serious control problems. Teams also need a kill switch that blocks new autonomous execution without preventing customers from accessing existing orders and refunds.

Economics should be measured after support, fraud, payment fees, model use, protocol maintenance and exception handling. Agentic commerce may improve discovery and reduce checkout friction, but the safe case is strongest where a bounded task is repeated often enough to justify the control infrastructure.