Cybersource Test Card Numbers

How Cybersource test cards work

Cybersource (a Visa company) runs a separate sandbox that simulates the live gateway. Sandbox transactions are never sent to banks, and the sandbox needs its own credentials: production credentials used against the sandbox — or the other way round — return HTTP 401. REST API test requests go to apitest.cybersource.com.

If no expiry date is given, use any date after today. If a card verification code is required, use any three digits for Visa, Mastercard, Discover, Diners Club and JCB and any four digits for American Express — except for the five Visa cards that come with their own CVV in the table.

In the REST API sandbox the request decides most results. An amount of 1 is authorized, a negative amount is rejected as invalid data, and malformed card fields (month 13, year 1998, a number that fails the Luhn check) come back as DECLINE or INVALID_REQUEST. For specific decline reasons and AVS or CVV results, pick your processor — Chase Paymentech, Barclays, Visa Platform Connect and others — at the top of the testing guide to see its trigger amounts.

Request values that trigger responses

The REST API sandbox decides most results from the request itself. These triggers come from the common payment responses table:

Field names are shortened: totalAmount is orderInformation.amountDetails.totalAmount and card.* is paymentInformation.card.*. The testing guide also has processor-specific trigger amounts for more than 20 processors (Chase Paymentech, Barclays, FDC, Visa Platform Connect and others).

Testing Cybersource payments step by step

1. Create a sandbox account and generate API keys for it (never reuse production keys).
2. Send a payment with 4111 1111 1111 1111 and totalAmount 1 and check for an AUTHORIZED response.
3. Send the trigger values from the table to cover INVALID_REQUEST and DECLINE handling in your code.
4. Open the testing guide for your processor and use its trigger amounts for specific decline reasons and AVS/CVV results.
5. Look up each test transaction in the Merchant Portal to read its reason code.

Common errors and fixes

HTTP 401 in the sandbox

Production credentials were used against the sandbox. Create separate sandbox keys.

Every decline looks the same

The common responses only cover basic cases. Use your processor’s trigger amounts from the testing guide.

Card rejected as INVALID_DATA

Check that the number passes the Luhn check and has at most 19 digits; the sandbox declines Luhn failures and 21-digit numbers.

Sources

Every number on this page was copied from Cybersource’s official documentation and passes the Luhn check. Checked October 2026; gateways change their test data from time to time, so if a number stops working, check the source:

• Cybersource Developer Center – Testing guide