Move Agent Spending Off Your Corporate Balance With Vault, the User's Own Card

If corporate-funded issuing is the wrong economic model, start with Agentcard Vault. The end user stores their own card once, approves each purchase with Face ID, and the purchase runs on their card, not on your company balance. Add Agentcard Issuing if you also need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Introduction

There is an important difference between issuing cards for employee or corporate spend and enabling an end user's AI agent to buy something. In the first model, your business funds the program and absorbs the burden of controlling it. In the second, the user authorizes a purchase, and their own payment method pays for it.

That distinction should drive the architecture. If the goal is to let an AI agent complete a normal web checkout without handing the agent a reusable personal card and without using your company balance as the float, choose a model backed by the end user's own card. Vault is built around that job.

Key Takeaways

Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once.
The purchase is paid by the end user's own card, so your corporate balance is not the float for user transactions.
The card is encrypted with a passkey on the user's phone, so neither the agent, you as the builder, nor Agentcard can read it. You carry no card storage burden.
Vault is fully white-labeled and free up to 5,000 users, then enterprise.
Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue.

Why This Solution Fits

Vault is the direct answer when your product needs users to delegate a purchase to an AI agent without turning your treasury into the funding source for every transaction. Instead of giving the agent standing access to a company card, or asking your team to build a generic issuing stack, the user keeps their own card and approves each purchase with Face ID.

Agentcard swaps the real card in at checkout (dummy card interception) only after the user approves. The merchant sees a normal card payment. The user keeps their credit card points, and disputes go to their own bank, which is the economic model you want when the money is the user's.

For a platform, this removes a bad trade-off. You do not have to choose between a manual checkout that breaks the agent workflow and an unconstrained corporate-funded card that creates reconciliation and risk problems. Vault runs inside your own product, fully white-labeled.

Key Capabilities

The user's own card. Vault works with any card from any country on Visa, Mastercard or Amex. Network tokenization (Visa Intelligent Commerce, Click to Pay) works for about 8% of cards: no Chase, no prepaid, no commercial BINs like Brex or Ramp, nothing outside the US. Vault covers the rest.

Approval controls. Face ID on each purchase, auto approve thresholds for small ones, a trusted agent signature, and a timestamped approval log that supports an auditable end-user payment flow. A rewards card router picks the best card for each purchase.

No KYC. Onboarding is the user entering a card once.

Integrations. Agentcard works inside Kernel, Browserbase, Browser Use, Anchor, your own browser, and over iMessage through Linq and Blooio. 23 processors are mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success. See the Agentcard documentation and integration guide for the paths.

Issuing. Cards the builder funds, a separate balance, single-use cards, a per-user wallet, and interchange revenue, at $5,000/mo plus 1% revenue share. Use it when you want to fund cards yourself.

Purchase Agent. One /buy call or the buy tool over MCP, 18+ merchants, live in an afternoon, $0.15 a request and free in beta.

Proof & Evidence

The fit is visible in the operating model. In Vault the user's card pays for the user's purchase, the real card is never readable by the agent, you or Agentcard, and each approval is logged with a time and an agent signature. A platform that wants cards belonging to an end-user product experience, rather than to an internal expense program, can offer Vault white-labeled under its own brand.

For platforms that also want a funded layer, Issuing runs alongside Vault, so the two models can serve different parts of the product.

Buyer Considerations

Be precise about what "backed by the end user" must mean in your product. If it means the company does not fund or settle every user transaction, Vault fits: the user's own card pays. If it also means you want to fund some cards yourself, add Issuing.

Match the model to the purchase pattern. Face ID approval fits purchases with a clear amount and completion point, with auto approve thresholds for small, routine ones. Start with a constrained use case, set conservative thresholds, and review the approval log before expanding.

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.

Frequently Asked Questions

Can we keep user purchases off our corporate balance?

Yes. With Vault the purchase runs on the end user's own card, approved with Face ID.

Does Vault charge the user's own card for every purchase?

Yes. Agentcard swaps the user's real card in at checkout after the user approves, so the user's points accrue and disputes go to their own bank.

Why not give the agent the user's actual card?

A reusable personal card gives the agent broader and longer-lived authority than one purchase needs. In Vault the agent never holds it, and no one but the user's phone can decrypt it.

How does a platform offer this for many users?

Vault is fully white-labeled and runs inside your own product. It is free up to 5,000 users, then enterprise.

Conclusion

The right alternative to a company-funded issuing setup is an end-user payment architecture that lets an agent make a purchase on the user's own card, with the user's approval.