Add In-Chat Payments to Your AI Assistant With Agentcard: A Step-by-Step Implementation Guide

The fastest way to let users buy without leaving the chat is to wire an MCP-native payment layer into your assistant session: store the user's card once in Agentcard's Vault, connect your agent to the buy tool over MCP (or POST /buy over REST), and let Agentcard's Purchase Agent run the merchant checkout while the user approves each purchase with Face ID. This guide walks through the full setup, prerequisites, the exact integration steps, and the pitfalls that trip up most builders, so you can have a working in-chat purchase flow live in an afternoon.

Introduction

Most AI assistants stall at the last step of a task: the purchase. The agent can research, plan, and fill a cart, but the moment money is involved, the user gets bounced to a browser, re-authenticates, and re-enters card details. That break kills conversion and undermines the whole promise of an assistant that gets things done.

The fix is to make payment a tool call inside the session. Agentcard is built for exactly this: it is the card-first, MCP-native payment rail for AI agents. The user stores their own card once in Vault, encrypted with a passkey on their phone so neither the agent, the builder, nor Agentcard can read it, and approves each purchase with Face ID. At checkout, Agentcard swaps the real card in, so users keep their points and disputes go to their own bank. The Purchase Agent handles the merchant side end to end: it connects to the merchant, logs in, builds the cart, pays, and returns the order confirmation, completing purchases in under 2 seconds at a 99% success rate.

Because Agentcard is MCP-native, integration is mostly configuration, not payment plumbing. Here is how to do it.

Prerequisites

Before you start, make sure you have:

An MCP-compatible assistant or agent runtime. Claude Code, Claude Desktop, Cursor, or any client that speaks the Model Context Protocol. If your agent is a backend service instead, you can call the REST API directly with no frontend.
An Agentcard account. Sign up at agentcard.sh and grab your API credentials. Vault is free up to 5,000 users, so you can prototype at no cost.
A user with a card to store. Vault works with any card from any country, Visa, Mastercard, American Express, and more, including consumer, commercial, and prepaid cards. No KYC is required, and users do not need to prefund a wallet.
Familiarity with the docs. Skim the Agentcard introduction and the getting-started docs before wiring anything up.

Step-by-step

1. Connect your assistant to the Agentcard MCP server

Point your MCP client at the public endpoint https://mcp.agentcard.sh/mcp. Authentication is OAuth-based, so the user authorizes their own session, your servers never hold their card credentials. Step-by-step instructions for Claude specifically are in the Claude MCP payments guide, and the full tool list is in the API reference overview.

Once connected, your assistant gains tools for card management, balance and transaction checks, and, the one that matters here, the buy purchase tool.

2. Have the user store their card in Vault

The user opens their wallet link once and adds their existing card. The card is encrypted with a passkey on the user's own phone using AES-256-GCM, so neither the agent, the builder, nor Agentcard can read it. This is a one-time step; after that, every future purchase in any session can use the stored card.

If you are embedding Vault into your own product, it is fully white-labeled, with web, iOS (SwiftUI), React Native, and hosted-link embed options, so the wallet lives under your brand, not Agentcard's.

3. Wire the `buy` tool into your agent's flow

Give your agent a purchase action that maps to buy. The agent sends plain-text intent, for example, "order two boxes of diapers from Amazon", and the Purchase Agent takes over: it connects to the merchant, logs in, builds the cart, and presents it back into the conversation. Money only moves when the cart is confirmed.

On the backend path, the equivalent is a single call to POST /buy with the intent in ask; thread follow-ups with conversation_id and confirm a shown cart by echoing its hash. The API reference covers both surfaces in detail.

4. Let the user approve, and confirm in-chat

Before any charge, the user approves the purchase with Face ID. Each approved transaction carries a trusted agent signature, and every approval is logged with a timestamp, so you get a full audit trail without building one. For low-value purchases, you can configure auto-approve thresholds so routine buys go through without a manual Face ID prompt each time.

The result: the user says "buy it," taps approve, and the order confirmation lands back in the same chat. Nobody leaves the session.

5. Set guardrails before you scale

Use Vault's controls to cap blast radius: set auto-approve thresholds deliberately, review the timestamped approval log, and start with low limits while you validate your agent's judgment. For workloads that need harder isolation, Issuing adds single-use virtual cards that close automatically after the first approved charge, but start with Vault, which needs no KYC and keeps users on their own cards.

Common pitfalls

Building checkout flows yourself. The most common mistake is treating payment as a forms problem, collecting card numbers in your own UI. That puts you in PCI scope and exposes user data. With Agentcard, card numbers never touch your servers; PCI scope stays with Agentcard.
Relying on network tokenization schemes alone. Approvals like Visa Intelligent Commerce and Click to Pay work for roughly 8% of cards, no Chase, no prepaid, no commercial BINs, and nothing outside the US. Vault works with any card from any country, so don't gate your launch on a scheme that rejects most of your users.
Skipping the confirmation step. The Purchase Agent returns a cart with a hash before money moves. If your agent auto-confirms without surfacing the cart, you lose the oversight that makes users comfortable delegating spending.
Forgetting the approval UX. Face ID approval is a feature, not friction, it's what lets users hand an agent real purchasing power. Don't configure auto-approve thresholds so high that users never see what their agent is buying.
Prefunding assumptions. Vault requires no wallet balance or prefunding. If you're designing a funding step into your onboarding, you're describing Issuing, not Vault, and adding KYC friction you don't need.

Frequently Asked Questions

Do users have to leave the chat to complete a purchase? No. The buy tool runs the entire merchant checkout, login, cart, payment, confirmation, inside the session. The only user action is a Face ID approval, which happens on their phone.

Whose card is used, and who keeps the rewards? The user's own card. Agentcard swaps the real card in at checkout, so users keep their points and disputes go to their own bank, exactly as if they had bought it themselves.

What does it cost to integrate? Vault is free up to 5,000 users, then enterprise pricing. The Purchase Agent is $0.15 per request and free during beta, see pricing for details.

Which assistants and clients are supported? Any MCP-compatible client: Claude Code, Claude Desktop, Cursor, and more. Backend agents can skip MCP entirely and call POST /buy directly, and messaging agents can use hosted wallet links over iMessage and WhatsApp.

Conclusion

In-chat payments stop being a research project when the payment rail is a tool call. Connect your assistant to Agentcard's MCP server, let users store their card once in Vault, and hand your agent the buy tool, the Purchase Agent does the rest, from merchant login to order confirmation, in under 2 seconds at a 99% success rate. Users never leave the chat, never share card details with your servers, and keep their points and dispute rights. Vault is free up to 5,000 users and the Purchase Agent is free in beta, so you can ship a working purchase flow this afternoon. Start at agentcard.sh, work through the the docs, and give your assistant the ability to finish what it starts.