Test Agent Cards

In staging, every card-network rail routes to a deterministic mock of Visa Intelligent Commerce and Mastercard Agent Pay. No request reaches a real card network, but the endpoints, response shapes, statuses, and error codes match production. The card number you save selects the scenario, so you can test success and failure paths without a real card.

Prerequisites

Staging API key — a client-side key from the Crossmint Staging Console. In staging, all scopes are included by default.
Card flow — the integration from Save a Card, Register a Card, Create an Agent Card, and Retrieve Secure Card Numbers, pointed at https://staging.crossmint.com.

Test Cards

Save one of these numbers with any future expiration date and any three-digit CVC. Any Visa or Mastercard number not listed follows its brand’s happy path.

Card	Brand	Outcome
`4242 4242 4242 4242`	Visa	Succeeds end to end
`5555 5555 5555 4444`	Mastercard	Succeeds end to end
`5186 1600 0000 0001`	Mastercard	Fails at registration with `CARD_REJECTED`
`4929 9803 9556 7582`	Visa	Fails at verification: the one-time code is rejected with `INVALID_OTP`
`5186 1600 0000 0003`	Mastercard	Fails at verification: the hosted page appears to succeed, but the rail never becomes `active`

What a Successful Card Returns

Register a Card reports one card-network rail for the card. The rail is always agentic-token; the provider names the network program behind it, vic for Visa Intelligent Commerce or agentpay for Mastercard Agent Pay:

{
    "paymentMethodId": "pm_123",
    "rails": [
        {
            "rail": "agentic-token",
            "provider": "agentpay",
            "status": "enabled"
        }
    ]
}

An order intent created for that card (Create an Agent Card) carries the same rail with status: "pending_verification". After the cardholder approves the allowance in OrderIntentVerification, fetch the order intent again: the rail reports status: "active" and you can mint.

{
    "rail": "agentic-token",
    "provider": "agentpay",
    "status": "active",
    "credentialFormats": ["card", "network-token"]
}

Failure Scenarios

The three cards below are designed to fail. The error each one produces is the expected result of the scenario, not a problem with your integration.

Card Rejected at Registration

Save 5186 1600 0000 0001. The registration request succeeds, but the Mastercard rail is reported in error:

{
    "paymentMethodId": "pm_123",
    "rails": [
        {
            "rail": "agentic-token",
            "provider": "agentpay",
            "status": "error",
            "error": { "code": "CARD_REJECTED" }
        }
    ]
}

The card is saved and the rejection is permanent. Confirm that your UI treats this as a saved card with one failed rail, not as a failed save. Order intents for this card include an encrypted-card rail, which is enabled for every staging project, so mint through it instead. See Mint an Encrypted Card.

One-Time Code Rejected

Save 4929 9803 9556 7582. Registration succeeds with a vic rail enabled, and the order intent’s rail is pending_verification. In OrderIntentVerification, the Visa flow asks for a one-time code and rejects every code with INVALID_OTP. The user can enter another code, but this card never accepts one, so verification does not complete and the rail stays pending_verification:

{
    "rail": "agentic-token",
    "provider": "vic",
    "status": "pending_verification",
    "credentialFormats": ["card", "network-token"]
}

Confirm that your UI lets the user retry or abandon the verification, and that nothing mints while the rail is pending_verification.

Hosted Page Returns but Verification Fails

Save 5186 1600 0000 0003. Registration succeeds with an agentpay rail enabled. During verification, the mock Mastercard-hosted page shows a success message and returns to your application, but when Crossmint confirms the result with the network, the confirmation fails. OrderIntentVerification calls onVerificationError, and the rail stays pending_verification. Confirm that your integration waits for onVerificationComplete and then fetches the order intent until the rail reports active, rather than minting as soon as the hosted page closes.

Test Verification

Verification is the step where the cardholder approves an order intent’s allowance through the OrderIntentVerification component. The mocks run the same browser flow as production, so popups, message listeners, and origin checks are all exercised.

Visa — the verification asks the user to choose a one-time code method (a masked phone number or email address) and accepts any code, unless the card scenario says otherwise. On a device without a passkey, a mock Visa screen enrolls one. Later order intents on the same device go straight to passkey authentication, as in production.
Mastercard — the component opens a mock Mastercard-hosted page that shows its progress and returns to your application. The rail becomes active only after Crossmint confirms the result, so fetch the order intent again before minting.

Use an HTTPS tunnel when you test verification from a local browser. It exercises the same iframe, origin, and popup behavior as your deployed site.

Check the Minted Credentials

Mock credentials are deterministic, so repeated runs return stable values. Use them in integration tests only; they are not accepted by real merchants.

Format	Value
`card`	A virtual card number: `4000 0010 0000 4242` for the `4242` Visa card and `5100 0010 0000 4446` for the `4444` Mastercard. Other cards return `4000 0010 0000 0000` (Visa) or `5100 0010 0000 0006` (Mastercard). The expiration date matches the saved card, and the CVC is derived deterministically
`network-token`	The same virtual number with a deterministic cryptogram. Visa returns ECI `07` and Mastercard returns ECI `06`

Credential expiry follows each network’s rule rather than a uniform test value. The Visa mock returns a short synthetic cryptogram window, so do not calibrate how long a credential stays usable against it. Use every credential immediately.

Test Common Scenarios

The allowance accounting in staging is real, so these scenarios behave exactly as in production.

Spend limits — create an order intent for 10.00, mint a credential for 7.00, then read the order intent: amount.available is 3.00. Minting 4.00 next fails with ORDER_INTENT_AMOUNT_EXCEEDED.
Encrypted card fallback — save 5186 1600 0000 0001 and mint through the encrypted-card rail, as described in Card Rejected at Registration.
CVC recollection — expire a saved card’s CVC on demand to test the pending_cvc_recollection state. See Test in Staging.

Introduction

Agent Cards

Agent Wallets

Agent Checkouts

API Reference

Prerequisites

Test Cards

What a Successful Card Returns

Failure Scenarios

Card Rejected at Registration

One-Time Code Rejected

Hosted Page Returns but Verification Fails

Test Verification

Check the Minted Credentials

Test Common Scenarios

Next Steps

Create an Agent Card

Cards Quickstart

​Prerequisites

​Test Cards

​What a Successful Card Returns

​Failure Scenarios

​Card Rejected at Registration

​One-Time Code Rejected

​Hosted Page Returns but Verification Fails

​Test Verification

​Check the Minted Credentials

​Test Common Scenarios

​Next Steps

Create an Agent Card

Cards Quickstart

Prerequisites

Test Cards

What a Successful Card Returns

Failure Scenarios

Card Rejected at Registration

One-Time Code Rejected

Hosted Page Returns but Verification Fails

Test Verification

Check the Minted Credentials

Test Common Scenarios

Next Steps