Skip to main content
Agentcard has one quickstart per type of product, because what differs between integrations is the shape, not the language: where the wallet opens, and how the agent buys. Every quickstart has the same five steps, takes ten to fifteen minutes, runs entirely in sandbox, and ends the same way, with the user’s agent running a real purchase conversation at a real merchant up to the sandbox wall, where the confirm is refused by design because no sandbox call ever moves money. If you’re unsure, start with the web app quickstart. It’s the most complete path, its wallet step is the simplest to run on your own machine, and everything you wire there (credentials, connecting users, the agent’s buy loop, webhooks) carries over unchanged to every other shape. The first five rows share one wallet. Your server creates a wallet link the same way in every one of them, and the shape only changes how that link opens: a sheet over your page, a tap in a thread, a hosted page, a native view. The last row has no end-user wallet at all. The agent acts as a cardholder you created, with a buy token as its bearer, and the money behind every purchase is your company balance. Use a wallet shape when your users pay with their own cards or their own Agentcard balance, which is the case for almost every consumer product. Use company-funded accounts when your company is the one paying, for example an internal agent that buys supplies, or a service whose price already includes what the agent spends.

​
What every quickstart covers

  1. Credentials. Your sandbox client_id and client_secret from the dashboard, exchanged for a bearer token, plus a sandbox webhook destination so the last step has something to read.
  2. Connect a user. Start a connection, verify it with the sandbox code 111111, record consent. You keep the user’s id and their connection token. (Company-funded accounts create a cardholder and a buy token here instead.)
  3. The wallet for your shape. A wallet link, opened the way your shape opens it, and the test card 4242 4242 4242 4242. (Company-funded accounts fund the company balance here instead.)
  4. The agent buys. The MCP buy tool, or POST /buy, with the connection token as the bearer. Sandbox refuses the confirm on purpose; that refusal is the finish line.
  5. See what happened. The deliveries in the dashboard, every one with livemode: false.
The steps that are identical across shapes are literally the same text on every page, so if you switch shapes later you only reread the wallet step.

Web app whose agent buys

The default. Register your origin, embed the wallet on localhost, and let the agent buy over MCP or HTTP.

Messaging agent (iMessage, WhatsApp, SMS)

Text a wallet link, let the user add a card on the hosted wallet, and buy over MCP.

Backend or CLI agent, no frontend

Hand the user a hosted wallet link and call POST /buy from your server.

iOS app

Present the AgentcardWalletKit sheet and buy over MCP.

React Native app

Render the wallet component and buy over MCP.

Company-funded accounts (no end-user wallet)

Create cardholders and buy tokens, fund the company balance, and buy with the buy token.