Test Payment Cards

Overview

Simulated transactions use dedicated card numbers to control transaction outcomes.

• Each test card number maps to a specific outcome
• Any unrecognized card number which passes LUHN validation is treated as a success
• Use any future expiration date, any CVV, and any billing address
• Amount and CVV values have no effect on the outcome

Success Cards

Use any of these cards to get an approved transaction.

Any card number not listed on this page (success or error) is also treated as success. Brand is auto-detected from the BIN pattern.

Error Cards

These cards simulate specific failure scenarios. Each card maps through a processing pipeline that produces a result and an errorCode in the API response.

Decline Cards (card/issuer rejected the transaction)

Understanding Result vs Error Code

The API response contains two independent fields for error scenarios:

• result -- The system-level outcome category. Tells you what kind of problem occurred.
• errorCode -- The user-facing error classification. Tells you what to display or act on.

These are derived independently, mirroring how real processors (e.g., Mastercard) map a single processor response code to both a result and an error code separately.

Card Present Test Terminals (TIDs)

Card present transactions use Terminal IDs (TIDs) instead of card numbers to control transaction outcomes. Pass the TID as the terminal parameter in the pay request.

• Each TID maps to a specific outcome
• Any TID not in the list below returns CARD_PRESENT_INVALID_TERMINAL
• TID values are the error code names themselves, making test scenarios self-documenting

Success Terminal

Decline Terminals (card/issuer rejected the transaction)

Terminal Interaction Errors (device-level issues)

Cannot Connect is special: the processor was never reached, so the transaction record is deleted entirely. No result or payment status is returned -- the pay request fails with an error response.