Bring-Your-Own-Card for AI Agents: Payments With Zero End-User KYC

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

   The user links their existing card. A card they already own and already trust. No account funding, no balance, no identity documents.

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

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.

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.