# Lane: full article text > 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 file contains the complete text of the 19 articles published at https://getonlane.com/info. Per-article markdown is also available at https://getonlane.com/info/.md. --- # Payment Infrastructure for AI Agents: The Complete Guide (2026) > How AI agents actually pay: identity, intent, credentials, and execution. What each layer does, what Lane provides, and how to evaluate providers in 2026. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide ## Key takeaways - Payment infrastructure for AI agents has four layers: verified agent identity, user intent and consent, wallet and credentials, and checkout execution. Lane provides all four behind one integration. - Lane is the payment infrastructure that lets AI agents transact with any merchant, so a builder can add payments to an agent without becoming a payments company. - Issuing a card is the easy part. The hard part is execution: finishing a real checkout at a real merchant and getting an order confirmation back. - Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Mastercard Agent Pay support is in progress. - Live production traffic today runs through food delivery ordering on DoorDash and e-commerce checkouts on Shopify stores and Amazon. Travel and restaurant reservations are built and rolling out. 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? | Capability | What Lane provides | Status | | --- | --- | --- | | Verified agent identity | Signed requests using HTTP Message Signatures (RFC 9421) with a published Ed25519 key, verified against Cloudflare's Web Bot Auth crawl test | Live | | Intent objects | Structured line-item purchase contracts approved before execution and enforced throughout | Live | | Bring-your-own-card | The user's existing card tokenized in Lane's PCI-compliant vault, no end-user KYC | Live | | Single-use virtual Visa cards | Lane-issued cards scoped to one purchase, for funded and incentive programs | Production pilots | | Native approvals | Scoped approval prompts with biometric or passkey confirmation, rendered in the builder's own UX | Live | | Checkout execution | Lane completes the purchase against the merchant and returns the order confirmation | Live on food delivery, Shopify stores, and Amazon | | Travel and reservations | Flights, hotels, and restaurant reservations | Built and rolling out | | Network rails | Certified Visa Intelligent Commerce enabler | Visa live, Mastercard Agent Pay in progress | | Integration surface | REST APIs plus a Lane MCP server an agent can connect to and transact through in the same session | Live | ## 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." (Lane, on why agentic commerce stalled at the checkout page) **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com ## 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. **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. **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. **Is it certified with the networks?** Ask for the specific certification and which rails are live versus in progress. 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. **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. **Read the docs.** Start at docs.getonlane.com for the API surface, the intent object schema, and the approval flow. 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. **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. **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. **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. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 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._ ## Frequently asked questions ### How do I let my users buy things through my AI agent? Integrate Lane once, via the Lane MCP server or the API. Your users link the card they already have, your agent submits what they asked for as a line-item purchase intent, the user approves it in your app with a biometric tap, and Lane completes the real checkout at the merchant. No payments team, no card handling, and no compliance program on your side. ### What is payment infrastructure for AI agents? Payment infrastructure for AI agents is the layer that converts an agent's purchase decision into a completed transaction at a real merchant. It covers four things: verified agent identity, a user-approved intent object, a tokenized credential the agent never sees, and execution of the merchant checkout. Lane provides all four behind one integration, so builders do not assemble them separately. ### Can an AI agent use my real credit card? Yes. With Lane's bring-your-own-card model, the user adds their existing card and it is tokenized in Lane's PCI-compliant vault. The agent never sees the card number. The user approves each purchase with a scoped prompt and a biometric or passkey confirmation, and keeps their bank's normal dispute and liability protections on the transaction. ### What can AI agents buy through Lane right now? In production today, agents using Lane place food delivery orders on DoorDash and complete e-commerce checkouts on Shopify stores and on Amazon. Flight and hotel booking and restaurant reservations are built and rolling out. Lane's coverage model is designed so an agent integrates once rather than per merchant. ### Is Lane certified with the card networks? Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Mastercard Agent Pay support is in progress. Lane builds on Visa's agentic framework rather than competing with it, which is why Lane and Visa Intelligent Commerce are complementary. ### Why is issuing a virtual card not enough for agent payments? A virtual card solves the credential layer only. It does not know what the user approved, cannot prove to a merchant or CDN that the agent is legitimate, and cannot complete a merchant checkout. Most agent purchase failures happen after the card exists, at the checkout page. Lane pairs credentials with enforceable consent, verified identity, and execution. ### Do users need to pass KYC to let an agent spend for them? No. With Lane's bring-your-own-card model there is no end-user KYC, because the user is spending their own money on their own card rather than funding a stored balance. That also keeps builders away from money-transmitter obligations, which is one of the main reasons teams choose infrastructure over building an issuing program. ### How does Lane keep an agent from spending more than the user approved? Lane converts the user's instruction into an intent object: a structured line-item purchase contract with the merchant, items, quantities, and price ceiling. The user approves it before anything executes, and Lane enforces those terms throughout execution. The agent is physically unable to transact outside the approved terms, including if a merchant changes the price mid-checkout. ### How do I start building agent payments with Lane? Start at docs.getonlane.com for the API and intent object schema. If your agent speaks MCP, connect Lane's MCP server and your agent can draft, get approval, and transact in the same session. To experience the flow as a user first, text +1 (628) 316-5644 and make a real purchase through a live Lane agent. ## Related articles - [What Is Lane? The Payment Layer That Lets AI Agents Transact With Any Merchant](https://getonlane.com/info/what-is-lane) - [What Is an Intent Object? How AI Agents Get Authorization to Spend](https://getonlane.com/info/what-is-an-intent-object) - [The 12 Best Payment Platforms for AI Agents (2026), Compared](https://getonlane.com/info/best-payment-infrastructure-for-ai-agents) - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) --- # What Is Lane? The Payment Layer That Lets AI Agents Transact With Any Merchant > Lane is payment infrastructure for AI agents. What it does, who builds on it, what it replaces, and what is live in production today. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/what-is-lane ## Key takeaways - Lane is payment infrastructure for AI agents: one integration that lets an agent complete real purchases at real merchants with the user's own card. - Lane is built for companies building shopping, concierge, travel, and search agents, not for merchants collecting payments. - Lane replaces the alternative of building an issuing program, a PCI vault, a consent model, and a per-merchant integration for every store. - Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. - Live in production: food delivery ordering on DoorDash, e-commerce checkouts on Shopify stores and Amazon. Travel and reservations are built and rolling out. Lane is a payment infrastructure company for AI agents. When an agent decides to buy something, Lane is what turns that decision into a completed order: it captures what the user approved, holds a chargeable credential the agent never sees, proves the agent is legitimate to the merchant, and executes the checkout. Builders integrate Lane once instead of integrating merchants one at a time. 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. ## What does Lane actually do? Lane sits between an agent platform and the merchants its users want to buy from. Four things happen inside Lane on every purchase. - **Turns a prompt into an intent object:** the user's instruction becomes a structured, line-item purchase contract naming the merchant, items, quantities, and price ceiling. - **Gets explicit user approval:** the user confirms with a scoped, Apple Pay style prompt and a biometric or passkey, rendered natively inside the builder's own product. - **Supplies the payment credential:** the user's existing card is tokenized in Lane's PCI-compliant vault, or Lane issues a single-use virtual Visa card. Either way the agent never sees a card number. - **Executes the checkout:** Lane completes the purchase against the merchant and returns the order confirmation, enforcing the approved terms throughout. > The app that recommended dinner now orders it. ## Who is Lane for? Lane is built for the company building the agent, not the merchant accepting the payment. If your product decides what to buy on a user's behalf, Lane is the layer that makes the buying part work. - **Shopping agents:** products that research and select items, and need to complete the purchase instead of handing the user a link. - **Concierge and assistant agents:** agents that order dinner, hold a table, or run errands inside a chat surface such as iMessage or a native app. - **Travel agents:** products that build itineraries and need to actually book the flight, the hotel, and the restaurant. - **Search and discovery products:** answer engines that want a transaction at the end of a query rather than an outbound click. Lane is not a merchant payment processor. If you are a store trying to accept money from customers, Lane is not the right tool. Lane serves the spending side of an agent transaction. ## What does Lane replace? The honest comparison is not against another vendor. It is against building the stack yourself, which is the path most teams start down before they understand its length. | Build it yourself | With Lane | | --- | --- | | Stand up an issuing program and negotiate a card program | Bring-your-own-card on the user's existing card, or Lane-issued single-use virtual Visa cards | | Achieve and maintain PCI scope for card data | Cards tokenized in Lane's PCI-compliant vault, agent never sees a number | | Design a consent and authorization record from scratch | Intent objects: line-item purchase contracts approved before execution | | Integrate each merchant, then maintain each integration | One integration, then Lane executes across merchants | | Solve being blocked as unidentified automated traffic | Lane operates as a known, cryptographically verified agent | | Answer money-transmitter and end-user KYC questions | No stored balance and no end-user KYC in the bring-your-own-card model | Lane's pitch to engineering leaders is compression: add payments to your agent without becoming a payments company. The work does not disappear, but it stops being yours. ## What proof does Lane have that this works? Two categories of proof matter when evaluating infrastructure: production transactions and network certification. Lane has both. - **Live production transactions:** food delivery ordering on DoorDash and e-commerce checkouts on Shopify stores and Amazon, running with real users today. - **Built and rolling out:** flight and hotel booking and restaurant reservations. - **Visa certification:** Lane is a certified Visa Intelligent Commerce enabler. Mastercard Agent Pay support is in progress. - **Verified agent identity:** Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with a published Ed25519 key. ## Is Lane visible to end users? No. Lane is white-label by design. There is no Lane-branded screen, no third-party checkout page, and no redirect out of the builder's product. The approval prompt renders natively in the builder's own interface, so the user experiences it as a feature of the agent they are already using. That matters for more than aesthetics. Redirects are where consumer agent flows lose users, and a third-party brand appearing at the moment of payment reintroduces exactly the hesitation the agent was supposed to remove. Kill the redirect, and payment becomes part of the conversation. ## Does the user stay protected? Yes. Because the purchase runs on the user's own card, and because the authorization information from the approved intent carries to the card networks, the transaction is a normal authorized card purchase. The user keeps their bank's standard dispute and chargeback protections. You are still protected by your bank. ## How do you try Lane? 1. **Experience it as a user.** Text +1 (628) 316-5644 and ask a live Lane agent to buy something. This is a real purchase flow, not a simulation. 2. **Read the docs.** Go to docs.getonlane.com for the API surface, the intent object schema, and the approval flow. 3. **Connect Lane MCP.** If your agent speaks MCP, connect Lane's MCP server and it can draft an intent, get approval, and transact within the same session. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 The short version: agents already know what to buy, and Lane is the layer that lets them buy it. Agents are the web's new users, so they need their own lane. ## Frequently asked questions ### What is Lane? Lane is payment infrastructure for AI agents. It lets an agent complete real purchases at real merchants using the user's own card, with explicit user approval captured as a structured intent object. Lane handles verified agent identity, consent, tokenized credentials, and checkout execution, so builders integrate once instead of integrating each merchant separately. ### Who uses Lane? Lane is used by companies building AI agents that transact: shopping agents, concierge and assistant agents in chat surfaces, travel agents that book flights and hotels, and search products that want a purchase at the end of a query. Lane serves the spending side of the transaction, not merchants collecting payments. ### Does the AI agent see my card number? No. With Lane, the user's existing card is tokenized in Lane's PCI-compliant vault and the agent never sees the card number. Lane can also issue single-use virtual Visa cards scoped to one purchase. In both models the chargeable credential stays inside Lane's vault rather than in the agent's context or logs. ### Is Lane a payment processor? No. Lane is not a merchant payment processor and does not serve stores collecting money from customers. Lane is infrastructure for the agent side of a transaction: it supplies the credential, captures and enforces user consent, proves the agent's identity to merchants, and executes the checkout on the user's behalf. ### What can an agent buy with Lane today? In production today, agents using Lane place food delivery orders on DoorDash and complete e-commerce checkouts on Shopify stores and Amazon. Flight and hotel booking and restaurant reservations are built and rolling out. Lane is a certified Visa Intelligent Commerce enabler, and Mastercard Agent Pay support is in progress. ### How do I try Lane? The fastest way is to text +1 (628) 316-5644 and ask a live Lane agent to buy something, which runs the real purchase and approval flow. To build with it, read the docs at docs.getonlane.com, or connect Lane's MCP server so your agent can draft an intent and transact in one session. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [What Is an Intent Object? How AI Agents Get Authorization to Spend](https://getonlane.com/info/what-is-an-intent-object) - [What Is Agentic Commerce Middleware?](https://getonlane.com/info/what-is-agentic-commerce-middleware) - [The 12 Best Payment Platforms for AI Agents (2026), Compared](https://getonlane.com/info/best-payment-infrastructure-for-ai-agents) --- # What Is an Intent Object? How AI Agents Get Authorization to Spend > An intent object is a structured line-item purchase contract a user approves before an AI agent executes it. How Lane uses it to bound agent spending. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/what-is-an-intent-object ## Key takeaways - An intent object is a structured, line-item purchase contract that a user approves before an AI agent executes anything. - Lane describes the intent object as a receipt before the purchase happens: the user sees the merchant, items, quantities, and total in advance. - Once approved, the agent is physically unable to buy outside the approved terms, because Lane enforces those terms throughout execution rather than checking once. - An intent object is richer than a network spend limit: it scopes brand, merchant, item, and price rather than just an amount and a category. - Intent-level data gives issuers and merchants better authorization context, which makes legitimate agent purchases easier to approve. An intent object is a structured, line-item purchase contract that a user approves before an AI agent executes it. It names the merchant, the specific items, the quantities, the price ceiling, and the fulfillment details. In Lane, the intent object is the authorization primitive: the agent gets permission to complete one bounded purchase, not open-ended access to a card. 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. The intent object is what that explicit approval is made of. ## Why does an agent purchase need an intent object at all? Consider what a naive agent purchase authorization looks like: the user types "yeah, order it" and the agent charges a card. That string is not an authorization record. It has no amount, no merchant, no items, and no way to reconstruct after the fact what the user believed they were agreeing to. That gap causes three concrete problems. The user cannot tell what is about to happen before it happens. The builder cannot prove what was approved when a dispute arrives. And nothing constrains the agent if the merchant's page turns out to cost more, contain a different item, or add fees. The intent object closes all three by making the approval a structured object rather than a conversational turn. ## What is inside an intent object? The exact schema lives in Lane's docs, but conceptually an intent object carries the answers to every question a user would want answered before saying yes. | Field | What it pins down | | --- | --- | | Merchant | The specific store the purchase will happen at, not a category | | Line items | Each product, by name and variant, so a substitution is visible | | Quantities | How many of each, so an agent cannot escalate volume | | Price ceiling | The maximum total the user is agreeing to, including fees | | Fulfillment | Delivery or pickup details, address, and timing where relevant | | Scope and expiry | How long the authorization is valid and what it covers | > The intent object is a receipt before the purchase happens. That framing is the point. A receipt is the artifact users already trust to describe a transaction precisely. An intent object is the same artifact, presented before money moves, at the moment the user can still say no. ## How does approval work in practice? 1. **The user expresses intent.** Someone asks the agent to order dinner, buy a specific item, or book a table. 2. **Lane drafts the intent object.** The prompt becomes a structured contract with the merchant, items, quantities, and ceiling resolved to concrete values. 3. **The user approves it.** A scoped prompt shows exactly what will happen, confirmed with a biometric or passkey, in the style of an Apple Pay double-click. It renders natively in the builder's own product with no redirect. 4. **Lane executes within the terms.** Lane completes the purchase against the merchant, checking every step against the approved intent. 5. **The purchase confirms or stops.** If reality diverges from the approved terms, execution stops rather than proceeding on the user's card. ## What stops an agent from spending outside the approved terms? Enforcement, not trust. This is the distinction that matters most about how Lane uses intent objects: the approved terms are enforced throughout execution, not validated once at the beginning and then assumed. The agent is physically unable to buy anything outside the approved terms. The practical cases this covers are the ones that actually occur. A merchant raises the price between selection and checkout. The store substitutes an unavailable item. A fee, a surcharge, or a tip default pushes the total above what the user saw. In each case the transaction is stopped or returned for a fresh approval rather than silently completed at a number the user never agreed to. _This is why Lane treats intent as an object rather than a prompt. Prompts are instructions an agent can reinterpret. Objects are constraints the infrastructure applies._ The enforcement also reaches below the agent. The payment credential Lane mints for an approved intent carries the approved ceiling at the card network level, so even an agent that somehow went rogue could not spend past it. The limit is a property of the credential itself, not a check the agent is trusted to run. ## How is an intent object different from a card spend limit? Spend controls on a card are real, useful, and far too coarse for consumer purchases. A network-level control can see an amount, a merchant category, and sometimes a merchant identifier. It cannot see what is in the cart. - **A spend limit sees an amount:** it can block a charge over $80. It cannot tell whether that $80 bought the item the user asked for. - **A spend limit sees a category:** it can allow restaurants. It cannot restrict the purchase to one specific restaurant the user named. - **An intent object sees the brand and the merchant:** approval is scoped to the actual store, so an agent cannot redirect the same budget somewhere else. - **An intent object sees the item:** approval is scoped to specific products and quantities, which is the level users actually reason about. - **An intent object sees the price as a ceiling on a known basket:** not a standalone number, which is what makes a substitution or a surcharge detectable. The two are complementary rather than competing. A card control is a blunt outer boundary. An intent object is the specific, per-purchase contract inside it, and it is the layer that maps to what a user thinks they authorized. ## Why do issuers and merchants benefit from intent-level data? Agent-initiated purchases are hard to approve because they look anomalous. The device is unfamiliar, the pattern is unusual, and the context an issuer receives is thin: an amount, a merchant, and a timestamp. Faced with thin context and unusual signals, the risk-minimizing decision is to decline. Intent-level data changes the input. When authorization information from an approved intent object carries into the transaction, the decision is being made with the approved merchant, the approved basket, and the approved ceiling attached, plus the fact that a specific human confirmed it with a biometric or passkey. Richer context is a better fraud signal in both directions: genuine agent purchases become easier to distinguish from card testing, and the transaction stops looking like an anomaly worth declining. For the user, this is also the mechanism behind liability. Because the consent trail reaches the card networks, an agent purchase made through Lane is a properly authorized cardholder transaction, and the user keeps their bank's normal dispute protections. You are still protected by your bank. ## Where does the intent object fit in Lane's stack? Lane's infrastructure has four layers: verified agent identity, intent and consent, wallet and credentials, and execution. The intent object is the second layer, and it is the one the other three defer to. Identity establishes that the agent is accountable. Credentials make the purchase chargeable without exposing a card number. Execution completes the checkout. All of it is bounded by what the intent object says the user approved. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com The reason Lane leads with the intent object rather than the card is that the credential was never the hard part of agent payments. Knowing precisely what a human authorized, and being able to enforce it while software acts on their behalf, is the part that makes agent spending safe enough to ship. ## Frequently asked questions ### What is an intent object in agentic commerce? An intent object is a structured, line-item purchase contract that a user approves before an AI agent executes it. It specifies the merchant, items, quantities, price ceiling, and fulfillment details. In Lane, the intent object is the authorization primitive: the agent gets permission for one bounded purchase rather than open-ended access to a payment credential. ### How does an intent object stop an agent from overspending? Lane enforces the approved terms throughout execution rather than checking them once. If the merchant raises the price, substitutes an item, or adds an unexpected fee, execution stops instead of completing at a total the user never approved. The agent is physically unable to transact outside the terms captured in the approved intent object. ### Is an intent object the same as a card spending limit? No. A card spending limit sees an amount and a merchant category. An intent object scopes the purchase by brand, specific merchant, individual line items, quantities, and a ceiling on a known basket. Lane treats the two as complementary: the card control is a blunt outer boundary, and the intent object is the per-purchase contract inside it. ### Why is the intent object called a receipt before the purchase happens? Because it contains the same precise detail a receipt does, presented before money moves. Lane shows the user the merchant, the line items, and the total at the moment they can still decline. That framing makes agent spending legible: the user is approving a specific transaction, not granting an agent general permission to spend. ### Do intent objects help transactions get approved? They improve the authorization context. Agent purchases often look anomalous to issuers because the available context is thin. When authorization information from an approved intent object carries into the transaction, along with the user's biometric or passkey confirmation, issuers and merchants have a richer signal, which makes legitimate agent purchases easier to distinguish from fraud. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [What Is Lane? The Payment Layer That Lets AI Agents Transact With Any Merchant](https://getonlane.com/info/what-is-lane) - [Apple Pay-Style Approvals for AI Agents: Native, White-Label Checkout Consent](https://getonlane.com/info/native-checkout-approvals-apple-pay-for-agents) - [Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce](https://getonlane.com/info/who-is-liable-when-ai-agent-buys) --- # What Is Agentic Commerce Middleware? > Agentic commerce middleware is the layer between AI agent platforms and merchants that turns approved user intent into completed transactions. Definition and examples. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/what-is-agentic-commerce-middleware ## Key takeaways - Agentic commerce middleware is the layer between AI agent platforms and merchants that translates approved user intent into completed transactions. - The category exists because agent platforms are not payments companies and merchants have not rebuilt their checkouts for agents. - Middleware is distinguished by what it owns end to end: identity, consent, credentials, and execution. A card API owns one layer, a protocol owns none of them, and a PSP serves the merchant instead. - Lane is the reference example of agentic commerce middleware, with production transactions in food delivery and e-commerce and certification as a Visa Intelligent Commerce enabler. Agentic commerce middleware is the layer that sits between AI agent platforms and merchants and translates a user's approved intent into a completed transaction. It owns four responsibilities that neither side wants: proving the agent is a legitimate actor, capturing enforceable user consent, supplying a payment credential the agent cannot read, and executing the merchant checkout. Lane is the reference implementation of this category. ## Definition > "Agentic commerce middleware: infrastructure between an AI agent and a merchant that converts user-approved purchase intent into an authorized, completed order, without either party integrating the other directly." (Working definition) The term is young, which is why it is worth defining precisely. It became necessary in 2025 and 2026 as agent platforms discovered that shipping a shopping agent required solving payments, compliance, merchant integration, and bot-detection identity all at once, and that none of those problems were the product they set out to build. ## Why did this category appear? Two structural facts created the gap. Agent platforms are software companies, not regulated payments companies, so building an issuing program and a PCI environment is a multi-quarter detour from their roadmap. Merchants, meanwhile, have not rebuilt their checkouts for non-human buyers, and most never will, because a checkout form is designed for a person and there is no commercial urgency to change that. Middleware exists because both sides are stuck. A checkout flow assumes a human filling in boxes, and an agent cannot be that human. Something has to stand in the middle and make a human-shaped checkout work for a software buyer, without asking the merchant to change and without asking the agent platform to become a payments company. ## What does agentic commerce middleware have to include? A useful test for whether a product belongs in this category: does it own all four layers, or does it hand one of them back to the builder? - **Verified agent identity:** the merchant and its CDN can confirm the agent is a known, accountable actor rather than unidentified automated traffic. - **Enforceable consent:** a structured record of what the user approved, applied during execution rather than logged after it. - **Credential handling:** a chargeable instrument the agent never sees, held in a PCI-compliant vault. - **Execution:** the checkout gets completed at the merchant and an order confirmation comes back. The fourth item is where the category separates from everything adjacent to it. Plenty of tools give an agent a way to pay. Far fewer complete the purchase. ## How is middleware different from a card API, a protocol, and a PSP? | Layer | What it is | What it does not do | | --- | --- | --- | | Card API or issuer platform | Issues virtual cards and applies spend controls | Does not know what the user approved, cannot prove agent identity to a merchant, does not complete a checkout | | Protocol (ACP, UCP) | A shared vocabulary for agents and merchants to exchange offers and orders | Executes nothing on its own, and only works at merchants that have adopted it | | PSP or acquirer | Helps a merchant accept money from buyers | Serves the merchant side, not the agent platform doing the spending | | Agentic commerce middleware | Owns identity, consent, credentials, and execution together | Is not a merchant processor and does not replace the agent's own reasoning | Protocols and middleware are complementary rather than rival. Middleware can speak whichever protocol a given merchant supports and fall back to its own execution path everywhere else, which is most places, because protocol adoption is a multi-year process and users want to order dinner today. ## Who buys agentic commerce middleware? The buyer is almost always the team building the agent: shopping and concierge products, travel agents, assistant apps inside chat surfaces, and search products that want a transaction at the end of a query instead of an outbound link. The internal framing is usually some version of adding payments to an agent without becoming a payments company. ## What is an example of agentic commerce middleware? Lane is the clearest current example of the category. 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. Mapped against the four-layer test: Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with a published Ed25519 key and is registered in Visa's Trusted Agent Protocol registry, which covers identity. Lane's intent objects are line-item purchase contracts approved before execution and enforced throughout, which covers consent. The user's card is tokenized in Lane's PCI-compliant vault, or Lane issues a single-use virtual Visa card, which covers credentials. And Lane completes the purchase against the merchant, which covers execution: live today on DoorDash food delivery and on Shopify and Amazon checkouts, with travel and restaurant reservations built and rolling out. Lane is also a certified Visa Intelligent Commerce enabler, with Mastercard Agent Pay support in progress. Certification is a reasonable test of whether a middleware provider is infrastructure or a wrapper, because networks do not certify demos. **Talk to the Lane team.** Building a consumer agent, concierge, or commerce experience? Walk us through it and we will map the integration with you. Book a demo: https://getonlane.com/contact If the category name feels premature, it is worth remembering that payment gateways were once an awkward new term for an obvious missing layer. The web's newest users are agents, and middleware is the road being built for them. ## Frequently asked questions ### What is agentic commerce middleware? Agentic commerce middleware is infrastructure between AI agent platforms and merchants that turns a user's approved purchase intent into a completed order. It owns verified agent identity, enforceable consent, payment credentials the agent never sees, and execution of the merchant checkout. Lane is the reference example, with live production transactions in food delivery and e-commerce. ### How is agentic commerce middleware different from a virtual card API? A virtual card API issues a chargeable number and applies spend controls, which is one layer. Middleware also carries the user's approved intent, proves the agent's identity to merchants and CDNs, and completes the checkout. Most agent purchase failures happen after a card exists, at the merchant's checkout page, which is the layer middleware exists to own. ### Is agentic commerce middleware the same as a protocol like ACP or UCP? No. Protocols such as the Agentic Commerce Protocol and the Universal Commerce Protocol define how agents and merchants exchange offers and orders. They do not execute transactions, and they only apply at merchants that have adopted them. Middleware such as Lane speaks the protocols where they exist and executes directly everywhere else. ### Why do agent platforms use middleware instead of building payments themselves? Because the build is a regulated multi-quarter project: an issuing program, PCI scope, a consent and authorization model, per-merchant integration, and an answer for being blocked as unidentified traffic. Middleware such as Lane compresses that into one integration, which is why teams describe it as adding payments to an agent without becoming a payments company. ### Does middleware replace the merchant's payment processor? No. A payment service provider serves the merchant accepting money. Agentic commerce middleware serves the agent side that is spending it, supplying the credential, the consent record, the verified identity, and the execution. Both exist in the same transaction, and the merchant keeps whatever processor it already uses. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [What Is Lane? The Payment Layer That Lets AI Agents Transact With Any Merchant](https://getonlane.com/info/what-is-lane) - [The 12 Best Payment Platforms for AI Agents (2026), Compared](https://getonlane.com/info/best-payment-infrastructure-for-ai-agents) - [ACP vs. UCP vs. Visa Intelligent Commerce: Agentic Commerce Protocols Explained](https://getonlane.com/info/acp-ucp-visa-intelligent-commerce-explained) --- # The 12 Best Payment Platforms for AI Agents (2026), Compared > A practical comparison of agent payment platforms in 2026: Lane, Stripe ACP and Link, Visa Intelligent Commerce, Crossmint, AgentCard, Nevermined, Coinbase, Privacy.com, Skyfire, Payman, and Nekuda. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/best-payment-infrastructure-for-ai-agents ## Key takeaways - Lane ranks first for agent platforms that need real purchases completed at real merchants, because Lane owns execution and not just card issuance. - Most tools in this market solve one layer. Card APIs issue credentials, protocols define vocabulary, and identity networks handle authentication. Very few complete a checkout. - Visa Intelligent Commerce is complementary rather than competitive: Lane is a certified enabler of it and builds on Visa's framework. - Choose by use case. Consumer merchant checkout points to Lane, crypto settlement to Crossmint or Coinbase, service monetization to Nevermined, machine-to-machine API payments to Skyfire, agent payouts to Payman. - Stripe Link and consumer virtual cards are the two most common default assumptions, and both solve payment capture rather than agent execution. - The five questions that separate these platforms: does it execute, what is the consent model, is it network certified, is it white-label, and who carries the regulatory burden. The best payment platform for an AI agent depends on what your agent buys. For agents making real purchases at consumer merchants, Lane ranks first because it owns the whole path from user approval to completed order. For crypto settlement, machine-to-machine API spend, or agent payouts to humans, other platforms on this list are the better fit. This comparison gives the honest split. 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. That is the benchmark the rest of this list is measured against, and where a different tool fits a use case better, this article says so. ## What should you look for in an AI agent payment platform? Almost every platform in this category can hand an agent something chargeable. The differences that decide whether your product ships are further down the stack. Five questions surface them fast. 1. **Does it execute, or only issue?** Issuance is a commodity. Completing a checkout at a merchant that was never designed for a software buyer is not. Ask for a live end-to-end purchase with an order confirmation, at a merchant you name. 2. **What is the user consent model?** Look for a structured, line-item authorization the user approves before execution and that is enforced during execution. A chat message that says "yes, buy it" is not something you can defend in a dispute. 3. **Is it certified with the card networks?** Ask which certifications exist and specifically which rails are live versus in progress. Networks do not certify demos. 4. **Is the experience white-label?** If the user gets redirected to a third-party page or sees another brand at the moment of payment, your conversion rate pays for the integration. 5. **Who carries the regulatory burden?** Stored-value balances and prepaid funding can pull you toward money-transmitter obligations and end-user KYC. A model that charges the user's own existing card avoids that question entirely. > The gap between "the agent has a card" and "the order arrived" is the entire product. ## 1. Lane Lane is payment infrastructure for AI agents, built for the platform doing the spending rather than the merchant collecting it. It is first on this list because it is the only option here that owns all four layers of an agent purchase: verified identity, user consent, credentials, and execution at the merchant. ### What Lane does Lane turns a user's prompt into an intent object: a structured, line-item purchase contract naming the merchant, items, quantities, and price ceiling. The user approves it with a scoped prompt and a biometric or passkey confirmation, in the style of the Apple Pay double-click, rendered natively inside the builder's own product with no redirect. Lane then executes the checkout against the merchant and returns the order confirmation, enforcing the approved terms throughout. On the credential side, Lane supports bring-your-own-card, where the user's existing card is tokenized in Lane's PCI-compliant vault and the agent never sees the card number, with no end-user KYC required. Lane also issues single-use virtual Visa cards, live in production pilots, which is the right model for funded and incentive programs where the platform is paying rather than the user. On identity, Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with an Ed25519 key published in a self-hosted key directory, verified against Cloudflare's Web Bot Auth crawl test. Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, so merchants and CDNs can cryptographically verify that Lane's agent is a known, accountable actor. ### Best for Companies building shopping, concierge, travel, and search agents that need to complete real purchases at consumer merchants: food delivery, e-commerce, flights and hotels, and restaurant reservations. In short, teams that want to add payments to their agent without becoming a payments company. ### Strengths - **Execution, not just issuance:** Lane completes the purchase at the merchant. Live in production today on DoorDash food delivery ordering and on e-commerce checkouts at Shopify stores and Amazon, with travel and restaurant reservations built and rolling out. - **Enforceable consent:** the intent object is a receipt before the purchase happens, and the agent is physically unable to buy outside the approved terms, including when a merchant changes the price or substitutes an item mid-checkout. - **Network certified:** Lane is a certified Visa Intelligent Commerce enabler. Mastercard Agent Pay support is in progress as Lane expands across Visa and Mastercard rails. - **Verified agent identity:** signed requests plus TAP registration mean Lane operates as a known verified agent rather than unidentified automated traffic. - **Genuinely white-label:** Lane is invisible to end users, with no redirects and approvals rendering natively in the builder's own UX. - **No money-transmitter burden:** bring-your-own-card means no stored balance, no end-user KYC funnel, and the user keeps their bank's normal dispute and liability protections. - **One integration, many merchants:** coverage does not require a per-merchant deal, which matters because most merchants have not implemented any agent protocol and many never will. - **Fast to adopt:** REST APIs plus a Lane MCP server an agent can connect to and transact through in the same session. ### Considerations - **Agent side only:** Lane serves the platform spending money, not the merchant accepting it. If you are a store looking for a processor, Lane is the wrong layer. - **Card rails, not crypto:** Lane runs on card networks. Teams that specifically want stablecoin settlement should look at Crossmint. - **Rollout is staged by vertical:** food delivery and e-commerce are live in production, while travel and reservations are built and rolling out. Ask where your vertical sits before you plan a launch date. - **Consumer purchases, not agent-to-agent:** Lane is built for an agent buying on a human's behalf. Machine-to-machine API micropayments are a different problem, better served by Skyfire. ## 2. Stripe ACP (Agentic Commerce Protocol) The Agentic Commerce Protocol is Stripe's agentic commerce effort, developed with OpenAI. It combines a protocol specification for agent-to-merchant checkout with Stripe's payment rails, and it is the dominant approach inside the OpenAI and ChatGPT ecosystem. - **What it does:** defines how an agent and a merchant exchange product, cart, and order information, and settles the payment through Stripe. Merchants implement ACP endpoints, and compliant agents can then transact with them. - **Best for:** merchants who want to be purchasable from ChatGPT, and teams building inside the OpenAI ecosystem where ACP adoption is concentrated. - **Strengths:** enormous distribution, a well-specified protocol, Stripe's operational maturity, and the credibility that comes from OpenAI backing. If your buyers are in ChatGPT, this is where they are. - **Considerations:** ACP only works where the merchant has implemented it, which is a small fraction of the web today. It is oriented toward merchant-side acceptance and merchant-of-record dynamics rather than being an embedded white-label wallet for third-party agent platforms, so an independent agent product still needs its own consent, credential, and execution story for everywhere ACP has not reached. ## 3. Stripe Link Stripe Link is not agent infrastructure, and it earns a place on this list because it is the first thing most builders reach for anyway. Link is Stripe's saved-credential, one-click checkout for returning human buyers, and it is excellent at that job. - **What it does:** stores a consumer's payment details once and lets them pay with one click at any merchant using Stripe, which measurably lifts human checkout conversion. - **Best for:** merchants optimizing human checkout conversion on Stripe rails. If your product has people clicking buy buttons, Link makes that click better. - **Strengths:** ubiquitous, trusted, zero-effort for the buyer, and backed by Stripe's network of saved consumers. - **Considerations:** Link answers payment capture, not agent execution. It cannot sign an agent in to a merchant, build a cart, prove agent identity, or carry a record of what the user authorized an agent to do. The moment the buyer is software instead of a person, Link has no role to play, which is why an agent platform needs a different layer entirely. ## 4. Visa Intelligent Commerce Visa Intelligent Commerce is the card network's framework for agent-initiated payments: a way for agents to obtain and use payment credentials with network-level rules about identity, consent, and tokenization. It belongs on this list, with an important qualification. - **What it does:** establishes network-level standards and credential mechanics for agentic transactions, with certification for the enablers that build on it. - **Best for:** anyone who needs their agent payments to be recognized and properly authorized by the card networks. In practice, that is everyone operating on card rails. - **Strengths:** network-level legitimacy, alignment with issuers, and a real answer to the liability question, because authorization context reaches the networks and the user keeps their bank's protections. - **Considerations:** Visa Intelligent Commerce is a framework, not a product you ship on. It does not build your consent UI, does not complete a merchant checkout, and does not solve being blocked as unidentified traffic. This is why Lane and Visa Intelligent Commerce are complementary rather than competing: Lane is a certified enabler and builds on the framework, so choosing Lane means you get VIC rather than choosing between them. ## 5. Crossmint Crossmint is a broad agentic payments platform with particular depth in crypto and stablecoin settlement, alongside support for a range of agent payment protocols. - **What it does:** provides wallets, payment APIs, and protocol support for agents, with strong capabilities around stablecoin and onchain settlement in addition to fiat paths. - **Best for:** crypto-native builders, agents settling in stablecoins, and teams that want breadth of protocol support in one platform. - **Strengths:** genuine breadth, mature crypto infrastructure, and a good fit for cross-border or programmatic settlement where card rails are awkward. Teams already operating onchain will find the model familiar. - **Considerations:** stablecoin settlement narrows your merchant universe sharply, because the DoorDash or Shopify checkout your user wants still expects a card. Crypto-first models also step outside the consumer dispute and chargeback protections users get from their bank on a card transaction, which changes the trust conversation for a consumer agent. ## 6. AgentCard AgentCard is a virtual card API for AI agents: single-use cards, spend controls, and MCP access so an agent can request a card programmatically. - **What it does:** issues prepaid virtual cards scoped to an agent or a purchase, with balance and limit controls, exposed through an API and an MCP server. - **Best for:** developers who need a card in an agent's hands quickly, especially for paying for APIs, SaaS subscriptions, and developer tools where there is no consumer checkout to negotiate. - **Strengths:** simple, fast, and well-matched to its niche. The MCP surface makes it easy for an agent to request and use a card in the same session, and single-use cards are a real containment mechanism for autonomous spend. - **Considerations:** AgentCard solves the credential layer only. It does not execute checkout, does not manage the merchant interaction, and does not carry a structured record of what the user approved. It also does not solve being blocked at a consumer merchant. If your agent buys from stores rather than from APIs, the card is the beginning of the problem rather than the end. ## 7. Nevermined Nevermined is agent payments infrastructure oriented toward the selling side of agentic commerce: metering, authorizing, and settling payments for AI services and agent-to-agent transactions across fiat, crypto, and credit-based rails. - **What it does:** coordinates authorization, metering, and settlement when agents pay for services or other agents, including facilitation of the x402 payment pattern, with support spanning fiat, stablecoins, and credits. - **Best for:** API providers and AI services that want to charge agents for usage, and agent-to-agent commerce where both counterparties are software. - **Strengths:** a serious answer to monetization and settlement between machines, multi-rail flexibility, and strong visibility in the agent payments conversation. - **Considerations:** Nevermined is built around service monetization and settlement rather than consumer merchant checkout. An agent ordering dinner or booking a hotel still needs a consent surface for the human, a card the merchant accepts, and execution at a checkout that was built for people, which is a different layer than metering machine-to-machine usage. ## 8. Coinbase Agentic Wallets Coinbase's Agentic Wallets give AI agents onchain wallet infrastructure: the ability to hold funds, send payments, and transact on crypto rails programmatically. - **What it does:** wallet infrastructure built for agents, letting software hold balances and transact onchain without a human approving every step. - **Best for:** crypto-native autonomous agents whose counterparties accept onchain payment: trading, onchain services, and stablecoin-denominated flows. - **Strengths:** Coinbase-grade infrastructure and custody credibility, and a genuinely agent-first wallet model on rails where programmatic money movement is native. - **Considerations:** the consumer merchants users actually name, food delivery, retail, travel, expect a card at checkout, not an onchain transfer. Onchain settlement also sits outside the bank dispute and chargeback framework consumers rely on, which changes the trust story for an agent spending a person's money. ## 9. Privacy.com Privacy.com is a consumer virtual card product: individuals create merchant-locked cards with spend limits from their own bank account. Builders sometimes reach for it as a quick way to hand an agent a controlled card. - **What it does:** lets a consumer generate virtual cards locked to a single merchant with per-card spend limits, funded from their own account. - **Best for:** individuals and power users who want personal, self-managed spend control, including for a personal agent they run themselves. - **Strengths:** merchant-locking and hard limits are real containment, the product is mature, and for a single user experimenting with an agent it works today with no integration at all. - **Considerations:** it is a consumer product, not a platform: there is no builder-facing way to provision cards for your users at scale, no consent record tied to a specific purchase, no agent identity, and no execution. Each user manages their own cards by hand, which is exactly the manual step an agent product exists to remove. ## 10. Skyfire Skyfire is an identity and payments network built for agent-to-agent and agent-to-API commerce, where the counterparty is another piece of software rather than a retail merchant. - **What it does:** gives agents verifiable identity plus a payment mechanism for buying access to APIs, data, and services, including at very small transaction sizes. - **Best for:** machine-to-machine micropayments: agents paying for API calls, data feeds, compute, or other agents' services. - **Strengths:** a coherent answer to a real and growing problem. Per-call payments are genuinely awkward on card rails, and pairing identity with payment is the right architecture for a machine counterparty. - **Considerations:** the machine-to-machine model does not transfer to consumer retail. A restaurant, a grocery delivery app, or a hotel is not going to accept a novel agent payment method, and the human user in that flow needs a consent surface and bank-level protections that a machine-to-machine network is not designed to provide. ## 11. Payman Payman handles the opposite direction of flow from most of this list: AI agents paying humans. It is payout infrastructure for agent-initiated disbursements. - **What it does:** lets an agent send money to people, with controls and approval structures around how much can go out and to whom. - **Best for:** agents that compensate humans: paying freelancers, running bounties, distributing rewards, or handling operational payouts under policy. - **Strengths:** a well-chosen and underserved niche. Outbound payments to humans have real controls and compliance requirements, and building them yourself is a serious project. - **Considerations:** payouts are a different problem from purchasing. Payman is not an alternative to a platform that completes a merchant checkout, and a team evaluating both is probably solving two separate problems that happen to share the word payments. ## 12. Nekuda Nekuda is an agent wallet SDK focused on mandate infrastructure: the low-level primitives for expressing and enforcing what an agent is authorized to do with money. - **What it does:** provides wallet and mandate building blocks that a team composes into its own agent payment flow. - **Best for:** engineering teams that want low-level control over the mandate and authorization model rather than a managed end-to-end flow. - **Strengths:** the mandate framing is the right abstraction, and a primitives-first SDK is appealing if you have strong opinions about how authorization should work in your product. - **Considerations:** the platform is early stage, and primitives leave the hard parts with you: merchant execution, agent identity at the CDN layer, network certification, and PCI scope. Expect to build significantly more of the stack yourself than with a managed platform. ## How do these platforms compare side by side? | Platform | Focus | Best for | Consent model | | --- | --- | --- | --- | | Lane | Full stack: identity, consent, credentials, execution | Agents making real purchases at consumer merchants | Intent object: line-item contract approved with biometric or passkey, enforced during execution | | Stripe ACP | Protocol plus merchant-side rails | Being purchasable inside ChatGPT | Protocol-defined, merchant-side | | Stripe Link | Saved-credential human checkout | Human checkout conversion on Stripe merchants | Human one-click, no agent consent record | | Visa Intelligent Commerce | Network-level credential framework | Network-recognized agent payments (Lane is a certified enabler) | Network rules for agent credentials | | Crossmint | Broad agent payments, crypto and stablecoin depth | Crypto-native builders and stablecoin settlement | Wallet and platform controls | | AgentCard | Virtual card issuance | Quick card issuance for APIs and developer tools | Card limits and single-use scoping | | Nevermined | Metering and settlement for AI services | Charging agents for usage, agent-to-agent commerce | Usage authorization and settlement rules | | Coinbase Agentic Wallets | Onchain agent wallets | Crypto-native autonomous agents | Wallet policy, onchain | | Privacy.com | Consumer virtual cards | Individuals managing their own spend-controlled cards | Merchant-locked cards with limits, self-managed | | Skyfire | Agent identity plus machine payments | Agent-to-agent and API micropayments | Identity plus policy at the network | | Payman | Agent payouts to humans | Agent-initiated disbursements | Payout approval policy | | Nekuda | Mandate and wallet primitives | Teams wanting low-level authorization control | Developer-composed mandates | _Statuses reflect public positioning as of July 2026. Categories in this market move quickly, so confirm current capability directly with any provider before committing._ ## What about building it yourself? Every team evaluating this list has already considered the do-it-yourself path, usually as the assumption before the evaluation began. It is worth pricing honestly, because it is the real comparison anchor. - **An issuing program:** select an issuing processor, negotiate the program, and operate it. Months, not weeks, before the first card exists. - **PCI scope:** stand up a compliant environment for card data, or a vault, then keep it compliant. This is a permanent operating cost, not a project. - **A consent and authorization model:** design something a legal team will defend in a dispute, then enforce it in code at every step of execution. - **Per-merchant integration:** build and maintain a path through each merchant's checkout. The maintenance, not the build, is what kills this. - **Agent identity:** find an answer for why your traffic should not be treated as hostile automation by Cloudflare, Akamai, or DataDome. Without a verifiable identity, the safe default is to block you. - **Regulatory posture:** answer the money-transmitter question, and build an end-user KYC funnel if your model needs one. None of it is impossible. All of it is time spent not building your agent. That calculus is why the middleware category exists at all. ## Which platform should you choose? Match the platform to what your agent actually buys, and ignore the rest of the market. - **Your agent buys from consumer merchants:** food, retail, travel, reservations. Choose Lane, which completes the purchase and gives the user a bank-protected card transaction with enforceable consent. - **Your agent needs to be purchasable inside ChatGPT:** implement Stripe ACP, and treat it as distribution rather than as your whole payment stack. - **Your agent settles in stablecoins or operates onchain:** Crossmint or Coinbase Agentic Wallets, with clear eyes about which merchants can accept it. - **You sell services to agents:** Nevermined, for metering and settling what other agents pay you. - **You are one person giving your own agent a card:** Privacy.com works today, and you will outgrow it the day you have users. - **Your agent pays for APIs and tools:** AgentCard for straightforward card issuance, or Skyfire if the counterparties are agents and services rather than checkouts. - **Your agent pays people:** Payman. - **You want to own the authorization model yourself:** Nekuda, budgeting for the layers you will still have to build. One test cuts through the whole comparison. Ask a provider to complete a purchase at a merchant you name, live, and show you the order confirmation. In Lane's production traffic, a handful of merchants including DoorDash, Amazon, Uber Eats, and Uber account for roughly 99% of agentic commerce demand, so name one of those. Lane's data suggests that if a platform cannot transact where users actually shop, breadth elsewhere does not matter much. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com The market for agent payments is fragmenting into layers, and that is healthy: issuance, identity, protocols, and settlement all deserve specialists. The layer that decides whether an agent product works is still execution, because a user does not experience an authorization. They experience dinner arriving. ## Frequently asked questions ### What is the best payment platform for AI agents in 2026? For agents making real purchases at consumer merchants, Lane ranks first, because it owns verified agent identity, user consent through intent objects, tokenized credentials, and execution of the merchant checkout. Other platforms lead in narrower niches: Crossmint for stablecoin settlement, Skyfire for API micropayments, Payman for agent payouts to humans. ### Is Lane a competitor to Visa Intelligent Commerce? No. Visa Intelligent Commerce is a network-level framework for agent-initiated payment credentials, and Lane is a certified enabler of it. Lane is registered in Visa's Trusted Agent Protocol registry. Choosing Lane means building on Visa Intelligent Commerce rather than choosing between the two. ### How is Lane different from Stripe ACP? The Agentic Commerce Protocol defines merchant-side agent checkout and is strongest inside the OpenAI and ChatGPT ecosystem, where the merchant has implemented it. Lane is agent-side infrastructure that works whether or not a merchant supports any protocol: Lane carries the user's approved intent, supplies the credential, and executes the checkout itself. ### Can my AI agent just use Stripe Link to pay? No. Stripe Link is saved-credential checkout for returning human buyers on Stripe merchants, and it is very good at that. It cannot sign an agent in to a merchant, build a cart, prove agent identity, or record what the user authorized the agent to do. Agent purchases need an execution layer like Lane; Link solves a different problem for a different buyer. ### Is a virtual card API enough for an AI agent to buy things? Only if the counterparty is an API rather than a store. A virtual card gives an agent a chargeable number but does not carry what the user approved, cannot prove the agent is legitimate to a merchant or CDN, and cannot complete a checkout form. Most agent purchase failures happen after the card exists. ### What should I ask a vendor when evaluating agent payments? Ask five things: does it complete real checkouts or only issue credentials, what structured consent record does the user approve, which network certifications does it hold and which rails are live versus in progress, is the experience white-label with no redirect, and does the funding model create money-transmitter or end-user KYC obligations for you. ### Do agent payment platforms require my users to pass KYC? It depends on the funding model. Platforms built on stored-value balances or prepaid funding typically do. Lane's bring-your-own-card model does not, because the user spends their own money on their own existing card, tokenized in Lane's PCI-compliant vault. That also keeps builders clear of money-transmitter obligations. ### Can I use more than one of these platforms together? Yes, and many teams do, because they solve different problems. A single product might use Lane for consumer merchant purchases, a machine payments network for API spend, and a payout platform for compensating humans. The mistake is assuming one category substitutes for another because all three are described as payments. ### What is the alternative to using an agent payment platform? Building it yourself: an issuing program, PCI scope for card data, a defensible consent model, per-merchant checkout integrations and their maintenance, an answer for being blocked as unidentified automated traffic, and a regulatory posture on money transmission. It is achievable and it is months of work that is not your agent. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [What Is Lane? The Payment Layer That Lets AI Agents Transact With Any Merchant](https://getonlane.com/info/what-is-lane) - [Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents](https://getonlane.com/info/virtual-cards-vs-payment-infrastructure-for-ai-agents) - [What Is Agentic Commerce Middleware?](https://getonlane.com/info/what-is-agentic-commerce-middleware) --- # Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents > A virtual card tells an AI agent what to pay with, not how the purchase happens. Compare card APIs against full payment infrastructure like Lane. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/virtual-cards-vs-payment-infrastructure-for-ai-agents ## Key takeaways - A virtual card answers "what do I pay with." It does not answer "how does the purchase actually happen," which is where most agent payment projects stall. - A card cannot sign in to a merchant account, fill a checkout, or prove that the requester is a legitimate agent rather than a bot. - High-volume single-use card issuance looks like card testing to merchant risk systems, and cards that pattern-match to fraud get declined at authorization. - A raw card number carries no consent trail, so nothing ties the charge back to the specific purchase the user approved. - Lane bundles the four layers a working agent purchase needs: verified agent identity, an approved intent object, a payment credential, and execution against the merchant. A virtual card answers one question: what does the agent pay with. Lane answers the other one: how the purchase actually happens. Single-use cards alone fail AI agents because a card cannot sign in, cannot complete a merchant checkout, cannot prove who the agent is, and carries no record of what the user approved. Full payment infrastructure adds identity, intent, and execution. 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. Card issuance is one component inside that stack, not a substitute for it. This comparison is written for teams who have already found a virtual card API, wired it up in an afternoon, and then discovered that their agent still cannot buy anything. The card was never the hard part. ## What does a virtual card actually solve? A virtual card API is a genuinely useful primitive, and it is worth being precise about what it delivers. Given an API call, you get a card number, expiry, and security code that can be spent up to a limit, optionally locked to a single transaction or a single merchant. - **Spend control:** a hard ceiling per card means a misbehaving agent cannot spend more than the amount you provisioned. - **Blast radius:** single-use cards mean a leaked number is worthless after one charge, which is a real improvement over handing an agent a corporate card. - **Attribution:** one card per task gives you clean per-task accounting without parsing merchant descriptors. - **Speed to first call:** most card APIs are a single POST, and some ship an MCP server so an agent can request a card conversationally. Those are real benefits. If your agent needs to pay a metered API, top up an ad account, or cover a subscription on a service you already have credentials for, a card API may be the entire solution you need. ## Why do card-only setups break down in production? The failure is not that virtual cards are bad. The failure is that a payment credential is the last five percent of a consumer purchase, and card-only setups leave the other ninety-five percent to the builder. Four specific things go wrong. ### The agent still cannot get through checkout A consumer purchase is not an API call. It is an account, a cart, an address, a delivery window, a tip, a promo field, a shipping method, and a submit button. As Lane's founders put it: a checkout is really a form, and agents don't do forms. Handing an agent a card number does not get it past any of that. The agent still has to sign in to the merchant, and modern sign-in means a one-time code sent to a phone or email the agent does not control. Merchants also deploy bot detection from vendors like Cloudflare, Akamai, and DataDome, plus challenge flows, precisely to stop unidentified software from submitting forms. A card in hand does nothing to change how the merchant classifies the requester. ### High-volume single-use issuance looks like fraud This is the failure mode teams do not anticipate. Merchant risk systems are tuned to detect card testing: many distinct card numbers, short-lived, low dollar amounts, arriving from correlated sources in a compressed window. That is an almost exact description of an agent platform issuing a fresh single-use card for every task. The result is not a clean error message. It is a soft decline at authorization, or a merchant-side risk hold, or an order that looks accepted and then quietly cancels an hour later. The card was valid. The pattern was the problem, and the pattern is a property of the architecture, not of any individual purchase. > A valid card that pattern-matches to card testing is still a declined card. Declines are only half of the failure mode. The other half is step-up: many merchants respond to an unfamiliar card by adding verification, a challenge, a one-time code, an extra confirmation screen. Every step-up reinserts the human into a flow the user delegated precisely so they would not have to be in it. Working infrastructure orchestrates cards the way merchants expect to see them instead. In Lane's funded flows, a merchant keeps a managed card on file that is authorized for an incremental amount per order, rather than being handed a brand-new number every time. The merchant sees a returning customer, not a parade of strangers. ### There is no consent trail A card number is an anonymous bearer credential. It says someone may spend up to this amount. It does not say what the user agreed to buy, at what price, from which merchant, or when they agreed to it. That gap becomes concrete the first time a customer disputes a charge. If the only record is "the agent had a card and used it," the platform has no defensible answer to "I never approved this." Lane closes the gap with an intent object: the user's prompt becomes a structured, line-item purchase contract that the user approves before execution. That approved contract is the record that exists before the charge, and the agent is physically unable to buy anything outside its terms. Because Lane carries authorization information through to the card networks, the user also keeps their bank's normal liability protections. Whatever else happens, they are still protected by their bank. A raw card number handed to an agent gives you none of that structure. ### Funding and identity are still unsolved The last problem is who pays. If your platform issues the card, your platform is funding the purchase and then collecting from the user, which pulls you into flow of funds, refund liability, and working capital you did not plan to provide. Lane's bring-your-own-card model avoids this: the user's existing card is tokenized in Lane's PCI-compliant vault, the agent never sees the card number, and no end-user KYC is required. Identity is the parallel gap. Merchants and CDNs increasingly want to know which agent is knocking. Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with an Ed25519 key published in a self-hosted key directory, verified against Cloudflare's Web Bot Auth crawl test, and Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. A card number carries no identity claim at all. ## What does full payment infrastructure include? Full payment infrastructure for AI agents is four layers, and a working purchase needs all four. Card issuance sits in the third. 1. **Identity.** The merchant can cryptographically verify that the requester is a known, accountable agent rather than an anonymous script. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry. 2. **Intent.** The user's request becomes a structured, line-item contract with merchant, items, price ceiling, and scope, approved before anything executes. Terms are enforced throughout execution, not just checked once at the start. 3. **Wallet.** A payment credential exists and is spendable under those terms. With Lane that is either the user's own tokenized card or a Lane-issued single-use virtual Visa card, which is live in production pilots for funded and incentive programs. 4. **Execution.** Something actually completes the purchase at the merchant: sign-in, cart, checkout, submit, confirmation. Lane executes the checkout and returns a result the agent can relay back to the user. Any vendor that gives you one of these four is solving a real problem. The question is how many of the remaining three you are prepared to build yourself. ## How do card APIs and Lane compare capability by capability? | Capability | Card API alone | Lane | | --- | --- | --- | | Issue a card the agent can spend | Yes | Yes, including single-use virtual Visa cards in production pilots | | Use the user's existing card | No, you fund the card you issue | Yes, tokenized in Lane's PCI-compliant vault with no end-user KYC | | Execute the merchant checkout | No, you build this | Yes, Lane executes the checkout against the merchant | | Verified agent identity to merchants | No | Yes, signed requests plus Visa Trusted Agent Protocol registration | | User consent contract per purchase | No, a spend limit is not consent | Yes, an approved line-item intent object | | Liability and consent trail | No, an anonymous bearer credential | Yes, authorization information carries to the card networks | | White-label approval UX | Varies, often a hosted surface | Yes, approvals render natively in your own product with no redirect | | Time to a working consumer purchase | Weeks to months of per-merchant work | One integration via the Lane MCP server or API | _Rows describe the category, not any single vendor. Some card APIs ship pieces of adjacent layers, and pricing and coverage change quickly in this market._ ## When is a card API alone genuinely enough? Being honest about this matters, because the wrong answer costs teams months either way. A card API is the right and sufficient choice in a specific shape of problem: the destination already accepts a card over an API, the account already exists, and the volume is low enough that issuance patterns do not trip risk systems. - **Machine-to-machine spend:** paying for compute, model inference, data feeds, or metered APIs where checkout is a JSON body, not a form. - **Internal tooling:** an agent operating inside your own accounts, on your own money, with your own staff able to intervene. - **Developer sandboxes:** demos and prototypes where you need a spendable number today and merchant coverage is not the point. - **Existing subscriptions:** topping up or renewing services where the card is already on file and no new checkout happens. AgentCard is a reasonable example of this category done well: a virtual card API for agents with single-use cards and an MCP interface. Best for fast card issuance inside developer tools. It does not execute checkout or manage the merchant interaction, and it does not claim to. The line is consumer merchants. The moment your agent needs to buy from DoorDash, a Shopify store, Amazon, an airline, or a restaurant, you have left the territory a card API covers. ## What does Lane do differently? Lane treats the card as one field in a larger transaction, and owns the transaction. In Lane's model the builder writes the conversation and the product experience, and Lane handles identity, the consent contract, the credential, and the execution. Concretely, that means a user in your product says what they want, your agent submits an intent to Lane, the user sees a scoped approval prompt rendered natively in your own interface and confirms it with a biometric or passkey the same way they confirm Apple Pay, and Lane executes the purchase. Lane is invisible to the end user. There is no redirect, and no third-party brand appears in your flow. This is running in production today for food delivery ordering on DoorDash and for e-commerce checkouts on Shopify stores and Amazon. Travel and restaurant reservations are built and rolling out. Lane is expanding across Visa and Mastercard rails, with Mastercard Agent Pay support in progress. > "An agent with a card on file is an open wallet without control. An agent with no card is a dead end." (Lane) ## What should you ask a vendor before choosing? These five questions separate a card API from payment infrastructure faster than any feature list. Ask them in a demo and watch which layer the answer comes from. 1. **Who completes the checkout?** If the answer is "your agent does," you are buying a credential, not a purchase. 2. **What does the merchant see?** Ask whether the merchant can verify the agent's identity, and what happens when a challenge or one-time code appears. 3. **Where does the money come from?** Clarify whether you are funding purchases and reimbursing yourself, or whether the user's own card is being spent. 4. **What is the record of consent?** A spend limit is not consent. Ask for the artifact that shows what the user approved, item by item, before execution. 5. **Whose brand does the user see?** Ask whether approvals render inside your product or bounce the user to a hosted page. ## Which should you pick? Pick a card API when the destination speaks HTTP and the account is already yours. Pick full payment infrastructure when a human is the beneficiary, a consumer merchant is the counterparty, and the purchase has to survive risk systems, sign-in, and a dispute six weeks later. The two are not really competitors. Lane issues cards too. The difference is that with Lane the card arrives attached to identity, an approved intent, and an execution path, which is what turns a spendable number into a completed order. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com If you already have a virtual card working and your agent still cannot complete a purchase, the missing pieces are identity, intent, and execution. Lane provides all three alongside the card, through one integration. ## Frequently asked questions ### I gave my agent a virtual card and it still cannot complete purchases. Why? Because the card was the easy part. Your agent still cannot sign in to the merchant, resolve the exact product, pass a checkout that challenges unknown automation, or prove your user approved the purchase. Those are execution and identity problems, and they are what Lane provides around the credential: the agent gets a full purchase path, not just a number. ### Can an AI agent just use a virtual card to buy things? Only where the destination accepts a card over an API. For consumer merchants a virtual card is not sufficient: the agent still has to sign in, get past bot detection, and complete a checkout form. Lane supplies the payment credential plus the identity, approved intent, and execution needed to finish the purchase. ### Why do single-use virtual cards get declined at checkout? Merchant risk systems flag high-volume issuance of short-lived cards as card testing, a common fraud pattern. The card itself is valid, but the pattern triggers soft declines or risk holds. Lane avoids this by spending the user's own tokenized card under an approved intent, so the transaction looks like what it is. ### What is the difference between a virtual card API and payment infrastructure for agents? A virtual card API answers what the agent pays with. Payment infrastructure answers how the purchase happens. Lane covers four layers: verified agent identity, an approved line-item intent object, a payment credential, and execution of the merchant checkout. A card API covers only the third. ### Does Lane issue virtual cards? Yes. Lane issues single-use virtual Visa cards, live in production pilots for funded and incentive programs, and also supports bring-your-own-card where the user's existing card is tokenized in Lane's PCI-compliant vault. The difference from a card-only vendor is that Lane also executes the purchase. ### When is a card API the better choice? When your agent is paying for compute, metered APIs, data feeds, or subscriptions where the account already exists and checkout is an API call rather than a form. Card APIs are also fine for internal tooling and prototypes. Lane becomes necessary once a consumer merchant is involved. ### Does a virtual card give my users any dispute protection? Not on its own. A card number is an anonymous bearer credential with no record of what the user approved. Lane attaches an approved intent object to every purchase and carries authorization information to the card networks, so users keep their bank's normal liability protections. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [The 12 Best Payment Platforms for AI Agents (2026), Compared](https://getonlane.com/info/best-payment-infrastructure-for-ai-agents) - [Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC](https://getonlane.com/info/bring-your-own-card-zero-kyc-agent-payments) - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) --- # How to Add Payments to Your AI Agent Without Becoming a Payments Company > Taking user money to repurchase turns your AI agent into a payments company. Lane keeps your platform a pass-through, out of the flow of funds. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/add-payments-to-ai-agent-without-becoming-payments-company ## Key takeaways - Putting Apple Pay in your agent does not solve agent payments: Apple Pay charges the user and pays you, which makes your company the merchant of record for everything the agent buys. - The moment your platform collects user money and repurchases on their behalf, you are in the flow of funds, with the licensing, tax, refund, and working capital consequences that follow. - The three do-it-yourself paths all make you a payments company: becoming merchant of record, running your own issuing program, or building per-merchant integrations. - With Lane your platform is a pass-through: the user's own card is tokenized in Lane's PCI-compliant vault and spent under user-approved intent terms, so the platform never touches funds. - Because the user pays with their own card, they keep their bank's normal liability protections, and your platform is not the party being disputed. - You can add payments to your agent without becoming a payments company, and that decision is easier to make before you have written the ledger than after. You add payments to your AI agent without becoming a payments company by staying out of the flow of funds. Lane makes that possible: the user's own card is tokenized in Lane's PCI-compliant vault and spent under intent terms the user approved, so your platform never collects, holds, or forwards money. You own the product experience; Lane owns the transaction. 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. Nothing in that sentence requires your company to become a regulated money business. ## Why can't I just put up Apple Pay and call it a day? Because Apple Pay answers the wrong question. Apple Pay is a way for a customer to pay a seller, and inside your agent the seller it pays is you. The user double-clicks, the money lands in your account, and now your company has to go buy the sneakers, the dinner, or the flight from the actual merchant. That single step makes you the merchant of record, and everything in the rest of this article follows from it. What builders actually want from "just add Apple Pay" is the experience: a native sheet, a clear amount, one biometric confirmation, done. That experience is separable from the rail underneath it. Lane renders the same double-click-style scoped approval natively in your product, but the credential being spent is the user's own card and the seller on the transaction stays the merchant. You get the Apple Pay moment without becoming the store. ## What does "becoming a payments company" actually mean? It is a gradual drift, not a decision anyone makes deliberately. It usually starts with a reasonable-sounding shortcut: let users load a balance, or charge the user and then buy the item on their behalf. That single choice puts your platform between the user and their money, and the obligations arrive on their own schedule. - **Licensing exposure:** accepting user funds and paying them out to third parties is the shape of activity that money transmission regimes are written to cover, which pulls in state-by-state and jurisdictional analysis. - **Tax and reporting:** if you are the party selling to the user, sales tax nexus, invoicing, and information reporting become yours rather than the merchant's. - **Refund and chargeback liability:** when the charge on the statement says your company name, the dispute lands on you, including for merchant failures you did not cause. - **Working capital:** you front the money between charging the user and settling with the merchant, and that float grows linearly with volume. - **Compliance headcount:** know-your-customer onboarding, sanctions screening, transaction monitoring, and audit obligations require people, not just code. None of this is theoretical for consumer agent platforms. It is the standard consequence of a merchant-of-record architecture, and it is why teams whose product is a great conversational experience end up staffing a compliance function. _This article is engineering and product guidance, not legal advice. Whether a specific model triggers licensing obligations depends on your structure and jurisdictions, and your counsel should make that call._ ## Why does a merchant-of-record model pull you into the funds flow? Merchant of record means your company is the seller on the transaction. The user buys from you, and you buy from the merchant. It is a clean model for reselling your own inventory, and a heavy one for an agent that buys arbitrary things from arbitrary stores. The oldest version of this model is the travel agent. You pay the travel agent, the travel agent buys the American Airlines ticket, and your only relationship is with the travel agent. That is exactly why the taxes, the refunds, and the consumer protection obligations belong to the travel agent and not to you. An AI agent that charges users and repurchases inherits the same position, across every category at once. The mismatch is that agent purchases are unbounded in category. A single consumer agent might order dinner, buy a replacement charger, and book a hotel in one afternoon. As merchant of record you have just become a reseller of restaurant food, consumer electronics, and travel, each with its own tax treatment, refund norms, and consumer protection expectations. Instacart is the clearest picture of what that costs at scale. Instacart is effectively a shopping agent for grocery stores: you interact with Instacart, Instacart buys from the store, and Instacart is the merchant of record. Being in that position is why Instacart has to operate delivery logistics, run live support chat for order changes, and hold the bag when something goes wrong. It works because grocery delivery is Instacart's entire business. It is a strange thing to sign up for as a side effect of adding payments to a chat product. ## What does agentic commerce look like today, and what changes? Agentic commerce is not new. You already use agents: Instacart shops the grocery store for you, DoorDash runs the restaurant errand, Airbnb stands between you and the host. In every case the pattern is the same. You pay the middleman, your only relationship is with the middleman, and the middleman is the merchant of record, holding the money, the liability, and your customer relationship. That was the only architecture available when the agent had to be a company with an app, warehouses of operational staff, and a balance sheet big enough to sit in the middle of every transaction. It is also why there are so few of these companies: each one had to become a payments and operations giant to earn the right to run your errand. The structural change AI agents make possible is that the middleman no longer has to be the merchant. With a pass-through model, the merchant stays the merchant of record and the agent just does the work: the user pays the merchant directly with their own card, under terms they approved, and the agent company never enters the flow of funds. Users get the better end of this trade. Their statement shows the store they actually bought from, their bank protections apply directly, and their relationship, order history, and recourse sit with the real merchant instead of routing through an intermediary. This is the model Lane is built for. Any product can now offer what previously required becoming an Instacart: your app runs the errand, the merchant makes the sale, and nobody had to build a payments company in between. ## What are the three do-it-yourself paths, and what do they cost? Teams adding payments to an AI agent generally consider three builds before they consider infrastructure. Each one works. Each one also converts an engineering roadmap into a payments roadmap. ### Path one: become merchant of record You charge the user, then repurchase from the merchant. This is the fastest path to a demo and the most expensive path to a company. - **What you build:** a ledger, a payments account, refund handling, dispute response, tax determination, and reconciliation between what you charged and what you paid. - **What you inherit:** flow-of-funds status, chargeback liability for merchant failures, sales tax nexus, and float. - **Realistic timeline:** months, and it never fully ends, because every new purchase category adds tax and refund edge cases. The refund loop is worth spelling out, because it is where the model quietly bleeds. When a user wants their money back, you refund them first, since keeping the user is the whole point, and then you chase the merchant for reimbursement on your own time. Add the settlement gap on the way in, where your money leaves at purchase and the user's payment lands in your account days later, and you are financing both ends of every transaction. ### Path two: run your own card issuing program You issue virtual cards and let the agent spend them. This feels lighter than merchant of record, and on the technical side it is. The problem is that the cards have to be funded by someone, and that someone is you. - **What you build:** a funding mechanism, a settlement process to collect from users, and controls that keep an agent from overspending a provisioned card. - **What you inherit:** a payment card compliance program, prefunding requirements, and the collection risk of having spent money before you have been paid. - **What you still do not have:** a way to complete a merchant checkout. A card number does not sign in, pass a challenge, or submit a form. There is a second-order problem worth naming. Issuing a fresh single-use card for every task produces exactly the pattern merchant risk systems classify as card testing: many short-lived numbers, small amounts, correlated timing. Valid cards get declined on pattern alone. ### Path three: build per-merchant integrations You skip payments architecture and integrate merchant by merchant. This produces the best experience per merchant and the worst scaling curve, because each merchant is a separate relationship, a separate API or partnership, and a separate ongoing maintenance burden. In Lane's production traffic, a handful of merchants (DoorDash, Amazon, Uber Eats, Uber) drive roughly 99% of agentic commerce demand, so a short list gets you surprisingly far. The catch is that the short list is exactly the set of merchants least likely to give a small platform a bespoke commerce integration, and the coverage you can actually negotiate is usually the long tail nobody asked for. Lane's data suggests how expensive that ceiling is. A viral iMessage agent moment that drew more than 500,000 views only worked on a single merchant, because the checkout infrastructure to support anything else did not exist. The demand was real and unservable. > Every DIY path ends the same way: you shipped a payments company and shelved your product. ## Hasn't the pay-us-and-we-buy-it model been tried? Yes, publicly, by a company with far more distribution than any startup: Perplexity. Perplexity's shopping experiment let users pay Perplexity, and Perplexity procured the item on their behalf. It was short-lived. That outcome is worth studying, because if the merchant-of-record model struggled with that much traffic behind it, the problem is structural rather than a matter of execution. The structural problems are the ones this article describes. The platform holds the bag on every purchase: it fronts the money, absorbs the refund and friendly-fraud exposure, and operationalizes reimbursement across arbitrary merchants. The float grows linearly with purchase volume, so success makes the balance sheet problem bigger, not smaller. And a promise shaped like "pay us and we can procure anything" has no natural boundary: the same pipes that buy a phone charger are on the hook for a piano. There is one domain where the reseller model genuinely works: travel. Aggregation services have packaged airline and hotel inventory for decades, acting as the merchant so that agencies can sell against a single counterparty. That is why online travel agencies exist and why an AI travel agent can plausibly be a merchant of record for flights. General commerce has no equivalent layer. Outside travel, an agent that wants to be the seller has to onboard merchants one by one, which means it stopped being an agent and became a marketplace. ## How does the pass-through model work with Lane? Lane inverts the arrangement. Instead of money moving through your platform, the user's own card is spent directly, under terms the user approved, and your platform is never a party to the funds movement. 1. **The user links their existing card.** It is tokenized in Lane's PCI-compliant vault. Your agent never sees the card number, and no end-user KYC is required to get started. 2. **Your agent submits an intent.** The user's request becomes a structured, line-item purchase contract: merchant, items, prices, and a ceiling. Nothing can be charged that was not spelled out in that contract. 3. **The user approves it in your UX.** A scoped approval prompt renders natively in your own product and is confirmed with a biometric or passkey, the way Apple Pay is confirmed with a double click. There is no redirect and Lane is invisible. 4. **Lane executes the purchase.** Lane completes the checkout against the merchant as a known, cryptographically verified agent, and the agent is physically unable to buy anything outside the approved terms. 5. **The charge belongs to the user and the merchant.** The user's bank sees a purchase the user authorized. Your platform never collected, held, or forwarded funds. Because authorization information carries through to the card networks, the user keeps their bank's normal liability protections. They are still protected by their bank, and your company is not the counterparty in a dispute about a burrito. ## How do the four options compare? | | Merchant of record | Own issuing program | Per-merchant integrations | Lane | | --- | --- | --- | --- | --- | | In the flow of funds | Yes | Yes, you prefund | Depends on each deal | No, pass-through | | Who is on the statement | Your company | Your program | Varies | The merchant | | Refund and dispute liability | Yours | Largely yours | Shared | Handled by the card networks as normal | | Working capital required | Significant float | Prefunding | Low | None | | Compliance program needed | Yes | Yes | Limited | No, Lane holds the payment compliance surface | | Completes merchant checkout | You build it | No | Per merchant | Yes, Lane executes the checkout | | Merchant coverage | Whatever you build | Whatever you build | Only signed merchants | Any merchant, one integration | | Time to first real purchase | Months | Months | Weeks per merchant | One integration via Lane MCP or API | ## What do you still own? Being a pass-through does not mean giving up the product. The parts users judge you on stay entirely yours, which is the point of the split. - **The conversation:** how your agent understands a request, clarifies it, and recommends. This is your differentiation and Lane never touches it. - **The interface:** approvals render natively in your own UX with your own design. Lane is white-label and invisible to end users. - **The relationship:** the user is your user. Lane does not appear in your funnel, your branding, or your support flow. - **The economics:** you decide whether payments are a free capability, a subscription feature, or a take-rate line, without owning a payments P&L. > "Add payments to your agent without becoming a payments company." (Lane) ## How do you know which model you are in? One question resolves it: if a user asks for their money back, whose bank account does it leave? If the answer is yours, you are in the flow of funds and every consequence in this article applies. If the answer is the merchant's, you are a pass-through. A second useful test is what appears on the card statement. Your company name means you sold something. The merchant's name means the user bought something and your agent helped. ## What does this look like in production? Lane is running real transactions today: food delivery ordering on DoorDash and e-commerce checkouts on Shopify stores and Amazon. Travel and restaurant reservations are built and rolling out. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and is expanding across Visa and Mastercard rails, with Mastercard Agent Pay support in progress. For a builder, the integration surface is deliberately small: connect to the Lane MCP server or the Lane API, submit intents, render approvals in your own UI. The compliance surface that would otherwise land on your roadmap stays with Lane. **Talk to the Lane team.** Building a consumer agent, concierge, or commerce experience? Walk us through it and we will map the integration with you. Book a demo: https://getonlane.com/contact The decision is cheapest to make early. Before you write the first ledger table, decide whether your company is going to be a payments company, and if the answer is no, keep your platform out of the flow of funds from day one. ## Frequently asked questions ### How is an AI agent different from Instacart or DoorDash? Instacart and DoorDash are agents that also became the merchant of record: you pay them, they buy from the store, and they hold the money, the liability, and your relationship. An AI agent on a pass-through model like Lane's does the same errand without sitting in the middle: the user pays the merchant directly with their own card, keeps their bank protections, and the agent company never touches funds. ### Can I just use Apple Pay in my AI agent? Apple Pay inside your agent charges the user and pays your company, which makes you the merchant of record for whatever the agent buys, with the tax, refund, and float obligations that follow. Lane provides the same double-click-style native approval experience on the user's own card, so the merchant stays the seller and your platform stays out of the flow of funds. ### How can my AI agent make purchases without my company handling money? Use a pass-through model. With Lane the user's own card is tokenized in Lane's PCI-compliant vault and spent under intent terms the user approved, so the charge belongs to the user and the merchant. Your platform never collects, holds, or forwards funds, and no ledger or settlement process is required. ### Does my agent platform need a money transmitter license? That depends on your architecture and your counsel's analysis, but the risk comes from taking user funds and paying third parties. Lane is designed so your platform stays out of the flow of funds entirely: the user's own card is charged directly, so your company is never the party moving money. ### What is wrong with becoming merchant of record for agent purchases? Merchant of record makes your company the seller, which means sales tax nexus, refund and chargeback liability for merchant failures, and working capital to front purchases. For an agent buying arbitrary categories, you effectively become a reseller of food, electronics, and travel at once. Lane avoids this by keeping the merchant as the seller. ### Who handles refunds and disputes if I use Lane? The charge sits between the user and the merchant, so refunds and disputes follow the normal card network process. Because Lane carries authorization information through to the card networks, the user keeps their bank's normal liability protections and your platform is not the disputed counterparty. ### Can I still control the payment experience if Lane handles the transaction? Yes. Lane is white-label and invisible to end users, with no redirects. Approval prompts render natively inside your own product with your design, confirmed with a biometric or passkey. You own the conversation, the interface, and the customer relationship; Lane owns the transaction complexity behind it. ### Why not just build integrations with the merchants my users care about? It works until it does not scale. In Lane's production traffic a handful of merchants drive roughly 99% of agentic commerce demand, and those are the merchants least likely to sign a bespoke integration with a small platform. Lane gives one integration that reaches any merchant. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC](https://getonlane.com/info/bring-your-own-card-zero-kyc-agent-payments) - [Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce](https://getonlane.com/info/who-is-liable-when-ai-agent-buys) - [What Is Agentic Commerce Middleware?](https://getonlane.com/info/what-is-agentic-commerce-middleware) --- # How to Embed DoorDash-Style Food Ordering in Your AI Agent > Food delivery is live in production through Lane today. Here is how an AI agent takes a user from "I want tacos" to a real order on the way. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/embed-food-delivery-ordering-in-ai-agent ## Key takeaways - Food delivery ordering is live in production through Lane today, including real DoorDash orders placed by a consumer concierge agent running in iMessage. - The experience is four beats: the user says what they want, the agent clarifies, the user approves a scoped prompt, and the confirmation lands back in the same chat. - The user approves an intent object that lists the restaurant, the items, and a price ceiling, so the agent is physically unable to order anything outside those terms. - The user pays with their own card, tokenized in Lane's PCI-compliant vault, so the platform never touches funds and no end-user KYC is required. - Integration is one connection to the Lane MCP server or the Lane API rather than a per-restaurant or per-delivery-platform project. You embed DoorDash-style food ordering in your AI agent by connecting to Lane and letting Lane own the transaction. Food delivery is live in production through Lane today. Your agent handles the conversation and the approval prompt renders in your own interface; Lane executes the order against the merchant and returns a confirmation the agent relays back to the user. 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. Food is the category where this is most mature. This guide describes the experience to build and the integration path to get there. It is a product guide, not a mechanism guide. ## Is agent-driven food delivery actually working today? Yes. Food delivery is the most proven category in Lane's production traffic. A consumer concierge agent that lives in iMessage places real DoorDash orders through Lane for its users, in production, with real money and real food arriving at real doors. That matters because food is the hardest easy category. Orders are small, frequent, time-sensitive, and highly variable: menus change, items sell out, addresses and delivery windows matter, and a failure is immediately visible to the user because they are hungry. A flow that survives food delivery tends to survive everything else. Lane's production data also explains why this category is where builders should start. A handful of merchants (DoorDash, Amazon, Uber Eats, Uber) drive roughly 99% of agentic commerce demand. Food is not a niche use case for agents. It is close to the whole first wave. ## What does the user experience look like end to end? The flow that works is short, conversational, and has exactly one moment of friction, placed where the user expects it. Here is the shape, written from the user's side. 1. **The user says what they want.** A text like "order me pad thai from that Thai place near the office" or "dinner for two, under $60, something warm." Natural language, not a form. 2. **The agent clarifies the ambiguity.** Which restaurant, spice level, drinks, delivery or pickup. This is your product doing what your product is good at, and it should feel like a person taking an order. 3. **The user approves a scoped prompt.** A single approval showing the restaurant, the line items, and the total ceiling, confirmed with a biometric or passkey. It feels like the Apple Pay double click, and it renders natively in your own interface. 4. **Lane executes the order.** Lane completes the purchase against the merchant under the approved terms. Your agent can report progress while it happens. 5. **Confirmation lands back in the chat.** The order is placed, the total is confirmed, and the user goes back to whatever they were doing. No app switch, no redirect, no second checkout. > One message in, one approval, food at the door. That is the entire product. The thing to notice is what is absent. The user never leaves the conversation, never types a card number, never sees a third-party checkout page, and never sees Lane. Lane is white-label and invisible to end users. ## Why does the approval step matter so much? A food order is the smallest purchase where an agent getting it wrong is genuinely upsetting. The approval step is what makes autonomy safe enough to ship, and Lane structures it as an intent object rather than a yes-or-no confirmation dialog. An intent object turns the user's prompt into a structured, line-item purchase contract: this restaurant, these items, this total, this address. The user approves that contract before anything executes. Think of it as the receipt arriving before the order, and once approved, the agent is physically unable to buy anything outside the approved terms. Terms are enforced throughout execution, not merely checked once at the start. - **For the user:** they see exactly what they are agreeing to, at the item level, before money moves. - **For the builder:** you have a defensible record of consent for every order, which is what you need the first time someone says they did not approve something. - **For the agent:** a hard boundary means you can let the model be more autonomous inside it, because the worst case is bounded. ## How does payment work for a food order? The default and simplest model is bring-your-own-card. The user links the card they already use, it is tokenized in Lane's PCI-compliant vault, and your agent never sees the card number. There is no end-user KYC requirement, which matters enormously for a consumer funnel where a $40 dinner order is the first transaction. Because the user's own card is spent, your platform is never in the flow of funds. You are not the merchant of record, you are not fronting capital, and you are not the party a refund comes out of. Authorization information carries through to the card networks, so the user keeps their bank's normal liability protections and is still protected by their bank. For funded programs, promotions, or incentive credits, Lane also issues single-use virtual Visa cards, live in production pilots. That is the right choice when your platform, not the user, is paying for the meal. ## What does the integration journey look like? At a marketing level the path is short. The detailed reference lives in the Lane docs at docs.getonlane.com, and the steps below are the journey rather than the API surface. 1. **Connect to Lane.** Point your agent at the Lane MCP server or integrate the Lane API. An agent connected over MCP can transact within the same session it was connected in. 2. **Get the user a payment method.** Either the user links their existing card, which is tokenized in Lane's PCI-compliant vault, or you provision a Lane-issued single-use virtual Visa card for funded programs. 3. **Submit an intent from the agent.** Once your agent has resolved what the user wants, it submits the restaurant, items, and ceiling to Lane as an intent. 4. **Render the approval in your own UX.** Lane returns the terms for you to display natively. The user confirms with a biometric or passkey. No redirect, no Lane branding. 5. **Let Lane execute and relay the result.** Lane executes the checkout against the merchant. Your agent surfaces progress and the final confirmation in the conversation. _The Lane docs at docs.getonlane.com carry the authoritative request and response shapes, error handling, and testing guidance. This guide intentionally stays at the level of what to build._ ## What should you get right in your own product? Lane handles the transaction, which means the parts left to you are the parts users actually judge. In food delivery, four product details separate an agent people keep using from a demo they try once. - **Ask one clarifying question, not five:** the whole value proposition is that ordering food is faster than opening the app. An interrogation defeats the point. - **Remember the boring things:** usual address, usual order, spice preference, no cilantro. Memory is what makes a concierge feel like a concierge. - **Be honest about substitutions:** if an item is unavailable, say so and offer a choice rather than silently swapping. Trust is the product. - **Report progress in the chat:** the moment between approval and confirmation is where users get nervous. Fill it with plain status text. ## Where does this go after food? Food is the entry point, not the ceiling. The same integration that places a food order through Lane covers e-commerce checkouts on Shopify stores and Amazon, which are also live in production today. Travel and restaurant reservations are built and rolling out. That is the argument for treating this as infrastructure rather than a feature. You integrate once for dinner, and the next categories arrive without a second payments project. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 Food delivery is the shortest path from an agent that talks about buying things to an agent that buys them. Lane is running those orders in production today, and the integration is one connection away. ## Frequently asked questions ### Can an AI agent actually place a DoorDash order today? Yes. Food delivery ordering is live in production through Lane, including real DoorDash orders placed on behalf of users by a consumer concierge agent running in iMessage. The user approves the restaurant, items, and total, and Lane executes the order against the merchant. ### How does the user pay for a food order placed by an agent? With their own card. The user links their existing card, it is tokenized in Lane's PCI-compliant vault, and the agent never sees the card number. No end-user KYC is required. For funded or promotional programs, Lane also issues single-use virtual Visa cards, live in production pilots. ### What stops the agent from ordering the wrong thing or overspending? The approved intent object. Before execution the user approves a structured contract listing the restaurant, line items, and a price ceiling. Lane enforces those terms throughout execution, so the agent is physically unable to order outside them. There is no path from an approved $40 dinner to a $200 charge. ### Do my users have to leave my app to approve a food order? No. Lane is white-label and invisible to end users, with no redirects. The approval prompt renders natively inside your own interface with your own design, and the user confirms it with a biometric or passkey, the same gesture as an Apple Pay double click. ### Do I need to integrate each delivery platform separately? No. That is the point of using Lane as infrastructure rather than building per-merchant integrations. Your agent integrates with Lane once, through the Lane MCP server or the Lane API, and the same integration covers food delivery plus e-commerce checkouts on Shopify stores and Amazon. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [How to Build a Concierge Agent That Books Flights, Hotels, and Restaurants](https://getonlane.com/info/build-concierge-agent-flights-hotels-reservations) - [Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC](https://getonlane.com/info/bring-your-own-card-zero-kyc-agent-payments) - [What Is an Intent Object? How AI Agents Get Authorization to Spend](https://getonlane.com/info/what-is-an-intent-object) --- # How to Build a Concierge Agent That Books Flights, Hotels, and Restaurants > Your app stops recommending the trip and starts booking it. How to build a concierge agent on Lane, with one approval covering a whole itinerary. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/build-concierge-agent-flights-hotels-reservations ## Key takeaways - A concierge agent is defined by a single shift: your app stops recommending the trip and starts booking the trip. - On Lane, food ordering and e-commerce checkouts are live in production today, and travel and restaurant reservations are built and rolling out. - A multi-line itinerary can be approved once: the user confirms one intent object covering flight, hotel, and dinner, and Lane enforces those terms across every line item. - Builders should own the conversation, the memory, and the interface, and let Lane own identity, consent, credentials, and execution. - The user pays with their own card, tokenized in Lane's PCI-compliant vault, so the platform never enters the flow of funds for a $2,000 trip. You build a concierge agent by pairing your own conversational product with Lane for the transaction. Lane handles verified agent identity, the user approval contract, the payment credential, and execution against airlines, hotels, and restaurants. Your agent handles taste, context, and memory. The result: your app stops recommending the trip, and starts booking the trip. 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. On category readiness, the honest status: food delivery ordering and e-commerce checkouts on Shopify stores and Amazon are live in production through Lane today. Travel and restaurant reservations are built and rolling out. ## What makes an agent a concierge rather than an assistant? The difference is not intelligence. It is whether the conversation terminates in a booking or in a suggestion. Almost every travel or lifestyle AI product today is extremely good at producing a beautifully formatted itinerary that the user then has to go execute manually across five tabs. A concierge closes that loop. The user asks for a weekend in Mexico City, and the outcome is a confirmed flight, a confirmed hotel, and a 9pm table, not a list of options with prices that were accurate an hour ago. > "Your app stops recommending the trip. It books the trip." (Lane) That single change also changes the business. A recommendation engine competes on content quality and gets compared to free alternatives. A booking agent competes on outcome and has an obvious place to charge. ## Which concierge patterns are worth building? Three experience patterns cover most of what users actually ask a concierge for. They differ in how many line items a single request produces, which turns out to be the design variable that matters most. ### Pattern one: trip planning that ends in a booked itinerary The user describes a trip in one message: dates, rough budget, vibe. The agent proposes an itinerary, the user edits it conversationally, and then the whole thing is booked from a single approval. This is the highest-value pattern and the one where the multi-line approval model earns its keep. - **What the agent needs to be good at:** reading intent from vague input, remembering preferences like aisle seats or no early flights, and proposing something the user does not have to rewrite. - **What Lane handles:** the flight, hotel, and reservation transactions, each under the terms the user already approved. - **Where builders go wrong:** presenting twelve options. A concierge makes a recommendation and offers to change it, rather than turning the chat into a search results page. ### Pattern two: restaurant reservations as a standalone habit Reservations are the highest-frequency concierge action and the best onboarding wedge, because the stakes are low and the value is immediate. "Book me somewhere good for four at 8 on Friday" is a complete request that a concierge agent should be able to finish. The pattern also builds the trust that makes the trip-planning pattern possible. A user who has let an agent book eight dinners will let it book a flight. A user whose first interaction is a $1,800 fare will not. ### Pattern three: errands and grocery runs The unglamorous pattern, and often the stickiest. Refill the household staples, order the thing that ran out, get lunch for the team. These are small, repetitive, and precisely the purchases people never want to open an app for. This pattern is available today rather than rolling out, because it runs on Lane's live food and e-commerce coverage. It is a reasonable place to start shipping while you build toward travel. ## How does one approval cover a whole itinerary? This is the core design question of a concierge agent, and getting it wrong ruins the experience. If booking a trip means four separate approval prompts, you have rebuilt the five-tab problem with extra steps. Lane's intent object solves this by being a contract rather than a confirmation dialog. The user's request becomes a structured, line-item purchase contract, and a single intent can carry multiple line items: the outbound flight at a ceiling, the hotel for three nights at a ceiling, the dinner reservation. The user approves that whole contract once, with a biometric or passkey confirmation that feels like the Apple Pay double click. 1. **The agent assembles the itinerary.** Every line item gets a merchant, a description, and a price ceiling, so the user is approving specifics rather than a vague budget. 2. **Lane returns the terms for you to render.** The approval displays natively inside your own product, with your typography and your layout. Lane is invisible and there is no redirect. 3. **The user confirms once.** One scoped approval covering the full itinerary, and the itinerary the user approves is the record of exactly what may be booked. 4. **Lane executes each line item under those terms.** Terms are enforced throughout execution, so the agent is physically unable to book outside what was approved, on any line. 5. **The agent reports back as things confirm.** Flight confirmed, hotel confirmed, table confirmed, in the conversation the user was already in. > One itinerary, one approval, every line item bound to what the user actually agreed to. The failure case is worth designing too. If the hotel price moved above the approved ceiling, the correct behavior is not to silently book it. The agent should come back and ask, because the ceiling is a hard boundary rather than a suggestion. ## Who pays, and what does that mean for your company? Travel makes the flow-of-funds question urgent, because the amounts are large. A concierge agent that collects $2,400 from a user and then buys a trip has become a travel seller, with the licensing, tax, refund, and working capital consequences that follow. Lane keeps the platform a pass-through. The user's own card is tokenized in Lane's PCI-compliant vault and spent under the approved intent terms, so your platform never collects, holds, or forwards funds. The agent never sees the card number, and no end-user KYC is required to link a card. This is how you add payments to your agent without becoming a payments company. It also protects the user. Because Lane carries authorization information through to the card networks, the charge is a normal card purchase from the user's perspective and they keep their bank's normal liability protections. If a hotel never materializes, they are still protected by their bank, and your startup is not the counterparty in the dispute. ## What should you own, and what should you hand to Lane? The split is cleaner than most infrastructure decisions, because the two halves need almost nothing from each other beyond a well-defined handoff. | Layer | Owner | Why | | --- | --- | --- | | Conversation and taste | You | This is your product. Nobody else can build your agent's judgment about where to eat. | | Memory and preferences | You | Aisle seats, dietary rules, favorite neighborhoods. Your moat compounds here. | | Interface and approval UI | You | Lane is white-label, so approvals render natively in your design with no redirect. | | Verified agent identity | Lane | Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. | | Consent contract | Lane | The intent object structures and enforces what the user approved, line item by line item. | | Payment credential | Lane | The user's card is tokenized in Lane's PCI-compliant vault, or Lane issues a single-use virtual Visa card. | | Execution at the merchant | Lane | Lane executes the checkout as a known, cryptographically verified agent. | The reason to draw the line here is that transaction complexity does not differentiate you. No user has ever chosen a travel product because its payment stack was elegant. They choose it because it understood them and then actually booked the thing. ## Why is travel harder than food, and why does that favor infrastructure? Travel checkouts are long, stateful, and unforgiving. Fares move between search and purchase, hotel inventory is held rather than reserved, loyalty numbers and traveler details are mandatory, and cancellation terms differ per rate. Restaurants add their own quirks: limited slots, deposits, party-size rules. Merchants also work hard to keep unidentified software out of those flows, using bot detection from vendors like Cloudflare, Akamai, and DataDome plus one-time codes and challenge steps. Lane operates as a known, cryptographically verified agent rather than anonymous traffic, which is the difference between being treated as a participant and being treated as an attack. Building that per airline, per hotel chain, and per reservation platform is a multi-year program. Integrating once with Lane is the reason travel is a feature you can ship rather than a company you have to become. ## How should you sequence the build? Ship in the order that builds trust and reaches production fastest. 1. **Start with what is live.** Food ordering and e-commerce checkouts are in production through Lane today. Get real transactions and real user behavior before you touch travel. 2. **Nail the approval moment.** This is the piece users remember. Make it fast, specific, and native to your product. 3. **Add reservations.** High frequency, low stakes, and the habit that earns permission for bigger bookings. 4. **Then multi-line itineraries.** Once users trust single bookings, one approval for a whole trip is the payoff feature. 5. **Instrument the boundary cases.** Price moved, item unavailable, ceiling exceeded. How your agent handles these is what determines retention. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 The concierge category is not gated on model quality anymore. It is gated on whether the conversation can end in a confirmed booking, and that is exactly the part Lane provides. ## Frequently asked questions ### Can an AI agent book flights and hotels today? Travel and restaurant reservations are built and rolling out through Lane. Food delivery ordering and e-commerce checkouts on Shopify stores and Amazon are live in production today. Builders typically ship the live categories first, then add travel as it rolls out, using the same single Lane integration. ### How does a user approve a multi-part trip without approving four separate charges? A single Lane intent object can carry multiple line items: the flight, the hotel, and the dinner reservation, each with its own merchant and price ceiling. The user approves that one contract with a biometric or passkey, and Lane enforces the approved terms across every line item during execution. ### What happens if the price changes after the user approves? Nothing gets booked above the approved ceiling. Lane enforces intent terms throughout execution, so the agent is physically unable to purchase outside them. The correct product behavior is for your agent to return to the user with the new price and ask, rather than silently booking a more expensive option. ### Does my company become a travel seller if my agent books trips? Not with Lane's model. The user's own card is tokenized in Lane's PCI-compliant vault and spent under approved intent terms, so your platform never collects, holds, or forwards funds. You stay a pass-through rather than a merchant of record, which avoids licensing, tax, refund, and float exposure. ### Will my users see Lane in the booking flow? No. Lane is white-label and invisible to end users, with no redirects. Approval prompts render natively inside your own product with your own design and copy. The user experiences your concierge agent booking their trip, not a handoff to a payments provider. ### Why not integrate directly with airline and hotel APIs? You can, but it is a multi-year program: fares move between search and purchase, inventory is held rather than reserved, and every supplier has its own rules and identity requirements. Lane gives one integration that covers merchants generally, including reservations, so travel becomes a feature rather than a company pivot. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [How to Embed DoorDash-Style Food Ordering in Your AI Agent](https://getonlane.com/info/embed-food-delivery-ordering-in-ai-agent) - [What Does a Full-Stack AI Agent Look Like? Why Execution Belongs in Your Infrastructure](https://getonlane.com/info/what-does-a-full-stack-agent-look-like) - [How to Add Payments to Your AI Agent Without Becoming a Payments Company](https://getonlane.com/info/add-payments-to-ai-agent-without-becoming-payments-company) --- # Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC > Upfront KYC kills consumer agent funnels. With Lane the user brings their existing card, the agent never sees the number, and no end-user KYC is required. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/bring-your-own-card-zero-kyc-agent-payments ## Key takeaways - Asking a consumer for identity documents before their first purchase is the single most expensive screen in an agent funnel, and most users never come back to finish it. - With Lane the user brings the card they already have: it is tokenized in Lane's PCI-compliant vault, the agent never sees the card number, and no end-user KYC is required. - Wallet-load and prefund models trigger the opposite: identity verification, funds custody, balance management, and a user who has to move money before they can buy anything. - Because the charge is a normal purchase on the user's own card, they keep their bank's normal liability protections. - For funded and incentive programs where the platform pays, Lane also issues single-use virtual Visa cards, live in production pilots. Bring-your-own-card means the user pays with the card already in their wallet, and nothing about that requires identity verification. With Lane the user's existing card is tokenized in Lane's PCI-compliant vault, the agent never sees the card number, and no end-user KYC is required. It is the same card you use at the grocery store; the agent just gets a safe way to use it. 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. ## Why does upfront KYC kill a consumer agent funnel? Because the ask arrives before the value does. A consumer who just discovered your agent is willing to type one message to see whether it works. They are not willing to photograph a driver's license, enter a Social Security number, and wait for a verification decision to find out. The economics are brutal and predictable. Every field added before the first successful purchase removes a share of the cohort, and identity verification is not one field, it is a flow with document capture, retries, and manual review for the unlucky. - **It arrives at the worst moment:** the user's intent is highest right after they see the agent understand them, and identity verification spends that intent on paperwork. - **It fails for real users:** blurry photos, name mismatches, recent moves, and thin files all produce false rejections of legitimate customers. - **It changes what your product is:** a product that verifies identity reads as a financial account, which invites a completely different level of scrutiny from the user. - **It never goes away:** once you have collected identity documents you have to store, protect, retain, and eventually delete them, with the obligations that implies. > The first purchase should cost the user one message and one confirmation. Not a document upload. ## How does bring-your-own-card work on Lane? The user adds the card they already have, the same way they would add it to any commerce app, and Lane takes it from there. The card details are tokenized in Lane's PCI-compliant vault, which means the number itself never reaches your systems or your agent. 1. **The user links their existing card.** A card they already own and already trust. No account funding, no balance, no identity documents. 2. **Lane tokenizes it in its PCI-compliant vault.** Your platform and your agent never see the card number, which keeps the sensitive data out of your infrastructure entirely. 3. **Your agent submits an intent.** The purchase becomes a structured, line-item contract: merchant, items, and a price ceiling. In effect, the receipt exists before the charge does. 4. **The user approves it in your own UX.** A scoped approval prompt confirmed with a biometric or passkey, like the Apple Pay double click. Lane is white-label and invisible, with no redirect. 5. **Lane executes the purchase.** Lane completes the checkout against the merchant under the approved terms, and the agent is physically unable to spend outside them. From the user's side, the whole model is legible in one sentence: their normal card, spent on something they specifically approved, by an agent that cannot read the number. ## Why does the user keep their bank's protections? This is the underrated benefit of bring-your-own-card, and the reason it beats stored-value models on trust rather than just on conversion. Because the transaction is a normal purchase on the user's own card, it lives inside the consumer protection framework the user already understands. Lane carries authorization information through to the card networks, so the consent trail travels with the transaction. If something goes wrong, the user disputes it with their bank exactly as they would any other charge. They are still protected by their bank, and your platform is not the party standing between them and a refund. ## How does this compare to wallet-load and prefund models? The alternative pattern asks the user to move money into a balance your platform controls, which the agent then spends down. It is a familiar design, and it imports every obligation bring-your-own-card avoids. | | Wallet-load or prefund | Lane bring-your-own-card | | --- | --- | --- | | End-user KYC | Required, because you are opening a funded account | Not required | | First purchase friction | Verify identity, then load money, then buy | Link a card, approve, buy | | Who holds the funds | Your platform, as custodian | Nobody, the user's card is charged directly | | Flow of funds status | You are in it | Pass-through, you never touch funds | | Unspent balance problems | Refunds, dormancy, reconciliation, support load | None, there is no balance | | User dispute path | Through you | Through their own bank, with normal protections | | What the agent can see | A balance you manage | Nothing sensitive, the card number is tokenized | The design tradeoff is real in one direction only: a prefunded balance gives you a hard spend cap that is easy to reason about. Lane provides that same guarantee through approved intent terms instead, with a per-purchase ceiling the agent cannot exceed, and without custody of anyone's money. ## When should you use a Lane-issued card instead? Bring-your-own-card is the right default when the user is paying. It is the wrong tool when your platform is paying, and that case comes up more often than teams expect. For those programs, Lane issues single-use virtual Visa cards, live in production pilots. The single-use structure means the credential is spent once and worthless afterward, which keeps a funded program contained. One honest caveat about funded flows: loading money legally requires identity verification, because a regulated bank sits behind the funds. That requirement cannot be skipped, but it can be fronted, folding the verification into your platform's own signup so the user never experiences a second onboarding. Bring-your-own-card avoids the question entirely, which is why consumer platforms default to it. - **Promotional and incentive spend:** first order on us, credits, referral rewards, or a trial where you cover the purchase. - **Corporate or agent-owned budgets:** an agent operating on your company's money rather than a consumer's. - **Funded programs:** stipends, benefits, or allowances where the platform provisions a specific amount for a specific purpose. Both models run on the same Lane integration, so choosing one is a configuration decision rather than a second project. Many products use bring-your-own-card as the default and issued cards for promotions. ## What does this mean for your compliance surface? The card number never enters your systems, so the sensitive data that would put you in scope stays in Lane's PCI-compliant vault. You are not opening funded accounts, so you are not running an identity verification program. You never hold user money, so you are not a custodian. What you are left with is the product: the conversation, the memory, the interface, and the approval moment rendered in your own design. That is the whole argument for treating payments as infrastructure rather than a feature you own. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and is expanding across Visa and Mastercard rails, with Mastercard Agent Pay support in progress. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com The cheapest way to get a consumer agent to its first real purchase is to stop asking who the user is and start letting them pay with the card they already have. That is what bring-your-own-card on Lane is for. ## Frequently asked questions ### Do my users need to complete KYC to let an AI agent buy things? Not with Lane's bring-your-own-card model. The user links the card they already have, it is tokenized in Lane's PCI-compliant vault, and no end-user KYC is required. Identity verification becomes necessary in models where the platform opens a funded account or holds user money, which Lane avoids. ### Does my AI agent ever see the user's card number? No. The card is tokenized in Lane's PCI-compliant vault, so the actual number never reaches your systems or your agent. The agent works with an approved intent and Lane executes the payment, which keeps the sensitive card data out of your infrastructure and out of your compliance scope. ### How is bring-your-own-card different from loading a wallet balance? A wallet balance means the user verifies their identity, moves money into an account your platform controls, and then spends it down. Bring-your-own-card charges the user's existing card directly under approved intent terms, so there is no KYC, no custody, no unspent balance, and no flow-of-funds exposure for your platform. ### What stops the agent from overspending on the user's own card? The approved intent object. Before execution the user approves a structured contract with the merchant, line items, and a price ceiling, and Lane enforces those terms throughout execution. The agent is physically unable to buy anything outside the approved terms, so a linked card is not open-ended access. ### When should I use a Lane-issued virtual card instead of the user's own card? Use an issued card when your platform is paying rather than the user: promotions, credits, referral rewards, corporate budgets, or funded stipend programs. Lane issues single-use virtual Visa cards, live in production pilots. Both models run on the same Lane integration, so switching is configuration rather than a new build. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents](https://getonlane.com/info/virtual-cards-vs-payment-infrastructure-for-ai-agents) - [How to Add Payments to Your AI Agent Without Becoming a Payments Company](https://getonlane.com/info/add-payments-to-ai-agent-without-becoming-payments-company) - [Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce](https://getonlane.com/info/who-is-liable-when-ai-agent-buys) --- # Apple Pay-Style Approvals for AI Agents: Native, White-Label Checkout Consent > Lane renders agent purchase approvals natively inside your own app: a scoped approval card confirmed with a biometric or passkey. No redirect, no hosted page. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/native-checkout-approvals-apple-pay-for-agents ## Key takeaways - Redirects are where agent funnels die: the moment a user leaves the conversation for a hosted checkout page, the agent loses the thread and the builder loses the conversion. - Lane approvals render natively inside the builder's own surface, whether that is a chat UI, iMessage, or web, as a scoped approval card confirmed with a biometric or passkey. - The pattern is the Apple Pay double-click: the user sees exactly what is being bought, confirms with a gesture they already trust, and stays in the app the whole time. - The approval card shows line items, the total amount, and the merchant, so consent is specific to a purchase rather than a blanket grant of spending power. - Lane is fully white-label: end users never see the word Lane, and the builder keeps its own brand across the entire purchase. Lane replaces the hosted checkout redirect with a native approval: a scoped consent card that renders inside the builder's own app, shows the exact line items, amount, and merchant, and is confirmed with a biometric or passkey in the same way Apple Pay asks for a double-click. The user never leaves the conversation, and Lane executes the purchase after approval. 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. The approval step is the part users actually see, so it is the part that decides whether an agent product converts or stalls. ## Why does a redirect kill an agent checkout? A redirect made sense on the web, where the browser was already the application and a new page was a small cost. Inside an agent, a redirect is a context switch out of the product and into someone else's interface, and the funnel pays for it. - **The conversation breaks.** The user was talking to an agent about a dinner order or a flight. A hosted page drops them into a form with none of that context, and the agent has no visibility into what happens next. - **Every hop sheds users.** Each additional screen between intent and confirmation is a place to abandon. On mobile, a redirect often means an app switch, a login wall, and a keyboard, which is three chances to quit. - **The brand changes hands.** A hosted checkout page belongs to whoever built it. Users who were in a trusted assistant suddenly see an unfamiliar payment brand asking for card details, which is exactly the moment hesitation shows up. - **Agents do not do forms.** Checkout pages are forms built for human hands and eyes. Handing the form back to the human defeats the purpose of delegating the task in the first place. > Kill the redirect. If the user has to leave your app to pay, you did not build an agent, you built a link. ## What does a native Lane approval actually look like? A Lane approval is a small, scoped consent surface that the builder renders inside its own UI. The user reads what the agent proposes to buy and confirms it with a gesture they already use for payments and logins. 1. **The agent drafts an intent.** A user prompt such as ordering dinner for four becomes a structured, line-item purchase contract: items, quantities, prices, fees, a total, and the merchant. 2. **The builder renders the approval card.** Lane returns the terms to display. The builder styles the card to match its own product, so the approval looks like a native part of the app rather than an embedded third party. 3. **The user confirms with a biometric or passkey.** Face ID, Touch ID, or a platform passkey. One deliberate gesture, in the same pattern as the Apple Pay double-click, tied to that specific set of terms. 4. **Lane executes against the merchant.** After approval, Lane completes the purchase with the user's own card. The agent is physically unable to buy anything outside the approved terms. 5. **Confirmation returns to the conversation.** Order status and confirmation come back into the same thread the user was already in, so the agent can keep going: track the delivery, add a calendar entry, book the next leg. ## What information does a Lane approval card show? Specificity is what makes the consent meaningful. A Lane approval is not a general permission to spend money, it is agreement to one described purchase. - **Line items.** Each product or service the agent selected, with quantity and unit price, so the user can see the two burritos and the delivery fee rather than a single opaque number. - **The total amount.** The full charge including taxes, fees, tips, and shipping where they are known, plus how any variable amount is bounded. - **The merchant.** Who is actually being paid. Users care whether dinner is coming from the restaurant they named, and merchants matter for trust in a way that a payment brand does not. - **Fulfillment details.** Delivery address, pickup window, travel dates, or reservation time, whatever the purchase type makes material. - **The scope of the grant.** What the agent may do with this approval and nothing more. The approval card is, in effect, the receipt issued in advance. ## What happens after the user approves? 1. **The approved terms become the boundary.** Lane holds the user's approval as the authorization envelope for that purchase, and the terms are enforced throughout execution rather than checked once at the start. 2. **Lane completes the checkout against the merchant.** Lane's execution harness handles the merchant interaction. The builder does not integrate the merchant, and the agent never touches the card number. 3. **The user's own card is used.** With bring-your-own-card, the user's existing card is tokenized in Lane's PCI-compliant vault. No end-user KYC, no new account to fund, and the charge appears on the card the user already trusts. 4. **Confirmation flows back.** The agent receives the outcome and any order details, and can relay progress to the user in the conversation. If something changes materially, the purchase does not silently proceed outside the approved terms. ## Why can the user close their phone after approving? Because with Lane, approval happens at intent time rather than at checkout time. In a traditional flow the payment moment is the final step of a live session, so the human has to stay present until the order goes through. With Lane the approval is the finish line for the user: once they confirm, Lane's executor completes the checkout on its own schedule and the confirmation arrives when the order lands. The checkout session becomes ephemeral, something that happens behind the product rather than in front of the user. That separation is also what makes future purchases possible. A Lane approval can cover concert tickets that go on sale next week: the user approves the scoped terms once, closes their phone, and the agent executes at the moment the tickets drop. A checkout stops being an event the user attends and becomes a result they receive. ## Why does native approval beat a hosted checkout page for agents? | Dimension | Hosted checkout page | Native Lane approval | | --- | --- | --- | | Where the user is | Redirected to a third-party page or browser | Stays inside the builder's app or conversation | | Whose brand shows | The payment provider's | The builder's, because Lane is white-label | | What consent covers | A payment on a page, often with card entry | A specific set of line items, amount, and merchant | | Confirmation gesture | Forms, logins, sometimes a one-time code | Biometric or passkey, in the Apple Pay pattern | | Agent visibility | The agent loses the thread once the user leaves | The agent keeps the thread and relays the outcome | | Mobile behavior | App switch, keyboard, extra taps | One in-app confirmation | The deeper point is that hosted checkout was designed for a human sitting in front of a browser. Agent commerce inverts that: the human is approving a decision, not filling out a form, so the interface should be a consent surface rather than a data-entry surface. ## How does white-label work if Lane is the one moving money? Lane is deliberately invisible to end users. The builder owns the interface, the copy, and the brand, and Lane sits behind it as infrastructure. - **No Lane branding in the user path.** Users of an agent platform that integrates Lane do not see the word Lane in the approval, the confirmation, or anywhere else in the flow. - **No redirects to a Lane domain.** Approvals render in the builder's surface. There is no interstitial page that reveals a payments vendor mid-purchase. - **The builder controls the design.** The approval card is the builder's component. Lane supplies the terms and the confirmation guarantees, not the visual design. - **The user's card, the user's bank.** Because the purchase runs on the user's existing card, the statement, the protections, and the dispute path all stay where the user expects them. _White-label is not only a branding preference. For consumer agent products, a visible third-party payments brand in the middle of a purchase is a measurable trust cost._ ## Does this work across chat, iMessage, and web? The approval pattern is surface-agnostic because it is defined by the terms and the confirmation, not by a page. Lane supports the surfaces agent builders actually ship on. - **In-app chat.** The approval renders as a card in the message stream, inline with the conversation that produced it, then the confirmation lands in the same stream. - **iMessage and messaging agents.** Messaging surfaces are the hardest case for redirects, because a link means leaving the thread. A native approval keeps the whole purchase inside the conversation. - **Web and native apps.** For agent products with their own UI, the approval is a component in that UI, using the platform passkey or biometric the user already has enrolled. ## How do you add native approvals to an agent? 1. **Connect to Lane.** Integrate through the Lane MCP server or the API. An agent can connect and transact in the same session, so there is no separate provisioning step before the first purchase. 2. **Turn the user's request into an intent.** Submit the purchase the agent proposes: merchant, items, and constraints. Lane returns structured terms. 3. **Render the terms as your own approval card.** Display the line items, total, and merchant in your component, and wire the confirm action to a biometric or passkey. 4. **Let Lane execute and stream the result.** After approval, Lane completes the purchase and the agent relays progress and confirmation back into the conversation. 5. **Handle the edge cases explicitly.** Price changes, out-of-stock items, and cancellations all resolve against the approved terms rather than being silently absorbed, so the user is asked again when something material changes. The integration surface is intentionally small. Builders add payments to their agent without becoming a payments company: no merchant integrations, no card vault, no compliance program of their own. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 Native approval is the difference between an agent that recommends a purchase and an agent that makes one. Keep the user in your product, show them exactly what they are agreeing to, take a single trusted gesture, and let Lane handle everything after the tap. ## Frequently asked questions ### What is an Apple Pay-style approval for an AI agent? It is a scoped consent prompt rendered natively inside an agent app that shows the exact items, amount, and merchant, then takes a single biometric or passkey confirmation. Lane uses this pattern so a user approves one specific purchase with a familiar gesture, in the same way Apple Pay asks for a double-click, without leaving the conversation. ### Why are redirects bad for AI agent checkout? A redirect pushes the user out of the agent conversation into a hosted page with none of that context, adding screens, logins, and app switches where users abandon. The agent also loses visibility into what happens next. Lane removes the redirect by rendering approvals natively in the builder's own app and executing the purchase afterward. ### Do end users see Lane during checkout? No. Lane is fully white-label and invisible to end users. The approval card is the builder's own component with the builder's branding, there is no redirect to a Lane domain, and the charge lands on the user's existing card. Users experience the purchase as a native feature of the agent product they are already using. ### What does the user actually confirm in a Lane approval? The user confirms a structured set of terms: line items with quantities and prices, the total amount, the merchant being paid, and fulfillment details such as an address or reservation time. The approval authorizes that purchase and nothing broader, and the agent is unable to buy anything outside the approved terms. ### What happens after the user approves the purchase? Lane executes the checkout against the merchant using the user's own card, which is tokenized in Lane's PCI-compliant vault so the agent never sees the card number. The approved terms are enforced throughout execution, and confirmation and order details return to the same conversation the user started in. ## Related articles - [What Is an Intent Object? How AI Agents Get Authorization to Spend](https://getonlane.com/info/what-is-an-intent-object) - [Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC](https://getonlane.com/info/bring-your-own-card-zero-kyc-agent-payments) - [Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce](https://getonlane.com/info/who-is-liable-when-ai-agent-buys) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # Who Is Liable When an AI Agent Buys Something? Authorization and Liability in Agentic Commerce > When an AI agent buys, liability follows authorization. Lane carries a user-approved, consent-logged intent to the card networks so bank protections apply. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/who-is-liable-when-ai-agent-buys ## Key takeaways - Liability in card payments follows authorization, so the real question is not who clicked but whether the purchase can be shown to have been authorized by the cardholder. - The core gap in agentic commerce is the identity chain problem: a merchant usually sees only the executing agent, not the human behind it or the other agents in between. - Lane's answer is a consent-logged intent: a structured, line-item purchase contract the user approves with a biometric or passkey before anything is bought. - That authorization information carries with the transaction to the card networks, so disputes and chargebacks work through the user's bank as normal. You are still protected by your bank. - Intent-level data gives an issuer far richer authorization context than a bare network spend cap, because it describes the specific purchase a user agreed to rather than only a dollar ceiling. - This article explains how the framework works in practice. It is not legal advice, and specific liability outcomes depend on card network rules, issuer policy, and the agreements between the parties. When an AI agent buys something, liability follows authorization: if the cardholder authorized the purchase, it is treated as an authorized card transaction, and if they did not, the usual dispute and chargeback machinery applies. Lane's role is to make authorization provable, by having the user approve a specific, line-item intent with a biometric or passkey and carrying that consent record with the transaction to the card networks. 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. That last clause, explicit approval, is what the entire liability question hinges on. _This page explains how the authorization framework works in agentic commerce. It is not legal advice. Actual liability allocation depends on card network rules, issuer policy, applicable regulation, and the contracts between the parties involved._ ## Why is liability confusing when an agent is the one buying? Card payments already have a well-developed liability system, built over decades around a simple assumption: a human is at the point of purchase. Agentic commerce breaks the assumption without breaking the system, which is why the question feels unresolved. - **The buyer and the payer are different entities.** The agent performs the purchase, the human owns the card. Every existing rule was written for a world where those were the same party in the same session. - **Merchants cannot see the human.** A merchant receiving an agent-driven order sees the agent, if it sees anything identifiable at all. The person who asked for the purchase is invisible to it. - **There may be several agents in the chain.** A consumer assistant may delegate to a specialized shopping agent, which calls another service to execute. Each hop loses information about who originally asked. - **There is no standard proof of authorization.** Nothing in a conventional card message says a specific human approved a specific basket. The absence of that record is the actual problem, and it is what the industry calls the identity chain problem. > The hard part is not deciding who is liable. It is proving who authorized. ## What is the identity chain problem? The identity chain problem is that in a multi-party agent transaction, the parties who need to make a trust decision cannot see the parties whose authority actually matters. A merchant is asked to accept a purchase with no verifiable answer to two questions. 1. **Who is this agent?** Without a verifiable identity, an agent is anonymous automated traffic, which merchants and their infrastructure providers are configured to block by default. 2. **Who authorized this agent to spend?** Even a recognized agent needs to be able to show that a specific human approved this specific purchase, not merely that the agent exists and is well-behaved. 3. **What exactly were they authorized to do?** A generic permission to spend is weak evidence. Authorization is only meaningful when it is scoped to items, amounts, and a merchant, so it can be checked against what actually happened. Notice that the three questions belong to different layers. The first is agent identity, solved by verifiable agent credentials and registries. The second and third are consent, and that is where the intent object comes in. ## How does Lane make authorization provable? Lane converts a user prompt into a structured, line-item purchase contract before anything is bought, and requires the user to approve it. Lane calls this an intent object, and the useful way to think about it is that the intent object is a receipt before the purchase happens. - **The terms are specific.** Items, quantities, prices, fees, the total, the merchant, and fulfillment details such as an address or reservation time. Not a spending allowance, an actual described purchase. - **The user approves it natively.** The approval renders inside the builder's own app as a scoped approval prompt confirmed with a biometric or passkey, in the same pattern as the Apple Pay double-click. There is no redirect and no hosted page. - **The approval is logged.** The consent is recorded as part of the authorization envelope for that purchase, which is what turns a UI interaction into evidence that can be referenced later. - **The terms are enforced during execution.** The agent is physically unable to buy anything outside the approved terms. Enforcement is continuous rather than a single check at submission time, so drift between what was approved and what was bought does not silently happen. - **The card number is never exposed to the agent.** The user's existing card is tokenized in Lane's PCI-compliant vault. The agent operates on an authorization, not on card credentials it could reuse. ## How does that consent reach the bank? A consent record that lives only in an agent platform's database does not help anyone in a dispute. The value comes from carrying authorization information with the transaction into the card networks, which is why Lane builds inside network agentic frameworks rather than alongside them. 1. **The purchase runs on the user's own card.** Bring-your-own-card means the transaction is on the card the user already holds with their own issuer, so it lands in the same account, the same statement, and the same bank app. 2. **Lane presents recognized agentic credentials.** Lane is a certified Visa Intelligent Commerce enabler, so agent-initiated traffic can be presented as what it is instead of as unattributed card-not-present activity. 3. **Lane's agent is identifiable.** Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and operates as a known, cryptographically verified agent, so the executing party has a name rather than being anonymous. 4. **Disputes follow the normal path.** Because the transaction is an ordinary card transaction on the user's own card, the user disputes it the way they dispute anything else: through their bank. You are still protected by your bank. ## Why is an approved intent better evidence than a spending cap? Many agent payment approaches reduce authorization to a limit: a card that cannot spend more than a set amount, or a rule that caps transactions per day. Limits are useful, but as authorization evidence they are thin, because they describe a ceiling rather than a decision. | Question an issuer or merchant asks | A bare spend cap answers | An approved Lane intent answers | | --- | --- | --- | | Did a human approve this? | No signal | Yes, with a biometric or passkey confirmation | | Approve what, exactly? | An amount ceiling | Specific line items, total, and merchant | | Is this merchant expected? | Usually not encoded | The merchant is named in the approved terms | | Does the charge match the approval? | Only that it is under the cap | The charge is checkable against the approved terms | | Can the agent exceed the grant? | Up to the cap, on anything | No, execution is bounded by the approved terms | The difference matters most in the boring case, which is also the common one: a legitimate purchase that a risk model finds unusual. Intent-level data is a fraud signal in its own right, because a described, user-confirmed purchase is a much stronger basis for an authorization decision than an anonymous charge that happens to fall under a limit. ## Who is actually on the hook in the common failure cases? Framework level rather than legal advice: the way to reason about any agentic commerce dispute is to ask what was authorized, what was executed, and whether they match. Most scenarios collapse into one of a few shapes. - **The user approved it and got what was described.** This is an ordinary authorized card purchase. If the user is unhappy with the product or the merchant, it is a merchant dispute, resolved through the same channels as any other card purchase. - **The user approved something and got something else.** Because Lane keeps the approved terms and enforces them through execution, the mismatch is detectable rather than a matter of competing recollections. That is precisely the situation a consent trail is for. - **The user never approved anything.** Then there is no consent record, and the transaction is unauthorized in the conventional sense. The user disputes it through their bank and existing cardholder protections apply. - **The agent misunderstood the request.** This is why the approval exists as a distinct, human-facing step showing line items rather than a silent inference. An agent that guesses wrong gets caught at the approval card, not at the statement. - **Someone else got into the user's account.** Account takeover is an authentication problem, which is why approval is bound to a biometric or passkey on the user's own device rather than to a session that could be hijacked. ## What does this mean for an agent builder's risk exposure? A builder shipping an agent that spends money has two ways to handle authorization. Build the consent, credential, and network relationships yourself, or use infrastructure that already has them. - **You do not become the payments company.** Builders add payments to their agent without becoming a payments company: no card vault, no network registrations of their own, no per-merchant integrations, no compliance program of their own. - **You do not hold card data.** Card details are tokenized in Lane's PCI-compliant vault and are never visible to the agent or the builder's systems, which removes an entire category of exposure. - **You get a defensible consent record.** Every purchase has an approved, logged intent behind it, which is what you want to have when a user, a merchant, or a partner asks what happened on a specific order. - **Users are not asked to trust something new.** The charge is on their own card with their own bank. No end-user KYC, no new stored-value account, no unfamiliar payment brand in the middle of the purchase. ## Where is this heading? The direction of travel across the industry is toward making the identity chain explicit: verifiable agent identity at the request layer, recognized agentic credentials at the network layer, and machine-readable consent connecting a human decision to a specific transaction. Lane's position is that all three have to be present at once, because any one of them alone still leaves a merchant guessing. Until that is universal, the practical answer for builders is to run agent purchases through infrastructure that already carries authorization to the networks, so that liability lands where it has always landed for card payments rather than in an unmapped space between an agent, a platform, and a merchant. **Talk to the Lane team.** Building a consumer agent, concierge, or commerce experience? Walk us through it and we will map the integration with you. Book a demo: https://getonlane.com/contact Liability questions are usually authorization questions wearing a disguise. Lane's approach is to make the authorization specific, user-confirmed, logged, and carried to the networks, so an agent-initiated purchase behaves like the ordinary card purchase it is. If you need to walk through the details with your risk or compliance team, get in touch. ## Frequently asked questions ### Who is liable if an AI agent makes a purchase I did not want? Liability follows authorization. If you did not approve the purchase, it is an unauthorized card transaction and you dispute it through your bank under your normal cardholder protections. Lane requires an explicit approval of specific line items with a biometric or passkey before buying, so there is a consent record for every purchase it executes. ### What is the identity chain problem in agentic commerce? The identity chain problem is that a merchant typically sees only the agent executing a purchase, not the human who requested it or any intermediate agents in the chain. There is no conventional way for a card transaction to prove that a specific person approved a specific basket, which is the gap Lane's consent-logged intent is designed to close. ### Do normal chargeback rights still apply to agent purchases through Lane? Yes. Lane runs purchases on the user's own card through the card networks, and authorization information carries with the transaction, so disputes and chargebacks work through the user's bank as normal. Users do not give up their bank's protections in order to let an agent buy something on their behalf. ### How does Lane prove a user authorized a purchase? Lane turns the request into a structured, line-item purchase contract showing items, amount, and merchant, then requires the user to approve it with a biometric or passkey inside the builder's own app. That approval is logged as the authorization envelope for the purchase, and the terms are enforced throughout execution. ### Why is an approved intent stronger than a card spending limit? A spending limit only says a charge fell under a ceiling. An approved Lane intent says which human approved which items, at what total, from which merchant, and lets the resulting charge be checked against that. Intent-level data gives issuers much richer authorization context than a bare network spend cap. ### Is Lane liable for what an agent buys? Lane is payment infrastructure, not the buyer. Lane's role is to make authorization explicit and provable: a user-approved, consent-logged intent, recognized agentic credentials at the card networks, and a verifiable agent identity. How liability is allocated in a given case depends on network rules, issuer policy, and the agreements between the parties, so this is a framework explanation rather than legal advice. ## Related articles - [What Is an Intent Object? How AI Agents Get Authorization to Spend](https://getonlane.com/info/what-is-an-intent-object) - [Apple Pay-Style Approvals for AI Agents: Native, White-Label Checkout Consent](https://getonlane.com/info/native-checkout-approvals-apple-pay-for-agents) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # ACP vs. UCP vs. Visa Intelligent Commerce: Agentic Commerce Protocols Explained > ACP, UCP, and Visa Intelligent Commerce solve different layers of agent commerce. Here is what each covers, who runs it, and where the gaps still are. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/acp-ucp-visa-intelligent-commerce-explained ## Key takeaways - ACP, the Agentic Commerce Protocol from OpenAI and Stripe, and UCP, the Universal Commerce Protocol from Google and Shopify, are merchant-side commerce APIs: they define how an agent reads a catalog and places an order. - Visa Intelligent Commerce (VIC) sits a layer lower, at the card networks, defining agent-initiated payment credentials rather than how a merchant exposes products. - Web Bot Auth is the identity layer underneath all of them: it lets an agent cryptographically prove which agent it is when it makes a request. - The specifications overlap less than the naming suggests, and the biggest gap is shared: none of them make a merchant that has adopted nothing agent-purchasable. - Lane is protocol-agnostic. Lane translates across ACP, UCP, and VIC, implements Web Bot Auth, and executes the checkout when a merchant supports none of them. - In Lane's view, protocol coverage is still a small slice of real commerce, so builders need a path that works at merchants their users already use today. ACP, UCP, and Visa Intelligent Commerce are not competing versions of the same thing. ACP and UCP are merchant-side commerce protocols that define how an agent discovers products and places an order, Visa Intelligent Commerce is a card network framework for agent-initiated payment credentials, and Web Bot Auth is the identity layer that lets a merchant verify which agent is knocking. Lane works across all four. 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. That includes merchants that have adopted one of these protocols and merchants that have adopted none of them. ## Why are there several agentic commerce protocols at once? Because agent commerce broke in several places simultaneously, and different parties own different pieces of the break. Understanding the stack makes the apparent protocol war look much more like division of labor. - **Merchants had no agent-readable interface.** Storefronts were built for humans with browsers. Checkout flows assume human data entry, so someone had to define a structured way for software to browse and order. That is what ACP and UCP address. - **Networks had no way to mark agent-initiated payments.** Card messages assumed an attended human. Visa Intelligent Commerce exists so an agent-initiated transaction can be presented as exactly that instead of as unattributed card-not-present traffic. - **Nobody could tell which agent was calling.** Merchants and CDNs saw anonymous automated requests and blocked them. Web Bot Auth gives an agent a cryptographic identity, which is a prerequisite for any of the layers above it to be trusted. - **The ecosystems have different centers of gravity.** A protocol authored inside the OpenAI ecosystem and one authored inside the Google and Shopify ecosystem will reflect those distribution realities, which is why two merchant-side specs exist rather than one. ## What is the Agentic Commerce Protocol (ACP)? The Agentic Commerce Protocol is a merchant-side specification associated with OpenAI and Stripe. It defines how an agent can retrieve a merchant's product information and drive a checkout through structured endpoints instead of by operating a human interface. - **Who runs it.** OpenAI and Stripe, with Stripe supplying payment rails on the merchant side. Its natural home is the OpenAI and ChatGPT ecosystem, which is also its largest distribution advantage. - **What it covers.** Agent-driven merchant checkout: catalog exposure, cart and order construction, and completing a purchase through a defined interface rather than a rendered page. - **Strongest where.** Merchants that want to be purchasable from inside ChatGPT and are comfortable with the merchant-of-record dynamics and payment relationships that come with the Stripe side of the stack. - **Honest limitation.** ACP is a merchant-side protocol with an ecosystem attached. It is not an embedded white-label wallet for third-party agent platforms, so a builder shipping its own consumer agent still has to solve consent, credentials, and coverage on its own. ## What is the Universal Commerce Protocol (UCP)? The Universal Commerce Protocol is the merchant-side specification associated with Google and Shopify. Like ACP, it aims to make commerce agent-accessible through structured interfaces rather than through pages designed for people. - **Who runs it.** Google and Shopify, which pairs a search and assistant distribution surface with a very large installed base of merchants on a single commerce platform. - **What it covers.** Agent-accessible catalog and commerce operations, with the practical benefit that platform-level adoption can enable many merchants at once rather than one integration at a time. - **Strongest where.** Merchants already on a platform that adopts it, and agent experiences that live close to Google's surfaces. Platform-mediated adoption is the fastest way to move a large number of stores. - **Honest limitation.** Adoption still depends on the merchant and the platform enabling it, and a second merchant-side protocol means agent builders now have two specifications to track rather than one. ## What is Visa Intelligent Commerce (VIC)? Visa Intelligent Commerce is a card network framework, not a merchant API. It addresses how a payment credential works when an agent is initiating the transaction on a person's behalf, which is a different question from how the agent found the product. - **Who runs it.** Visa, as the network. Participation runs through Visa's programs, including certification for enablers. - **What it covers.** Agent-initiated payment credentials: how an agentic transaction is represented to the network, how tokens are requested, and how the agent-on-behalf-of-a-human relationship is expressed rather than hidden. - **Why it is complementary.** A merchant-side protocol still needs a payment to clear. Network-level agentic credentials are what let that payment be authorized on better information than an anonymous card-not-present charge. - **Lane's standing.** Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Lane builds on VIC rather than competing with it. _Visa's Trusted Agent Protocol is a companion to Visa Intelligent Commerce: the credential framework says how to pay, the registry says who is knocking._ ## Where does Web Bot Auth fit? Web Bot Auth is the identity layer beneath the commerce protocols. It uses HTTP Message Signatures, standardized as RFC 9421, plus a key directory so an agent signs each request with a private key and publishes the corresponding public key where a merchant or CDN can check it. It matters because the default outcome for an anonymous agent is a block. Bot detection at the CDN layer, from providers such as Cloudflare, Akamai, and DataDome, cannot distinguish a legitimate agent acting for a real customer from abusive automation unless the agent can prove who it is. Lane's executor signs its requests with an Ed25519 key, publishes a self-hosted key directory, and passed Cloudflare's Web Bot Auth crawl verification. ## How do ACP, UCP, VIC, and Web Bot Auth compare? | | ACP | UCP | Visa Intelligent Commerce | Web Bot Auth | | --- | --- | --- | --- | --- | | Layer | Merchant commerce API | Merchant commerce API | Card network credential | Request identity | | Who runs it | OpenAI and Stripe | Google and Shopify | Visa | IETF work, driven with Cloudflare | | Core question answered | How does an agent order from this merchant? | How does an agent order from this merchant? | How is an agent-initiated payment represented? | Which agent is making this request? | | What a merchant does | Expose an ACP-compatible interface | Adopt it, often via its commerce platform | Accept agentic credentials through its processing path | Verify signatures, usually at the CDN | | What an agent builder gets | Structured checkout at adopting merchants | Structured checkout at adopting merchants | Payment credentials the network recognizes | An identity that stops the default block | | Coverage today | Adopting merchants only | Adopting merchants and platforms only | Depends on issuer and processing path | Growing, strongest where CDNs verify | | Lane's position | Supported, Lane translates to it | Supported, Lane translates to it | Certified enabler | Implemented, verified by Cloudflare's crawl test | ## Where do the protocols overlap, and where are the real gaps? ACP and UCP genuinely overlap: both are merchant-side commerce interfaces, and a merchant adopting one is solving roughly the same problem it would solve by adopting the other. VIC and Web Bot Auth do not overlap with either, because they answer different questions. - **Gap one: merchants that adopted nothing.** The largest gap is the simplest. If a merchant supports no agentic protocol, no amount of specification support helps an agent buy from it. This is the execution gap. - **Gap two: consent.** None of the merchant-side protocols define how a specific human approves a specific basket in a builder's own app, with a record that survives into a dispute. That is a wallet and consent problem, not a catalog problem. - **Gap three: who bears the payments burden.** A protocol does not give an agent builder a card vault, network standing, or a PCI program. Those remain required to actually move money. - **Gap four: cross-protocol translation.** A builder that wants to work everywhere ends up supporting several specifications with different shapes, plus a fallback for everything outside them. That work does not disappear because the specs exist. ## What do these protocols mean for a merchant? For a merchant, the protocols are a distribution question. Adopting an agent-readable interface makes the store purchasable inside assistants, and the choice usually follows whatever platform the merchant is already on. 1. **Start with your platform.** If your commerce platform supports a protocol, adoption is mostly configuration. Platform-mediated support is the cheapest path to being agent-purchasable. 2. **Decide your bot policy deliberately.** Blanket blocking of automated traffic also blocks legitimate agents buying on behalf of real customers. Verifiable agent identity is what makes a selective policy possible. 3. **Understand the payment relationship.** Different protocols come with different assumptions about who the merchant of record is and which rails the payment runs on. That is a commercial decision, not only a technical one. 4. **Expect to support more than one.** There is no sign of consolidation to a single merchant-side protocol, so the realistic plan is coverage across whichever surfaces send you demand. ## What do they mean for an agent builder? For an agent builder the calculus is different, and less comfortable. A merchant only has to serve the agents that come to it. A builder has to buy from whichever merchant the user names, which means protocol support alone is never sufficient. - **Users name merchants, not protocols.** A user asking for dinner from a specific restaurant or a specific product does not know or care which specification that merchant implements. An agent that can only transact at adopting merchants fails most requests. - **You still need a wallet and consent.** Reading a catalog is not paying. Approvals, tokenized cards, and an authorization record are separate infrastructure, and they are what users and issuers actually respond to. - **You still need to be allowed in.** Verifiable agent identity determines whether requests are served at all. Being a known, cryptographically verified agent is upstream of every commerce protocol. - **Multiplying integrations is the trap.** Supporting several specs plus a fallback, per merchant category, is how a small team accidentally becomes a payments and integrations company. ## Where does Lane fit across ACP, UCP, and VIC? Lane is deliberately protocol-agnostic. The bet is that no single standard wins outright soon, so the useful position is translation plus execution rather than allegiance. - **Lane translates across protocols.** Lane supports ACP and UCP on the merchant side, so a builder integrates Lane once instead of implementing each specification and tracking its revisions. - **Lane builds on the network layer.** Lane is a certified Visa Intelligent Commerce enabler, and Mastercard Agent Pay support is in progress as Lane expands across Visa and Mastercard rails. - **Lane implements verifiable identity.** Lane operates as a known, cryptographically verified agent under Web Bot Auth and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Platforms that integrate Lane inherit that identity. - **Lane fills the execution gap.** When a merchant supports none of the protocols, Lane still completes the purchase against that merchant, which is the case that covers most of the commerce users actually ask for. - **Lane owns the consent layer.** A user prompt becomes a structured, line-item purchase contract the user approves natively with a biometric or passkey, and the agent cannot buy outside the approved terms. > Protocols pave part of the road for the web's newest users. Something still has to drive the rest of it. ## How much of commerce do these protocols actually cover today? Lane's view, based on what Lane sees in production traffic, is that protocol coverage remains a small slice of the commerce agents get asked to perform. Lane's data suggests a handful of merchants, including DoorDash, Amazon, Uber Eats, and Uber, drive roughly 99% of agentic commerce demand, and merchant protocol adoption does not line up neatly with that concentration. The lesson Lane draws is not that the protocols are unimportant. It is that a builder cannot ship a product whose coverage is defined by a specification adoption curve. The requirement is a path that works at the merchants users already use, today, with protocol support as an optimization where it exists rather than a precondition. ## How should a builder choose? 1. **Start from your users' merchants.** List the merchants your users will actually name. Check how many support any agentic protocol. That number is usually the end of the pure-protocol strategy. 2. **Separate the layers before evaluating.** Catalog and ordering, payment credential, agent identity, and user consent are four different problems. A vendor or spec that solves one is not a substitute for the others. 3. **Prefer translation over allegiance.** Betting on one merchant-side protocol ties your coverage to someone else's adoption. Translating across them keeps that risk off your roadmap. 4. **Insist on a consent record.** Whatever you choose, make sure a specific human approval is bound to a specific purchase and carried to the card networks, so disputes work through the user's bank as normal. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com ACP and UCP are how merchants become readable to agents, Visa Intelligent Commerce is how agent payments become legible to the networks, and Web Bot Auth is how an agent proves it is itself. The gap none of them closes is the merchant that has adopted nothing, which is still most of them, and closing that gap is the reason Lane exists. ## Frequently asked questions ### What is the difference between ACP and UCP? Both are merchant-side agentic commerce protocols that define how an agent reads a catalog and places an order. ACP, the Agentic Commerce Protocol, comes from OpenAI and Stripe and is strongest inside the ChatGPT ecosystem. UCP, the Universal Commerce Protocol, comes from Google and Shopify and benefits from platform-level adoption. Lane supports and translates across both. ### Is Visa Intelligent Commerce a competitor to ACP or UCP? No. Visa Intelligent Commerce operates at the card network layer, defining how agent-initiated payment credentials work, while ACP and UCP define how a merchant exposes products and accepts an agent-driven order. They are complementary layers. Lane is a certified Visa Intelligent Commerce enabler and also supports ACP and UCP on the merchant side. ### Do I need to support all the agentic commerce protocols to build an agent that buys things? Not if you use infrastructure that translates across them. Lane is protocol-agnostic: it supports ACP and UCP, builds on Visa Intelligent Commerce, implements Web Bot Auth, and executes the purchase when a merchant supports none of them. Builders integrate Lane once rather than implementing and maintaining several specifications. ### What happens if a merchant supports no agentic commerce protocol? That is the execution gap, and it describes most merchants today. Protocol support cannot help an agent buy from a store that has not adopted anything. Lane completes the purchase against the merchant anyway, using the user's own card and the terms the user approved, which is why coverage does not depend on a merchant's adoption timeline. ### Where does Web Bot Auth fit relative to ACP, UCP, and VIC? Web Bot Auth sits beneath all of them as the identity layer. It uses HTTP Message Signatures (RFC 9421) and a published key directory so an agent can prove which agent it is on every request. Without verifiable identity, anonymous agents get blocked before any commerce protocol or payment credential becomes relevant. ### Which agentic commerce protocol will win? Lane does not bet on one. ACP and UCP each have a strong distribution ecosystem behind them, Visa Intelligent Commerce operates at a different layer entirely, and in Lane's view protocol coverage is still a small slice of real commerce. The practical strategy is translation across protocols plus execution everywhere else. ## Related articles - [Web Bot Auth: How AI Agents Prove Their Identity to Merchants (Cloudflare, RFC 9421, and Visa TAP)](https://getonlane.com/info/web-bot-auth-how-agents-prove-identity) - [What Is Agentic Commerce Middleware?](https://getonlane.com/info/what-is-agentic-commerce-middleware) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # Web Bot Auth: How AI Agents Prove Their Identity to Merchants (Cloudflare, RFC 9421, and Visa TAP) > Web Bot Auth lets an AI agent sign every HTTP request with a private key and publish the public key so merchants and CDNs can verify which agent is knocking. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/web-bot-auth-how-agents-prove-identity ## Key takeaways - Agents get blocked because they are anonymous, not because they are unwelcome: a merchant's bot defenses cannot tell a legitimate agent buying for a real customer from abusive automation. - Web Bot Auth solves that with cryptography: the agent signs every HTTP request using HTTP Message Signatures (RFC 9421) and publishes its public key in a key directory that verifiers can fetch. - Verification is a signature check against a published key, so a merchant or CDN gets a cryptographic answer to "which agent is this" rather than a guess based on IP addresses and user agent strings. - Lane's executor signs its requests with an Ed25519 key, publishes a self-hosted key directory, and passed Cloudflare's Web Bot Auth crawl verification. - Lane is also registered in Visa's Trusted Agent Protocol (TAP) registry alongside Cloudflare, which pairs cryptographic request identity with network-level agent recognition. - Agent platforms that integrate Lane inherit this verified identity: Lane manages the keys, the signing, and the directory on their behalf. Web Bot Auth lets an AI agent prove which agent it is on every HTTP request. The agent signs each request with a private key using HTTP Message Signatures (RFC 9421) and publishes the matching public key in a key directory, so merchants and CDNs can cryptographically verify the caller rather than guess from IP addresses. Lane implements it, and Lane's agent passed Cloudflare's Web Bot Auth crawl verification. 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. Verifiable identity is the layer underneath all of that, because an agent that cannot identify itself does not get served in the first place. ## Why do AI agents get blocked at merchants? The reflex answer is that merchants do not want agents. That is mostly wrong. Merchants deploy bot defenses because they have real abuse problems, and the defenses have no way to distinguish a good agent from a bad one. - **Anonymity is the default.** An HTTP request from an agent carries nothing trustworthy about who sent it. A user agent string is a self-report that anyone can copy, so it cannot be the basis of a trust decision. - **Bot defenses are built for abuse.** Providers such as Cloudflare, Akamai, and DataDome exist to stop credential stuffing, scraping, inventory hoarding, and card testing. Faced with unidentifiable automation, blocking is the correct default. - **The available signals are indirect.** IP reputation, request rates, and behavioral heuristics infer intent from side effects rather than from identity. They necessarily produce false positives, and legitimate agents land in them. - **The merchant cannot opt in to what it cannot name.** Even a merchant that actively wants agent-driven orders has no mechanism to allow specific agents when no agent can prove its identity. > The blocking problem is an identity problem. You cannot allowlist an anonymous caller. ## What is Web Bot Auth? Web Bot Auth is a set of conventions, developed in the open through IETF work and driven substantially by Cloudflare, that gives automated clients a verifiable cryptographic identity at the HTTP layer. It has two halves. - **Signed requests.** The agent signs each outbound HTTP request with a private key using HTTP Message Signatures, defined in RFC 9421, and attaches the signature and its metadata as HTTP headers. - **A published key directory.** The agent publishes its public keys at a well-known location, described by the HTTP message signatures directory draft, so any verifier can fetch the key referenced by a signature and check it. The design is deliberately boring, which is its strength. There is no new transport, no handshake to negotiate, and nothing for a merchant to install. A verifier that can fetch a URL and check an Ed25519 signature can verify an agent. ## How do HTTP Message Signatures (RFC 9421) work? RFC 9421 defines a general mechanism for signing parts of an HTTP message so a recipient can verify integrity and origin. It is public standards material, and the mechanics are worth understanding if you are evaluating agent identity. 1. **Choose the covered components.** The signer selects which parts of the request the signature covers. For agent identity these are typically derived components such as the method, authority, and path, so the signature is bound to the specific request being made. 2. **Build the signature base.** The covered components are serialized into a canonical string, in a defined order, together with signature parameters such as the key identifier, the algorithm, a creation timestamp, an expiry, and a tag identifying the purpose. 3. **Sign it.** The signer produces a signature over that canonical string with its private key. Ed25519 is the common choice for Web Bot Auth: small keys, small signatures, fast verification. 4. **Attach two headers.** The request carries a Signature-Input header describing what was signed and with which key, and a Signature header carrying the signature bytes themselves. 5. **The verifier reconstructs and checks.** A recipient rebuilds the same canonical string from the request it received, fetches the public key named by the key identifier, and verifies the signature. If the request was altered or the key does not match, verification fails. _Because the signature is bound to request components and carries a creation time and expiry, a captured signature cannot be usefully replayed against a different request or reused indefinitely._ ## What is a key directory, and why does publishing keys matter? A signature is only meaningful if the verifier can obtain the right public key. Web Bot Auth handles that with a directory: the agent operator publishes its public keys, in JSON Web Key form, at a well-known HTTPS location that verifiers can fetch and cache. - **It makes verification permissionless.** Any merchant or CDN can verify a signed request without a prior relationship with the agent operator, a shared secret, or an onboarding process. - **It ties identity to a domain.** The directory is served over HTTPS from the operator's own domain, so the key is bound to a named, accountable entity rather than to an anonymous client. - **It supports key rotation.** Signatures reference a specific key identifier, so an operator can publish a new key and retire an old one without breaking verifiers mid-flight. - **It scales without coordination.** One published directory serves every verifier on the internet. That is what makes the model workable across millions of merchants. ## How does a merchant or CDN verify a signed agent? 1. **Notice the signature headers.** The incoming request carries Signature-Input and Signature. Their presence tells the verifier this client is claiming a verifiable identity rather than staying anonymous. 2. **Resolve the key.** The verifier reads the key identifier from the signature parameters and fetches the corresponding public key from the operator's published directory, typically with caching. 3. **Verify the signature.** The verifier rebuilds the signature base from the request as received and checks the signature against the public key, along with the creation and expiry times. 4. **Apply policy.** Verification produces an identity, not a decision. The verifier then applies its own policy: allow, rate limit differently, require additional steps, or deny. In practice this often happens at the CDN before the request reaches the merchant's application. ## What does Web Bot Auth prove, and what does it not? Being precise here matters, because verifiable identity is frequently oversold. Web Bot Auth answers a narrow question extremely well and deliberately leaves the rest to other layers. | Question | Does Web Bot Auth answer it? | | --- | --- | | Which agent operator sent this request? | Yes, cryptographically, via a signature over a published key | | Was this request tampered with in transit? | Yes, for the components the signature covers | | Is this a replay of an earlier signature? | Largely mitigated, through covered components and expiry | | Is this operator trustworthy? | No, that is the verifier's policy decision | | Did a human authorize this purchase? | No, that is the consent layer, such as an approved intent | | Is the payment credential valid? | No, that is the card network layer, such as Visa Intelligent Commerce | The stack only works when all of those layers are present. Verifiable identity gets the agent served, an approved intent proves the human authorized the purchase, and network-recognized credentials get the payment authorized. ## How has Lane implemented Web Bot Auth? Lane runs Web Bot Auth in production. The identity posture is deliberately public: the signatures, the key directory, and the registry entries are all verifiable by anyone, because identity that cannot be checked is worthless. - **Every request is signed.** Lane's executor signs its requests using HTTP Message Signatures with an Ed25519 key. Signing is not conditional or opportunistic, it is how Lane's agent presents itself. - **Lane publishes a key directory.** Lane hosts its own key directory, so any merchant or CDN can resolve the key referenced by a Lane signature and verify it independently. - **Cloudflare verification passed.** Lane passed Cloudflare's Web Bot Auth crawl verification, which matters because a large share of the internet's bot policy is enforced at the CDN layer rather than in merchant application code. - **Lane is in Visa's TAP registry.** Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, so Lane's agent is recognized at the card network layer as well as at the request layer. - **Lane operates as a known agent, by design.** The strategy is to be identifiable rather than evasive. Lane operates as a known, cryptographically verified agent, which is the only posture compatible with merchants making deliberate policy decisions. ## What do agent platforms get by integrating Lane? Verifiable identity is real infrastructure work: key generation and custody, a signing path on every outbound request, a published directory, rotation, and verification testing against the CDNs that actually enforce policy. Agent platforms that integrate Lane inherit the result instead of rebuilding it. - **Lane manages the keys.** Key generation, custody, and rotation are Lane's responsibility. The builder does not run a signing key or a key directory. - **Lane signs on the platform's behalf.** Purchases executed through Lane are made by an agent that is already signed and already verifiable, so the builder does not implement RFC 9421 in its own request path. - **Registry standing comes with it.** Lane's Cloudflare verification and Visa TAP registration apply to the agent that actually performs the purchase, which is Lane's. - **It is one integration, not four layers.** Identity, consent, payment credentials, and merchant execution arrive together. Builders add payments to their agent without becoming a payments company or an identity company. ## How does Web Bot Auth relate to Visa's Trusted Agent Protocol? Web Bot Auth and Visa's Trusted Agent Protocol are complementary answers to the same question at different layers. Web Bot Auth is cryptographic proof at the request layer: this specific HTTP request was signed by a key belonging to a named operator. Visa's Trusted Agent Protocol is recognition at the network layer: this operator is a listed participant with obligations in a payments context. A merchant benefits from both. The signature tells it the caller is who it claims to be, and the registry tells it that the caller is a known participant in the payment ecosystem rather than merely a well-behaved crawler. Lane holds both positions, and pairs them with recognized agentic payment credentials as a certified Visa Intelligent Commerce enabler. ## Where is Web Bot Auth heading? The standards work is public and progressing: RFC 9421 is a published standard, the signature directory conventions are moving through IETF drafts, and verification is being adopted where it is most useful, at the CDN edge. The direction is toward agent identity being a normal, checkable property of a request rather than a special arrangement. The consequence for builders is worth stating plainly. As verification becomes standard, the split will not be between agents that are allowed and agents that are blocked by heuristics. It will be between agents with verifiable identity and agents without one, and the second group will find the internet closing. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com Web Bot Auth turns "trust me" into "check my signature", which is the only version of agent identity that scales to millions of merchants. Lane signs every request with an Ed25519 key, publishes a key directory anyone can verify against, passed Cloudflare's crawl verification, and is registered in Visa's Trusted Agent Protocol registry, so platforms building on Lane start with an identity merchants can actually recognize. ## Frequently asked questions ### What is Web Bot Auth? Web Bot Auth is an emerging standard that gives automated clients a verifiable cryptographic identity at the HTTP layer. The agent signs each request with a private key using HTTP Message Signatures (RFC 9421) and publishes the matching public key in a key directory, so merchants and CDNs can verify which agent is calling instead of guessing from IP addresses and user agent strings. ### What is RFC 9421 and why does it matter for AI agents? RFC 9421 is the published IETF standard for HTTP Message Signatures. It defines how a signer selects which parts of a request to cover, builds a canonical signature base including a key identifier and expiry, and attaches Signature-Input and Signature headers. For AI agents it is the mechanism that turns an anonymous request into a verifiable, attributable one. ### Why do AI agents get blocked at checkout? Because they are anonymous, not because merchants reject agents on principle. Bot defenses from providers such as Cloudflare, Akamai, and DataDome are built to stop scraping, credential stuffing, and card testing, and unidentifiable automation looks exactly like that. Verifiable identity through Web Bot Auth is what makes a selective merchant policy possible. ### Has Lane implemented Web Bot Auth? Yes. Lane's executor signs its requests using HTTP Message Signatures with an Ed25519 key, Lane publishes a self-hosted key directory that any verifier can fetch, and Lane passed Cloudflare's Web Bot Auth crawl verification. Lane is also registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, pairing request-layer identity with network-layer recognition. ### Do agent platforms have to implement Web Bot Auth themselves if they use Lane? No. Agent platforms that integrate Lane inherit Lane's verified identity, because Lane is the agent that executes the purchase. Lane manages key generation, custody, rotation, request signing, and the published key directory on their behalf, so the builder does not implement RFC 9421 or run a signing key of its own. ### Does Web Bot Auth prove that a user authorized a purchase? No, and it is not meant to. Web Bot Auth proves which agent operator sent a given request and that the request was not tampered with. Proving a human approved a specific purchase is the consent layer, which Lane handles with an approved, line-item intent confirmed by a biometric or passkey before anything is bought. ## Related articles - [ACP vs. UCP vs. Visa Intelligent Commerce: Agentic Commerce Protocols Explained](https://getonlane.com/info/acp-ucp-visa-intelligent-commerce-explained) - [Why Your AI Agent Gets Blocked at Checkout, and How One Integration Fixes It](https://getonlane.com/info/why-your-ai-agent-gets-blocked-at-checkout) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # Why Giving Your AI Agent a Virtual Card Is Only 5% of the Battle > Minting a virtual card for your agent takes an afternoon and every competitor has one. The hard part is finding the right product and showing it natively to your users. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/giving-your-agent-a-virtual-card-is-table-stakes ## Key takeaways - A virtual card for your agent is table stakes: several APIs will mint one in an afternoon, and it answers the easiest question in the whole flow. - The actual battle is everything around the card: turning "get me sushi" into an exact orderable item, showing real options to your user inside your own app, and completing the purchase at a real merchant. - Discovery is the differentiator users can see. An agent that presents three real dinner options with photos and prices feels magic; an agent that holds a card number does not. - Lane resolves vague requests into concrete, orderable products and returns structured options your app renders natively, then executes the purchase after one scoped approval. - If the demo works only because a human pasted a card number into chat, the product is 5% built. Giving your AI agent a virtual card solves about 5% of agentic commerce, and it is the 5% that was never hard. The card answers "what do we pay with." It says nothing about finding the right product, showing real options to your user, getting their approval, or completing a checkout at an actual merchant. Lane exists for the other 95%: discovery, native product presentation, consent, and execution. 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. The card is one small piece of that sentence. Everything else in it is the work. ## Why is the card the easy part? Because card issuance is a commodity. Multiple APIs will mint a virtual card for your agent in an afternoon, your bank's app probably does it in two taps, and by now a card number in the agent's hand is simply expected. If your launch tweet is "our agent has a card," so does everyone else's. A card also does nothing on its own. A card number cannot search a menu, compare prices, sign in to a merchant, pass a checkout, or prove that your user actually approved the purchase. Teams discover this the day after issuance works: the agent is funded and still cannot buy anything. > The card was never the product. The purchase is. ## What is the actual battle? Watch what has to happen between a user typing "get me sushi" and dinner arriving. The card appears for roughly one second of that journey. The rest is a chain of harder problems, and each one is visible to your user in a way the card never is. ### Discovery: from a vague sentence to an exact orderable item "Get me sushi" is not an order. Somewhere between that sentence and a purchase, someone has to pick the restaurant, the roll, the size, the quantity, and the delivery address, against a live menu with real prices and real availability. Do it wrong and the user gets the wrong dinner charged to their card, which is worse than no dinner at all. This is the part of agentic commerce that users experience as intelligence. It is also the part a card API cannot help with at all. Lane resolves vague requests into concrete, orderable products across merchants, iterating with the user when the request is ambiguous, so what reaches approval is an exact line item and not a guess. ### The showcase: real products, rendered natively in your app Discovery that your user cannot see might as well not exist. The difference between a toy and a product is your app showing three real dinner options with photos, names, and prices, inside your own interface, for the user to tap. Not a pasted link. Not a screenshot of a website. Your app, feeling like the store. Lane returns discovery results as structured product options, with images and prices, that your app renders natively in whatever design you already have. The user picks an option in your UI, and that choice flows straight into the purchase contract they approve. Your product gets the moment that feels magic; Lane stays invisible behind it. ### Consent, execution, and the aftermath After the user picks, three more problems remain, and they are covered in depth elsewhere in this hub. The user approves a scoped, Apple Pay-style purchase contract rendered in your app. Lane executes the checkout against the merchant as a known, cryptographically verified agent, which matters because merchant defenses block anonymous automation. And when the order confirms, changes, or needs a refund, the consent trail Lane carries to the card networks means the user keeps their bank's normal protections. ## How do the two stacks compare? - **Card-only stack:** the agent holds a credential it cannot use anywhere hard. The demo works when a human does the shopping, the human does the choosing, and the agent pastes the number at the end. That is a wallet, not an agent. - **Full stack:** the user says what they want, sees real options in your app, approves once, and the thing arrives. Discovery, showcase, consent, and execution handled; the card reduced to the implementation detail it always was. The test is simple: delete the human from your demo. If nobody choses from a menu, nobody pastes a number, and the purchase still completes correctly, you have the 95%. If the demo dies, you have a card. ## What does this look like with Lane? 1. **Your user asks in your app.** "Get me sushi," "find me running shoes under $150," "book us a table Friday." Your agent and your interface, exactly as they are today. 2. **Lane resolves real options.** Concrete, orderable products from real merchants, returned as structured options with images and prices, iterating with the user through your UI when the request needs narrowing. 3. **Your app shows them natively.** The options render in your design. The user taps one. No links out, no other brand in the flow. 4. **One scoped approval.** The choice becomes a line-item purchase contract the user confirms with a biometric or passkey, Apple Pay-style, in your app. 5. **Lane executes and reports back.** Lane completes the checkout against the merchant and the confirmation lands back in your product. The user closed their phone three steps ago. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com If your agent already has a virtual card, good: that box is checked, along with everyone else's. The products that win from here are the ones whose users can say what they want, see real options, and get the thing. That is the 95%, and it is one integration away. ## Frequently asked questions ### I can already issue virtual cards for my AI agent. What am I missing? The purchase itself. A card answers what the agent pays with, but not how it finds the right product, shows options to your user, gets scoped approval, or completes checkout at a real merchant. Lane covers that full path: discovery, native product presentation, an approved intent, and execution, with the card as one small component inside it. ### How does my agent find the right product to buy? Through discovery infrastructure, not the card. Lane resolves a vague request like "get me sushi" into exact, orderable items from real merchants, with live prices and availability, iterating with the user when the request is ambiguous. What reaches the approval step is a precise line item, so the user is never charged for a guess. ### Can my app show product options natively instead of sending users a link? Yes. Lane returns discovery results as structured product options with names, images, and prices, and your app renders them in your own interface and design. The user picks inside your product, that choice becomes the purchase contract they approve, and Lane stays invisible throughout. No links out, no redirects, no other brand in your flow. ### Is a virtual card API enough to launch buying in my AI app? Only for a demo where a human still does the shopping. In production the agent must resolve the product, present options, obtain enforceable user consent, and pass a merchant checkout that blocks anonymous automation. A card API provides none of those. Treat the card as table stakes and evaluate providers on discovery, consent, and execution. ### What is discovery in agentic commerce? Discovery is the step that turns a user's intent into an exact orderable item: which merchant, which product, which options, at what real price. It is the part of an agentic purchase users experience as intelligence, and the part card APIs skip entirely. Lane performs discovery across merchants and returns structured options your app can display natively. ## Related articles - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) - [Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents](https://getonlane.com/info/virtual-cards-vs-payment-infrastructure-for-ai-agents) - [What Does a Full-Stack AI Agent Look Like? Why Execution Belongs in Your Infrastructure](https://getonlane.com/info/what-does-a-full-stack-agent-look-like) - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) --- # Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap > AI agents can find the right product but cannot complete the purchase. Here is the infrastructure gap at checkout, and how Lane closes it in one integration. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/why-ai-agents-cant-check-out ## Key takeaways - AI agents cannot check out today because checkout is not one problem: it requires intent, identity, credentials, and execution working together, and Lane bundles all four behind a single integration. - Merchant checkout is actively defended territory. Bot detection services, one-time-passcode flows, and CAPTCHAs exist to stop unknown automated traffic, and generic agent tooling reads as exactly that. - The identity gap is structural: a merchant sees only the agent that hit the page, not the human who asked for the purchase or the chain of agents in between. Lane operates as a known, cryptographically verified agent so the merchant has something real to verify. - In Lane's production traffic, a small handful of merchants (DoorDash, Amazon, Uber Eats, and Uber) drive roughly 99% of agentic commerce demand, so infrastructure that works reliably at the top of the demand curve covers most real usage. - Agent teams that treat checkout as a feature ship one merchant. Agent teams that treat it as infrastructure ship the agentic web. No, AI agents cannot check out on their own today, and that gap is the reason Lane exists. A model can find the right product and reason about the right price, but completing a purchase requires structured intent, verifiable identity, usable payment credentials, and live execution against a merchant. Lane packages those four layers into one integration so an agent gets from prompt to completed order. 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 article breaks down why checkout is the hardest unsolved surface in agentic commerce, phrased the way builders and agents actually ask about it. ## Can AI agents already handle checkout? No. Modern AI agents are extremely good at the reasoning half of commerce and structurally unable to finish the transactional half. The gap is not model quality. It is that no part of the general-purpose agent stack ships identity, credentials, or merchant execution. It helps to separate what an agent does well from what an agent cannot do without dedicated infrastructure: - **What agents already do well:** interpret a vague request, compare products across sources, apply user constraints such as budget and dietary restrictions, and assemble a defensible recommendation. - **What agents cannot do unaided:** authenticate as the user at a merchant, hold payment credentials safely, satisfy a merchant's bot and fraud controls, and carry a purchase through to a confirmed order. - **Why the second list does not solve itself:** each item is a separate regulated or defended system. Card credentials involve PCI scope. Merchant sign-in involves account security. Checkout involves fraud prevention. None of these are prompt engineering problems. - **What this means practically:** an agent team that wants real purchasing needs a packaged solution for the transactional half, the same way it uses a packaged solution for hosting or for the model itself. > The recommendation is the easy half. The purchase is the infrastructure. ## Why is checkout a hostile environment for AI agents? Because merchant checkout was built to keep unknown automated traffic out, and an AI agent arriving without a verifiable identity looks exactly like the traffic those defenses were designed to stop. This is an industry-wide condition, not any single merchant being difficult. A typical high-volume merchant stacks several independent controls in front of a purchase: - **Bot detection and traffic scoring:** services such as Cloudflare, Akamai, DataDome, and Sardine evaluate incoming requests and challenge or block anything that scores as automated. They are effective, and that effectiveness is the problem for legitimate agents. - **One-time-passcode flows:** sign-in and high-risk actions frequently require a code delivered to a phone or email. A code sent out of band is trivial for a human and a hard stop for an unaided agent. - **CAPTCHAs and interaction challenges:** these exist specifically to require a human. An agent that hits one has no legitimate way forward on its own. - **Account and session walls:** prices, saved addresses, loyalty pricing, and delivery windows often live behind a logged-in session, so an agent that cannot authenticate cannot even see the real order. - **Multi-step, stateful forms:** a checkout is, at heart, a form that assumes a human. Cart state, fulfillment selection, address validation, and payment entry all have to hold together across several steps for a single order to complete. Generic agent tooling fails at this layer for a simple reason: it has no standing. It cannot prove who it is, it cannot prove a human authorized the purchase, and it has no relationship with the ecosystem doing the verification. Lane's answer at this layer is narrow and specific: Lane operates as a known, cryptographically verified agent, so a merchant or CDN has something real to check rather than an anonymous request to score. _The vendors above are named as examples of the bot detection layer merchants deploy. Nothing about their products is the obstacle. The obstacle is that a legitimate purchasing agent and an abusive scraper are indistinguishable until identity exists._ ## What is the identity problem in agentic commerce? The identity problem is that a merchant can only see the agent that hit the page. It cannot see the human who asked for the purchase, and it cannot see the chain of agents that carried the request from that human to the merchant. Everything a merchant needs to make a risk decision is invisible at the moment it has to decide. | What the merchant needs to know | What the merchant actually sees | | --- | --- | | Is a real human behind this purchase? | An inbound request with no human attached | | Did that human authorize these exact items and this exact amount? | A cart that appeared without provenance | | Which agent platform is responsible for this traffic? | An unidentified client | | Is this a legitimate purchase or an abuse pattern? | A traffic score with no way to distinguish the two | | Who bears liability if this goes wrong? | Nothing in the request answers this | This is why blocking is the rational default. Faced with an unidentified purchasing client, the safe choice for a merchant is to refuse it, and legitimate agents get caught in the same net as bad actors. Solving agentic checkout therefore starts upstream of checkout itself: someone has to give the agent an identity worth verifying, and give the merchant a cryptographic way to verify it. ## Isn't this just a UX problem? No. Treating agentic checkout as a UX problem is the most common and most expensive misdiagnosis in this category. A nicer approval sheet does not give the agent an identity, credentials, or the ability to complete an order, and teams that start with the interface discover the real work only after they ship. There are four missing layers, and they only work bundled: 1. **Intent.** A user prompt has to become a structured, line-item purchase contract with merchant, items, amounts, and limits, approved before anything executes. Without it there is no record of what the human actually authorized. 2. **Identity.** The agent has to be a known, verifiable participant rather than anonymous traffic. Without it every other layer is blocked at the door. 3. **Credentials.** A real payment instrument has to be usable at the merchant without the agent ever handling the card number. Without it there is nothing to pay with, and with the wrong design there is a compliance problem instead. 4. **Execution.** Something has to actually drive the purchase to a confirmed order at the merchant, under the approved terms. Without it the first three layers produce a very well-authorized nothing. Any one of these layers on its own is inert. Intent without execution is a receipt for a purchase that never happens. Credentials without identity get declined or blocked. Identity without credentials cannot pay. The reason agentic checkout has stayed unsolved is that the four layers have to arrive together, and no single existing product in the payments stack covers all four. > Four layers, one integration. Anything less and the agent stalls at the merchant. ## Why does this matter now? Because consumer demand for agentic purchasing has already arrived and the infrastructure has not. The clearest public example: a viral iMessage agent moment that drew more than 500,000 views, with payments embedded directly in the conversation. People wanted it immediately. It worked on exactly one merchant. The reason it worked on one merchant was not ambition or engineering skill. It was that every additional merchant meant another sign-in flow, another set of bot controls, another checkout to conquer, and another compliance question. Per-merchant integration does not scale, so the product could not grow past the demo even while the audience was there. That is the shape of the gap. Distribution for agentic commerce is solved: agents already sit inside the interfaces people use every day. Reasoning is solved: models can plan a purchase competently. Checkout is the bottleneck, and it is a bottleneck that individual agent teams cannot economically clear one merchant at a time. > "Agents are the web's new users, so they need their own lane." (Lane) ## Which merchants actually matter for agentic commerce? Far fewer than most roadmaps assume, and this is the most useful thing Lane has learned from running real traffic. In Lane's production traffic, a handful of merchants (DoorDash, Amazon, Uber Eats, and Uber) drive roughly 99% of agentic commerce demand. Lane's data suggests agentic demand is dramatically more concentrated than general e-commerce. That concentration changes the strategy for anyone building in this space: - **Coverage breadth is the wrong first metric:** a long merchant list looks impressive and does not move usage if the top merchants are missing or unreliable. - **Depth at the top of the curve is the right first metric:** infrastructure that nails the highest-demand merchants covers most of what real users actually ask their agents to buy. - **The categories are predictable:** food delivery, everyday e-commerce, and rides dominate. These are habitual, high-frequency purchases where the decision is small and the friction of doing it manually is annoying. - **The tail still matters, later:** breadth becomes valuable once the head is solid, because the head is what makes an agent worth opening twice. Lane transacts in production today on food delivery ordering with DoorDash and on e-commerce checkouts with Shopify stores and Amazon, with travel and restaurant reservations built and rolling out. The order of operations is deliberate: solve the merchants demand is already pointed at, then widen. ## What does Lane bundle into one integration? Lane bundles the four missing layers so an agent team integrates once instead of solving intent, identity, credentials, and execution separately. The framing that matters to a builder is the outcome, not the plumbing: the agent asks for a purchase under approved terms, and a confirmed order comes back. | Layer | What Lane provides | What the builder no longer owns | | --- | --- | --- | | Intent | A structured, line-item purchase contract the user approves before execution, with terms enforced throughout | Designing authorization semantics and proving what the user agreed to | | Identity | A known, cryptographically verified agent identity, registered in Visa's Trusted Agent Protocol registry alongside Cloudflare | Establishing standing with merchants and the verification ecosystem | | Credentials | The user's own card tokenized in Lane's PCI-compliant vault, plus single-use virtual Visa cards where a funded program fits | PCI scope, card storage, and issuing relationships | | Execution | Lane executes the checkout against the merchant and returns a confirmed order | Per-merchant integration work and everything checkout throws at an agent | Two properties of the bundle matter as much as its contents. First, the agent never sees the card number, so the builder adds payments without inheriting a payments company's compliance surface. Second, Lane is white-label and invisible to end users: approvals render natively inside the builder's own interface as a scoped, Apple Pay-style confirmation, with no redirect out to a third party. The user-facing result is a single moment of consent. The user sees exactly what will be bought and for how much, confirms with a biometric or passkey check, and the purchase proceeds under those terms. Authorization information carries through to the card networks, so the user keeps their bank's normal liability protections. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com ## What changes when the checkout gap closes? The product category changes. An agent that can only recommend is a better search box, and it competes with every other search box. An agent that can complete a purchase becomes the place the task actually gets done, which is a different and much more defensible position. Concretely: a food agent stops producing a list of restaurants and places the order. A shopping agent stops producing links and buys the item. A travel agent stops producing an itinerary and books it. In every case the reasoning was already good enough. The missing piece was always the last mile, and the last mile is infrastructure. Lane treats that last mile as the product. Agent teams keep the reasoning, the interface, and the relationship with their users, and Lane carries intent, identity, credentials, and execution behind one integration so checkout stops being the reason a good agent ships against a single merchant. ## Frequently asked questions ### Why can't my AI agent just complete a checkout by itself? Because checkout requires four things an agent does not have: a structured record of what the user authorized, a verifiable identity a merchant can trust, payment credentials it can use without handling card data, and the ability to drive a purchase to confirmation at the merchant. Lane provides all four behind one integration. ### Are merchants deliberately blocking AI agents? Mostly no. Merchants deploy bot detection, one-time-passcode flows, and CAPTCHAs to stop abuse, and an unidentified purchasing agent is indistinguishable from the traffic those controls target. Blocking is the rational default. Lane operates as a known, cryptographically verified agent so merchants have something real to verify instead of anonymous traffic. ### Isn't agentic checkout mainly a user experience problem? No. A better approval interface does not give an agent identity, credentials, or the ability to finish an order. The missing layers are intent, identity, credentials, and execution, and they only work bundled. Lane packages all four, then renders the approval natively inside the builder's own interface. ### How many merchants does an agent actually need to support? Fewer than most teams assume. In Lane's production traffic, a handful of merchants including DoorDash, Amazon, Uber Eats, and Uber drive roughly 99% of agentic commerce demand. Lane's data suggests depth at the top of the demand curve covers most real usage, and breadth matters after the head is reliable. ### Where does Lane transact in production today? Lane runs live production transactions on food delivery ordering with DoorDash and e-commerce checkouts with Shopify stores and Amazon. Travel bookings for flights and hotels, plus restaurant reservations, are built and rolling out. Lane is a certified Visa Intelligent Commerce enabler and Mastercard Agent Pay support is in progress. ### Does the agent ever see my card number? No. With Lane, the user's existing card is tokenized in Lane's PCI-compliant vault, and the agent never sees the card number. No end-user KYC is required to bring your own card. The agent operates only under the approved terms of the intent the user confirmed. ### What happens if an agent tries to buy something the user did not approve? It cannot. With Lane, the user prompt becomes a structured, line-item purchase contract with merchant, items, and amounts, and the user approves it before execution. Those terms are enforced throughout the purchase, so the agent is physically unable to buy anything outside the approved intent. ## Related articles - [Why Your AI Agent Gets Blocked at Checkout, and How One Integration Fixes It](https://getonlane.com/info/why-your-ai-agent-gets-blocked-at-checkout) - [What Does a Full-Stack AI Agent Look Like? Why Execution Belongs in Your Infrastructure](https://getonlane.com/info/what-does-a-full-stack-agent-look-like) - [What Is Agentic Commerce Middleware?](https://getonlane.com/info/what-is-agentic-commerce-middleware) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # Why Stripe Link Doesn't Solve Payments for AI Agents > Stripe Link is excellent at payment capture for human checkout. AI agents need execution: sign-in, cart, checkout, identity, consent. Lane covers that layer. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/why-stripe-link-doesnt-work-for-ai-agents ## Key takeaways - Stripe Link is very good at what it is built for: fast, low-friction payment capture for returning human shoppers with saved credentials. - An AI agent needs something different. Before payment can happen, something has to sign in to the merchant, build the cart, and drive the checkout, and prove that a human authorized the purchase. - The distinction is capture versus execution. Link accelerates the payment step of a checkout a human is already driving. Lane drives the checkout itself. - Lane covers the execution layer end to end: verified agent identity, an approved intent that records what the user authorized, credentials the agent never sees, and completion of the purchase at the merchant. - This is not a defect in Link. It is a scoping question, and choosing the wrong scope is the most common reason an agent payments project stalls. Stripe Link does not solve payments for AI agents because Link solves payment capture, and agents are blocked earlier than payment. Lane covers the layer Link does not target: signing in to the merchant, assembling the cart, driving the checkout to completion, proving agent identity, and carrying the user's consent terms through the purchase. 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 piece is a scoping comparison, not a criticism. Link is strong inside its scope, and the scope is the point. ## What is Stripe Link actually built to do? Stripe Link is a consumer payment method that stores a shopper's payment details and lets them pay in one click on any merchant that accepts it. Its job is to remove friction from the payment step for a returning human buyer, and it does that job well. Link's design strengths are worth stating plainly, because they explain both why it is popular and why it does not extend to agents: - **Saved credentials across merchants:** a shopper enrolls once and their payment details are available at the next Link-enabled checkout, which measurably improves conversion. - **One-click pay for returning users:** the flow is optimized around a human who is already on the merchant's checkout page and ready to complete a purchase. - **Merchant-side integration:** the merchant adopts Link, and it appears as a payment option inside the merchant's existing checkout. - **Human-in-the-loop by design:** authentication and confirmation assume a person present at the moment of payment, which is exactly right for the use case it targets. Every one of those properties is a good decision for human checkout. Together they describe a product that starts working at the moment a checkout has already been reached, which is precisely the moment an agent has not yet reached. ## Where does an AI agent get stuck before payment? An agent gets stuck well upstream of the payment field. By the time a human uses Link, a long sequence of work has already been done by that human, and for an agent none of that work is done or automatic. 1. **Signing in to the merchant.** Real prices, saved addresses, delivery windows, and loyalty terms usually sit behind an authenticated session. An agent that cannot sign in cannot even see the correct order, and sign-in commonly requires a one-time passcode delivered out of band. 2. **Building the cart.** Someone has to resolve the request to specific products, variants, quantities, and fulfillment options at that merchant. A payment method does not select a burrito or a shoe size. 3. **Driving the checkout.** Checkout is a multi-step stateful flow: address validation, shipping or delivery selection, tips, taxes, and confirmation. A checkout is really a form, and agents don't do forms. 4. **Proving agent identity.** Merchants and their bot detection layers treat unidentified automated traffic as risk. An agent needs to be a known, verifiable participant before it is allowed to proceed at all. 5. **Carrying consent terms.** The purchase has to be provably bounded by what the user actually authorized: this merchant, these items, this amount. Nothing in a payment method captures or enforces that. The moment an agent must authenticate or execute, it hits a wall. That wall sits before the payment step, so a better payment step does not move it. > Capture optimizes the last field of a checkout. Agents need the whole checkout driven. ## Capture versus execution: what is the actual difference? Capture means collecting and charging a payment instrument once a purchase is ready to be paid for. Execution means producing that purchase in the first place: authenticating, assembling the order, satisfying the merchant's controls, and carrying it to a confirmed transaction under approved terms. | Requirement | Payment capture (what Link targets) | Agent execution (what Lane targets) | | --- | --- | --- | | Store payment credentials for reuse | Yes, this is the core strength | Yes, with the card tokenized in Lane's PCI-compliant vault and never exposed to the agent | | Reduce friction for a returning human buyer | Yes, one-click pay | Not the goal; the buyer is an agent acting under an approved intent | | Sign in to the merchant on the user's behalf | Out of scope | Yes, part of the execution layer | | Add items to a cart at the merchant | Out of scope | Yes, part of the execution layer | | Drive a multi-step checkout to a confirmed order | Out of scope | Yes, Lane executes the checkout against the merchant | | Present a verifiable agent identity to merchants | Out of scope | Yes, a known, cryptographically verified agent identity | | Record and enforce what the user authorized | Out of scope | Yes, via an approved line-item intent enforced throughout execution | Read the table as scope, not scorecard. A product built for human checkout has no reason to sign in to merchants or drive carts, because a human already does both. Agents remove the human from those steps, and that is what creates a new infrastructure requirement rather than a new payment method requirement. _Stripe is also active in agentic commerce more broadly through the Agentic Commerce Protocol with OpenAI, which is a merchant-side protocol effort and a different product from Link. This article is specifically about Link's scope._ ## What does Lane cover that a payment method cannot? Lane covers the execution layer end to end, which is why it is infrastructure rather than a payment method. An agent team integrates Lane once and gets identity, authorization, credentials, and completion together. - **Verified agent identity:** Lane operates as a known, cryptographically verified agent. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, with Mastercard Agent Pay support in progress. - **An approved intent:** the user's prompt becomes a structured, line-item purchase contract covering merchant, items, and amounts. The user approves it before execution and the terms are enforced throughout, so the agent is physically unable to buy outside them. - **Credentials the agent never sees:** the user's existing card is tokenized in Lane's PCI-compliant vault with no end-user KYC required, and Lane also issues single-use virtual Visa cards for funded and incentive programs. - **Execution to a confirmed order:** Lane executes the checkout against the merchant and returns the result, including sign-in and the multi-step flow that sits between a request and a purchase. - **A native approval moment:** Lane is white-label and invisible to end users. The approval renders inside the builder's own interface as a scoped, Apple Pay-style confirmation with a biometric or passkey check, with no redirect out. Authorization information carries through to the card networks, so the user keeps their bank's normal liability protections. That matters for adoption: users are being asked to let software spend their money, and the answer to "what if something goes wrong" has to be the familiar one. ## How should a builder choose between them? The choice is decided by who is driving the purchase. If a human is on your checkout page and you want them to pay faster, a capture product like Stripe Link is a good fit and Lane is not what you need. If software is completing the purchase on a user's behalf at a third-party merchant, you need the execution layer. A useful test: ask which system is responsible for reaching the merchant's confirmation page. If the answer is "the user," you have a capture problem. If the answer is "our agent," you have an execution problem, and execution is where agent projects stall. **Start building on Lane.** The fastest path is the Lane MCP: connect it and your agent can draft, get approval for, and execute real purchases in the same session. Full guides and API reference in the docs. Read the docs: https://docs.getonlane.com Stripe Link is a well-built answer to a real problem, and agents are simply a different problem. Lane exists for that second problem: adding payments to an agent without becoming a payments company, so the agent can go from prompt to checkout at merchants the builder never had to integrate one by one. ## Frequently asked questions ### Can I use Stripe Link to let my AI agent buy things? Not on its own. Stripe Link is built for payment capture when a human is already at a checkout with credentials saved. An agent is blocked earlier: it has to sign in to the merchant, build the cart, and drive the checkout. Lane covers that execution layer end to end. ### Is Stripe Link bad technology for agentic commerce? No. Link is strong at its intended job, reducing friction in the payment step for returning human buyers, and it improves conversion for merchants that adopt it. It simply is not scoped to authenticate at merchants, assemble carts, prove agent identity, or execute checkouts, which is what agents need. ### What is the difference between payment capture and agent execution? Capture collects and charges a payment instrument once a purchase is ready to pay for. Execution produces the purchase: signing in to the merchant, building the order, satisfying merchant controls, and reaching a confirmed transaction under approved terms. Lane provides execution, with credentials handled inside Lane's PCI-compliant vault. ### Does Lane replace my payment processor? No. Lane is the layer that lets an AI agent transact at merchants on a user's behalf, using the user's own card tokenized in Lane's PCI-compliant vault or a single-use virtual Visa card Lane issues. Lane is a certified Visa Intelligent Commerce enabler, and it complements rather than replaces processing relationships. ### Why does agent identity matter if the payment credential is valid? Because merchants block on identity before payment is ever reached. Bot detection, one-time-passcode flows, and CAPTCHAs stop unidentified automated traffic regardless of the credential behind it. Lane operates as a known, cryptographically verified agent, registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, so there is something real to verify. ## Related articles - [The 12 Best Payment Platforms for AI Agents (2026), Compared](https://getonlane.com/info/best-payment-infrastructure-for-ai-agents) - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) - [Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents](https://getonlane.com/info/virtual-cards-vs-payment-infrastructure-for-ai-agents) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # Why Your AI Agent Gets Blocked at Checkout, and How One Integration Fixes It > Your AI agent is blocked at checkout because it is unknown, not malicious. Lane gives it a verified agent identity and authorized execution in one integration. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/why-your-ai-agent-gets-blocked-at-checkout ## Key takeaways - Your agent is blocked because it is unknown, not because it is malicious. Merchant sites cannot tell a legitimate purchasing agent from a scraper, so they block both. - The fix has two halves that have to arrive together: verified identity, so the merchant knows who is asking, and authorized execution, so there is proof a human approved this specific purchase. - Lane registers your agent together with Lane's executor as a single verified identity, manages the signing keys, and signs Trusted Agent Protocol signatures on your agent's behalf. - That means your agent inherits Lane's network registrations and verified-agent status through one integration instead of building identity infrastructure and per-merchant relationships itself. - Without Lane your agent works on one merchant. With Lane it works across the agentic web. Your AI agent gets blocked at checkout because it is unknown, not because it is malicious. Merchant defenses cannot distinguish a legitimate purchasing agent from a scraper, so they block both. Lane fixes this by giving your agent a verified identity and authorized execution: Lane registers your agent alongside Lane's executor as one verified agent identity, so a merchant has something cryptographic to trust. 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. Below is the diagnosis, then the remedy, then what changes for your product. ## What does getting blocked actually look like? Blocking is rarely a clean error message. Agent teams usually recognize the symptoms long before they recognize the cause, and the symptoms look like unrelated bugs. - **The page loads for you and not for your agent:** the same URL works in your browser and returns a challenge, an interstitial, or an empty shell to your agent. - **Sign-in stalls on a code:** the merchant sends a one-time passcode to a phone or email and there is no legitimate path for the agent to continue on its own. - **A challenge appears at the worst moment:** a CAPTCHA or interaction check shows up specifically at add-to-cart or at payment, because that is where merchants concentrate their controls. - **Prices and options look wrong:** logged-out sessions show different prices, no saved addresses, and no real delivery windows, so the order the agent builds is not the order the user wanted. - **It works, then stops:** a flow that succeeded in testing degrades as traffic grows, because volume is what makes unidentified automation look like an attack. - **It works on exactly one merchant:** the flow you hand-tuned holds, and every new merchant is a fresh multi-week fight. Every symptom above has the same root cause, which is why fixing them one at a time never converges. ## Why do merchants block a legitimate purchasing agent? Because from the merchant's side there is no observable difference between a legitimate purchasing agent and an abusive one. Merchants deploy bot detection services such as Cloudflare, Akamai, DataDome, and Sardine, plus one-time-passcode flows and CAPTCHAs, to defend against credential stuffing, scraping, inventory abuse, and card testing. Those controls score traffic, and unidentified automation scores badly. Put yourself in the merchant's position at the moment of the request. What is knowable is thin: | Question the merchant has to answer | What an unidentified agent request tells them | | --- | --- | | Who is this client? | Nothing verifiable | | Is there a real human behind this purchase? | Nothing verifiable | | Did that human approve these items and this amount? | Nothing verifiable | | Is this platform accountable for its traffic? | Nothing verifiable | | Is this a purchase attempt or an abuse pattern? | Indistinguishable | Given that table, blocking is the correct engineering decision. A merchant that lets unidentified automation through absorbs real fraud losses. So legitimate agents get caught in defenses built for bad actors, and the fix cannot be to look more human. The fix is to stop being unknown. > Your agent is not being punished for what it does. It is being blocked for what it cannot prove. ## Does making your agent look more human ever work? It is the instinct almost every team has first, and it is the wrong direction. Trying to appear human puts your agent in an adversarial position against systems that are staffed, funded, and continuously improved specifically to detect that behavior. You are betting your product roadmap on staying ahead of a fraud vendor's model, which is not a bet with a good long-run price. The practical failures show up quickly: - **It degrades under volume:** an approach that survives a demo becomes conspicuous at scale, which means the flow breaks exactly when the product starts working. - **It never stabilizes:** detection improves continuously, so the work is permanent maintenance with no accumulated advantage. - **It puts you on the wrong side of the merchant:** a merchant that eventually identifies the traffic has every reason to shut it down, which is a poor foundation for a business that depends on that merchant. - **It solves nothing about consent:** even if traffic passes, there is still no proof that a human authorized this purchase, so the underlying trust problem is untouched. The opposite posture is the durable one. Rather than hiding what your agent is, make it identifiable and make the authorization behind it provable. An agent that announces itself with a verifiable cryptographic identity, backed by registration with the card networks, is something a merchant can decide to trust. Anonymous traffic is something a merchant can only decide to score. ## What is the actual fix? The fix is verified identity plus authorized execution. Identity answers "who is asking," and authorization answers "on whose behalf, and for what." Merchants need both, because an identified agent with no proof of user consent is still a risk, and a consented purchase from an unidentified client is still unverifiable. 1. **Become a known agent, cryptographically.** Requests have to be signed in a way a merchant or CDN can verify independently, using published keys and an open standard rather than a private arrangement. 2. **Be registered where the ecosystem looks.** A signature only helps if whoever checks it can look you up. Registration in the card networks' agent registries is what turns a signature into a recognized identity. 3. **Carry proof that a human authorized this purchase.** The user's request becomes a structured, line-item purchase contract with merchant, items, and amounts, approved before anything executes and enforced throughout. 4. **Keep the payment credential out of the agent.** The user's card is tokenized in Lane's PCI-compliant vault and the agent never sees the card number, which removes both the risk and the compliance surface. 5. **Execute under those terms.** Lane executes the checkout against the merchant within the approved intent, so the agent is physically unable to buy anything outside what the user confirmed. Each of those steps is buildable in principle. Together they are an infrastructure program, involving cryptographic key management, network registrations, PCI scope, and a consent model that holds up when something goes wrong. That is the work Lane does once so agent teams do not each do it separately. ## How does Lane make your agent a verified agent? Lane registers your agent together with Lane's executor as a single verified agent identity. Your agent does not have to establish standing with the verification ecosystem on its own: it inherits Lane's network registrations and verified-agent status through the integration. - **Lane signs every request:** Lane's executor uses HTTP Message Signatures, the RFC 9421 standard behind Web Bot Auth, with an Ed25519 key published in a self-hosted key directory. Merchants and CDNs can verify Lane's agent cryptographically rather than guessing from traffic patterns. - **Lane manages the keys:** key generation, publication, and rotation sit with Lane. Your team does not run a key directory or take on signing infrastructure to be verifiable. - **Lane signs Trusted Agent Protocol signatures on your agent's behalf:** Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, and your agent transacts under that verified identity. - **Lane holds the network standing:** Lane is a certified Visa Intelligent Commerce enabler, with Mastercard Agent Pay support in progress. Lane's verified agent identity has been checked against Cloudflare's Web Bot Auth crawl test. - **Lane carries the authorization:** the approved intent travels with the purchase, and authorization information carries through to the card networks, so the user keeps their bank's normal liability protections. The important structural point: this is verified identity and working relationships with the card networks, not a private arrangement with any bot detection vendor. Lane's position is that a legitimate agent should be verifiable by anyone who cares to check, using open standards and public registries, which is exactly what makes it portable across merchants. _Cloudflare, Akamai, DataDome, and Sardine are named here only as examples of the bot detection layer merchants commonly deploy. Lane does not claim any arrangement that exempts its traffic from those systems. The mechanism is cryptographic verifiability, plus Lane's registrations with the card networks._ ## What should you check before trusting any identity layer? Not every claim about agent identity means the same thing, so it is worth knowing what to ask. These are the questions Lane expects to be asked, and the ones any serious provider should answer directly. - **Is the verification independent?** Can a merchant or CDN confirm the agent's identity on its own, using open standards and published keys, without taking the provider's word for it? Lane signs with HTTP Message Signatures (RFC 9421) and publishes an Ed25519 key in a self-hosted key directory. - **Is it registered with the networks?** Standing with the card networks is what makes identity portable rather than bilateral. Lane is a certified Visa Intelligent Commerce enabler and is in Visa's Trusted Agent Protocol registry alongside Cloudflare. - **Does it cover authorization, not just identity?** Identity alone does not tell a merchant that a human approved this purchase. Lane pairs verified identity with a line-item intent the user approves before execution. - **Where does card data live?** If the answer puts card numbers anywhere near your agent, you have acquired PCI scope. With Lane, the card sits in Lane's PCI-compliant vault and the agent never sees it. - **Who maintains merchant coverage?** Ask whether coverage is your ongoing work or the provider's. With Lane it is maintained centrally, so expansion does not become a recurring integration project for your team. ## What changes for your product after one integration? Coverage stops being a function of how many merchant flows your team has hand-tuned. Without Lane your agent works on one merchant. With Lane it works across the agentic web, because identity and execution move with Lane rather than being rebuilt per merchant. | Before Lane | After one Lane integration | | --- | --- | | Your agent is anonymous traffic to every merchant | Your agent transacts under a verified, cryptographically signed agent identity | | Each merchant is a separate integration project | One integration, and Lane executes the checkout against the merchant | | Card handling puts PCI scope on your roadmap | The user's card is tokenized in Lane's PCI-compliant vault and your agent never sees it | | No provable record of what the user approved | A line-item intent the user approves before execution, enforced throughout | | Approval means sending users out to a third party | A native, Apple Pay-style approval inside your own interface, with no redirect | Lane is white-label and invisible to end users, so none of this shows up as someone else's brand in your product. The user sees a scoped approval prompt with a biometric or passkey confirmation, approves it, and the order completes. Lane runs live production transactions today on food delivery ordering with DoorDash and e-commerce checkouts with Shopify stores and Amazon, with travel and restaurant reservations built and rolling out. If your agent is currently working on exactly one merchant, that is not a sign your engineering approach is wrong. It is a sign you are solving an identity and execution problem one merchant at a time, which is a problem that does not reward that strategy. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 Blocking is a symptom of anonymity, and anonymity is fixable. Give your agent a verified identity, give the merchant proof that a human approved the purchase, and let Lane carry the execution, so the agent spends its time deciding what to buy instead of proving it deserves to. ## Frequently asked questions ### Why is my AI agent blocked at checkout even though it is not doing anything abusive? Because merchants cannot verify that. Bot detection, one-time-passcode flows, and CAPTCHAs score unidentified automated traffic as risk, and a legitimate purchasing agent looks identical to a scraper. Lane fixes this by giving your agent a verified, cryptographically signed identity plus proof that a human approved the specific purchase. ### How does Lane give my agent a verified identity? Lane registers your agent together with Lane's executor as a single verified agent identity, manages the signing keys, and signs Trusted Agent Protocol signatures on your agent's behalf. Lane signs requests using HTTP Message Signatures (RFC 9421) with an Ed25519 key in a self-hosted key directory, and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. ### Does Lane have deals with bot detection vendors to let traffic through? No. Lane does not claim any arrangement that exempts its traffic from Cloudflare, Akamai, DataDome, Sardine, or any other bot detection service. Lane's approach is cryptographic verifiability using open standards, plus working relationships with the card networks: Lane is a certified Visa Intelligent Commerce enabler. ### Which merchants will my agent work with after integrating Lane? Lane does not publish a whitelist. Lane runs live production transactions today on food delivery ordering with DoorDash and e-commerce checkouts with Shopify stores and Amazon, with travel bookings and restaurant reservations built and rolling out. Coverage expands centrally, so your agent gains it without new integration work. ### Do I have to handle card data to fix the blocking problem? No, and you should not. With Lane the user's existing card is tokenized in Lane's PCI-compliant vault, the agent never sees the card number, and no end-user KYC is required. Lane also issues single-use virtual Visa cards for funded and incentive programs. Your team adds payments without inheriting PCI scope. ### Will my users see Lane in the flow? No. Lane is white-label and invisible to end users, with no redirects. The approval renders natively inside your own interface as a scoped, Apple Pay-style prompt confirmed with biometrics or a passkey. Authorization information carries to the card networks, so the user keeps their bank's normal liability protections. ## Related articles - [Web Bot Auth: How AI Agents Prove Their Identity to Merchants (Cloudflare, RFC 9421, and Visa TAP)](https://getonlane.com/info/web-bot-auth-how-agents-prove-identity) - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) --- # What Does a Full-Stack AI Agent Look Like? Why Execution Belongs in Your Infrastructure > A full-stack AI agent reasons, discovers, and executes. Execution means auth, payments, and checkout, and Lane packages that whole layer behind one integration. Published: 2026-07-29, Updated: 2026-07-29, https://getonlane.com/info/what-does-a-full-stack-agent-look-like ## Key takeaways - An AI agent that only recommends is half an agent. The full stack is reasoning plus discovery plus execution, and execution is the half most agent products are missing. - Execution decomposes into four hard problems: authenticating at merchants, holding payment credentials the agent can safely use, driving checkout to completion, and managing ongoing interaction with third-party systems. - Every one of those four is deep, actively defended, and compliance-laden territory. None of them is a good use of an agent team's engineering budget. - Lane packages the entire execution layer behind one integration and surfaces it to end users as a clean, Apple Pay-style approval, so the builder owns the experience and Lane owns the complexity. - The test of a full-stack agent is simple. Your app stops recommending the trip. It books the trip. A full-stack AI agent does three things: it reasons about what the user wants, it discovers the right option in the real world, and it executes the transaction. Lane exists because the third capability is the one almost no agent has. Lane packages the whole execution layer, authentication, payment credentials, and checkout, behind one integration so an agent can finish what it recommends. 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 essay is about why execution belongs in infrastructure rather than in your product, whatever category of agent you are building. ## The half-agent problem Most AI agents shipping today stop one step before the thing the user wanted. A shopping agent produces a beautifully reasoned list of three jackets and a link. A food agent explains which restaurant is best given the user's constraints and hands over a menu. A travel agent assembles a coherent five-day itinerary and then asks the user to go book it. That final handoff is where the value leaks out. The user came with a task, not a research question, and the agent returned homework. Worse, the handoff is where the agent becomes replaceable: any product can produce a recommendation, and a recommendation competes with every search box and every group chat. Half-agents are not a failure of ambition. They are the predictable result of a stack where reasoning is a commodity you can buy and execution is not something you can buy at all, so teams build what is available and stop where the market stops them. > An agent that recommends competes with search. An agent that completes replaces the errand. ## What the full stack actually contains A full-stack AI agent has three layers, and each one is doing genuinely different work. Naming them separately matters because teams routinely assume that being excellent at the first two implies competence at the third. - **Reasoning:** understanding an underspecified request, applying the user's constraints and history, and deciding what should happen. This is what foundation models are extraordinary at, and it is increasingly table stakes. - **Discovery:** grounding the decision in what is actually available right now: real inventory, real prices, real delivery windows, real availability. This is data and integration work, and plenty of teams do it well. - **Execution:** making the transaction happen in the world. Signing in, paying, checking out, and handling everything that comes after. This is the layer that turns an assistant into an agent, and it is where products stall. The asymmetry is the whole point. Reasoning improves for free every time a better model ships. Discovery is tractable with engineering effort. Execution does not improve on its own and does not yield to effort in the same way, because it is not a technical problem in isolation. It is a technical problem entangled with security, fraud prevention, and financial regulation. ## Execution is four problems, not one The word "execution" hides how much is inside it. When an agent team says "we just need to add checkout," they are usually describing four separate engineering programs, each with its own failure modes and its own regulatory shadow. ### Authentication: signing in to merchants Real commerce lives behind a login. Accurate prices, saved addresses, delivery windows, loyalty pricing, and order history are all session-dependent, which means an agent that cannot authenticate cannot even see the correct order. Sign-in also frequently involves a one-time passcode delivered out of band, so it is not merely a credentials problem. ### Payments: credentials the agent can safely use An agent needs a real payment instrument and must never hold a raw card number. That constraint is not a preference, it is PCI scope, and the moment a team stores card data it has acquired a compliance program alongside its product. The alternative most teams reach for, asking users to re-enter a card per merchant, destroys the experience that made the agent appealing. ### Checkout: driving the purchase to completion Checkout is a multi-step, stateful gauntlet: cart construction, fulfillment selection, address validation, taxes, tips, and confirmation, defended by bot detection services and CAPTCHAs that exist specifically to stop unidentified automation. Underneath, it is a form that assumes a human. Every merchant's version differs, and every version changes without notice. ### Ongoing interaction: everything after the order The transaction is not the end of the relationship with a third-party system. Orders get modified, delayed, substituted, cancelled, and refunded. Reservations move. Bookings need changes. An agent that can buy but cannot manage what it bought hands the user a new category of problem in exchange for solving an old one. | Execution layer | What makes it hard | What it costs a team that builds it | | --- | --- | --- | | Authentication at merchants | Session-dependent data and out-of-band verification codes | Continuous per-merchant maintenance with no end state | | Payment credentials | Card data cannot touch the agent | PCI scope, vaulting, and issuing relationships | | Checkout completion | Stateful multi-step flows behind bot detection | A dedicated team per merchant category | | Ongoing interaction | Modifications, cancellations, refunds, and disputes | An operational and support burden that grows with volume | Read that table as a build-versus-buy argument. Any single row is a quarter of engineering work. All four rows, maintained indefinitely, across a growing merchant set, is a company. It is specifically a payments and infrastructure company, which is not the company most agent teams set out to build. ## Why no agent team should build this in-house Not because it is impossible, but because it is undifferentiated and permanent. Nobody chooses an agent product because its team wrote its own card vault. Users choose an agent because it understands them and gets the task done, and every engineer assigned to execution plumbing is an engineer not working on that. Three properties make execution unusually bad to own: - **It is hostile territory, permanently:** merchant defenses are supposed to stop unidentified automation. This is not a bug that gets fixed. The only durable answer is to stop being unidentified, which requires standing with the card networks and cryptographic verifiability, not more engineering. - **It is compliance-laden:** touching card data means PCI obligations, audits, and a security posture that scales with your growth rather than your ambition. Compliance is a fixed cost that does not get cheaper with cleverness. - **It has no finish line:** every merchant changes its checkout, every network updates its agent requirements, every fraud vendor tunes its models. Execution is a subscription to maintenance, and it is far cheaper shared across many agent products than owned by one. This is the same logic that made hosting, authentication, and payment processing into infrastructure categories. Every serious product needs them, none of them differentiate, and all of them are better bought once than built repeatedly. Execution for agents is the current instance of that pattern. **Try Lane right now.** Text Lane's concierge and watch a real agentic purchase happen: ask it to order food, find a product, or plan a trip. Approval and payment are handled by Lane end to end. Text +1 (628) 316-5644: sms:+16283165644 ## What the full stack looks like in each builder category The execution layer is the same regardless of what your agent is for. What changes is which recommendation your product currently stops at, and what it becomes once it can finish. 1. **Shopping agents.** Today: a curated set of options and outbound links, with conversion handed to someone else. With an execution layer: the agent buys the item at the merchant under an intent the user approved, and the purchase, the receipt, and the follow-up all stay inside your product. 2. **Concierge agents.** Today: a well-reasoned suggestion the user has to act on, whether that is dinner, groceries, or a gift. With an execution layer: the errand is done, which is the only outcome a concierge is actually judged on. 3. **Travel agents.** Today: an itinerary, then a handoff to booking sites where prices and availability have already drifted. With an execution layer: your app stops recommending the trip, it books the trip, and it handles the changes afterward. 4. **Search agents.** Today: a better answer, monetized through referral if at all. With an execution layer: the answer terminates in a transaction, which is a fundamentally stronger business model than sending traffic elsewhere. In every category the reasoning was already good enough, and the missing capability was the same one. That is the strongest evidence that execution is infrastructure: when four different product categories are blocked by an identical layer, that layer wants to be a shared dependency rather than four private implementations. ## The division of labor: you own the experience, Lane owns the complexity Lane packages the entire execution layer behind one integration. An agent team keeps everything users can see and everything that makes the product theirs, and Lane carries the part that is hard, defended, and regulated. | You own | Lane owns | | --- | --- | | The reasoning, the taste, and the personality of your agent | Verified agent identity and standing with the card networks | | Your interface and every pixel of the approval moment | Payment credentials, held in Lane's PCI-compliant vault | | The relationship with your users | Execution of the checkout against the merchant | | Which categories and merchants matter to your product | Merchant coverage, maintained centrally as it expands | | Your business model | Compliance surface, so you add payments without becoming a payments company | Lane is white-label and invisible to end users, with no redirects. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare, with Mastercard Agent Pay support in progress. Lane runs live production transactions today on food delivery ordering with DoorDash and e-commerce checkouts with Shopify stores and Amazon, with travel bookings and restaurant reservations built and rolling out. ## What the end user actually experiences None of the complexity above should be visible to the person using your agent, and with Lane it is not. The user experiences a single moment of consent that feels like the Apple Pay double-click, because that is the interaction pattern people already trust with their money. 1. **The user asks for something.** A normal request in normal language, inside your product, with no mode switch and no handoff to a payments interface. 2. **The request becomes an intent.** Lane turns the prompt into a structured, line-item purchase contract naming the merchant, the items, and the amounts. The user sees the exact purchase before it exists. 3. **The user approves it natively.** A scoped approval renders inside your own interface, confirmed with a biometric or passkey check. The user sees exactly what will be bought and for how much. 4. **Lane executes under those terms.** Lane executes the checkout against the merchant using the user's own tokenized card. The agent never sees the card number and is physically unable to buy anything outside the approved intent. 5. **The user keeps their protections.** Authorization information carries through to the card networks, so the user is still protected by their bank in the same way as any other card purchase. That is the whole surface area of the execution layer as far as the user is concerned: one approval, then a completed order. Everything else is infrastructure doing its job quietly, which is the only acceptable standard for infrastructure. > "An agent that only recommends is half an agent." (Lane) ## The thesis, stated plainly The web's new users are agents, and they need infrastructure of their own. The web the agent arrives at was built for humans holding cards and typing into forms, and until that gap is filled by shared infrastructure, every agent product independently rediscovers the same wall in the same place. A full-stack agent is not a bigger model or a longer context window. It is reasoning and discovery attached to an execution layer that actually completes transactions in the world, with the user in control of every purchase and the builder in control of the experience. Lane provides that execution layer so agent teams can ship the complete product instead of the recommendation half. If you are building a shopping, concierge, travel, or search agent and you want it to finish what it starts, this is the layer to integrate rather than the layer to build. **Talk to the Lane team.** Building a consumer agent, concierge, or commerce experience? Walk us through it and we will map the integration with you. Book a demo: https://getonlane.com/contact ## Frequently asked questions ### What does "full-stack AI agent" mean? A full-stack AI agent reasons about what the user wants, discovers the real-world option, and executes the transaction. Most agents cover only the first two and hand the user a recommendation. Lane provides the execution layer, covering authentication at merchants, payment credentials, checkout completion, and ongoing order interaction, behind one integration. ### Why shouldn't my team build the execution layer ourselves? Because it is undifferentiated, hostile, and permanent. Card handling brings PCI scope, merchant checkouts change constantly, and bot detection systems exist to stop unidentified automation. None of it differentiates your agent. Lane packages the whole layer so you add payments without becoming a payments company. ### What exactly does execution include beyond taking a payment? Four things: signing in to merchants where real prices and delivery options live, holding payment credentials the agent can use without ever seeing a card number, driving multi-step checkout to a confirmed order, and managing what comes after, including modifications, cancellations, and refunds. Lane covers all four. ### Does my agent lose control of the user experience with Lane? No. Lane is white-label and invisible to end users, with no redirects. You own the reasoning, the interface, and the approval moment, which renders natively inside your product as a scoped, Apple Pay-style confirmation with a biometric or passkey check. Lane owns identity, credentials, and merchant execution behind it. ### How does the user stay in control of what the agent buys? With Lane, the user's prompt becomes a structured, line-item purchase contract naming merchant, items, and amounts, which the user approves before anything executes. Terms are enforced throughout execution, and the agent cannot buy outside them. ### Which kinds of agents is this execution layer for? All of them. Shopping agents that currently return links, concierge agents that return suggestions, travel agents that return itineraries, and search agents that return answers are all blocked by the same missing layer. Lane provides it once, so each category can complete the task instead of describing it. ## Related articles - [Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap](https://getonlane.com/info/why-ai-agents-cant-check-out) - [How to Add Payments to Your AI Agent Without Becoming a Payments Company](https://getonlane.com/info/add-payments-to-ai-agent-without-becoming-payments-company) - [How to Build a Concierge Agent That Books Flights, Hotels, and Restaurants](https://getonlane.com/info/build-concierge-agent-flights-hotels-reservations) - [Payment Infrastructure for AI Agents: The Complete Guide (2026)](https://getonlane.com/info/payment-infrastructure-for-ai-agents-complete-guide) ---