payments for browser agents, powered by KERNEL

agents on KERNEL can now complete payments on existing checkout pages without exposing card data to the developer's application, agent, or browser. KERNEL handles checkout at the browser egress layer, keeping card data out of the agent runtime and context, and helping developers avoid expanding pci dss scope. to power this, we're launching multi-wallet support, starting with link by stripe and agentcard.

agents still need to use web checkout

new payment protocols like x402 create direct paths between agents and merchants when both sides opt-in. most merchants, however, still only support ordinary website checkout pages.

consider an agent booking a flight. it signs in, selects a seat, and reaches checkout. payment fields sit embedded in iframes, the form asks for a card number and cvc, and the transaction may require user approval or card issuer authentication. if the agent asks the user for these card details directly, the card details can leak into the agent’s context, application logs, screenshots, traces, and session recordings. this creates the risk of bringing the agent into pci dss scope.

to keep sensitive payment credentials out of their own systems, developers stitch together browser autofill, cdp scripts, payment-provider sdks, third-party vaults, and tokenization apis. each component solves part of the problem, but developers still have to coordinate the browser session, payment credential, and user authorization without accidentally exposing card data.

and, none of these layers spans the entire browser transaction. a payment sdk can initiate and track a payment, but it does not control the agent’s browser session or the network request leaving it. a credential vault can protect card details, but it does not by itself connect these details to the browser session and merchant checkout.

giving browser agents a secure, compliant way to pay

KERNEL can connect the agent, browser, and payment credential without exposing sensitive data to any of them, because we run the browser and its network path. this gives us a controlled point at egress (the point where a request leaves the KERNEL browser environment) to verify the session and coordinate the payment step. the merchant keeps its existing checkout and does not need to integrate with KERNEL.

the KERNEL api supports vaults as a new primitive that grants a browser session permission to use a payment method, without exposing the underlying credential. the agent receives aliases for the checkout form. KERNEL controls what those aliases can authorize when a payment request leaves the browser.

this architecture creates a clear boundary. the developer’s systems orchestrate the checkout using aliases, while KERNEL and the connected payment provider handle the underlying card data. the developer’s application, agent, browser, and observability stack never receive the card number or cvc.

here’s how the flow works:

1. before a browser session, the end user connects a supported wallet or card provider to the vault.
2. the developer attaches the vault when creating the browser session.
3. the agent receives payment aliases from the vault and enters them into the merchant’s checkout form.
4. KERNEL recognizes a supported payment request and verifies the browser, session, project, vault, and item binding.
5. KERNEL either substitutes a pre-approved one-use credential or holds the request while the connected provider executes it.
6. KERNEL returns the processor result to the browser, which then continues through the rest of the merchant’s existing checkout flow.

KERNEL's vault primitive is designed to work across credential providers and, over time, connect with third-party vaults developers already use. credential providers can continue to collect, hold, issue, and authorize sensitive values. KERNEL controls where and how browser agents can use those values. read more in our vaults documentation.

two native integrations, two payment flows

today, we’re launching our first two native wallet integrations with stripe link and agentcard to power agent payments on KERNEL. both providers collect and hold payment details through hosted flows, so developers do not need to build card-collection forms, store card data, or pass card numbers and cvc values through their agents.

developers integrate the wallets directly with KERNEL; we handle the wallet-side oauth, enrollment, and api flows. the developer receives the wallet's status, payment metadata, and aliases instead of the underlying card details. get started with our payments in browser agents guide.

link by stripe: single use credential substitution

users connect their link wallets, and the developer sets the boundaries of the transaction, including the merchant, amount, currency, and purpose.

once the user approves the purchase, link issues a single use payment card to KERNEL’s vault. the agent fills the checkout form with aliases, and KERNEL swaps in the real credential during the outgoing request. the merchant processes the transaction.

“many online tasks ultimately end in a payment. KERNEL gives agents a secure environment to complete those transactions. by integrating link’s wallet for agents, KERNEL is making it simple for agent builders to turn on payments in one go.”

steve kaliski, principal software engineer | stripe

“at beacons, we’re building ai that can help run and grow a creator’s business. KERNEL and link gave us a remarkably fast path to securely connect payments and enable our agents to take real financial actions on creators’ behalf. we were able to get payments working quickly, with the security and compliance infrastructure already in place.”

david zeng, co-founder & cto | beacons.ai

agentcard: authorized request handoff

users store their cards on agentcard. the developer creates vault items with merchant and spending constraints, and the agent uses aliases to complete the checkout form.

when the payment request leaves the browser, KERNEL holds the request and asks agentcard to create merchant and amount-bound authorizations. agentcard then prompts the user for approval. once approved, agentcard executes the processor request and KERNEL replays the response to the browser.

“agentcard allows customers to buy using their cards instead of one-time cards. we believe that buying things with agents should be easy and fast and we are very excited to partner with the KERNEL team to make that possible.”

karen serfaty, co-founder & ceo | agentcard

“building agentic experiences at scale relies on providing the right infrastructure and gateways to those agents. KERNEL gives our agents a reliable path through checkout, while agentcard lets them pay exactly what the user approved. agentcard and KERNEL provide the stability agents appreciate.”

adam wazzan, co-founder & cto, and axel eriksson, product & growth | orchid

where this is headed

we are expanding support for agentic payments across more wallets, checkout flows, merchant processors, partners and payment protocols. reach out if you'd like to work together.

but payments are only the beginning. we designed our vaults to be a general primitive for agents to use sensitive information without seeing the underlying values. the same model will extend to login credentials, identity documents, regulated form fields, and other sensitive data. across these use cases, the agent works with aliases while KERNEL controls when and where an underlying value can be used.

as agents take on more consequential work on the web, they’ll need secure access to more of the data and permissions humans use every day. we’re building to make that possible. stay tuned.