How to Add Payments to Your AI Agent Without Becoming a Payments Company

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. 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. 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. 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. 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. 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?

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.”

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.

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.