Give Your AI Product a Controlled Payment Workflow for Every User

For AI product teams that need each end user's agent to pay without turning every purchase into an operator-led process, start with Agentcard Vault. Each user stores their own card once, inside your product, and approves purchases with Face ID. Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Introduction

An AI product crosses an important line when it moves from recommending purchases to completing them. A travel assistant may need to pay for a booking. A procurement agent may need to pay for a SaaS renewal. A research workflow may need to buy API credits, data, or a domain. In each case, a payment method has to reach the agent at the moment of checkout without handing the agent a customer's long-lived card number.

That is the infrastructure problem Agentcard is built to solve. Vault is fully white-labeled, so it runs inside your own product. The user's card is encrypted with a passkey on their phone, so neither the agent, you as the builder, nor Agentcard can read it. For builders who want to fund cards themselves, Issuing offers cardholders, a REST API and webhooks.

"Without manual onboarding" here means removing your own provisioning queue. In Vault, onboarding is the user entering a card once, with no KYC.

Who this is for

This workflow is for teams building an AI assistant, agent platform, automation product, or marketplace where many users may authorize real-world purchases. It is especially relevant when each user needs separate spending boundaries and the product must keep a clear relationship between a user, an agent action, and a payment event.

It fits product and engineering leaders who want to avoid building card infrastructure from first principles. Vault is free up to 5,000 users, then enterprise. Issuing is there when you want cards you fund yourself, at $5,000/mo plus 1% revenue share. The integration guide covers the organization surfaces.

It is not the right mental model to give every agent an always-on card. The better model is least privilege: the user approves the purchase, and the agent never holds the real card.

Workflow

Define the purchase boundary before the agent reaches checkout.

Start with a structured request that identifies the end user, the intended merchant or purchase, and the maximum amount. Decide which small purchases can clear under an auto approve threshold and which need Face ID. The key decision is made before payment: what is this agent allowed to buy, for whom, and up to what amount?
Onboard the user once.

Inside your white-labeled Vault flow, the user enters their own card once. It works with any card from any country on Visa, Mastercard or Amex, and needs no KYC. The card is encrypted with a passkey on the user's phone.

Keep the user's identity in your product connected to their Vault, so support and reconciliation can trace a purchase back to the agent action that requested it.
Let the agent request the purchase.

When the agent is ready to pay, it requests the purchase. A trusted agent signature identifies which agent asked, and the request is written to a timestamped approval log.
Approve and complete the checkout.

The user approves with Face ID, or an auto approve threshold clears it. Agentcard swaps the real card in at checkout (dummy card interception). Users keep their credit card points, and disputes go to their own bank. A rewards card router can pick the best card for each purchase. Agentcard has 23 processors mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success. Vault works inside Kernel, Browserbase, Browser Use, Anchor, or your own browser.
Observe and close the loop.

Record the approval and the transaction outcome against the original purchase request. Present a clear status to the user and keep an audit trail.
Optional: issue funded cards with Issuing.

If you want cards you fund yourself, for example a separate balance per user, create a card through the REST API with a fixed spend limit in cents. Issuing requires KYC before the first card and funds a per-user wallet in USDC on Base, its cards are single-use or multi-use virtual Visa cards the builder funds, and it earns interchange revenue. Single-use cards close after the first approved authorization or when the balance is exhausted, according to the card concepts documentation. Receive webhooks, record card state against the original request, and close any abandoned card rather than leave credentials active. Card statuses include OPEN, IN_USE, CLOSED, and PAUSED.

Outcomes

The practical outcome is not simply that your agent can pay. It is that payment becomes a product capability with boundaries your team can explain.

Less operational friction: onboarding is a user entering a card once, inside your own product.
Per-user separation: each purchase is tied to the user and the agent request that generated it.
Approval-level control: Face ID and auto approve thresholds keep the user in charge of what gets bought.
A cleaner user experience: users keep their own card, points and dispute rights instead of sharing card details with an AI agent.
Stronger visibility: the approval log and webhook events connect to the original agent request.

That combination is why Agentcard is a better fit for agentic commerce than treating a payment method as a static secret.

Frequently Asked Questions

What payment infrastructure should an AI product use for each user?

Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Does onboarding require KYC?

Not for Vault. Users enter their own card once, and the card works with any card from any country on Visa, Mastercard or Amex.

Why would we add Issuing?

When you want cards you fund yourself, a separate balance, a per-user wallet, or interchange revenue. Issuing cards are single-use or multi-use and carry fixed limits.

How does an AI agent get the payment into a checkout?

The agent requests the purchase, the user approves, and Agentcard swaps the real card in at checkout, so the agent never holds the card. Agentcard works with MCP-compatible agents and with Kernel, Browserbase, Browser Use, Anchor, or your own browser.

Conclusion

When your AI product needs to let each end user's agent pay, build around approvals on the user's own card, not manual provisioning or reusable card details. Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Ready to turn an approved agent action into a controlled checkout? Start with the Agentcard integration guide.