agentcard is backed by a card the user enrolls, but the agent and browser still
enter aliases rather than the underlying card details. those details remain
outside the browser and are handled during provider handoff at egress.
to run either path with a coding agent that has access to the KERNEL cli, use one of these prompts. connect the provider wallet first through your trusted application or a terminal outside the coding agent. the agent must stop whenever a provider action is required because cli output can contain the action url.
Before you start
- install a KERNEL sdk version that includes the
vaultsresource. - set
KERNEL_API_KEYandKERNEL_PROJECT_IDin the trusted controller that creates your browser. - use a low-value web checkout you control whose outgoing payment request matches a native processor adapter. the merchant processor doesn’t need to be stripe.
- stripe link card creation is live-only. agentcard mode comes from the integration’s configured credential.
- for agentcard, keep an application-owned
AGENTCARD_MODEdeployment setting and fail closed unless it explicitly matches the sandbox or live environment you intend to use. the vault api does not return this mode.
1. Create a vault
scope the client and vault to the same project that will own the browser session.vaults.upsert creates the vault or retrieves an existing vault with the same name. vault names are immutable within the project.
2. Connect the end user’s payment method and prepare a card item
wallet and card are KERNEL api resources, not the underlying wallet or card.
your end user initiates setup and purchases through your product. your
application then makes the authenticated api calls on their behalf. a card item
represents the payment authorization and aliases for a purchase; creating one
does not add or expose the end user’s real card.
the end user creates the purchase intent. your application translates that
confirmed intent into a KERNEL card item without exposing its api key to the
user or agent.
Once per end user and provider
your payment settings ui must allow at most one wallet item for each provider in a vault. list the vault’s items before rendering provider controls, group wallet items byspec.provider, and apply this flow:
if both stripe link and agentcard wallets exist, hide both provider add options.
recheck this condition in your trusted controller immediately before wallet
creation so a stale ui cannot submit a second wallet.
the api currently makes item keys unique, not wallet providers. using a
different key can create another wallet for the same provider, so your product
must enforce the one-per-provider rule. deleting a wallet invalidates its
dependent card items; require an explicit replacement flow rather than creating
a second wallet beside it.
- your end user chooses a provider that does not already have a wallet in the vault.
- your application creates or retrieves a vault for that end user, checks its items again, then creates a wallet item only when that provider is absent.
- your application presents the returned action in a trusted user-facing surface outside the agent-controlled browser.
- your end user completes the provider-hosted connection or enrollment flow.
- your application waits until the wallet item’s status is
connected.
Present hosted actions in your application
provider action urls are bearer-like handoffs to enrollment or approval. route them through your trusted application:- your backend retrieves the item and keeps the raw action url out of logs, analytics, and model context.
- store the action server-side under an opaque id bound to the authenticated end user, vault id, item key, and action name.
- render a link to your own authenticated action endpoint. before redirecting, verify the session owns that binding and the item still returns the same action.
- send the redirect with
Cache-Control: no-storeandReferrer-Policy: no-referrer. - apply a short application ttl capped by
item.expires_atorstate.authorization.expires_atwhen present. invalidate the record immediately when the action changes, disappears, or reaches a terminal state.
presentProviderAction functions later in this guide represent this
application-owned flow. the checkout agent and its browser must never receive
the raw provider url.
For each purchase
purchase verification is a required, fail-closed gate before creating or updating a card item:- let the browser agent propose the merchant, amount, currency, and item or cart contents. treat every proposed value as untrusted.
- independently obtain the expected values from a trusted source. prefer your order or cart backend. when no backend exists, use deterministic page extraction with fixed selectors or structured page data, not another model response.
- normalize the values in trusted code and compare the proposal with the trusted result. compare the amount in minor currency units and require the merchant, currency, and item or cart contents to match.
- stop when any value is missing, cannot be verified, or disagrees. do not create or update a card item and do not invoke authorization.
- show the independently verified values to the end user and wait for explicit confirmation.
- freeze that verified, confirmed purchase object. derive the card specification and any authorization request from that same object. do not accept replacement values from the agent after confirmation.
- for stripe link, list the connected wallet’s payment methods and let the end user select one. for agentcard, pin an enrolled card or let the end user choose during approval.
- ask KERNEL to prepare a card item on the end user’s behalf. stripe link requires a new one-use item. agentcard can reuse a ready item and update its specification when the api permits. the item refers to the connected wallet; it is not the end user’s real card.
- for stripe link, invoke the advertised
authorizeoperation using the same verified purchase object, then present any returned approval action to the end user. agentcard begins authorization after the browser submits checkout. - wait for the card item to become
ready, then pass only its aliases to the browser agent.
account_settings.display_name, line_item_group.total,
line_item_group.currency, and line_item_group.line_items. use dom text and
data-testid attributes only as supplemental checks. stripe can render multiple
responsive copies of a summary or omit product-level test ids in another layout,
so don’t require a specific test id or number of matching elements. these are
stripe page details rather than a KERNEL contract. if the structured response is
missing or its values disagree with the rendered checkout, fail verification
instead of falling back to model inference.
stripe adaptive pricing can change the checkout’s displayed amount and currency
for the browser’s location. create the card item from the active presentment
amount and currency shown to the user and submitted by that checkout, not the
payment link’s base integration amount and currency. include those active values
in the verified purchase object and the confirmation screen. when the checkout
response is your deterministic source, create the attached browser in step 3
before you create or update the card item, then inspect and submit with that same
browser session. the vault attachment covers items created later in that vault.
we’re adding credential-provider integrations and merchant-processor adapters
and will update this guide as coverage expands. we plan to build additional
card-collection and vault-management surfaces so developers can connect the
credential providers and third-party vaults they already use. over time, we want
KERNEL to support more of the
browser-side steps required to complete a payment without exposing the
underlying credential to the agent or browser.
state.status is ready and whose state.aliases contains number, cvc, exp_month, and exp_year.
Collect non-card checkout fields
payment aliases cover only the card number, cvc, and expiry. merchant checkouts can also require email, billing name, postal code, shipping address, phone number, or other customer data. collect the required values from the end user in your trusted application, or load values the end user has already approved from your backend. pass them to the browser agent separately from the card aliases. do not ask the agent to invent missing customer data. merchant-specific agent disclosures are normal checkout fields. if the page asks whether automation is acting for another person, instruct the agent to answer truthfully in the merchant’s form before submission. for a checkout that offers I am an AI agent acting on behalf of someone else, select that option. stripe can render hidden or duplicate copies of its disclosure control for responsive layouts. target the visible label. if the label doesn’t toggle the control, locate the associated realinput[type="checkbox"] and invoke its
native dom click(). read that same input’s checked property and require it to
be true before submission. if you can’t verify the checked state, stop without
submitting. don’t bypass the disclosure or replace the page’s normal submission
with a raw processor request. after triggering submission once, never retry it,
including after a timeout, unchanged page, or indeterminate result.
retrieve the item immediately before creating the browser. don’t cache aliases after an item expires, changes state, or is deleted.
3. Attach the vault to the browser
vault attachments are fixed at browser creation. use the same project-scoped client that created the vault.browser_live_view_url lets the end user watch the checkout during confirmation
and agentcard approval pauses. presentLiveView represents your authenticated
application page: keep the url server-side with the end user and browser session
binding, render or embed it only after checking that session, and remove it when
you delete or time out the browser. don’t log the url or put it in model context.
see live view for iframe and csp
requirements.
connect your existing agent to browser.cdp_ws_url. see Controlling a Browser for supported connection options.
4. Give the aliases to your agent
pass the aliases as structured task input. instruct the agent to use them in the page’s normal card fields and submit checkout once.5. Keep approval and observation outside the agent
start observing the card item before the agent submits checkout and keep the observer running until the merchant reaches a terminal order state. this is required for agentcard, where the outgoing checkout request is held while the user approves it. the same observer works for stripe link and provides item events after credential substitution. the example usespresentProviderAction, an application-owned function. it
must publish the action only to an authenticated session for the end user who
owns the vault. bind the action to that user, vault, and item; expire it no later
than the item or authorization expiry; and stop serving it as soon as the action
changes or disappears. don’t put the url in application logs, analytics, model
context, or the agent-controlled browser.
--wait performs one bounded observation, so rerun the commands to
continue observing the existing attempt. CLI commands prepare and observe the
payment state; they don’t submit merchant payments or retry them. run --open
only from the trusted controller or a human-operated terminal, and never send
its output to the browser agent.
events returns an ordered array. an empty array means no new observation arrived during the wait. it does not mean payment failed. correlate event.browser_id with the browser you created when a vault is attached to more than one session.
6. Verify the outcome
use item state, item events, the checkout page, and the merchant’s order record together.
use the merchant order record as the authority for whether the expected order
was created and paid. require its merchant, amount, currency, and items to match
the frozen purchase object. use authorization state and item events to explain
the provider and handoff path, and use the checkout page as supporting evidence.
only report success when the trusted merchant record confirms the matching
order. a ready agentcard item, an approved authorization, a delivered replay, or
a success page cannot establish that by itself. merchant success text is
page-specific: a completed stripe checkout might say Thanks for your payment,
but don’t use that string or any other generic text matcher as the success
condition. when the sources disagree or the merchant record is unavailable,
keep the result indeterminate and do not retry.
delete the browser when the task and outcome inspection are complete. keep or delete the vault and provider items according to whether the user needs them for a future task.