Jasmine Birtles
Your money-making expert. Financial journalist, TV and radio personality.

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.
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 software, not a browser session driven by a human.
That shifts three things. Authorization is granted in advance rather than at the moment of purchase. The party interacting with the merchant is not the account holder. And the usual behavioral signals are largely absent, so risk engines have less to work with.
Identifying agents. A merchant needs some way to tell a legitimate agent acting for a real customer from an automated bot scraping or testing cards. Visa’s Trusted Agent Protocol, introduced in 2025, approaches this by letting agents present verifiable identity to merchants. It’s one approach among several, not a universal standard.
Proving consent. Someone has to show that the customer 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.
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 payment orchestration platforms between the merchant’s checkout and its providers, so routing and monitoring sit in one place. Whether that fits depends on how many providers a business runs and how much in-house engineering capacity it has.
Use tokenized credentials throughout. Storing and passing tokens instead of card data limits exposure and aligns with where network programs for agents are heading. It also makes it easier to revoke or restrict a credential without affecting the customer’s underlying account.
Make risk controls adjustable. Rules should be easy to segment, so a team can treat agent-originated traffic separately, tighten or loosen thresholds as data comes in, and review outcomes without a development cycle each time.
Don’t depend on a single rail. If one network’s program or one provider’s agent feature becomes the only way to accept agent payments, the merchant’s options narrow to that vendor’s roadmap.
It is tempting to respond to each announcement with a dedicated integration: one for a particular assistant, another for a specific protocol, a third for a network program. That approach doesn’t scale. Protocols are young, and some will merge, change, or fade. Rebuilding checkout and payment logic for each one means paying the integration cost repeatedly.
A better framing is to treat agent protocols the way mature payment teams treat payment methods: as inputs to a common layer. The merchant defines how it authenticates requests, validates consent, applies risk rules, and routes transactions once. Individual protocols and token formats connect to that layer through adapters.
This also protects against concentration. If most agent traffic eventually flows through one ecosystem, a merchant with a neutral internal design can support it without having rebuilt everything around it. If traffic fragments, the same design handles several at once.
Teams weighing whether to build that abstraction themselves or use external infrastructure often compare the best white label payment gateway options against the cost of maintaining provider connections in-house. The right answer depends on volume, markets, and engineering resources, but the question is worth asking before the first agent-driven purchase request arrives, not after.
Agentic commerce does not require a new payment stack, but it does expose weaknesses in rigid ones. Agent identity, verifiable consent, scoped credentials, and adaptable risk controls are the recurring requirements across the protocols emerging today. Businesses that keep their integrations modular, support more than one provider and payment method, and treat protocols as interchangeable inputs will be better placed to adopt whichever standards prove durable.
Disclaimer: MoneyMagpie is not a licensed financial advisor and therefore information found here including opinions, commentary, suggestions or strategies are for informational, entertainment or educational purposes only. This should not be considered as financial advice. Anyone thinking of investing should conduct their own due diligence.