Name: create-payment-credential
Author: stripe

Gets secure, one-time-use payment credentials (cards, tokens) from a Link wallet so agents can complete purchases on behalf of users. Use when the user says "get me a card", "buy something", "pay for X", "make a purchase", "I need to pay", "complete checkout", or asks to transact on any merchant sit

Create Payment Credential Use [Link](https://link.com) to get secure payment credentials from a Link wallet for one time purchases and recurring payments. The CLI can produce three credential types: A virtual card (PAN) for use with a standard web checkout form. The issued card works anywhere. A Shared Payment Token (SPT) when the seller is in the Stripe Network and accepts payments programmatically (for example with Machine Payment Protocols). A Link Pay Token (LPT) for a supported Stripe payment surface. Installing Install with npm install g @stripe/link cli . Always run the installed link cli binary; never substitute a package runner such as npx , pnpx , or bunx . Running commands Link CLI can run as an MCP server or as a standalone CLI . MCP: Add the following to your MCP client config ( .mcp.json , etc.) Run the MCP server directly with link cli mcp . Call tools/list to see all available MCP tools. Common commands/options List all commands: link cli llms List all commands with parameters: link cli llms full Get a command's exact schema with schema . For example, link cli spend request create schema Multi step commands return a next action. Spend request approval and automatic resume polling return next.argv ; mpp pay returns next.poll argv and next.pay argv . Invoke these directly without a shell. The command value is a Link CLI subcommand: pass [command, ...args] to the trusted CLI entrypoint. Dynamic compatibility strings are omitted on Windows — see the security notes. Authentication also returns a static next.command for polling. By default all output is in toon format. Pass format [json md yaml] to change output format. Some commands return a verification or approval URL. These must be presented to the user clearly for their action. auth <path flag to store auth credentials in a specific file instead of the default location. auth login writes to this file; all other commands read from it. Example: link cli auth login auth credentials.json Recommended : Run link cli llms to understand all the available commands. The llms full output is the canonical reference for parameter names, types, and valid values. Pass schema before invoking a command to understand its parameters and constraints. Core flow Copy this checklist and track progress: Step 1: Authenticate with Link for the whole task Step 2: Evaluate merchant site (determine credential type) Step 3: Get payment methods Step 4: Create spend request with correct credential type Step 5: Complete payment Step 1: Authenticate with Link for the whole task Check auth status: When authenticated, the response also reports the session's granted scope and authorization details (when the token endpoint returned them). If the response includes an update field, a newer version of link cli is available — run the update command from that field to upgrade before proceeding. If not authenticated: Replace <your agent name with the name of your agent or application (for example, "Personal Assistant" , "Shopping Bot" ). This name appears in the user's Link app when they approve the connection. Use a clear, unique, identifiable name. The response includes a next command — run it to poll until authenticated. If your environment cannot relay the verification code while a separate polling command blocks I/O, use inline polling instead: auth login client name "<name " interval 5 timeout 300 . This yields the code immediately then polls in the same command. If the user's email is already known and no creation time callback context was supplied, save them time by adding it as the URL encoded fromEmail query parameter to any app.link.com verification or action URL; preserve existing query parameters. DO NOT PROCEED until the user is authenticated with Link. Always check the current authentication status before starting a new login flow — the user might already be logged in. If the user is already authenticated but you need broader access (an additional scope , source actions , or authorization detail ), use auth upgrade instead of auth login . It takes the same flags but, rather than stopping with an "already logged in" message, merges what you request with the current scope / authorization details and starts a new approval for the superset — so existing access is never dropped. Check auth status first so you know what's already granted. The current session stays valid during the approval and is only replaced once the user approves the new one, so an abandoned upgrade leaves the existing session working. Optionally, before a purchase, run link cli user info retrieve to inspect the address, applicable spend limits, and verification requirements. Finite limit values are cents, while null limit or remaining values mean unlimited. When agent wallet verification requirement.action url is present, direct the user there to complete the required action. Step 2: Evaluate the merchant site BEFORE creating a spend request CRITICAL: Before calling spend request create you must complete this checklist: 1. Understand how the merchant accepts payments (cards or machine payments or other). Do NOT default to card credential type. The merchant determines the credential type — you cannot know it without checking first. Skipping this step will produce a spend request with the wrong credential type. 2. Have the final total amount needed. Inclusive of any shipping costs, taxes or other costs. Skipping this step will produce a spend request that does not cover the full amount needed, and will be rejected. 3. Clear context and understanding of what the user is purchasing. Be sure to know sizes, colors, shipping options, etc. Skipping this step will produce a spend request that the user does not recognize or understand. Determine how the merchant accepts payment: 1. Navigate to the merchant page — browse it, read the page content, and understand how the site accepts payment. 2. If the checkout page includes the AI agent steering block (find the .AiAgentPaymentSteering container — visually hidden but present in the DOM, typically inside a Stripe iframe) — it may support the Link Pay Token flow (Step 5, "Link Pay Token" section). Requires browser automation. Before creating an LPT request, verify that both input[name="link pay token"] and data stripe merchant account appear in the same frame. Read the account ID from that attribute. If either marker does not appear, use card instead. Without browser automation, use card . 3. If the page has a credit card form and no AI agent steering block (no .AiAgentPaymentSteering ) — use card . 4. If the page describes an API or programmatic payment flow — make a request to the relevant endpoint. If it returns HTTP 402 with a www authenticate header, use shared payment token . What you find determines which credential type to use: What you see Credential type What to request .AiAgentPaymentSteering block containing both input[name="link pay token"] and data stripe merchant account link pay token Link Pay Token (else card ) Credit card form, no AI agent steering block card (default) Card HTTP 402 with method="stripe" in www authenticate shared payment token Shared payment token (SPT) HTTP 402 without method="stripe" in www authenticate not supported Do not continue For 402 responses: Use mpp pay — it handles the entire flow automatically (probes URL, parses challenge, picks payment method, creates spend request, gets approval, and pays). See Step 5. Step 3: Confirm payment method and potentially shipping addresses Link will automatically use the default payment method on the account. If the user explicitly asks to pay with a specific card or bank, use the list command to show available options. Note that not all of the user's payment methods might appear; this will filter on "agentic ready" payment types. Only rename or clear a payment method nickname when the user explicitly asks. Never infer that a nickname should change. If the target ID is not known, run payment methods list first and identify the intended method using only its redacted details and existing nickname. Then use: Pass nickname "" to clear a nickname. Only set or clear the wallet wide default when the user explicitly asks. Use payment methods list to identify the intended method from redacted details if its ID is unknown. Setting a new default replaces the previous wallet default. Pass an explicit value; false clears the selected method's default status: nickname and is default can be combined. Omitted fields stay unchanged. If the merchant checkout requires a shipping or delivery address, fetch the user's saved shipping addresses. Use the default address unless the user specifies otherwise. Step 4: Create the spend request with the right credential type For card and Shared Payment Token flows, use the command below. For Link Pay Token, do not create this generic request: follow the LPT instructions in Step 5 after you have read the merchant account ID from the checkout DOM. Card requests may also include network id <network id to identify the merchant's network profile. Keep the card's merchant name and URL parameters. Completion callbacks (optional): If your application has a callback destination, generate an opaque, unpredictable nonce (for example, NONCE="$(openssl rand hex 32)" ) and add both flags to the create command above: Save the nonce unchanged and verify an exact match when the callback is received. Both flags must be supplied together. The URL must be valid and at most 2,048 characters; the nonce must be nonblank and at most 512 UTF 16 code units. The API validates live mode HTTPS and URL security. Use the returned approval url and action url as is; do not manually append callback parameters when creation time context was supplied. Retrieve the request to check its status after a callback. Currency: Pass the merchant's checkout currency with currency as a 3 letter ISO 4217 code (e.g. usd , eur , gbp ). If omitted, Link uses the consumer's default spend request currency. Do not convert prices yourself. If the currency is not supported, the API rejects the request. Amounts ( amount , unit amount , and total amounts) are integers in the currency's smallest unit (e.g. cents): 1999 is $19.99 USD or €19.99 EUR. Some currencies have no minor unit, so 1999 in jpy is ¥1,999. Recurring payments: Use recurring terms only when the user's request covers the subscription or recurring purchase. Confirm the spending limit, currency, and cadence from the user or existing task context. Describe these terms in context so the user can review them during approval. Add recurring interval day week month year to spend request create . recurring interval count is an optional positive integer; the server defaults it to 1 . For a $20 monthly limit, use amount 2000 currency usd recurring interval month . For every two weeks, use recurring interval week recurring interval count 2 . The amount is the spending limit for each period, not a lifetime total. The merchant schedules charges. Keep the credential type and merchant targeting required by checkout; recurring terms do not replace those inputs. Omit recurring flags for one time purchases. Follow normal approval and credential retrieval. Recurring card requests stay active after individual charges. Do not poll for succeeded after each payment or create a replacement each period. Confirm payment from the merchant's result or transaction records. Respect credential expiry, including card.valid until . spend request update cannot change the interval or count. To stop future use of a credential, call spend request cancel <id and check the