An Authorize.net test card is a published card number that the Authorize.net sandbox accepts, so you can run payment tests without a real card. The standard approved Visa is 4111111111111111, used with any future expiry date and any CVV. Test numbers work only in test mode and are declined in production.
What Makes a Test Card Different From a Real One?
A test number never reaches an issuing bank. The sandbox matches it against a table of known numbers, then returns the response assigned to that entry.
Your integration sees a normal API response: same fields, same response codes, same webhook payloads. That lets you build and debug against realistic data before a merchant account exists.
Standard Authorize.net Test Card Numbers
Authorize.net publishes one approved number per card brand. All of them pass the Luhn check, so client-side validation behaves the way it would with a real card.
- Visa: 4111111111111111
- Mastercard: 5424000000000015
- American Express: 370000000000002
- Discover: 6011000000000012
- JCB: 3088000000000017
- Diners Club: 38000000000006
Use an expiry date in the future, such as 12/2030, and CVV 123. American Express uses a four-digit code, so 1234 for the Amex number.
How Do You Test a Decline or an Error?
The sandbox also ships numbers that trigger the failure paths your code needs to handle. The declined Visa test number is 4222222222222220, which returns a decline instead of an approval.
For an expired card, keep an approved number and set the expiry date in the past. For AVS or CVV mismatches, submit the address and code values mapped in Authorize.net's testing guide, then read the AVSResultCode and CVVResultCode fields in the response.
Running a Test Transaction Step by Step
- Create a sandbox account in the Authorize.net developer portal. It stays separate from your live account.
- Copy the sandbox API Login ID and Transaction Key. Sandbox keys fail on the live endpoint, and live keys fail on the sandbox.
- Point your client at the sandbox host (apitest.authorize.net) and send a charge request with a test card number.
- Read the response: responseCode 1 is approved, 2 is declined, 3 is an error, 4 is held for review.
- Store the transaction ID and run refunds, voids, and subscription calls against it.
What the Sandbox Checks and What It Skips
No authorization request leaves Authorize.net, so issuer rules such as 3-D Secure challenges, issuer declines, and velocity limits never show up in test results.
The sandbox does check card format, expiry, and CVV field length. It also returns AVS and CVV result codes, which exercises your conditional logic before launch.
Common Mistakes in Authorize.net Testing
- Submitting a real card number to the sandbox. The gateway stores it like any other transaction, which drags that data into PCI scope for no reason.
- Mixing live and sandbox credentials, which produces authentication errors on every call.
- Using an expiry date that has passed. The request fails validation before it reaches the card table.
- Treating a sandbox approval as proof that a real card will approve. It proves the code works, nothing more.
- Testing the happy path only and shipping without a decline branch.
Frequently Asked Questions
Do Authorize.net test cards work in production?
No. Production mode sends the number to the card networks, and a published test number has no real account behind it, so it comes back declined. Keep test numbers out of live traffic.
Where do I find the full list of test card numbers?
Authorize.net's developer documentation carries the current list in its testing guide, including numbers for each brand and each failure case. The list changes on occasion, so check the source rather than a blog copy.
Do test card numbers expire?
The numbers do not expire. The expiry date you type does have to sit in the future, or the request fails validation.
Can I test refunds, voids, and recurring billing with a test card?
Yes. Create a charge with an approved test number, then run refund, void, and subscription calls against that transaction ID in the sandbox.
Is a test card the same thing as a payment token?
No. A test card is a card number for the sandbox. A token, such as a Customer Profile or an Accept.js nonce, is a reference to stored payment data, and the sandbox issues those too.