# Card - paying MyRadar Cards pay for plan purchases. No crypto wallet is needed. Eligible hosted checkouts support browser agents with Link Pay Tokens (LPT), with human checkout as a fallback. ## Lanes - `"checkout": true` - creates an unpaid hosted checkout; creating the URL needs no funds or card. Inspect the page for browser-agent payment support as described below, or privately deliver the URL to your human. Poll the returned `statusUrl` to confirm completion. - Shared payment token - an `spt_` your platform granted for this seller (single-use: mint a fresh one per purchase), settled over the standard MPP lane: every card-eligible 402 carries a `method="stripe"` challenge in `www-authenticate`; answer it with the credential in `Authorization` (`Authorization: Payment `; on purchases your bearer rides `ZC-Agent-Authorization`), never as a body field. Mint against this seller's network profile `profile_61VOExu4T5rZ6kYZ0A6VOExt04SQ8q86q59ZzMTqa98q` (Stripe account `acct_1UEYf3P5iqAeM9Kp`); Link wallets settle automatically with `link-cli mpp pay`. The 402's (or purchase 402's) `card` block is the authoritative contract - it lists the exact fields. ## Browser-agent checkout: LPT and WebMCP Creating checkout does not complete payment. Open `checkout.url` and confirm the seller, amount, currency, and live/test mode before proceeding. Keep the checkout URL and credentials private. 1. Discover WebMCP tools on the actual Stripe checkout and read their current definitions. Discover them again after form or payment-method changes. Tool names and schemas vary; unavailable discovery may reflect browser support or frame permissions rather than absent checkout capabilities. 2. Before requesting a Link Pay Token (LPT), find the AI-agent steering checkbox in the top document or a Stripe frame and enable it. It can be offscreen; use a DOM-level interaction or focus it and press Space. Verify `input[name="link_pay_token"]` and `[data-stripe-merchant-account]` in that SAME Stripe document/frame. Read the merchant account from that marker and compare it with any seller/account information returned by the checkout tools. Stop on a mismatch; Link branding alone is insufficient. 3. Use your authorized Link wallet to request a merchant-bound LPT for the confirmed amount, using the DOM-derived account. Obtain spend approval and retrieve the token immediately before use; tokens expire within 30 minutes or when the spend request expires. LPT requests do not support `--test`. Follow [Stripe's current LPT instructions](https://github.com/stripe/link-cli#link-pay-token). 4. If a discovered WebMCP tool explicitly accepts an LPT (for example, `set_link_pay_token`), follow its live schema. Treat token submission as a payment action requiring authorization, not a harmless field setter; do not assume a separate submit step is needed. If that tool is unavailable but the same-frame markers are valid, follow Stripe's documented DOM token-input and submission flow. Handle any further authentication or approval requested by Stripe. 5. Poll the returned `statusUrl` to establish completion before retrying delivery. After an uncertain submission, reconcile status before attempting another payment. `pending_human_payment` is the existing pending-checkout status; it does not restrict who can operate the browser. If the LPT route cannot be established, do not request a token based on assumptions. Privately give your human the checkout URL to pay. LPT is submitted only to Stripe checkout, never to a ZeroClick API body or as an MPP credential. Keep SPT/MPP as a separate programmatic payment flow when advertised. Availability is specific to the inspected checkout. Do not infer support for manual or partial capture, saved-card setup, or recurring charges from a one-time checkout's LPT tools. For those flows, use human checkout unless the required behavior has been verified. Preserve the existing identity and claim requirements for the purchase. ## Plan purchases by card Buying a plan needs an agent credential first - see [Identity](https://agents.myradar.dev/zcj/hnp9jvh1efbw/auth.md). Send the purchase with `Authorization: Bearer ` and one body lane above, or answer the purchase 402's stripe challenge with `Authorization: Payment ` and your bearer moved to `ZC-Agent-Authorization: Bearer `. Topping up a credit balance works exactly the same way: `POST https://agents.myradar.dev/zcj/hnp9jvh1efbw/extend` with your bearer, an `amountUsd` meeting BOTH the existing plan minimum and the $0.50 card floor, and the same body lane. Its 402 carries the same `card` block. A failed delivery refunds the card in full automatically (see the `zc-billing` response header). A retry answering `payment_refunded` or `payment_consumed` is terminal: that payment is spent - start over with a fresh request and pay its new 402.