diff --git a/browsers/enable-payments-in-browser-agent.mdx b/browsers/enable-payments-in-browser-agent.mdx
index eacee4c6..db618228 100644
--- a/browsers/enable-payments-in-browser-agent.mdx
+++ b/browsers/enable-payments-in-browser-agent.mdx
@@ -12,7 +12,7 @@ verify and approve each purchase before completing checkout.
 - have an existing browser agent. this guide adds payment handling, not navigation or reasoning.
 - choose a wallet integration from the [wallet overview](/integrations/wallets/overview), then follow its tab below.
 - install a KERNEL sdk with the `vaults` resource. set `KERNEL_API_KEY` and `KERNEL_PROJECT_ID` in your controller.
-- use a low-value checkout you control. link is live-only and requires an https merchant origin and verified field selectors. agentcard requires a [native processor adapter](/integrations/wallets/overview#checkout-and-processor-coverage); the processor doesn't need to be stripe.
+- use a low-value checkout you control. link is live-only and requires an https merchant origin. on stripe checkouts that support link pay tokens, KERNEL fills the payment without field selectors; elsewhere you need verified field selectors for the virtual card. agentcard requires a [native processor adapter](/integrations/wallets/overview#checkout-and-processor-coverage); the processor doesn't need to be stripe.
 - for agentcard, set `AGENTCARD_MODE` in your controller and verify it against the credential's mode. customer-owned configs expose `test_mode` (`true` means sandbox); for KERNEL-managed credentials, confirm the deployment's mode. stop if the mode is unknown or mismatched.
 - identify how you'll read the merchant's trusted order record. you need it to confirm a matching paid order. deterministic checkout data can verify purchase details before submission, but without the order record afterward, the result remains indeterminate.
 
@@ -215,9 +215,9 @@ step 2, a connected wallet in the same vault, and this browser session.
 #### Prepare and authorize the card
 
 1. list the wallet's payment methods and let the user select one.
-2. [create a link card item](/integrations/wallets/stripe-link) named `notebook-order` from the verified purchase and selected method.
-3. require `authorize` in `available_operations`, invoke it with that same purchase object, and present any returned action through your controller.
-4. wait for the card to become `ready`, then require `fill` immediately before use. link cards never expose `state.aliases`.
+2. with the browser on the final checkout page, [create a link card item](/integrations/wallets/stripe-link#create-and-authorize-a-card-item) named `notebook-order` from the verified purchase and selected method.
+3. require `authorize` in `available_operations` and invoke it with the browser's `browser_id` and the checkout's exact current `page_url`. KERNEL inspects the checkout and chooses a [link pay token or a virtual card](/integrations/wallets/stripe-link#link-pay-tokens-and-virtual-cards). present any returned action through your controller.
+4. wait for the card to become `ready`, then require `fill` immediately before use and follow its description. link cards never expose `state.aliases`.
 
 <CodeGroup>
 
@@ -256,8 +256,14 @@ kernel vaults items get user-12345 notebook-order --wait 60 -o json
 
 your controller must authorize the destination and selectors before disclosure.
 `checkoutURL` / `checkout_url` is the browser's exact current top-level https url,
-including query and fragment. it must share the origin of `spec.merchant_url`.
-no playwright page object is required. see [field requirements](/integrations/wallets/stripe-link#fill-the-checkout).
+including query and fragment. it must be on the origin of the checkout page you
+authorized at. no playwright page object is required. see
+[field requirements](/integrations/wallets/stripe-link#fill-the-checkout).
+
+if the card's `fill` description says to omit fields, KERNEL delivered a link pay
+token: send only `browser_id` and `page_url`, as in
+[fill a link pay token](/integrations/wallets/stripe-link#fill-a-link-pay-token).
+the example below is for a virtual card.
 
 `fill` supports stored [billing fields](/integrations/wallets/stripe-link#map-card-fields-to-inputs)
 as well as card fields. requesting an absent value returns `field_unavailable`
@@ -717,25 +723,32 @@ card.
    creating or authorizing a card.
 6. show me the verified merchant, amount, currency, and item or cart contents.
    wait for my explicit confirmation, then freeze that verified purchase object.
-7. list the wallet's payment methods and ask me which one to use. create a link
-   card item named `checkout-card` from that same verified, confirmed object and
-   the selected payment method. use the exact checkout url as `merchant_url` and
-   include a specific context of at least 100 characters.
+7. list the wallet's payment methods and ask me which one to use. with the
+   browser still on the final checkout page, create a link card item named
+   `checkout-card` from that same verified, confirmed object and the selected
+   payment method. use the exact checkout url as `merchant_url` and include a
+   specific context of at least 100 characters.
 8. retrieve the card item and confirm that `authorize` appears in
-   `available_operations`. give me the exact cli command, but do not run it. ask
-   me to invoke authorization and complete any provider action from a trusted
-   terminal or application outside this agent. after i confirm completion,
-   retrieve the item again and require its status to be `ready`. do not print,
-   return, or open an action url.
-9. require `fill` in the card's `available_operations`. inspect the checkout's
-   inputs and invoke `kernel vaults items invoke user-12345 checkout-card fill`
-   with `--params` or `--spec-file`: browser_id is the attached session id,
+   `available_operations`. give me the exact cli command, including
+   `--browser-id` with the attached session id and `--page-url` with the exact
+   current top-level checkout url, but do not run it. ask me to invoke
+   authorization and complete any provider action from a trusted terminal or
+   application outside this agent. KERNEL inspects the checkout and chooses a
+   link pay token or a virtual card; do not inspect or invoke the checkout's
+   webmcp tools yourself. after i confirm completion, retrieve the item again
+   and require its status to be `ready`. do not print, return, or open an
+   action url.
+9. require `fill` in the card's `available_operations` and follow its
+   description. invoke `kernel vaults items invoke user-12345 checkout-card fill`
+   with `--params` or `--spec-file`: browser_id is the attached session id and
    page_url is the exact current top-level https url (including query and
-   fragment), and fields maps stored field names to unique css selectors.
-   the page must share the card's merchant_url origin. combined expiration
-   requires format MM/YY or MM/YYYY; timeout_ms is optional. request only needed
-   card and billing fields. fill writes actual values into the browser; do not
-   read them back, expose them in model context, or assume recordings omit them.
+   fragment), on the origin of the checkout you authorized at. if the
+   description says to omit fields, send no fields. otherwise inspect the
+   checkout's inputs and add fields mapping stored field names to unique css
+   selectors; combined expiration requires format MM/YY or MM/YYYY. timeout_ms
+   is optional. request only needed card and billing fields. fill writes actual
+   values into the browser; do not read them back, expose them in model
+   context, or assume recordings omit them.
 10. preserve the value-free fill result and every per-field outcome. continue
    only on `completed`. after failed or unknown outcomes or transport errors:
    fill never submits, so a retry is safe. retry only after checking the page,
diff --git a/browsers/payments.mdx b/browsers/payments.mdx
index 3003d03b..287d0555 100644
--- a/browsers/payments.mdx
+++ b/browsers/payments.mdx
@@ -23,7 +23,7 @@ agentcard uses an integration-specific alternative: the agent enters non-sensiti
 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. attach the vault when you create the browser session. the attachment also covers items created later in that vault.
-4. create a card item for the verified, user-confirmed purchase. complete the provider's required preparation and approval. link issues a single-use card; agentcard can reuse a card item with separate approval for each checkout.
+4. create a card item for the verified, user-confirmed purchase. complete the provider's required preparation and approval. link authorizes at the checkout page and issues a merchant-bound link pay token on supported stripe checkouts or a single-use virtual card elsewhere; agentcard can reuse a card item with separate approval for each checkout.
 5. invoke KERNEL's advertised `fill` operation to inject payment fields without supplying their values, then inspect the outcomes before submitting. for agentcard's alias-based flow, enter aliases and keep a trusted approval observer running while the checkout request is held.
 6. submit checkout once, complete any remaining provider-hosted approval, and reconcile with the merchant's order state. fill or approval alone is not payment success.
 
diff --git a/integrations/wallets/overview.mdx b/integrations/wallets/overview.mdx
index e48f15e9..f4936db9 100644
--- a/integrations/wallets/overview.mdx
+++ b/integrations/wallets/overview.mdx
@@ -5,7 +5,7 @@ description: "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. link supplies approved single-use cards that you inject through KERNEL's [`fill` api](/vaults/fill), keeping the values out of your application's injection flow and model context. agentcard uses aliases and provider-executed requests instead of `fill`.
+wallet providers supply payment material and determine approval and reuse behavior; they are not the merchant's payment processor. link supplies an approved credential for each purchase, a merchant-bound link pay token on supported stripe checkouts or a single-use virtual card elsewhere, that you inject through KERNEL's [`fill` api](/vaults/fill), keeping the values out of your application's injection flow and model context. 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](/browsers/payments).
 
@@ -44,18 +44,18 @@ see [how payments work on KERNEL](/browsers/payments#how-payments-work) for the
 | ------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------- |
 | user eligibility          | requires a US phone number                               | —                                                                   |
 | 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                                      |
+| purchase authorization    | explicit `authorize` operation at the final checkout page | the user approves with Face ID                                      |
 | payment handoff           | KERNEL's `fill` api injects values without passing them through application code or model context; values enter the browser | agentcard executes the intercepted request; KERNEL replays the response |
-| reuse                     | provider-issued single-use card | reusable card item; each checkout requires approval             |
+| reuse                     | single-use virtual card, or a merchant-bound link pay token on supported stripe checkouts | reusable card item; each checkout requires approval             |
 | environment               | live only                                                | credential-defined; customer-owned configs expose `test_mode`       |
 
-choose [link by stripe](/integrations/wallets/stripe-link) to enable users to pay with cards stored in their link wallet, each purchase is paid by a newly approved, single-use card. choose [agentcard](/integrations/wallets/agentcard) to enable users to pay with their actual cards, the same card can be used for multiple purchases and user-approval is required for each.
+choose [link by stripe](/integrations/wallets/stripe-link) to enable users to pay with cards stored in their link wallet, each purchase is paid with a newly approved credential: a link pay token on supported stripe checkouts, or a single-use virtual card elsewhere. choose [agentcard](/integrations/wallets/agentcard) to enable users to pay with their actual cards, the same card can be used for multiple purchases and user-approval is required 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
 
-KERNEL's `fill` api does not require a native processor adapter. for link-issued cards, the page must match the allowed merchant origin and provide supported checkout inputs. see [link card requirements](/integrations/wallets/stripe-link#fill-the-checkout).
+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](/integrations/wallets/stripe-link#fill-the-checkout).
 
 agentcard's alias-based checkout requires a recognized processor request. see [agentcard's processor coverage](/integrations/wallets/agentcard#checkout-and-processor-coverage) for supported formats and limitations. neither field filling nor provider handoff guarantees processor acceptance or payment success.
 
diff --git a/integrations/wallets/stripe-link.mdx b/integrations/wallets/stripe-link.mdx
index bc8ba436..d4b92c7e 100644
--- a/integrations/wallets/stripe-link.mdx
+++ b/integrations/wallets/stripe-link.mdx
@@ -3,11 +3,11 @@ title: "Link by Stripe"
 description: "use link by stripe to approve a one-use payment credential for a browser checkout"
 ---
 
-[link by stripe](https://stripe.com/payments/link) connects a user's wallet through oauth and issues a single-use card for an approved purchase. KERNEL's native integration handles wallet connection, token refresh, approval actions, and card storage through vault items. oauth credentials and card material use kms-backed envelope encryption.
+[link by stripe](https://stripe.com/payments/link) connects a user's wallet through oauth and issues a payment credential for an approved purchase: a merchant-bound link pay token on supported stripe checkouts, or a single-use virtual card everywhere else. KERNEL inspects the checkout and chooses which one; you never choose or handle it. KERNEL's native integration handles wallet connection, token refresh, approval actions, and card storage through vault items. oauth credentials and card material use kms-backed envelope encryption.
 
 use KERNEL's [`fill` api](/vaults/fill) to safely inject the approved card's values into an attached browser without passing them through your application's injection code or model context. you provide references and selectors; KERNEL returns outcomes, not the values. link supplies the card, while `fill` is a KERNEL operation shared with other supported vault items.
 
-link is the wallet provider, not the merchant's payment processor. `fill` does not require a native processor adapter; link-issued cards require supported, uniquely selectable checkout inputs on an allowed merchant page. the merchant's processor doesn't need to be stripe. for the overall offering, see [payments on KERNEL](/browsers/payments).
+link is the wallet provider, not the merchant's payment processor. a virtual card works on any checkout with supported, uniquely selectable card inputs, so the merchant's processor doesn't need to be stripe. a link pay token works only on stripe checkouts that expose link's agent payment tools; KERNEL detects them during authorization. for the overall offering, see [payments on KERNEL](/browsers/payments).
 
 
 ## Before you start
@@ -184,10 +184,12 @@ that grant. continue with [Select a payment method](#select-a-payment-method).
 1. connect a wallet: use KERNEL's client and present the returned `link_oauth` action, or complete oauth in your backend and import the grant with your provider configuration.
 2. require the wallet to be `connected`.
 3. request the advertised `payment_methods` expansion and let the user choose an eligible method.
-4. create a `card` item with the purchase details.
-5. retrieve the card, verify that it advertises `authorize`, and perform that operation after explicit user approval.
+4. reach the final checkout page in a browser with the vault attached, then create a `card` item with the purchase details. creating the card doesn't contact link. to change the details before authorizing, update the card.
+5. retrieve the card, verify that it advertises `authorize`, and after explicit user approval invoke it with the browser's `browser_id` and the checkout's exact current top-level `page_url`. KERNEL inspects that checkout, chooses a link pay token or a virtual card, and sends the user an approval request.
 6. complete the returned `spend_approval` or `push_approval` action and wait for `state.status` to become `ready`.
-7. require the advertised `fill` operation, then supply the attached browser's session id, exact current top-level https `page_url`, and field/selector bindings. inspect every fill outcome before deciding whether to submit checkout once.
+7. require the advertised `fill` operation and follow its description: a link pay token takes `browser_id` and `page_url` only, and a virtual card also takes field/selector bindings. inspect the fill outcome, then submit the checkout yourself once.
+
+each item's `available_operations[].description` describes the next step and its recovery, so have your agent read it rather than hard-coding the flow.
 
 ## Connect a wallet
 
@@ -377,6 +379,8 @@ show the returned methods in a trusted user-facing surface, let the user choose
 
 ## Create and authorize a card item
 
+create the card once the browser is on the final checkout page and you know the final amount, currency, and merchant. the examples use `browser`, a KERNEL browser created with this vault attached, and `checkoutURL` / `checkout_url`, the browser's exact current top-level checkout url obtained through your browser-control method.
+
 <CodeGroup>
 
 ```typescript TypeScript
@@ -402,10 +406,16 @@ if (!card.available_operations.some(({ type }) => type === "authorize")) {
   throw new Error("authorization is unavailable");
 }
 
-card = await kernel.vaults.items.performOperation(card.key, {
+const authorized = await kernel.vaults.items.performOperation(card.key, {
   id_or_name: vault.id,
   type: "authorize",
+  browser_id: browser.session_id,
+  page_url: checkoutURL,
 });
+if (authorized.type !== "card") {
+  throw new Error("unexpected operation response");
+}
+card = authorized;
 if (card.action && "url" in card.action) {
   await presentProviderAction({
     userID: authenticatedUser.id,
@@ -443,6 +453,8 @@ card = kernel.vaults.items.perform_operation(
     card.key,
     id_or_name=vault.id,
     type="authorize",
+    browser_id=browser.session_id,
+    page_url=checkout_url,
 )
 if card.action is not None and hasattr(card.action, "url"):
     present_provider_action(
@@ -465,25 +477,103 @@ kernel vaults cards create user-12345 notebook-order \
     "context": "buy one notebook from example shop for a total of 23.06 usd, including tax and shipping. this request is for this purchase only and must not be repeated."
   }'
 kernel vaults items get user-12345 notebook-order -o json
-kernel vaults items invoke user-12345 notebook-order authorize --open
+# BROWSER_ID is the attached session ID; PAGE_URL is its exact current checkout URL.
+kernel vaults items invoke user-12345 notebook-order authorize \
+  --browser-id "$BROWSER_ID" --page-url "$PAGE_URL" --open
 kernel vaults items get user-12345 notebook-order --wait 60 -o json
 ```
 
 </CodeGroup>
 
-`amount` uses minor currency units, so `2306` means 23.06 usd. link accepts values from 1 to 50000. `context` must contain at least 100 characters. card creation is live-only, and `spec.test` is not supported.
+`amount` uses minor currency units, so `2306` means 23.06 usd. link accepts values from 1 to 500000, but a virtual card allows at most 50000. `context` must contain at least 100 characters. card creation is live-only, and `spec.test` is not supported.
+
+until you authorize the card at a checkout, you can change its spec with an update. after that, updates return `409`: delete the card and create a new one with the updated details.
+
+### Link pay tokens and virtual cards
+
+authorization fixes how link delivers the credential:
+
+| | link pay token | virtual card |
+| --- | --- | --- |
+| when KERNEL chooses it | the checkout is a stripe checkout that exposes link's agent payment tools | any other checkout |
+| amount limit | 500000 minor units | 50000 minor units |
+| what `fill` does | passes a short-lived token to the checkout's link tools; the checkout shows link as the payment method | writes the card number, cvc, expiry, and requested billing fields into the inputs you select |
+| where `fill` works | pages on the origin of the checkout you authorized at, for the stripe account the user approved | pages on the origin of the checkout you authorized at |
+
+link resolves the merchant shown on the approval screen from the checkout's stripe account, so a link pay token request doesn't send `merchant_name` or `merchant_url`. the token is fetched fresh for each fill and never returned to you.
 
-`merchant_url` supplies provider context and restricts the destination for card use. see [fill the checkout](#fill-the-checkout) for exact page and origin requirements; `state.domains` is metadata, not an authorization rule.
+don't inspect or invoke the checkout's webmcp tools yourself. KERNEL does that during `authorize` and `fill`.
+
+authorizing without `browser_id` and `page_url` still issues a virtual card that fills pages on the `merchant_url` origin. use it only as a fallback when checkout inspection keeps failing.
+
+### Authorization errors
+
+these errors happen before any payment request is created, so the card stays `requested` and you can authorize again:
+
+| code | what to do |
+| --- | --- |
+| `page_not_found` | open the checkout in the browser at exactly `page_url`, then authorize again |
+| `ambiguous_page` | close extra tabs so exactly one is at `page_url`, then authorize again |
+| `browser_not_found`, `browser_unavailable`, `destination_denied`, `timeout`, `browser_error` | make sure the browser exists in this project, is leased, has the vault attached, and isn't busy with another fill, and that the checkout is open in exactly one tab, then authorize again |
+| `invalid_request` for the amount | the checkout needs a virtual card and the amount exceeds 50000. delete the card and tell the user this checkout can't be paid with a link virtual card; don't lower the amount of a confirmed purchase |
+
+if the user declines or the request expires, delete the card and create a new one. once approval has been requested, `{"type":"authorize"}` only re-checks the request and never creates another payment request.
 
 ## Fill the checkout
 
 after the user completes approval, retrieve the card with `wait: 60`. continue only when it is `ready` and advertises `fill`; one bounded wait may finish before approval does. the examples below show the fill request; for the full controller and agent handoff, follow the [browser agent payments guide](/browsers/enable-payments-in-browser-agent#4-fill-payment-fields).
 
-supply `browser_id`, exact current top-level `page_url`, and ordered `fields` bindings. the browser must have the vault attached in the same project. the card must remain ready, unexpired, and undeleted, with stored encrypted material and an existing parent wallet. combined `expiration` requires `format: "MM/YY"` or `"MM/YYYY"`; `timeout_ms` is optional.
+the advertised `fill` description says which inputs the card needs. every fill supplies `browser_id` and the exact current top-level `page_url`. the browser must have the vault attached in the same project, and the card must remain ready, unexpired, and undeleted with its parent wallet. a link pay token fill also requires that wallet to be connected, because the token is retrieved with it. `timeout_ms` is optional.
+
+`page_url` must use https without embedded credentials and must be on the origin of the checkout page you authorized at, or on the origin of `spec.merchant_url` for a card authorized without a checkout. the origin comparison includes the host and port (default `443` is normalized); it does not allow other subdomains. the path can differ, so a fill still works after the checkout moves to another page on the same origin, but the request must name the exact current page. a disallowed origin returns `403 destination_denied`. descendant payment frames can have different origins; the restriction applies to the top-level merchant page.
+
+### Fill a link pay token
+
+omit `fields`. KERNEL selects card on the checkout if needed, checks that the checkout's stripe account is the one the user approved, retrieves a fresh token, and passes it to the checkout's link tools. on stripe checkouts, the card form is replaced by the user's link payment method.
+
+<CodeGroup>
+
+```typescript TypeScript
+const result = await kernel.vaults.items.performOperation("notebook-order", {
+  id_or_name: vault.id,
+  type: "fill",
+  browser_id: browser.session_id,
+  page_url: checkoutURL,
+});
+if (result.type !== "fill") throw new Error("unexpected operation response");
+if (result.status !== "completed") {
+  throw new Error(`fill ${result.status}; check the checkout page, then retry`);
+}
+```
+
+```python Python
+result = kernel.vaults.items.perform_operation(
+    "notebook-order",
+    id_or_name=vault.id,
+    type="fill",
+    browser_id=browser.session_id,
+    page_url=checkout_url,
+)
+if result.type != "fill":
+    raise RuntimeError("unexpected operation response")
+if result.status != "completed":
+    raise RuntimeError(f"fill {result.status}; check the checkout page, then retry")
+```
+
+```bash CLI
+kernel vaults items invoke user-12345 notebook-order fill \
+  --params "{\"browser_id\":\"$BROWSER_ID\",\"page_url\":\"$PAGE_URL\"}" -o json
+```
+
+</CodeGroup>
+
+a different stripe account on the page returns `403 destination_denied`, and nothing is passed to the page. KERNEL checks the account before retrieving the token and again before passing it.
+
+### Fill a virtual card
 
-`page_url` is required, must use https without embedded credentials, and must share the https origin of `spec.merchant_url`. the origin comparison includes the host and port (default `443` is normalized); it does not allow other subdomains. the checkout path can differ from the stored merchant url, but the request must name the exact current page. a disallowed origin returns `403 destination_denied`. descendant payment frames can have different origins; the restriction applies to the top-level merchant page.
+supply ordered `fields` bindings. combined `expiration` requires `format: "MM/YY"` or `"MM/YYYY"`.
 
-### Map card fields to inputs
+#### Map card fields to inputs
 
 the examples below continue after wallet connection and spend approval with a ready `notebook-order` card, the same project-scoped `kernel` client with retries disabled, and a `browser` created with its vault attached. `checkoutURL` / `checkout_url` is the browser's exact current top-level url, obtained through your browser-control method; no playwright page object is required. verify the purchase and destination before calling fill; neither a model-proposed url nor a selector authorizes disclosure.
 
@@ -595,17 +685,17 @@ wallet and card items accept these `spec` fields. fields not listed here are rej
 | item | required fields | optional fields |
 | --- | --- | --- |
 | wallet | `provider: 'link'`, `authorization.method: 'oauth'`, `authorization.client` | write-only `authorization.tokens` is required only with a customer-managed client |
-| card | `provider`, `wallet`, `payment_method_id`, `amount`, `currency`, `merchant_name`, `merchant_url`, `context` | `line_items`, `totals`, `metadata`, `expires_at` |
+| card | `provider`, `wallet`, `payment_method_id`, `amount`, `currency`, `merchant_name`, `merchant_url`, `context` | `line_items`, `totals`, `metadata` |
 
 the default link client is `{type: 'kernel_managed'}`. for your own client, set
 `authorization.client` to `{type: 'customer_managed', provider_config: {name: 'checkout-link'}}`
 and supply `authorization.tokens` with `access_token` and `refresh_token`.
 
-`amount` uses minor currency units. link accepts 1–50000, requires a three-letter `currency`, limits `merchant_name` to 255 characters, requires an absolute http or https `merchant_url`, and requires at least 100 characters in `context`. its optional `expires_at` is a unix timestamp in seconds.
+`amount` uses minor currency units. link accepts 1–500000, and a virtual card allows at most 50000. link requires a three-letter `currency`, limits `merchant_name` to 255 characters, requires an absolute http or https `merchant_url`, and requires at least 100 characters in `context`. the card item's `expires_at` comes from link: the spend request's expiry, or the issued virtual card's validity. when link reports no expiry for a link pay token request, `fill` stays available for 30 minutes after authorization, including the time the user takes to approve.
 
 link `line_items` support `name`, `quantity`, `unit_amount`, `description`, `sku`, `url`, `image_url`, `product_url`, and `totals`. each `totals` entry supports `type`, `display_text`, and `amount`. link `metadata` accepts string values.
 
-card updates replace the complete `spec`; they are not partial merges. link card items can update only while `requested`.
+card updates replace the complete `spec`; they are not partial merges. a `requested` link card accepts any valid spec, and a pending virtual-card request can update the fields link supports on its existing request. once a card is authorized with `browser_id` and `page_url`, updates return `409`: delete it and create a new card.
 
 ### Item states
 
diff --git a/vaults/fill.mdx b/vaults/fill.mdx
index f75902da..97a0ec13 100644
--- a/vaults/fill.mdx
+++ b/vaults/fill.mdx
@@ -27,7 +27,7 @@ attach the vault when creating the browser. the browser and vault must belong to
 
 ## Map fields to inputs
 
-your request names the item and vault, the attached browser's `browser_id`, the current `page_url`, and field-selector bindings. field names come from the item's schema; they are not raw values. the following example uses a credential item with username and password fields.
+your request names the item and vault, the attached browser's `browser_id`, the current `page_url`, and field-selector bindings. field names come from the item's schema; they are not raw values. the item's advertised `fill` description says which inputs it needs. a link card that delivers a [link pay token](/integrations/wallets/stripe-link#fill-a-link-pay-token) takes no field bindings. the following example uses a credential item with username and password fields.
 
 <Note>
   `fill` reads values from a ready credential item. if another vault