Payment teams have spent years optimizing for a human on the other side of the checkout: someone who types an address, taps a wallet button, and approves a 3-D Secure prompt. Agentic commerce changes that assumption. When an AI agent searches, compares, and buys on a person’s behalf, the transaction no longer looks like the flows that fraud rules, authentication steps, and checkout pages were built around.
Most of this is still early. Card networks, large platforms, and payment providers have announced and, in some cases, launched agent-specific programs, but standards are still moving, and volumes are small. That’s exactly why the infrastructure question deserves attention now rather than after the first wave of agent traffic arrives.
What Agentic Commerce Changes in the Payment Flow
In a conventional flow, the customer is present at every step. They see the price, choose the payment method, authenticate, and confirm. Every risk signal a merchant relies on, from device fingerprint to typing behavior, comes from that person’s session.
With agentic payments, the agent handles some or all of those steps. The person may set a goal (“book a flight under a certain price”) and a spending limit, then step away. The merchant receives a request from actually authorized this purchase, within these limits. Google’s Agent Payments Protocol (AP2) uses cryptographically signed “mandates” to record what the user approved. OpenAI and Stripe’s Agentic Commerce Protocol takes a different route, built around a scoped, single-use token tied to a specific merchant and amount.
Credential security. Handing raw card numbers to an agent would be a step backward. Network tokenization is the more common direction: Mastercard’s Agent Pay, for example, issues tokens scoped to a particular agent and set of spending rules. The principle matters more than any single product: the agent should hold a limited-purpose credential, never the underlying card.
Fraud and risk controls. Rules tuned to flag “unusual” behavior may block a legitimate agent simply because it doesn’t behave like a person. Rules that wave agents through risk the opposite problem. Teams need controls that can evaluate agent-originated transactions as their own category.
Disputes and liability. If an agent buys the wrong thing, or buys something the customer says they never approved, the chargeback process was not designed with that question in mind. Rules here are still being worked out by networks and providers, and merchants should expect them to change.
Interoperability. Several protocols now compete or overlap, covering different layers: product discovery and checkout, payment authorization, and agent identity. Some are tied to a card network; others are payment-method neutral. No single one has settled the field.
How Businesses Can Prepare Their Payment Stack
Nobody can predict which protocols will win. Preparation therefore means making the stack adaptable rather than betting on one outcome.
Keep integrations flexible. If checkout logic, provider connections, and risk rules are hard-wired together, every new requirement becomes a rebuild. Separating them, so that a new authentication method or token type can be added without touching everything else, is the most useful thing a payment team can do.
Support multiple providers and payment methods. Agent-initiated payments will reach merchants through different rails: network tokens on cards, wallets, and in some cases bank transfers or stablecoins. A merchant tied to a single provider inherits that provider’s timeline for supporting each one. Having a second route available, even if lightly used, reduces that dependence.
Centralize payment management. When rules, routing, and reporting live in separate tools per provider, it becomes difficult to see how agent-originated transactions perform compared with human ones, or to adjust controls quickly. One common approach is to put a layer such as
<p>Teams weighing whether to build that abstraction themselves or use external infrastructure often compare the
