Update Link payment docs for checkout-bound card items

[rgarcia]

Depends on kernel/kernel#3950; do not merge before it and the SDK release.

Summary

Updates the wallet and payment docs for the new Link card flow, where a Link card item is one immutable credential bound to a checkout:

1. connect a Link wallet
2. at the final checkout page, in a browser with the vault attached, PUT a Link card with browser_id and the exact page_url
3. the user approves through action.url (spend_approval) or in the Link app (push_approval)
4. fill
5. the agent clicks Pay

Changes

• integrations/wallets/stripe-link.mdx: rewrote the lifecycle and replaced "create and authorize" with new sections for opening the checkout and creating the card there. Added:
  • How KERNEL pays: Stripe Checkout pages that expose Link Pay Token WebMCP tools get a merchant-bound Link Pay Token (no field selectors, up to 500000 minor units). Other checkouts get a one-time virtual card filled into card fields (up to 50000). Callers never choose.
  • Immutability and retry rules, and a table of creation errors (browser_not_found, browser_unavailable, destination_denied, ambiguous_page, timeout, browser_error, 429).
  • A Link Pay Token fill example with no fields.
  • The fill browser_id/page_url must exactly match the card spec.
  • Updated the item reference (browser_id, page_url, amount limits, wallet description). Removed merchant_url and card updates.
• browsers/enable-payments-in-browser-agent.mdx: the Link tab now creates the card at checkout and reads the advertised fill description to decide whether to send fields. The coding-agent prompt follows the new flow. Removed the create/update/authorize wording, and the AgentCard tab no longer suggests updating a card spec.
• integrations/wallets/agentcard.mdx: removed the card update/PATCH example. The reuse section now says cards are immutable: a ready card can be reused for the same purchase details, and different details need a new item. Removed the authorize and merchant_url references.
• integrations/wallets/overview.mdx, browsers/payments.mdx, vaults/overview.mdx, vaults/fill.mdx: removed authorize from the operation list and comparison table, described both Link payment modes, noted that fields is optional depending on the item and that fill results can have an empty fields array, and stated that fill never clicks Pay.

The API reference pages are generated from the live OpenAPI spec (docs.json → api.onkernel.com/spec.json), so they will update when kernel/kernel#3950 deploys. This repo has no CLI or MCP reference page for vaults, so none needed changes.

SDK / CLI targets

The code samples target the upcoming SDK release generated from kernel/kernel#3950. This repo doesn't build or pin SDKs, so there is nothing to swap here after the release. CLI examples match kernel/cli#250 (kernel vaults cards create ... --provider link --spec '{"browser_id", "page_url", ...}', and items invoke ... fill without authorize).

Testing

• mint broken-links (the CI check, mint@4.2.930): no broken links
• mint validate: build validation passed
• Extracted the new and changed TypeScript and Python Link snippets and type-checked them locally against the #3950 preview SDKs (kernel-node-sdk-staging@6c92f22 with tsc --strict, kernel-python-sdk-staging@166faf3 with pyright): 0 errors. This was not run against a live API.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Sep 25, 2026, 2:06 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cursor]

Risk assessment: Medium

I did not approve this PR.

This repo is a Mintlify docs site, and the diff is limited to seven .mdx pages (no application code, config, schema, or infrastructure). There is no CODEOWNERS file, and this PR has no existing approval.

The change is still medium risk because it is not a typo or cosmetic docs edit:

• browsers/enable-payments-in-browser-agent.mdx rewrites the copy-paste coding-agent prompts under Try with a coding agent. Those prompts are model instructions for a live Link or Agentcard checkout. The new text drops the explicit authorize step, binds card creation to a browser session and exact page_url, changes which fill inputs to send, and tells the agent to click pay. That can change how an agent handles a real payment.
• The same payment-flow change is repeated across the Link, Agentcard, payments, and vault fill pages: immutable checkout-bound cards, pay-token vs virtual-card fill, amount limits, and removal of card update / authorize.

Blast radius is anyone following the published guide, including an agent given the copied prompt. Incorrect instructions can start or submit a live checkout against the wrong flow. I am not assigning reviewers.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit db4c204. Configure here.}

[cursor]

Risk assessment: Medium

I did not approve this PR.

Re-checked the full diff after a9b8a10 ("Keep Link page intro high-level"). That commit only shortens the intro of integrations/wallets/stripe-link.mdx and moves the pay-token vs virtual-card detail into the existing How KERNEL pays section. It does not lower the risk of the rest of the change, and there is still no approval to revoke. No CODEOWNERS file is present.

This remains medium risk. The diff is seven .mdx pages and does not change application code, config, schema, or infrastructure, but it is not a typo or cosmetic docs edit:

• browsers/enable-payments-in-browser-agent.mdx rewrites the copy-paste prompts under Try with a coding agent. Those prompts are model instructions for a live Link or Agentcard checkout. The new text drops the explicit authorize step, binds card creation to a browser session and exact page_url, changes which fill inputs to send, and tells the agent to click pay. That can change how an agent handles a real payment.
• The same payment-flow change is repeated across the Link, Agentcard, payments, and vault fill pages: immutable checkout-bound cards, pay-token vs virtual-card fill, amount limits, and removal of card update / authorize.

Blast radius is anyone following the published guide, including an agent given the copied prompt. Incorrect instructions can start or submit a live checkout against the wrong flow. I am not assigning reviewers.

  

_{Sent by Cursor Automation: Assign PR reviewers}