What Are Agentic Payments?

By Nika, NodeTimes newsroom.

Agentic payments are payments that software initiates on someone's behalf, where the agent, not the person, decides when to pay, how much and to whom. How AI agents pay on blockchain rails is the same question with a stablecoin on the settlement leg and a signed mandate in place of a login. The hard part is not moving the money; it is proving afterwards that an autonomous system was allowed to move it, which is why every protocol in this field sits on a different layer instead of competing for the same one.

Why existing payment systems do not fit agents

Card and bank rails assume that a human clicked "buy" on a trusted page, so authorization is implied by the click itself. An agent breaks that assumption: it can act when nobody is present, and two things are then left open at once, who authorized the payment and who carries the loss when the agent gets it wrong.

Three separate problems follow from the broken assumption:

• Authorization: how does a merchant know that an agent had permission to spend?
• Checkout: how does an agent complete a purchase on a storefront built for people?
• Settlement: what actually moves the money, and how fast does it arrive?

Each of the three is being solved by a different protocol, which is why head-to-head comparisons of these protocols as rivals are the most common mistake in coverage of the space. If the vocabulary is new, the blockchain glossary keeps the definitions; this article carries only what the argument needs.

The protocols, and the layer each one owns

These protocols are usually listed as alternatives, but each one holds a different layer of the same purchase, and the layers compose. The table names the best-documented protocol in each layer today rather than every protocol that exists, because this field moves faster than its documentation.

A stack can compose them: authorize with AP2, run the purchase through a commerce or checkout layer, settle through x402 or MPP, and read ERC-8004 registries before dealing with an unfamiliar agent. The protocol that matters to a particular team is usually the one its counterparty already speaks.

How an agent proves it may spend

Authorization in AP2 is a signed credential rather than an API key. The protocol defines mandates as tamper-evident, cryptographically signed objects that travel with the transaction and give the merchant a record it can verify of what the user actually asked for; Google published the specification as an extension for the A2A and MCP agent protocols and has since donated it to the FIDO Alliance, so the authorization layer stays platform-agnostic.

There are three mandate types, and the difference between them matters when something goes wrong:

• IntentMandate: what an agent may buy when no human is present, the case that has no equivalent on card rails.
• CartMandate: the final basket plus the user's signature, for purchases where a human is present.
• PaymentMandate: a signal to acquirers and settlement rails that an agent was involved, so they can price the risk.

Combined with x402, both flows run at once: the mandate authorizes the order and the signed x402 payload authorizes the payment, with statuses such as payment-required, payment-submitted, payment-verified and payment-completed tracking the lifecycle.

Where the money actually moves

Where agentic payments settle today, they settle on a programmable rail, and in practice that means stablecoins such as USDC: a stablecoin closes in seconds, stays available around the clock and can be spent by a process rather than by a person. Settlement is the thinnest layer of the stack, and deliberately so, because every guarantee it adds is also a point of control.

x402 makes the mechanics explicit. An unpaid API request receives an HTTP 402 response with its price, the agent retries with a signed payment payload, and the service verifies and settles before it returns the response. The design removes API keys, accounts and subscriptions from machine-to-machine calls, which is what makes it attractive for pay-per-call inference, data and compute. It also means settlement inherits blockchain properties in both directions: there are no chargebacks, and there is no recovery if an agent pays a hostile counterparty.

Spending controls an agent wallet needs

Delegation is the whole risk surface, so the controls that work live in the wallet rather than in the protocol. EIP-7702 is the clearest published statement of the primitive: an account can sign sub-keys whose permissions are far weaker than global access, for example spending ERC-20 tokens but not ETH, spending at most 1% of the balance per day, or interacting with a single application.

EIP-4337 supplies the substrate most session-key wallets build on: a UserOperation object validated by an EntryPoint contract, with bundlers relaying operations and paymasters optionally sponsoring gas. Where a limit is actually enforced is the wallet, and that is the design decision a team controls rather than inherits.

What breaks first

The failure that matters is not a bug in a signature; it is an instruction the agent should never have followed. If a payment instruction can be planted in an agent's context, the wallet's spending limits are the last control standing.

• Prompt injection: untrusted content becomes a payment instruction, and a broad session key executes it.
• Over-delegation: one key that can move the whole balance, issued because it was faster to set up.
• No revocation path: a stolen agent key keeps spending until its mandate expires.
• Single-source state: the KelpDAO bridge was drained this way, when a single verifier was fed poisoned RPC data; an agent that reads balances from one endpoint inherits the same trust boundary the published breakdown of blockchain RPC describes.
• Liability: no published rule yet says whether the merchant or the wallet absorbs a loss when an agent buys the wrong thing.

Treat every control as compensating rather than sufficient: limits bound a loss, revocation ends it, and neither substitutes for not granting the permission at all. A wallet that gives an agent its own key is safer than one that lends the owner's key, and the principle scales: scope the key to one asset and one limit, cap the total, and keep the ability to revoke it without asking the agent.

The wider context is not cryptographic: an agent that trusts a single source of state inherits every weakness of that source. That is the same trust question what Web3 changes answers for the wider stack, while the labour side of the shift sits in The AI race without illusions.

Frequently asked questions

Are agentic payments just crypto payments?

No: crypto is a settlement rail, while agentic payments are the authorization problem that appears as soon as software can start a payment.

x402 and AP2 both list traditional card rails alongside stablecoins, and neither needs a chain to prove that an agent was allowed to spend.

Do agent payments need a blockchain at all?

No, and a card-based agent checkout proves it: a blockchain helps where the payer and the payee have no prior relationship, need sub-cent granularity, or need to settle without an account, and where one is used the settlement leg is a stablecoin such as USDC.

The contribution that matters to agents is programmability, because a spending limit and a revocation are then enforced by code rather than by policy.

Can an AI agent own a wallet?

It can hold keys, which is not the same thing: whoever holds the key can move the funds, so the practical design is a smart account that the user controls, with an agent key scoped by limits and revocable by its owner.

ERC-8004 answers the discovery half of the same question, through registries that record an agent's identity, reputation and validation history.

What stops an agent from overspending?

Limits stack: a per-transaction cap, a rolling budget, an asset allowlist and a step-up approval above a threshold.

No single control survives a compromised agent context, which is why revocation, rotating a key on demand, is the control teams tend to ship last.

Which protocol should a team start with?

Start from the counterparty rather than from the protocol list: card merchants point to a checkout layer, machine-to-machine APIs point to a settlement layer, and anything that may end in a dispute needs signed mandates for an audit trail.

Because the layers compose, the choice is usually additive, and the migration cost sits in wallet policy rather than in the integration.