What are agentic payments?
An agentic payment is a payment where the buyer is software. An AI agent is given a goal and a budget, it goes and finds what it needs, and it pays without a person clicking anything at the final step. The word that matters in the definition is autonomy. Scheduled transfers, autopay and recurring billing have automated when money moves for decades, but a human decided the amount and the counterparty in advance. In an agentic payment the agent decides the counterparty, often the amount, and always the timing, working from context rather than a fixed script. That is the whole difference, and it is why the existing payment stack struggles: card networks, fraud engines and checkout pages were all built on the assumption that a person is present. Take the person away and every transaction starts to look like card-not-present fraud unless something new travels with it to prove authority.
How agentic payments work, step by step
Every agentic payment, whatever the rail, runs the same five beats. One, authorization. A human grants the agent authority with limits attached: what it may buy, from whom, up to how much, for how long. Depending on the stack this is a policy record, a signed payment mandate, or a card provisioned with caps. Two, identity. The agent gets something that proves which agent it is and which human stands behind it, because a merchant that cannot identify the buyer cannot price the risk. Three, a scoped credential. The agent receives a credential that is deliberately near-worthless outside the purchase it was issued for: a single-use card locked to one merchant, a network token bound to an agent and a consent policy, or a session key with a balance ceiling. Four, the authorization check. The purchase is tested against the limits before money moves, and declined at the boundary if it fails. Five, the record. The transaction is written down in a way that ties the dollar amount to the agent, the task that triggered it, and the person who owns that agent. Most vendors do steps two and three well. Step four is where products genuinely differ, and step five is what finance will ask you for at month end.
The four agentic payment rails
There is no single agentic payment rail, and the four that exist solve different problems. Scoped virtual cards are the pragmatic default in the United States: the agent gets a real card number that works at any merchant that takes cards, with the issuer enforcing merchant locks, MCC blocks and per-card caps at authorization. Stripe Issuing, Lithic and Ramp Agent Cards all sit here. Card network agentic tokens are the networks own answer. Mastercard Agent Pay uses Agentic Tokens that bind a tokenized credential to a specific agent, merchant scope and consent policy, and Visa Intelligent Commerce issues merchant-specific tokens with scoped permissions; our Visa and Mastercard comparison covers how the two programs differ. Open checkout protocols standardize the handshake rather than holding money: the Agentic Commerce Protocol, Google AP2, and the Google and Shopify Universal Commerce Protocol, plus the Machine Payments Protocol for machine-to-machine buying. Stablecoin and metering rails such as x402 let an agent pay fractions of a cent per API call over ordinary HTTP, which cards simply cannot do economically. Read the deeper breakdown in AP2 vs ACP vs x402. Most US teams end up on cards for merchant purchases and a metering rail for machine-to-machine spend, which is the strongest argument for keeping your governance layer separate from any one rail.
Agentic commerce vs agentic payments: what is the difference?
The two terms get used interchangeably and they are not the same thing. Agentic commerce is the broad shift: AI agents doing commercial work on behalf of a person or a business, from discovery and comparison through sourcing, negotiation, purchase and reconciliation. Agentic payments are the narrower financial mechanism inside it, the part that actually moves money and proves the move was authorized. Agentic commerce is the shopping trip; agentic payments are the moment at the register. The distinction matters commercially, because the vendors selling into each are different. Agentic commerce products are mostly sell-side, aimed at merchants who want agents to be able to buy from them. Agentic payments products are split between sell-side acceptance and buy-side control, and if you are the company whose agents are doing the spending, almost everything marketed at you is really sell-side. Our explainer on agentic commerce covers the merchant half.
How big will agentic payments actually get?
Every forecast agrees the direction is up and they disagree about the size by roughly an order of magnitude, because they are quietly counting different things. Accenture estimated in May 2026 that more than 30 percent of online commerce could run through AI agents by 2030, close to 3.1 trillion dollars globally. McKinsey put global agentic commerce at 3 to 5 trillion dollars by 2030, with as much as 1 trillion in orchestrated US retail revenue. Bain, publishing in December 2025, landed far lower at 300 to 500 billion dollars, or 15 to 25 percent of US e-commerce. The gap is a definition problem, not a disagreement about AI. Bain deliberately excludes journeys that merely use AI-assisted search or discovery and counts only purchases an agent initiates, influences or completes. McKinsey reaches further, capturing the logistics and payment activity the transaction pulls along with it. Accenture is measuring global online commerce flowing through agents rather than US retail. The practical read for a buyer: treat any single headline number with suspicion, check the scope in the footnote, and plan for agent-initiated spend to be a real line item in your own budget within two to three years rather than a rounding error.
Where agentic payments break
Three failure modes show up repeatedly, and none of them is fixed by encryption or by picking a better rail. The first is the runaway loop: an agent retries a failed purchase, or misreads a quantity, and buys the same thing forty times in ninety seconds. No human is watching, so nothing stops it until a statement arrives. The second is prompt injection. An agent that reads web pages, emails or tool output can be steered by text an attacker planted there, and if that agent holds spending authority the attack converts directly into money. This is why every serious guardrail design puts the spending limit outside the model, enforced by infrastructure the agent cannot talk its way past. The third is quieter and hits later: reconciliation. A charge lands on a statement with a merchant name and no indication of which agent made it, under which task, for which internal owner. Finance cannot code it, so it gets queried, and the whole program stalls at month end. See runaway agent spend and prompt injection and agent spend for the detail.
The controls that make agentic payments safe
The safety model is boring and it works. A hard per-agent budget evaluated before every authorization, not a wallet balance the agent can drain in one call. Merchant and category allowlists, so a compromised agent can only reach counterparties you already approved. A human approval threshold, with a tiered model: automatic below a small amount, notify in the middle band, require a named person to approve above it. Single-use, merchant-locked credentials, so a leaked card number is worth nothing to whoever leaked it. An immutable record tying every charge to agent, intent and human owner. The critical design point, and the one teams get wrong, is that all five must be enforced outside the agent. A limit written into a system prompt is a suggestion. A limit enforced at the authorization boundary is a limit. Amazon documented the same principle when it shipped Bedrock AgentCore Payments in preview on May 7, 2026, enforcing a per-session spend ceiling and an expiry time at the infrastructure layer, explicitly outside agent code, so that prompt injection cannot lift them. Those controls are the payments half of a wider program: the same questions about identity, authority and evidence show up under the heading of AI agent governance, where most published frameworks stop short of the money.
B2B agentic payments and agentic bill pay
Most public discussion of agentic payments is about a consumer telling a chatbot to book a flight. The money in the near term is duller and larger. Inside US businesses, agents are already buying cloud capacity, ad inventory, API calls, SaaS seats, freight and supplier goods, which is spend that used to route through a purchase order, a corporate card or an AP run. B2B agentic payments inherit all the existing constraints that consumer flows do not: approval hierarchies, spend policy, cost center coding, supplier onboarding, tax treatment and an auditor who will eventually ask who authorized this. That is why the buy-side control question is sharper in B2B than in retail. An agent that raises a purchase requisition and waits for a threshold approval is not a worse agent than one that buys instantly; it is the only version a controller will sign off on. If you are heading here, start with the agents that buy the same thing repeatedly from a small set of known suppliers, because allowlisting is trivial and the audit story writes itself. Our procurement agent and bill pay agent pages cover the workflows in detail.
Agentic payments infrastructure: what to build and what to buy
A full agentic payments stack has five layers, and you should not build all of them. The rail (cards, tokens, stablecoins) you buy, always. Identity you buy or adopt as a standard; Skyfire KYA became the identity layer for Experian Know Your Agent in April 2026, and our Know Your Agent explainer covers what it requires. Credential issuance you buy from the issuer. Policy and approval is the layer teams try to build in-house, usually as a few checks in application code, and it is the layer that fails first, because the checks live inside the same process the agent influences and they multiply once you have more than a handful of agents. Reporting and audit gets deferred until finance asks, and then gets built badly against statement data that no longer contains the agent context. The honest build-versus-buy line: build the parts specific to your product, buy the parts where being wrong costs money you cannot claw back. A useful sanity check on any vendor is to demand a demo of the failure case rather than the happy path. Have an agent try to exceed its budget and watch what happens. If the transaction succeeds with a warning, you do not have a limit.
Where Agentspay fits
Agentspay is the control plane, not the rail. It sits above whichever agentic payments rail you use and answers the question none of them answer: should this specific purchase happen right now? Agents get an agent wallet, hard spend limits evaluated before every authorization, human approval above the threshold you set, scoped virtual cards that are merchant-locked and single-use, and an immutable audit trail that names the agent, the intent and the human owner on every line. Because it is rail-neutral, you are not betting your architecture on one protocol winning a standards race that is still wide open. If you are comparing categories rather than vendors, start with AI agent payment platforms compared, which breaks the market into five product types and is honest about which one you actually need.