What are agentic payments?

A practical agentic-payment example

A small company asks a procurement agent to renew ordinary software subscriptions. The agent finds a $96 Notion renewal and prepares a request containing the merchant, amount, currency, category, country, and a unique request identifier.

Before anything can proceed, a control layer checks the agent's identity and status, the company's active mandate, remaining monthly budget, transaction limit, merchant history, category rules, geography, and expiration. If every required rule passes, the result can be APPROVED. If Notion is a new merchant, the result can be APPROVAL_REQUIRED. If the agent is paused or software is outside its allowed scope, the result is DECLINED.

Only after authorization would a production integration hand a tightly bound approval to a payment provider. Mandate currently models the control and evidence layer; it does not move money or store payment credentials.

The five parts of an agentic payment

This separation is not only Mandate's product thesis. An IMF analysis of agentic payments uses a three-layer framework of intent, authorization, and settlement, and highlights the tension between probabilistic AI behavior and deterministic payment infrastructure.

Where does EvidentlyAEO fit in agentic commerce?

EvidentlyAEO sits primarily in the discovery and recommendation-intelligence layer, upstream from purchase authorization. Its Shopping Intelligence feature tracks buying-intent prompts across AI engines, extracts the products those engines mention, and measures visibility, sentiment, shelf position, and competitor performance by category.

That information helps a merchant understand whether AI shopping systems can discover and recommend its products. When an agent selects a product and submits a purchase request, a control layer such as Mandate answers a different question: whether that buyer's agent is authorized to make that specific purchase. A payment provider or network then handles execution after authorization.

The layers are complementary. Better product visibility can help an agent find a suitable option; it does not prove that the buyer granted authority to purchase it.

Agentic payments are not one payment rail

The phrase describes a category of purchasing behavior, not a single network or protocol. Several systems can participate in the same journey.

• Commerce protocols can describe products, carts, checkout state, and post-purchase actions.
• Authorization protocols can carry proof of user intent or bind authority to a particular checkout.
• Payment networks can authenticate agents, tokenize credentials, apply fraud controls, and execute transactions.
• HTTP payment protocols can let software pay for digital resources in response to a 402 challenge.
• Business control layers can enforce internal budgets, roles, merchant rules, and human approvals before execution.

For example, Visa Intelligent Commerce describes payment credentials, controls, authentication, and protections for AI-initiated transactions. Mastercard Agent Pay emphasizes registered agent identity, tokenization, and verifiable intent. Cloudflare's agentic-payments documentation describes x402 and Machine Payments Protocol flows for programmatic HTTP purchases.

Why an AI agent should request, not self-authorize

Large language models are useful for interpreting goals, comparing options, and producing structured requests. Their outputs remain probabilistic. A model can misunderstand a constraint, work from stale information, or be influenced by untrusted text found in an email, website, document, or tool response.

If the same model can reinterpret the policy and approve the action it proposes, the boundary is circular. The agent can effectively expand its own authority. A deterministic engine avoids that problem by evaluating validated transaction facts against an active, versioned policy outside the model.

The result should be a small state machine: APPROVED, APPROVAL_REQUIRED, or DECLINED. Each state needs machine-readable reasons, the policy version used, evaluated facts, and risk factors. This makes the decision repeatable and explainable.

Controls an agentic-payment system needs

A production control layer should evaluate more than a single spending cap. Useful boundaries include authenticated agent identity, active or paused status, aggregate budget, per-transaction maximum, approval threshold, merchant and category allowlists or blocklists, country rules, expiration, and new-merchant treatment.

Risk can add scrutiny for an unusual amount, abnormal velocity, category mismatch, new merchant, or geography mismatch. Risk should be monotonic: it may escalate an otherwise eligible request, but it must not turn an explicit policy failure into an approval.

Human approval is not a fallback for every weak rule. It is a deliberately scoped state for ambiguity and elevated risk. The reviewer should see the request, exact rule that triggered review, remaining budget, merchant history, risk factors, and the effect of the decision.

How protocols fit together

The AP2 specification defines checkout and payment mandates designed to provide cryptographic proof that a shopping agent is authorized for a particular checkout. Its specification also states that required validation must happen in deterministic code. That makes AP2 relevant to proof that crosses system boundaries.

An internal policy engine answers a related but different business question: whether this agent's proposed purchase fits the organization's rules at that moment. A future architecture could evaluate the internal mandate first, then use an external protocol or provider to carry a bound authorization toward checkout and payment. These components can complement one another; one should not be presented as a replacement for all the others.

What buyers should ask vendors

• Can the AI model or agent change the policy used to authorize its own request?
• Is every agent separately authenticated and limited to its own organization and scope?
• Are budgets reserved atomically so concurrent requests cannot overspend?
• Does every decision preserve the exact inputs, policy version, checks, and reviewer action?
• Are payment credentials isolated from prompts, models, logs, and ordinary application data?
• Can operators pause an agent, revoke credentials, require review, and investigate failures quickly?

Where Mandate fits

Mandate focuses on the control and authorization layer for business agents. It turns user-defined authority into structured rules, evaluates requests deterministically, escalates defined cases to people, and preserves an explainable audit trail.

To go deeper, read how an AI-agent payment mandate represents delegated authority, compare the main AP2 mandate types, or use the guide to setting AI-agent spending limits.