> ## Documentation Index > Fetch the complete documentation index at: https://www.kernel.sh/docs/llms.txt > Use this file to discover all available pages before exploring further. # Wallets > Connect user wallets through KERNEL's native integrations KERNEL's native wallet integrations connect a user's payment method to vault items and expose provider-hosted connection and approval through the KERNEL api. your application works with item references, advertised operations, and outcomes instead of passing raw card details to the agent. wallet providers supply payment material and determine approval and reuse behavior; they are not the merchant's payment processor. KERNEL's [`fill` api](https://www.kernel.sh/docs/vaults/fill) injects values from supported items without passing them through your application or model. agentcard uses aliases and provider-executed requests instead of `fill`. for the platform capabilities, benefits, and end-to-end lifecycle, start with [payments on KERNEL](https://www.kernel.sh/docs/browsers/payments.md). ## How payments work see [how payments work on KERNEL](https://www.kernel.sh/docs/browsers/payments.md#how-payments-work) for the vault, browser, approval, and checkout lifecycle. ## Choose a provider | integration | use it to | environment | | - | - | - | | [KERNEL card](https://www.kernel.sh/docs/integrations/wallets/kernel.md) | collect a user's card directly through hosted or embedded enrollment | live only | | [link by stripe](https://www.kernel.sh/docs/integrations/wallets/stripe-link.md) | use payment methods from the user's link wallet; requires a us phone number | live only | | [agentcard](https://www.kernel.sh/docs/integrations/wallets/agentcard.md) | use agentcard's card vault and provider-executed checkout | sandbox or live, set by the agentcard credential | approval, eligibility, and reuse depend on the integration and card. follow the provider guide before choosing a checkout flow. ## Checkout and processor coverage KERNEL's `fill` api does not require a native processor adapter. for link virtual cards, the page must be on the authorized origin and provide supported checkout inputs. on stripe checkouts that expose link's agent payment tools, KERNEL delivers a link pay token instead, with no field selectors. see [link card requirements](https://www.kernel.sh/docs/integrations/wallets/stripe-link.md#fill-the-checkout). agentcard's alias-based checkout requires a recognized processor request. see [agentcard's processor coverage](https://www.kernel.sh/docs/integrations/wallets/agentcard.md#checkout-and-processor-coverage) for supported formats and limitations. neither field filling nor provider handoff guarantees processor acceptance or payment success. ## Why use KERNEL handoff see [why use KERNEL payments](https://www.kernel.sh/docs/browsers/payments.md#why-use-kernel-payments) for safe value injection, native integrations, purchase control, and outcome handling. ## Provider configurations use KERNEL-managed credentials by default. if you need your own client, follow the optional setup in [link](https://www.kernel.sh/docs/integrations/wallets/stripe-link.md#bring-your-own-link-oauth-client) or [agentcard](https://www.kernel.sh/docs/integrations/wallets/agentcard.md#bring-your-own-agentcard-oauth-client). a named provider configuration stores your application's `client_id` and `client_secret`, not an end user's wallet grant. credentials are encrypted at rest; secrets are never returned. with your own client, you can connect users in your backend before creating wallets in KERNEL. link imports the user's oauth access and refresh tokens; agentcard imports the connected user's `user_id` after validating provider access under your configuration, without another hosted enrollment action. configurations are organization-scoped and shared across projects, unlike project-scoped vaults. create, update, and delete require organization-scoped authentication; project-scoped api keys receive `403`. names are unique within the organization, and duplicate creates return `409` without replacing secrets. * **selection:** choose exactly one config `id` or `name` when creating a wallet. the cli accepts `--provider-config-id` or `--provider-config-name`; responses resolve names to ids. * **binding:** the wallet's configuration is immutable, and cards inherit it. renaming a config preserves bindings. * **rotation:** updating `client_secret` affects all bound wallets. provider, client id, and agentcard mode cannot change; changing clients requires a new config and new wallets. * **deletion:** returns `409` while any non-deleted item references the config, even if disconnected. it does not delete the external oauth client or revoke unrelated grants. ## Wallet and card items for payment settings ui, enforce at most one wallet per provider in each vault. the api currently enforces uniqueness by item key, not by wallet provider, so a different key can create a second wallet for the same provider. list items before rendering provider options, hide the add option whenever that provider already has a wallet in any state, and reuse or recover the existing item. a card's `spec.wallet` must reference a wallet in the same vault and from the same provider. for provider-specific behavior, see [KERNEL card](https://www.kernel.sh/docs/integrations/wallets/kernel.md), [link](https://www.kernel.sh/docs/integrations/wallets/stripe-link.md#item-reference), or [agentcard](https://www.kernel.sh/docs/integrations/wallets/agentcard.md#item-reference). ## Payment actions and recovery `action.name` can be `link_oauth`, `spend_approval`, `push_approval`, `collect`, `mfa`, `embedded_ceremony`, or `card_enrollment`. actions that require a hosted interaction include a `url`. don't send action urls or provider authorization material to the agent. `recovery_required` means a card's provider outcome is unresolved. it stops item wait loops and blocks new authorization, checkout, and deletion of the card or its parent wallet or vault. inspect existing evidence and contact the provider or support when manual reconciliation is needed. there is no reset operation; deletion is not payment recovery. ## Next step start with the provider guide in [choose a provider](#choose-a-provider). for a complete agent workflow using link or agentcard, follow [enable payments in a browser agent](https://www.kernel.sh/docs/browsers/enable-payments-in-browser-agent). the provider guides include CLI commands for creating wallets and cards. once the card item is ready, the shared CLI flow is: ```bash CLI theme={null} kernel vaults create --name user-12345 kernel vaults items get user-12345 notebook-order --wait 60 -o json kernel browsers create --vault user-12345 -o json ``` `--wait` performs one bounded observation. it does not confirm that a payment succeeded, and the CLI does not submit or retry merchant payments. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.