Payment Infrastructure for AI Agents: The Complete Guide (2026)

Payment infrastructure for AI agents is the layer that turns an agent's purchase decision into a completed, authorized transaction at a real merchant. It has four parts: proving the agent is who it says it is, capturing what the user actually approved, holding a chargeable credential the agent never sees, and executing the checkout. Lane provides all four behind a single integration.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. This guide walks the full stack, names what is live in production today, and gives you a way to evaluate the providers in this market.

Why do AI agents need their own payment infrastructure?

The web's payment stack was designed around a human at a keyboard. Every assumption in it, from the checkout form to the fraud model to the liability framework, presumes a person clicking buttons and reading confirmation screens. Agents break all three assumptions at once.

A checkout is really a form, and agents do not do forms. An agent can reason brilliantly about which running shoe to buy and then fail at the address autocomplete, the guest-versus-account fork, the one-time passcode sent to the user's phone, and the bot challenge that fires because the traffic does not look human. The intelligence problem is solved. The transaction problem is not.

• Credentials: an agent cannot be handed a raw card number. If it can read the number, so can its logs, its prompt history, and anyone who compromises it.
• Consent: a chat message saying "yes, buy it" is not an authorization record. It has no amount, no merchant, no line items, and no way to prove after the fact what the user agreed to.
• Identity: merchants and CDNs cannot tell a legitimate shopping agent from a scraper or a card tester, so the safe default is to block it.
• Execution: even with a valid card and a clear instruction, somebody still has to complete the merchant's actual checkout and return an order confirmation.

Agents are the web's new users, so they need their own lane.

What are the layers of agent payment infrastructure?

It helps to think of agent payments as four stacked layers rather than one product. Each layer has a distinct failure mode, and most tools in this market cover one or two of them. Lane's design goal is that a builder integrates once and gets all four.

Layer 1: Identity

The identity layer answers a merchant's first question: is this traffic legitimate? Merchants deploy bot detection from Cloudflare, Akamai, and DataDome precisely because anonymous automated traffic is usually hostile. An agent with no verifiable identity is indistinguishable from an attacker, and gets treated like one.

Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with an Ed25519 key published in a self-hosted key directory. That signature has been verified against Cloudflare's Web Bot Auth crawl test, and Lane is registered in Visa's Trusted Agent Protocol registry. The practical result: merchants and CDNs can cryptographically verify that Lane's agent is a known, accountable actor rather than guessing from traffic shape.

Layer 2: Intent and consent

The consent layer answers: what exactly did the user approve? Lane's answer is the intent object, a structured line-item purchase contract that the user approves before anything executes. It names the merchant, the items, the quantities, the price ceiling, and the fulfillment details.

The intent object is a receipt before the purchase happens. Once approved, the agent is physically unable to buy anything outside those terms, because the terms are enforced throughout execution rather than checked once at the start. This is meaningfully stronger than a network spend limit, which can only see an amount and a merchant category, not a brand, a specific merchant, or an item.

Layer 3: Wallet and credentials

The credential layer answers: what gets charged, and who can see it? Lane supports two models, and most builders end up using both.

• Bring-your-own-card: the user adds their existing card, which is tokenized in Lane's PCI-compliant vault. The agent never sees the card number, and no end-user KYC is required because the user is spending their own money on their own card.
• Lane-issued single-use virtual Visa cards: Lane issues a card scoped to a single purchase. This is live in production pilots, and it is the right model for funded and incentive programs where the platform, not the end user, is paying.

The distinction that matters for product teams is who bears the compliance burden. With bring-your-own-card there is no money-transmitter question to answer, no KYC funnel to build, and no balance to reconcile. The card is the user's, the bank relationship is the user's, and Lane is the infrastructure in between.

Layer 4: Execution

The execution layer answers: did the order actually get placed? This is the layer that is easiest to underestimate and hardest to build. Issuing a card and getting an authorization is not a purchase. A purchase is a confirmed order at a merchant, with a total the user recognizes and a fulfillment path that works.

Lane executes the checkout against the merchant and returns the confirmation. Every step is gate-checked against the approved intent object, so a merchant that raises a price, substitutes an item, or adds an unexpected fee cannot silently push the transaction past what the user agreed to. The product stops recommending purchases and starts completing them.

What does Lane provide at each layer?

What can AI agents actually buy through Lane today?

Lane draws a hard line between what is running in production and what is built and rolling out, because in agentic commerce the gap between a demo and a real transaction is enormous.

• Food delivery, live: agents place real DoorDash orders through Lane in production, including cart construction, fees, tip, and delivery details, all bounded by the approved intent.
• E-commerce, live: agents complete real checkouts on Shopify stores and on Amazon. This is the long tail case, where every merchant's checkout is slightly different and per-merchant integration does not scale.
• Travel, built and rolling out: flights and hotels, where the booking is the product and a recommendation without a booking is a dead end.
• Restaurant reservations, built and rolling out: the concierge case, where the agent holds the table rather than telling the user which number to call.

Where does agentic commerce demand actually go?

In Lane's production traffic, demand is far more concentrated than the market narrative suggests. A handful of merchants, principally DoorDash, Amazon, Uber Eats, and Uber, account for roughly 99% of the agentic commerce demand Lane observes. Lane's data suggests that when a user asks an agent to buy something, they overwhelmingly mean one of a few places they already use every week.

That has two consequences for anyone building. First, breadth of merchant coverage matters less at launch than depth on the handful of destinations users actually name. Second, the constraint has never been demand. Lane watched a viral iMessage agent moment pull more than 500,000 views and convert on exactly one merchant, because the checkout infrastructure to serve the rest did not exist. The intent was there. The rails were not.

“The intelligence to decide what to buy arrived years before the infrastructure to actually buy it.”

How do users approve what an AI agent is about to buy?

Lane's approval model is deliberately modeled on Apple Pay: a scoped prompt showing exactly what is about to happen, confirmed with a biometric or passkey, in under a second of user effort. The user sees the merchant, the line items, and the total, then confirms.

Two properties make this work as product surface rather than friction. It is white-label, so Lane is invisible to end users and the approval renders natively inside the builder's own interface. And there is no redirect: the user is never bounced to a third-party payment page, which is where consumer agent flows historically lose people. Kill the redirect, and approval stops feeling like a handoff and starts feeling like a confirmation.

Who is liable when an AI agent buys something?

This is the question that decides whether a legal team signs off, and the answer depends entirely on whether the authorization context reaches the card networks. With Lane, it does. The consent captured in the intent object and the user's approval carries through to the networks as part of the transaction, so the purchase is a normal, properly authorized card transaction made by the cardholder.

The practical consequence: the user keeps their bank's normal liability protections. If something goes wrong, the dispute and chargeback rights they already have on that card still apply. You are still protected by your bank. That is a very different posture from a stored-value balance or a prepaid instrument, where the user has stepped outside the protections they are used to.

It also improves the picture on the other side of the transaction. Issuers and merchants approving an agent-initiated purchase normally see thin context: an amount, a merchant, and traffic that looks unusual. Intent-level data is richer, because it carries the approved merchant, the items, and the ceiling the user agreed to. Better authorization context is a better fraud signal, and better fraud signals mean legitimate agent purchases are less likely to be declined as anomalies.

How is payment infrastructure different from a virtual card API?

A virtual card API gives an agent a chargeable number. That solves the credential layer and nothing else. It is genuinely useful, and for some use cases, paying for an API subscription or a developer tool, it is all you need.

It stops being enough the moment the purchase involves a consumer merchant. A card number does not know what the user approved, cannot prove the agent is legitimate to a CDN, and cannot fill in a DoorDash checkout. The distance between "the agent has a card" and "the order arrived" is the entire product.

• A card API: issuance and spend controls. Best for machine-to-machine spend where there is no consumer checkout to complete.
• A protocol: a shared vocabulary for agent and merchant to exchange offers and orders. Necessary, but a protocol does not execute anything, and it only works where the merchant has implemented it.
• A PSP: merchant-side acceptance. A PSP serves the merchant taking money, not the agent platform spending it.
• Agentic commerce middleware: the layer that owns identity, consent, credentials, and execution together, and works whether or not the merchant has adopted any protocol.

How do the agentic commerce protocols fit in?

Three protocol efforts matter in 2026. The Agentic Commerce Protocol (ACP), from OpenAI and Stripe, defines merchant-side agent checkout and is strongest inside the ChatGPT ecosystem. The Universal Commerce Protocol (UCP), from Google and Shopify, covers the discovery and offer side. Visa Intelligent Commerce (VIC) is the network-level framework for agent-initiated payment credentials.

Lane's position is that protocols are complementary, not competitive. Lane is a certified VIC enabler, so Lane builds on Visa's framework rather than around it. A builder integrating Lane once gets translation to the protocols a given merchant supports, and Lane's own execution path for the very large number of merchants that support none of them yet. Protocol adoption is a multi-year process. Users want to order dinner today.

What network certifications should you look for?

Certification is the fastest way to separate infrastructure from a wrapper, because networks do not certify demos. Lane holds credentials worth checking for in any provider you evaluate.

• Certified Visa Intelligent Commerce enabler: Lane has completed Visa's certification for agent-initiated commerce, which means Lane's flows have been reviewed against Visa's requirements rather than self-declared.
• Visa Trusted Agent Protocol (TAP) registry: Lane is registered in Visa's TAP registry alongside Cloudflare, which is the identity side of the same problem: letting merchants recognize a known agent.

On the other network: Mastercard Agent Pay support is in progress, and Lane is expanding across Visa and Mastercard rails. Be skeptical of any provider that presents work in progress as live coverage, and ask specifically which flows are certified rather than which logos appear on the page.

How should you evaluate an agent payment provider?

Most of this market sells the credential layer and lets the buyer discover the execution gap after integration. These five questions surface the difference quickly.

1. 1

   Does it execute, or only issue? Ask for a live purchase at a consumer merchant, end to end, with an order confirmation. Card issuance is a solved commodity. Completing a real checkout is not.

2. 2

   What is the user consent model? Look for a structured, line-item authorization the user approves before execution, enforced during execution. A chat message that says "yes" is not a consent record you can defend later.

3. 3

   Is it certified with the networks? Ask for the specific certification and which rails are live versus in progress.

4. 4

   Is the experience white-label? If the user sees a third-party brand or gets redirected off your surface, it is your conversion rate paying for the integration.

5. 5

   Who carries the regulatory burden? Prepaid balances and stored value can pull you toward money-transmitter obligations and end-user KYC. A bring-your-own-card model on the user's own card avoids that question entirely.

Add one more test if your agent touches consumer merchants: ask what happens when the merchant blocks the request. A provider without an answer to bot detection, one-time passcodes, and sign-in walls has not run the flow at scale, whatever the API docs suggest.

What does a full-stack agent look like once payments are solved?

The pattern Lane sees in the agent platforms it works with is a shift from advisory to transactional. A shopping agent stops producing a list of links and places the order. A concierge agent stops naming three restaurants and holds a table. A travel agent stops building an itinerary and books the flight and the hotel.

The product consequence is that the agent finally has a completion event. That changes retention, because a user who received dinner comes back, and it changes the business model, because a transaction is monetizable in ways a recommendation never was. From prompt to checkout, with nothing in between that requires the user to open a browser tab.

How do you start building with Lane?

1. 1

   Read the docs. Start at docs.getonlane.com for the API surface, the intent object schema, and the approval flow.

2. 2

   Connect the Lane MCP server. If you are building an MCP-based agent, connect to Lane's MCP server and your agent can draft an intent, get it approved, and transact inside the same session.

3. 3

   Add a card the right way. Use bring-your-own-card so the user's existing card is tokenized in Lane's PCI-compliant vault and your agent never touches a card number. Add Lane-issued single-use virtual Visa cards if you are funding purchases yourself.

4. 4

   Wire the approval into your own UI. Render the scoped approval natively so the user confirms with a biometric or passkey without leaving your product.

5. 5

   Try it as a user first. Text +1 (628) 316-5644 and buy something through a live Lane agent. It is the fastest way to understand what your users will experience.

The decision layer of agentic commerce is finished. Agents already know what to buy. What has been missing is the boring, regulated, hard-to-build layer underneath: verified identity, enforceable consent, safe credentials, and execution that actually completes at the merchant. That is the layer Lane builds, so you can add payments to your agent without becoming a payments company.

Status labels in this guide reflect Lane's production state as of July 2026. Live means real user transactions in production. Built and rolling out means the flow exists and is being deployed. Mastercard Agent Pay support is in progress.