Agentic payments let an AI agent pay for goods or services on behalf of a person or a company, within limits approved in advance. For an enterprise, the hard part is not moving the money. It is proving the agent was authorized, bounding what it can spend, and keeping a record that stands up to audit and disputes.
Since 2025, card networks, Google, OpenAI, Stripe, and Coinbase have all published ways for agents to pay. The market is still early. In March 2026, OpenAI moved ChatGPT's Instant Checkout toward apps and merchants' own checkouts, as Digital Commerce 360 reported, a sign that the experience is still being worked out. That makes now the right time to design the security and payment foundations, before agents handle real spend at scale.
Agentic payments are payments an AI agent initiates under pre-approved authority, instead of a person clicking "pay".
The stack is layered: authorization (AP2, Verifiable Intent), network identity and tokens (Visa, Mastercard), checkout (ACP, UCP), and settlement (cards or stablecoins through x402).
Five controls make it safe: verifiable mandates, tokenized credentials, spend limits, step-up approval and a full audit trail.
Start narrow: pilot with low-value, reversible spend and widen autonomy as controls prove themselves.
What Are Agentic Payments?
An agentic payment is a payment initiated by software acting on a person's or organization's behalf. The principal sets the goal and the limits, such as "renew these licences, up to this amount", and the agent completes the purchase.
Traditional online payments assume a person is present to enter a card number or approve a prompt. Agents break that assumption. Google's updated Agent Payments Protocol, for example, adds support for 'Human Not Present' payments, where an agent pays based on instructions the user authorized earlier.
Dimension | Traditional online payment | Agentic payment |
|---|---|---|
Who initiates | A person at checkout | An agent acting on delegated authority |
When consent is given | At the moment of payment | In advance, as a scoped instruction |
Proof of consent | The person's action and an authentication step | A signed record of what the person approved |
Credential the payer uses | The person's own card or account | A token or credential issued to the agent |
What the merchant must decide | Is this a legitimate customer? | Is this a legitimate agent, and is it within its authority? |
Main risk | Stolen credentials | Overreach, manipulation of the agent, and disputes over intent |
Every agentic payment has to answer three questions: who authorized it, what exactly was approved, and who is accountable if it goes wrong. The protocols and controls in this guide are different answers to those questions.
Two sides of the same shift
Your enterprise as the payer. Agents that buy on your behalf: procurement, travel, software and API spend, supplier payments.
Your enterprise as the merchant. Customers' and partners' agents buying from you, which means you must recognize trusted agents and accept their payments safely.
Ready to Build Secure Agentic Payment Systems?
The Agentic Payments Landscape: Protocols and Networks
There is no single agentic payments standard. Several initiatives cover different layers, and a real transaction can touch more than one. Status as of 13 October 2026; this space changes quickly, so verify before you commit to a design.
Initiative | Led by | Layer | What it does |
|---|---|---|---|
Google; donated to the FIDO Alliance in April 2026 | Authorization | Defines how agents, merchants, wallets, and payment providers coordinate around a user's authorization; version 0.2 adds "Human Not Present" payments | |
Mastercard, co-developed with Google; contributed to FIDO | Evidence | Creates a tamper-proof record of what a user authorized an agent to do, compatible with AP2 | |
Visa, with Cloudflare (announced October 2025) | Agent identity | Lets merchants determine the identity and intent of agent traffic and accept payment from an agent; part of Visa Intelligent Commerce | |
Mastercard (announced April 2025) | Tokens | Introduces Agentic Tokens, built on Mastercard's existing tokenization, with acquirers and checkout providers | |
OpenAI and Stripe | Checkout | Connects users to merchants across the shopping journey; OpenAI says Instant Checkout is moving to apps while ACP remains the infrastructure | |
Google, with Shopify (unveiled January 2026) | Discovery and checkout | Designed to let agents manage the shopping journey from discovery to checkout | |
Coinbase; now the x402 Foundation at the Linux Foundation | Settlement | Uses the HTTP 402 status code so an agent can pay for a resource in stablecoins, suited to small pay-per-use payments between software |
The pattern to take from this is layering. One purchase might carry an AP2 authorization, a network token from Visa or Mastercard, a checkout through the merchant, and settlement over cards or, for machine-to-machine micropayments, stablecoins.
For an enterprise, the practical conclusion is to design for the layers, not for one acronym. Keep your payment orchestration protocol-agnostic, and make the controls in the sections below independent of whichever rails you connect.
Enterprise Use Cases for Agentic Payments
The best early use cases share three traits: the spend is routine, the rules are clear, and a mistake is cheap to reverse.
Use case | Your role | What the agent does | Typical controls |
|---|---|---|---|
Routine procurement | Payer | Reorders consumables from approved vendors when stock runs low | Approved vendor list, per-order and monthly caps, purchase order matching |
Travel and expenses | Payer | Books and pays for travel inside company policy | Policy engine, per-trip budget, approval above a threshold |
Software, API and data spend | Payer | Buys credits or pays per call for tools and data | Per-agent budgets, allowlisted payees, spend alerts |
Subscription and licence renewals | Payer | Renews, right-sizes or cancels subscriptions | Renewal calendar, human approval for any increase |
Supplier invoice payment | Payer | Matches invoices to orders and schedules payment | Three-way match, dual approval above a limit, segregation of duties |
Selling to customers' and partners' agents | Merchant | Accepts agent-initiated orders | Agent identity checks, structured product and price data, fraud screening, dispute evidence |
The merchant side is easy to overlook. If agents will buy from you, your catalogue, checkout, and fraud rules need to work for software buyers as well as people. Our merchant payment solutions cover that groundwork, and our guide to choosing a payment processor helps you pick partners that will support agent payments.
For the plumbing underneath, see our payment gateway integration guide, which covers classic gateway integration.
Ready to Build Secure Agentic Payment Systems?
The Risks of Letting AI Agents Spend Money
Payments are where an agent's mistake costs money immediately. Treat the agent as an untrusted requester whose instructions can be manipulated, and build the controls around it.
Threat | What happens | Main control |
|---|---|---|
Prompt injection that redirects spend | Hidden instructions in a web page, email, or tool result push the agent to pay the wrong payee or amount | Allowlisted payees, limits enforced outside the model, and approval for anything unusual |
Over-broad authority | A standing credential lets an agent spend far beyond what was intended | Scoped, expiring mandates with per-payment and cumulative limits |
Credential exposure | Card numbers or API keys appear in prompts, logs, or model context | Tokenization, so the agent never handles raw card data, plus a secrets manager |
Amount or intent mismatch | The item or price changes between approval and charge | Bind the approval to the exact cart and amount, and verify at capture |
Replay and context-binding failures | A valid authorization is reused or applied to a different transaction | Single-use mandates with nonces, tied to merchant, amount, and time |
Fake agents (merchant side) | Bots pose as legitimate buyer agents to test cards or scrape pricing | Agent identity verification and risk scoring |
Disputes and unclear liability | No one can show what the user actually approved | Signed mandates and decision logs kept as dispute evidence, and clear contract terms with processors |
Compliance exposure | The agent touches cardholder data or bypasses a required authentication step | Keep the agent out of card data scope with tokens, and design the authentication path with compliance |
These protocols are young. Researchers have already reported practical attacks on x402 payment flows that cause unpaid service or paid-but-denied outcomes, and have published work on weaknesses in how AP2 signs a transaction without capturing the decision behind it. Do not assume a protocol makes your integration safe. The controls below apply whichever rails you use.
Reference Architecture: A Secure Agentic Payment Stack
The agent should be able to ask for a payment, never to make one directly. Put a control layer between the agent and the money, and make that layer the only path to your payment rails.
Secure agentic payment stack · mandate, control layer, token, rails, audit
The principal signs a mandate. When the agent requests a payment, the control layer checks the mandate, enforces limits and risk rules outside the model, and issues a scoped token. Only that token reaches the payment rails and the merchant. Unusual payments go to a person, and every decision lands in the audit log.
Because the control layer owns the mandate, token, and log, you can add or swap rails, such as card networks, AP2, or stablecoins, without changing how authority and evidence are handled.
Five Controls for Secure Agentic Payment Infrastructure
1. Verifiable mandates
Record what the principal approved, including the payee or category, maximum amount, time window, and conditions, as a signed, tamper-evident mandate. AP2 mandates and Mastercard's Verifiable Intent both follow this idea. Tie each mandate to a distinct agent identity, bind every payment to a mandate, and reject any payment that has none. Make high-value mandates single-use or short-lived.
2. Tokenized credentials, never raw card data
Give agents network or processor tokens scoped to a merchant, an amount or a purpose, as in Mastercard's Agentic Tokens, and never real card numbers. The agent and the model context stay out of cardholder data, which shrinks your PCI DSS scope. Confirm the scope with your assessor.
3. Limits enforced outside the model
Set per-payment, daily, cumulative, per-payee, and per-category limits in a policy service that the model cannot edit or talk around. Add velocity checks and a kill switch that suspends an agent or a mandate immediately. A limit that lives only in a prompt is a suggestion.
4. Step-up approval for unusual payments
Decide in advance what an agent may do alone and what needs a person: auto-approve inside the mandate, but require approval for a new payee, an amount above a threshold, or anything irreversible. Use phishing-resistant authentication for approvers. Where regulations such as strong customer authentication apply, design the human-not-present path with your compliance advisers.
5. A complete audit trail and daily reconciliation
Log the mandate ID, agent and user identity, payee, amount, policy decision, any approval, and the processor reference for every payment. Store the records in tamper-resistant storage and reconcile them against processor statements every day. Feed the same data to anomaly detection (see our AI anomaly detection guide). If the agent reaches payment tools through MCP, secure those servers as well, as covered in securing MCP servers in the enterprise.
This is general information, not legal or compliance advice. Confirm requirements for your markets with your payments, security, and compliance teams.
Ready to Build Secure Agentic Payment Systems?
A Roadmap to Agentic Payments in Your Enterprise
Pick one narrow use case. Choose a payee class you already trust, with low-value, reversible payments and a named business owner.
Assess readiness. Review identity, integrations, security controls, and governance. Our AI readiness assessment is built for this step.
Build the control layer first. Stand up the mandate service, policy engine, token vault, and audit log before the agent gets any purchasing ability.
Pilot with approval on every payment. Once the data shows low exception rates and no policy breaches, relax approval inside the mandate, one limit at a time.
Stay protocol-agnostic. Put payments behind an orchestration layer so you can add AP2, network programs, or stablecoin rails as your processors support them.
Measure and review. Track exception rate, blocked attempts, disputes, reconciliation breaks, and cost per payment, and review limits regularly.
Before an agent spends real money, confirm that
every payment maps to a signed mandate and a named agent identity
the agent never sees raw card numbers or long-lived secrets
limits and the kill switch work when the model is ignored
approvers use strong authentication
logs reconcile with processor statements, and you know who handles a dispute
Conclusion: Build the Controls Before the Agents Spend
Agentic payments are real but early, and the standards are still settling. The enterprises that benefit will be those that treat the agent as an untrusted requester and put signed mandates, tokenized credentials, enforced limits, step-up approval, and a full audit trail around it, whichever protocol wins.
Zignuts helps enterprises design and build secure AI systems and payment infrastructure, as an OpenAI, Anthropic (Claude), and AWS partner. Explore our agentic AI services, see our AI solutions for fintech and banking, check where you stand with the AI readiness assessment, or request a project estimate.
Parth Trivedi
Co-founder and CTO of a global software agency, I lead innovative IT solutions across industries, focusing on scalable architectures and agile methodologies. Let’s connect to scale your digital initiatives!
