Skip to main content
An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration. An order intent can have multiple rails, each with its own status, credential formats, and verification.

Prerequisites

  • Registered cardregister a saved card and confirm that it has an enabled rail.
  • Crossmint API key — a client-side key with order-intents.create and order-intents.read scopes. In staging, all scopes are included by default.
  • User JWT — use the JWT for the user who owns the saved card.

Create the Order Intent

Create an order intent with the saved card, spending limit, description, expiration, and merchant. Include the merchant now when you already know where the agent will spend:
The response separates the order intent’s lifecycle from the status of each rail:
Setting merchant when creating the order intent is preferred when you know it. The merchant is fixed for the lifetime of that order intent, and credential requests inherit the restriction. If the agent will choose a merchant later, omit merchant. This creates an open order intent, and every credential request must supply the merchant instead. The top-level status is active while the allowance exists. A specific rail can still require verification. Treat rails as a set of independent ways to spend the same allowance:
  1. Choose the rail that provides the credential you need.
  2. If that rail is pending_verification, verify it.
  3. Once it is active, mint with the same rail and provider values.
You do not need every rail to be active. Other rails can remain pending_verification or error without blocking the selected rail. For example, when an allowance contains both VIC and SPT, minting a VIC credential only requires the VIC rail to be verified; you do not need to complete an SPT step. Crossmint currently exposes VIC and Mastercard Agent Pay card-network rails, and the same selection rule applies as more rails are added.

Verify the Selected Rail

When the rail you want to use has status: "pending_verification", render OrderIntentVerification in your client application. Do not start verification merely because an unrelated rail is pending.
After verification completes, fetch the order intent again and wait for the selected rail to report status: "active". You do not need to wait for the other rails. Card registration never prompts for verification. Verification belongs to an individual order-intent rail. The first Visa verification on a device can create a passkey; later order intents authenticate with the existing passkey when the device remains bound. The component also handles the Mastercard-hosted flow. For the complete request and response schemas, see the Create Order Intent API Reference.

Common Gotchas

Read rails[].status before minting. The top-level status describes the order intent’s lifetime, not whether every rail is ready.
Register the card once, then verify only the order-intent rail you plan to use when it returns pending_verification. Do not repeat card registration to authorize a new allowance.
Set expiresAt to a future ISO 8601 timestamp that matches the permission you present to the user.
Include merchant when creating the order intent if you already know it. Otherwise, omit it and supply a merchant with every credential request.
Use an HTTPS tunnel when testing the verification ceremony from a local browser.

Next Steps

Retrieve Secure Card Numbers

Mint a credential from an active rail

Customize UI

Style the allowance verification modal