Skip to main content
your browser agent can complete a web checkout without bringing your application, agent, or browser into pci dss scope. a provider-hosted flow collects and stores the user’s payment method, so neither you nor your agent handles the card number or cvc. KERNEL connects that payment method to a vault, returns non-secret aliases, and resolves those aliases at browser egress. the agent fills the checkout form with the aliases. the merchant page creates its normal payment request. KERNEL handles authorization and payment handoff outside the browser. stripe link and agentcard are credential providers, not merchant payment processors. at the browser form layer, both work with any web checkout that accepts standard card details, and the merchant’s processor does not need to be stripe. end-to-end handoff also requires the outgoing payment request to match a native KERNEL processor adapter.

​
How payments work

both credential providers use the same integration shape:
  1. create a vault for the user or task.
  2. create a wallet item and send the user through the provider-hosted collection flow.
  3. create a card item for the intended purchase and wait for aliases.
  4. attach the vault when you create the browser session.
  5. give the aliases to the agent and let it complete the merchant’s checkout.
  6. complete any provider-hosted approval and inspect item events alongside the merchant’s order state.
each vault must contain at most one wallet item for each provider. before showing a provider connection option, list the vault’s items. if that provider already has a wallet in any state, hide the add option and reuse or recover the existing item. when both stripe link and agentcard wallets exist, show both as configured and do not offer either provider again. the card number and cvc stay outside the agent-controlled environment. the browser sees format-valid aliases and the processor-shaped response, not the underlying payment credential.

​
Choose a provider

stripe link

collect a stripe link wallet and approve a one-use credential for a specific purchase.

Agentcard

add users’ cards to agentcard’s vault. the user approves each transaction with Face ID and earns points on the purchase.
stripe link and agentcard identify where the credential comes from and how the user approves it. choose between them based on that lifecycle, not the merchant processor. processor-adapter coverage is the same for both.
choose stripe link when each purchase requires a newly approved, single-use credential. choose agentcard when one enrolled card must support multiple purchases, with separate approval for each. both integrations may provide additional benefits, including card rewards and chargeback protection. review each provider’s own documentation for the most up-to-date details.

​
Checkout and processor coverage

KERNEL currently includes native adapters for these checkout request formats. all five adapters are enabled for both stripe link and agentcard. for example, a browser can enter stripe link or agentcard aliases into a Shopify checkout. Shopify remains the merchant platform; stripe link or agentcard supplies the credential and approval flow. the outgoing request must contain the complete alias set and match the adapter’s expected HTTPS method, host, path, content type, and card-field layout. these adapters are enabled today, but non-Stripe coverage still needs broader validation against real processor SDKs and hosted checkouts. encrypted payloads, different request layouts, and unrecognized processor endpoints pass through without native handoff. KERNEL’s native handoff aims to support the same processors supported by agentcard’s direct SDK. email support@kernel.sh if you need another processor so we can prioritize its adapter and validate a real checkout.

​
Why use KERNEL handoff

  • integrate with one KERNEL vault api for both stripe link and agentcard.
  • let KERNEL intercept recognized payment requests at egress, including requests from embedded payment frames, instead of maintaining cdp interception or page-routing logic in your agent.
  • verify the project, browser session, vault attachment, item, aliases, and lifecycle state before handoff, then record the payment lifecycle in vault audit events.
  • keep the underlying credential outside your application, agent, and browser through aliases and provider-hosted enrollment and approval.
the handoff is designed to prevent credential injection and browser-to-provider handoff failures. we don’t yet have comparative data showing higher checkout completion or payment acceptance rates. expanding acceptance coverage against real processors and measuring reliability are active priorities.
don’t retry a failed, timed-out, rejected, or indeterminate payment. a browser error, missing response, consumed link item, or reusable agentcard item does not prove whether the merchant created an order or money moved. inspect the existing item events and the merchant’s order state before taking another action.

​
Next step

configure stripe link or agentcard, then follow Enable Payments in a Browser Agent to attach the vault and give payment aliases to your agent. the provider pages show the CLI commands for creating wallets and cards. once the card item is ready, the shared CLI flow is:
CLI
--wait performs one bounded observation. it does not confirm that a payment succeeded, and the CLI does not submit or retry merchant payments.