The ecosystem
When an agent buys on someone’s behalf, it typically touches four kinds of platforms. Most teams end up using two or three at the same time.Agent browsers
Agent browsers run a real browser in the cloud, which lets an agent visit any website, search for products, add them to a cart, and reach the checkout page. KERNEL and Browserbase are the two we integrate with. They’re the most general-purpose tool in the stack: if a merchant has a website, an agent browser can usually reach checkout. The trade-offs are that browsers can be slow, bot protection can get in the way, and the checkout form still needs a card number entered. That last step is where we plug in.Ecommerce APIs
Ecommerce APIs skip the browser. Instead of clicking through a website, an agent calls an API that returns structured products, carts, and orders for the merchants it covers. Agentcard’s Purchase API is our version of this. It takes a free-text request, builds the cart, and completes checkout with the user’s card. Zinc and Ophelia cover other merchants in a similar way. APIs tend to be faster and more reliable than a browser, but each one covers a fixed set of merchants, so many companies use several.Messaging platforms
Many agentic purchases start in a chat. Linq, Photon, and Blooio give an agent a phone number on iMessage or WhatsApp so users can text it. The messaging platform is also where the user typically approves a purchase before it goes through.Agentcard
Agentcard is the payments layer underneath all of the above. It holds the user’s cards and merchant credentials, determines when a card can be used, provides card details to the browser or API at the moment of checkout, and gives the user a way to approve each purchase. It can work with whichever browser, API, or messaging platform you already use.How we store cards and credentials
A user adds a card once, through an Agentcard form that is PCI compliant. The card is encrypted on the user’s device with a passkey before it’s stored. Only that passkey can decrypt it, which means we never see the card number and neither would anyone who got hold of our database. Because the user’s real card is what gets charged, the purchase looks like any other purchase to their bank. They keep their points and retain the right to dispute a charge. We store who approved the purchase, when, and from where, which is what a merchant typically needs to defeat a bogus dispute.How a purchase flows through all the parts
- The user talks to your agent on iMessage, WhatsApp, or wherever it lives. They ask it to buy something.
- Your agent builds a cart. It uses an agent browser to navigate a merchant site, or an ecommerce API to get there directly.
- The agent reaches checkout and asks Agentcard for the card. In a browser, the agent types a placeholder card number and Agentcard intercepts the request at the network layer, with KERNEL and with our own SDK. Through an API, the API calls Agentcard directly.
- The user approves with Face ID. Agentcard sends the user an approval request on their phone. The passkey that unlocks the card lives there, so nothing moves without them.
- Agentcard swaps in the real card. The merchant receives the user’s real card details and charges it. Your agent never sees the card number, and neither do we.
- The order confirms. Your agent tells the user, and the purchase shows up on the user’s statement exactly like a purchase they made themselves.