Create Payment Credential

Create Payment Credential

Use Link to get secure, one-time-use payment credentials from a Link wallet to complete purchases.

The CLI can produce one of two 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).

It can also create a Link Pay Token (LPT)-bound SpendRequest for a supported Stripe checkout surface. LPT is an execution mode for the card flow, not a third credential type.

Installing

Install with npm install -g @stripe/link-cli. Or run directly with npx @stripe/link-cli.

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

{
  "mcpServers": {
    "link": {
      "command": "npx",
      "args": ["@stripe/link-cli", "--mcp"]
    }
  }
}

Run the MCP server directly with npx @stripe/link-cli@latest --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. For example, authenticating or creating a spend request returns a _next.command that must be run to complete the flow. Where a structured form is offered alongside it (mpp pay returns _next.pay_argv), prefer that and invoke it without a shell — see the security notes.
• 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
• 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

Check auth status:

link-cli 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:

link-cli auth login --client-name "<your-agent-name>"

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, 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 any 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 "I am an AI agent" checkbox, or 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, check the checkbox and 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, follow the block's on-page instructions and use card instead. Without browser automation, use card.
3. If the page has a credit-card form and no AI-agent steering block (no "I am an AI agent" checkbox / .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: