Skip to main content
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 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.

​
How payments work

see how payments work on KERNEL for the vault, browser, approval, and checkout lifecycle.

​
Choose a provider

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. agentcard’s alias-based checkout requires a recognized processor request. see agentcard’s 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 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 or agentcard. 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, link, or agentcard.

​
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. for a complete agent workflow using link or agentcard, follow enable payments in a browser agent. the provider guides include 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.