You ask an Agent to book a flight to Tokyo for next week. It scans the options, finds the lowest fare, opens the checkout page, and stops. It has no fingers to type a CVV and no phone to receive a verification code. You still have to come over and click confirm.
The problem is that today’s payment system assumes the buyer and the operator are the same person, and that person is present. When you pay with your phone, your fingerprint, face scan, or SMS code all prove “you are the one operating.” An Agent has none of these. It can pick the product, enter the checkout flow, and then wait — for you.
Delegated purchasing itself is not new. Subscriptions auto-deduct from your card each month. Card-on-file lets merchants store your card number. Corporate virtual cards and procurement cards have long let others spend on behalf of a business. What these scenarios share is that the authorization boundary is locked down before the transaction occurs: fixed merchant, fixed spending cap, fixed billing cycle.
What Agents introduce is more open-ended. You tell an Agent “book me a flight to Tokyo.” It needs to search, compare, pick a flight, fill in passenger details, and then pay. The merchant isn’t fixed (it could be the airline’s site, Ctrip, or Fliggy). The amount isn’t fixed (it depends on which day you fly). Even “which one to buy” is the Agent’s own decision. Earlier delegated payment scenarios never faced this kind of uncertainty. Agent authorization must be generated dynamically in the middle of a transaction.
The human remains the ultimate owner of the funds. The Agent is just an executor. But once an executor can trigger payment, the system needs to encode human intent into a machine-readable set of authorization boundaries: how much can be spent, at which merchant, whether substitutes are allowed, what happens when the budget is exceeded. This mechanism also needs to support post-hoc review and revocation. It is no longer just a shopping experience problem.
Discussions about Agent payments often conflate three distinct scenarios. Each has a different outlook, obstacles, and path forward.
The first layer is human-present checkout: the user is present, the Agent handles discovery and comparison, but the final payment confirmation is still done by a human. OpenAI and Stripe’s Instant Checkout falls here. ChatGPT organizes the purchase flow, Stripe generates a Shared Payment Token (SPT), and the transaction executes only after the user confirms. Stripe describes SPT as a new payment primitive that lets applications like ChatGPT initiate payments without exposing the buyer’s credentials (source).
OpenAI’s commerce documentation is explicit: customers buy directly from the merchant, payment flows directly to the merchant, the merchant decides whether to accept the order, and the merchant handles the full post-purchase experience (source). This model has reached production, but the critical decision step is still human execution. It proves that an AI conversational interface can serve as a purchase entry point, but its relevance to fully autonomous Agent spending is limited.
The second layer is delegated purchase: the user gives an Agent a set of boundaries and lets it buy autonomously within those conditions — buy when the price drops below a threshold, buy when tickets go on sale, auto-replenish every week. This is the genuinely new problem space for Agent payments. What is authorized, how much can be spent without confirmation, at which merchant, whether substitutes are allowed — all these constraints need system-level expression. Existing payment systems already have controls for amount, merchant, time, MCC, and recurring mandates, but the cross-platform semantic layer for Agent delegated purchases is not mature yet.
Google’s AP2 protocol handles authorization evidence. Think of a Mandate as a machine-readable power of attorney: the user writes in advance “my Agent can buy on my behalf under these conditions,” locks it with a cryptographic signature, and any merchant, wallet, or payment network can verify the signature and check the authorization scope to confirm it has not been tampered with (source). The mandate uses the W3C Verifiable Credential format. PayPal has noted that mandates could prove during disputes that the user did authorize the transaction at the time (source). AP2 itself does not move money — it only lets each party confirm “was this purchase authorized.” Whether issuers, merchant contracts, and regulatory rules will fully accept this kind of evidence remains to be tested in real dispute cases.
Stripe’s Link wallet for agents handles the issuance of payment credentials. The flow breaks down this way: the user first grants the Agent access to their Link wallet via OAuth; the Agent finds a purchase opportunity and initiates a spend request with amount, merchant, and other conditions; the user receives the request and approves it; upon approval, Link returns a single-use card or SPT to the Agent, with the merchant, amount, and currency already locked in (source). This flow is easy to confuse with the first-layer human-present checkout, because the current version still requires per-request user approval. The difference is in the starting point and the credential form: the Agent proactively discovers a purchase opportunity and initiates a payment request, and the system returns a short-lived credential restricted to a specific merchant, amount, and currency. The Agent never touches the raw card number. It sits between human-present checkout and a more autonomous future delegated purchase — a transitional form.
The distinction between AP2 and Link can be summarized this way: AP2 answers “was the Agent authorized”; Link answers “after the user approves, what restricted credential does the Agent get to complete payment.” They operate at different layers and can complement each other.
The third layer is business / machine spend automation: enterprises let Agents automate API calls, SaaS renewals, supplier payments, data purchases, and other controlled spending. This scenario does not depend on whether consumers are comfortable with AI shopping. Enterprises already have budgets, approvals, virtual cards, reconciliation, and audit processes. The Agent simply enters an existing workflow as an executor. Stripe is extending its Issuing product line to Agent scenarios precisely here: virtual cards, spend controls, real-time authorization, and reconciliation APIs are all ready-made control mechanisms (source). Visa and Mastercard have also launched Trusted Agent Protocol and Agent Pay respectively, aiming to keep card networks serving as the identity, tokenization, and trust signal layer in Agent transactions (Visa, Mastercard).
Progress across the three layers is strikingly uneven. The first layer is already in production. The third layer has the most fertile ground — it addresses automation and governance of existing enterprise spend. The second layer is the easiest to overestimate, because what really slows it down lies beyond the pay button: trust, fraud, disputes, merchant acceptance, and regulatory liability chains are all still immature.
Separating the three layers reveals a clear chain of difficulties, stretching from human intent all the way to Agent decision quality. The rest of this article follows that chain.
| Stage | Core Question |
|---|---|
| User Intent | What exactly did the user ask the Agent to do |
| Authorization Boundary | How to express and constrain amount, merchant, timing, alternatives, budget |
| Payment Credential | What restricted credential can the Agent hold (no raw card numbers) |
| Merchant Acceptance | How merchants identify legitimate Agent requests, integrate with catalog/order/fulfillment |
| Network & Risk | How card networks, PSPs, and issuers see agent presence and risk signals |
| Audit & Disputes | When something goes wrong, how to prove what happened, who authorized, who is responsible |
| Decision Quality | Even when the process is compliant, did the Agent actually buy the right thing |
An Agent buys a flight ticket but gets the date wrong. The user said “next Wednesday.” The Agent understood “next Friday.” Who is responsible for the mistake? The surface issue is model comprehension error, but the root cause is that the system never received the user’s precise intent. AP2’s Mandate tries to express authorization intent with verifiable credentials, but there is still a gap — a reliable compilation layer — between a natural language instruction and a deterministic spending constraint.
The user says “book me a flight.” What exactly is authorized? Price cap, time window, whether substitutes are allowed — these constraints need to be translated into machine-readable authorization boundaries. Stripe’s single-use card and SPT can restrict amount and merchant. AP2’s Mandate tries to express richer authorization semantics. The tension is that boundaries that are too tight make the Agent ineffective, while boundaries that are too loose defeat the purpose of authorization.
An Agent finds a bargain on a phishing site and submits the card number during checkout. The user only discovers the fraud when the bill arrives. The problem is that the Agent should never hold the raw card number or a long-lived wallet credential. SPTs, single-use cards, and OAuth-with-spend-request all share the same goal: let the Agent complete a payment without ever touching a long-lived payment key.
A merchant receives an order placed by an Agent, but has no way to integrate it into existing fulfillment systems. An Agent can trigger a payment, but the merchant needs catalog, inventory, shipping, refunds, and order events — full integration. Agent payments may also bring bot traffic, price arbitrage, returns, disputes, and higher risk management costs. If the integration cost exceeds the incremental conversion, merchants have no incentive to accept Agent orders.
An Agent checks prices and places orders for thousands of users simultaneously. The merchant’s risk control system sees hundreds of transactions per second with uniform behavioral patterns — this does not look like a normal buyer but rather an automated attack. How does a merchant distinguish a legitimate authorized Agent from a malicious bot? Agent traffic may be orders of magnitude larger than human traffic, and its behavioral patterns look more like an attack. Traditional fraud scoring may not correctly interpret its intent.
Suppose a user buys a pair of shoes through an Agent, then regrets it after delivery and claims they never ordered via Agent. Or the Agent genuinely exceeds its budget and buys something out of scope. Who bears the loss? The liability chain among user, Agent platform, merchant, wallet, and issuing bank has not been established. Every Agent-initiated spend also needs to answer: who triggered it, why, which budget was used, and whether it was authorized. Enterprise audits are easier since expense management already requires this level of record-keeping. Consumer scenarios are harder — ordinary consumers have no habit of auditing every automated purchase.
Even with authorization and audit fully resolved, an Agent can still make poor decisions in a transaction. A more capable Agent can negotiate better prices for its principal, while a weaker Agent gets outmatched — and the losing side may not even realize it is losing. Anthropic’s Project Deal experiment offered this warning. Authorization solves “allowed to spend and auditable.” Whether the Agent bought correctly is a separate layer of judgment.
A protocol can prove that authorization existed, but it cannot directly make consumers trust an AI to pay on their behalf. A Riskified survey found that 55% of consumers are uncomfortable with AI Agents handling purchases, and 53.9% believe AI will increase online fraud risk (source). Research cited by Ravelin points in the same direction: only 17% of shoppers globally are willing to let an AI Agent handle the entire shopping journey including payment, and far fewer have actually done it (source). These surveys do not represent all consumers’ long-term attitudes, but they are sufficient to show that fully autonomous checkout has not yet gained broad trust. Riskified also noted that 73.9% of consumers expect strong protections like biometrics or one-time passcodes. That number itself indicates that autonomy in consumer scenarios will not become full delegation anytime soon.
Agents may bring high-intent demand and new purchase channels, which is appealing to merchants. But Agents do not impulse-shop, do not watch ads, do not buy add-on items, and tend to compare prices, check reviews, and minimize friction. For retail models that depend on advertising, conversion funnels, and emotional purchasing, Agent traffic is not necessarily good news. Whether a merchant should support Agent payments depends on whether incremental conversion outweighs integration costs, risk management costs, returns, disputes, and margin pressure.
The liability chain also requires legal and regulatory frameworks. When an Agent buys the wrong thing, how is liability distributed among the user, Agent platform, merchant, wallet, and issuing bank? Existing chargeback, dispute, and liability shift rules are all built on the assumption of human operation. In Agent scenarios, these rules need new interpretations — and in some cases, entirely new contractual arrangements.
Agent capability disclosure is another gap that protocols have not yet addressed. The identity layer knows whose Agent it is. The authorization layer knows what it is allowed to do. But no one knows whether it is capable of making good deals for its principal. Project Deal showed that in an agent-to-agent marketplace, differences in model capability translate directly into economic outcomes, and the losing side does not even realize it lost. Payment protocols cannot solve this problem, but it will constrain the commercial scope of Agent payments.
Along this lifecycle, some links already have concrete solutions: authorization evidence, restricted credentials, merchant integration, and network signals are being filled in by products and protocols. Others remain open: user trust, merchant incentives, liability rules, and Agent capability disclosure. Looking at where each player sits makes it clearer which layer of the chain they are addressing.
Mapping these efforts back to the lifecycle makes each player’s position clearer. Different actors are handling different links in the same chain.
AP2 handles user intent and authorization boundaries. The AP2 protocol promoted by Google and PayPal focuses on whether an Agent was authorized and how authorization can be interoperable across platforms. The Mandate uses the W3C Verifiable Credential format, transforming human authorization intent into machine-readable, verifiably signed, storable authorization evidence. AP2 also distinguishes between Cart Mandate, Intent Mandate, and Payment Mandate, treating human-present and human-not-present transactions separately. PayPal has noted that mandates could prove during disputes that the user did authorize the transaction at the time. AP2 provides the authorization evidence layer; money movement is handled by downstream protocols.
Stripe Link and SPT handle payment credentials. After the user approves, the Agent needs a restricted credential to complete the transaction. Stripe Link wallet works this way: the user authorizes Agent access to their wallet via OAuth, the Agent initiates a spend request, the user approves, and Link returns a single-use card or SPT. The credential is restricted to a specific merchant, amount, and currency, and the Agent never touches the raw card number. The current version still requires per-request user approval, making it a transitional form. It ensures credential safety but has not yet addressed broader authorization semantics.
Stripe ACP and Agentic Commerce Suite handle merchant acceptance. Once the Agent has a payment credential, merchants need to receive, verify, and process Agent orders. Stripe’s Agentic Commerce Protocol (ACP) and Instant Checkout handle standardized checkout, catalog, inventory, shipping, refunds, and order events for merchant integration. OpenAI’s commerce documentation also makes this clear: customers buy directly from the merchant, the merchant decides whether to accept the order, and the merchant handles the full post-purchase experience. The goal of this layer is to ensure merchants do not need custom integration for every Agent platform.
Visa and Mastercard cover network and risk. Card networks need to ensure that Agent transactions flowing through card rails can be correctly identified by issuers and merchants. Visa launched Trusted Agent Protocol and Mastercard launched Agent Pay, both aiming to pass identity, tokenization, and trust signals at the card network layer. Traditional fraud scoring, faced with Agent’s high-volume, high-tempo behavioral patterns, needs a new signal layer.
Adyen and Checkout.com handle merchant orchestration and multi-protocol compatibility. They serve enterprise merchants and cannot bet on a single Agent platform or protocol. Their role is to keep merchants flexible across ACP, UCP, AP2, Visa, Mastercard, and other frameworks — regardless of how the protocol layer for Agent transactions evolves, the merchant side can handle it (Adyen, Checkout.com).
Stripe Issuing handles enterprise spend controls. Authorization and credential management in enterprise scenarios can leverage more mature tools. Virtual cards, spend limits, real-time authorization, MCC restrictions, and reconciliation APIs — the Issuing product line extends these capabilities to Agent scenarios. This differs from the Link wallet credential layer: Issuing targets the automation of enterprise budgets and approval workflows, while consumer scenarios require more flexible one-time authorization approvals.
All these approaches are working on different links of the same chain. What they share is a common direction: narrowing the Agent’s freedom. No one is designing the Agent as a free-spending buyer. Every solution is building an executor with provable authorization.
Taken together, these products and protocols reveal Agent payments as a lifecycle: human intent is first translated into authorization boundaries, the system issues a restricted payment credential, the merchant decides whether to accept the order, payment networks and risk systems identify risk, and audit trails and dispute evidence are left behind. One layer deeper is the hardest question: even when authorized, capable of paying, and auditable, the Agent may still not buy the right thing.
Today’s products fill some links in this lifecycle. AP2 handles authorization evidence. Stripe Link and SPT handle restricted credentials. ACP and Instant Checkout handle merchant integration. Visa and Mastercard handle network signals. Issuing connects enterprise budgets, limits, and reconciliation into Agent scenarios. All of these matter, but none of them have turned consumer fully autonomous shopping into a mature market.
Two short-term paths are more realistic: human-present checkout will be adopted first, and enterprise automated spending will be the first to land. The first lowers the consumer trust barrier. The second reuses enterprises’ existing approval, budget, and audit infrastructure. This is where the value of Agent payments becomes clear: it is a trust infrastructure that determines whether Agents can move from being recommendation systems to executing real transactions.