Evervault Launches Browser Tokens: How AI Agents Pay on Existing Checkouts Without Seeing Card Numbers
Evervault's Browser Tokens let AI agents pay on existing sites without seeing real card numbers. Learn how the tokenization works, what it means for PCI DSS scope, how it compares with Visa and Mastercard, and what merchants should check.
Key Takeaways
- On October 20, 2026, payment data infrastructure company Evervault launched Browser Tokens, which let AI agents pay and log in on existing e-commerce sites without ever receiving the real card number or password
- Visa and Mastercard agentic tokens require support from both the issuer and the merchant, while Browser Tokens are positioned as a network-agnostic compatibility layer that works without any merchant-side changes
- Because the product makes agent traffic look like an ordinary browser, merchants may see more orders they cannot identify as agent-driven, which is a reason to revisit bot management and fraud policies
A Stand-In Card Number, Announced at Money20/20
Evervault's Browser Tokens let AI agents pay and log in on merchant sites without seeing real card data or passwords.
thepaypers.comDuring Money20/20 in Las Vegas, the payments industry's major trade show, Evervault announced the launch of Browser Tokens. The product lets AI agents and browser automations complete purchases and logins without ever seeing card numbers, passwords, or personal data.
Founded in 2019, Evervault provides developer infrastructure for processing sensitive data while it stays encrypted, and is backed by Ribbit Capital, Sequoia, and Index. The first customers named for Browser Tokens are corporate card company Ramp and Natural. The product is already live for existing customers, and new developers can try it for free. According to the official blog, sandbox apps are free for testing, and production use on the Pro plan starts at $0.25 per card session and $0.05 per session for non-card data such as passwords. The base fee of the Pro plan itself and availability terms for Japan were not included in the announcement and remain undisclosed.
Why Browser Agents Stall at the Payment Form
An agent has made its choices and filled in every field, then stops in front of the payment form. That is the scene Evervault CEO Shane Curran describes at the start of his blog post. The reason is simple: handing a user's card number to an agent is dangerous. Anything given to a model can end up in logs or on someone else's servers. It can also be read by a web page built to trick the agent (prompt injection).
The other barrier is PCI DSS, the card industry's security standard. Every system that stores, processes, or transmits cardholder data falls within its assessment scope. Give an agent the raw card number, and scope expands to the agent code, the AI model provider, the headless browser (a browser with no visible screen) provider, and the logging infrastructure. Evervault's documentation notes that most model providers and browser automation platforms are not PCI compliant, so this is not a practical option.
Existing workarounds came with costs too. Storing the card in a browser provider's vault keeps it out of the prompt, but puts the browser provider in the sensitive data path and still leaves room for values to leak through the Chrome DevTools Protocol. Using a virtual card means the user loses the rewards on their own card.
How It Works: Tokens Become Real Outside the Browser
The idea behind Browser Tokens is that the agent handles only stand-ins from start to finish, and the swap to the real value happens on the network. At the center is the combination of format-preserving tokens and a browser proxy operated by Evervault.
Here is the flow. First, the user's card details are captured with Evervault's card collection component and encrypted, so the developer's database stores only encrypted values. Next, just before the agent starts its task, the encrypted values are sent to the API along with rules on which hosts may receive the real values, and tokens are issued.
The tokens that come back are different numbers in the same shape as the originals. A card number token keeps the length and the BIN (the first six digits, which identify the brand and issuer) and passes the Luhn checksum. The merchant's checkout form accepts it as a card of the correct brand. The CVV token keeps its digit length, and the expiry date is usually passed through as is.
The agent enters these tokens into the form and submits it as usual. The browser's traffic is configured to go through Evervault's proxy, and only requests bound for hosts on the allowlist have the tokens replaced with real values before they go out. The merchant or its payment processor receives the real card number and runs authorization as normal.
If a request goes to a host that is not on the allowlist, the proxy simply forwards it without swapping anything. Even if a malicious page tricks the agent into sending the card number, all that page receives is a worthless stand-in.
There are three more design points.
The first is that Evervault keeps no mapping between tokens and real values. The encrypted values are embedded in a time-bound JWE (JSON Web Encryption) that serves as the proxy credential, and the proxy reads from it which values may go to which hosts and until when. The claim is that there is no vault to breach in the first place.
The second is fixed permissions. The allowed hostnames, expiry (15 minutes by default), and data categories are set when the token is created, and neither the developer's code nor the agent can widen them later. Each reveal and refusal is logged per session.
The third is that it also works for passwords. The intended use includes giving the agent a stand-in password to log in to the user's account on a merchant site and pay with the card already saved there.
Because the product rewrites traffic in transit, though, the browser needs some setup. To swap values inside HTTPS traffic, Evervault's CA certificate must be added to the browser's trusted root store. Supported environments are Chromium-based, with developer browser infrastructure such as Playwright and Browserbase named. Support for consumer AI browsers is not part of this announcement.
How It Differs from Network Tokens and SPT
Browser Tokens are not the first mechanism for keeping card numbers away from agents. The difference lies in who issues the token and what the merchant has to do.
| Approach | Token issuer | What merchants need | Main constraints |
|---|---|---|---|
| Browser Tokens (Evervault) | Evervault (stand-in values in the original format) | No changes | Evervault's CA certificate must be added to the browser. Controls such as spend caps are still in progress |
| Visa Intelligent Commerce / Mastercard Agent Pay | Card network | Merchant and issuer support | Per Evervault, current coverage is US consumer credit cards. Each card brand needs a separate integration |
| Shared Payment Token (Stripe, ACP) | Stripe | ACP support | Issued scoped to a specific merchant and cart total |
| Virtual cards | Card issuing provider | No changes | Users lose rewards on their own card. Coverage is limited to regions the provider supports |
| Browser provider vault | None (browser provider holds the real value) | No changes | The browser provider joins the sensitive data path, and values can still leak through the Chrome DevTools Protocol |
Visa Intelligent Commerce and Mastercard Agent Pay are approaches where the card network itself issues tokens for agent purchases. In its blog, Evervault says these only work when both the user's bank and the merchant support them, and current coverage is US consumer credit cards. Note, however, that this assessment comes from a company selling an alternative.
Under the Agentic Commerce Protocol (ACP), co-developed by Stripe and OpenAI, Stripe's announcement explains that a Shared Payment Token (SPT) is issued scoped to a specific merchant and cart total, and the agent passes that token to the merchant via API. The security thinking is similar, but the merchant has to support ACP and set up a way to receive orders.
Browser Tokens differ in that they ask nothing of either merchants or networks. Curran says "agentic payments are just payments," stressing that the product works with today's cards and websites without waiting for merchants to adopt new standards. Put the other way, it is a mechanism that lets agent payments go through without any cooperation from the merchant.
The Shopper Merchants Cannot See
This product has a side that merchants should not overlook. Evervault's blog explains that, from the merchant's point of view, the flow looks like a normal sign-in and a normal card payment, and that the merchant never knows Evervault was involved.
The traffic itself is also built to look like a human shopping. According to the documentation, the proxy uses TLS and HTTP client impersonation so that network fingerprints such as JA4 match a regular browser. The blog also says that with a residential proxy, the merchant's fraud checks won't turn the agent away.
That runs in the opposite direction from another industry trend. In October 2025, Visa released the Trusted Agent Protocol, developed with Cloudflare. It lets agents declare their identity and purchase intent with cryptographic signatures, so merchants can tell legitimate agents from malicious bots, and Visa is building it into Visa Intelligent Commerce. According to Cloudflare's announcement, Mastercard is also incorporating Web Bot Auth into Agent Pay so merchants can identify trusted agents.
Forkast, a publication covering the agent economy, took aim at this contrast in an opinion piece. It argues that financial institutions worry less about credential theft itself than about the absence of verifiable intent, and that the ability to make agents look human may prove to be a liability.
The incomplete set of controls also deserves a caveat. The product page lists spend caps, human approval thresholds, a kill switch for live sessions, and merchant category blocks as in progress, with no disclosed release dates. The documentation also states that tokens are not single use and can be used multiple times within their TTL, and that transaction authorization remains with the issuer and payment processor. When a 3D Secure challenge or MFA prompt appears, a human still has to step in.
PCI DSS scope reduction is not unconditional either. The Browserbase documentation for the integration cautions that it does not automatically make an integration compliant, and that final scope depends on the full implementation, including logs and screenshots.
What Merchants Should Check Now
The users of Browser Tokens are companies building agents. Merchants are not the ones adopting it; they are on the receiving end of the orders. With that in mind, there are three things worth checking.
First, what your bot defenses actually stop. Agents that look human down to network fingerprints and residential IPs become hard to distinguish with conventional detection. Decide on a policy for whether to accept agent-driven orders and under what conditions to block them, rather than leaving it to the tooling.
Second, fraud detection and chargebacks. With orders placed via Browser Tokens, the fact that an agent was involved is structurally absent from the merchant's records, even if the user later disputes the purchase. For high-value items, check how well existing rules on shipping addresses and purchase frequency still hold up.
Finally, offer a route where agents identify themselves. Supporting the Trusted Agent Protocol or ACP lets you treat invisible orders and declared orders differently. How your terms of service treat agents logging in to customer accounts on a user's behalf is another point to sort out.
Conclusion
Browser Tokens are a pragmatic way to make agent payments work on today's web without waiting for card networks. As a design for keeping card data away from agents, it holds together.
At the same time, the launch highlights two trends moving in parallel: making agents declare themselves, and making them look human. When controls such as spend caps arrive, and how this approach coexists with network-side identification protocols, are the points to watch next.
