> ## Documentation Index
> Fetch the complete documentation index at: https://kernel.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# overview

> Add payments to a browser agent without exposing card data to your application, agent, or browser

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.

<span className="kernel-brand-name">KERNEL</span> connects that payment method
to a [vault](/docs/vaults), 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.
<span className="kernel-brand-name">KERNEL</span> 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 <span className="kernel-brand-name">KERNEL</span> 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.

```mermaid theme={null}
flowchart LR
  U[user] --> H[credential-provider collection]
  H --> W[wallet item]
  W --> C[card item and aliases]
  C --> A[agent fills checkout]
  A --> E[<span class='kernel-brand-name'>KERNEL</span> egress]
  E --> P[merchant processor]
  P --> M[merchant response]
```

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

<CardGroup cols={2}>
  <Card title="stripe link" href="/docs/integrations/payments/stripe-link" icon="link">
    collect a stripe link wallet and approve a one-use credential for a specific
    purchase.
  </Card>

  <Card title="Agentcard" href="/docs/integrations/payments/agentcard" icon="credit-card">
    add users' cards to agentcard's vault. the user approves each transaction
    with Face ID and earns points on the purchase.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

| behavior                  | stripe link                                              | agentcard                                                          |
| ------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------ |
| payment-method collection | hosted `link_oauth` action                               | fully white-labeled `card_enrollment` page                         |
| purchase authorization    | explicit `authorize` operation before checkout           | the user approves with Face ID                                     |
| payment handoff           | one-use credential substituted at egress                 | agentcard executes the request and returns the response            |
| reuse                     | card item and aliases are consumed on first substitution | cards can be reused for recurring and one-time purchases           |
| environment               | live only                                                | configured agentcard credential; not exposed through the vault api |

choose [stripe link](https://hypeship.dev/integrations/payments/stripe-link) when each purchase requires a newly approved, single-use credential. choose [agentcard](https://hypeship.dev/integrations/payments/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

<span className="kernel-brand-name">KERNEL</span> currently includes native
adapters for these checkout request formats. all five adapters are enabled for
both stripe link and agentcard.

| merchant processor or platform | recognized HTTPS `POST` request formats                                                                                                      |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| stripe                         | form requests to `api.stripe.com/v1/payment_methods`, `/v1/tokens`, `/v1/payment_intents/{id}/confirm`, and `/v1/payment_pages/{id}/confirm` |
| shopify                        | JSON card-session requests to `checkout.pci.shopifyinc.com/sessions` and `deposit.<region>.shopifycs.com/sessions`                           |
| square                         | JSON card-nonce requests to `pci-connect.squareup.com/v2/card-nonce` and `pci-connect.squareupsandbox.com/v2/card-nonce`                     |
| recurly                        | form token requests to `api.recurly.com/js/v1/token` and `api.eu.recurly.com/js/v1/token`                                                    |
| razorpay                       | form card-payment requests to `api.razorpay.com/v1/payments/create/ajax` and `api.razorpay.com/v1/standard_checkout/payments/create/ajax`    |

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.

<span className="kernel-brand-name">KERNEL</span>'s native handoff aims to
support the same processors supported by agentcard's direct SDK. email
[support@kernel.sh](mailto: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 <span className="kernel-brand-name">KERNEL</span> vault api for both stripe link and agentcard.
* let <span className="kernel-brand-name">KERNEL</span> 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.

<Warning>
  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.
</Warning>

## Next step

configure [stripe link](/docs/integrations/payments/stripe-link) or [agentcard](/docs/integrations/payments/agentcard), then follow [Enable Payments in a Browser Agent](/docs/browsers/enable-payments-in-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:

```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.