Quick answer
In the Authorize.net sandbox, 4111111111111111 returns an approved Visa transaction. Mastercard is 5424000000000015, American Express is 370000000000002, Discover is 6011000000000012. Use any future expiration date and a three or four digit card code and the gateway responds with code 1 (approved). No money moves and no issuer ever sees the request.
Why these numbers exist
Issuers publish test card numbers so developers can exercise a payment integration without touching real accounts. Authorize.net collects a set of them in its developer documentation and hosts the whole thing in a sandbox that mirrors the production API. Same request format, same response fields, same error codes. The only difference is that the authorization step is simulated.
That matters more than it sounds. Most payment bugs are not in the happy path, they are in the handling of a decline, an address mismatch, or a duplicate transaction. You cannot test any of that with a real card, and you should not try.
The standard test numbers
- Visa: 4111111111111111
- Visa (alternate): 4012888818888
- Mastercard: 5424000000000015
- Mastercard (2-series BIN): 2223000010005780
- American Express: 370000000000002
- Discover: 6011000000000012
- JCB: 3088000000000017
- Diners Club: 38000000000006
Expiration date can be anything in the future. Card code can be any three digits for Visa, Mastercard, and Discover, or four for Amex.
authorize.net credit card test
Forcing a decline or an error
The sandbox is built to approve almost everything, so getting a failure on purpose takes a little intent. The blunt method I use is an expiration date in the past: the gateway returns a decline or an expired card error, and it has never failed me across API versions. The alternative is to work through the response code table in the current testing guide, which documents which values produce code 2 (declined), code 3 (error), and code 4 (held for review).
Code 4 is the one people forget. A held transaction is not a decline. Your integration needs to treat it as pending and listen for the settlement or review outcome rather than telling the customer the card failed.
AVS and CVV testing
Address verification is tested with specific street address and ZIP combinations that the testing guide pairs with each expected AVS result. Card code testing works the same way: certain card code values map to CVV match, no match, and not processed. Copy the current table rather than memorizing it, because these values do change.
One trap: if your account settings have AVS or CVV filters turned off in the sandbox, the mismatch tests will pass when they should fail. Check the transaction detail in the Merchant Interface before you trust a green result.
Sandbox versus Test Mode
These are different things and mixing them up wastes an afternoon. The sandbox is a separate developer account with its own credentials and its own transaction history. Test Mode is a toggle on a live account, and it short-circuits the gateway: you get a canned approval and none of the real validation runs. If your declines never decline and your AVS checks never check, you are probably in Test Mode.
Before you go live
Swap the endpoint, swap the credentials, and confirm that no test card number survives anywhere in your code, your fixtures, or your seed data. Test numbers are fine in a repository; a live gateway will reject them, but a well-meaning support script on a live account can still cause noise. Keep the sandbox credentials in a separate config block so there is nothing to remember at deploy time.