Authorize.net Test Card Numbers: Sandbox Testing Guide

Quick answer

The Authorize.net test card most developers reach for is the Visa number 4007000000027. Pair it with any expiration date in the future, any three digit CVV (four digits for American Express), and any five digit billing ZIP, and the sandbox will return an approved authorization you can capture, refund, or void. Three criteria decide whether a test card is the right one for your run: the number has to satisfy the Luhn check digit, it has to belong to the sandbox environment rather than a live payment gateway account, and the response it produces has to match the specific scenario you are trying to reproduce.

What the sandbox actually does with a test number

The Authorize.net sandbox is a separate gateway instance with its own API Login ID and Transaction Key. Transactions sent there never reach an issuing bank. When the gateway sees a recognized test number, it returns a scripted response code and message instead of asking a bank for a decision. That is why a test card number that works perfectly in the sandbox will be rejected outright if you accidentally point your integration at production credentials. The card numbers and their expected responses live in the Authorize.net developer documentation, and the list does change, so treat any number you copy from a blog post (including this one) as a starting point and confirm it against the current sandbox reference.

Option A: Use the published sandbox card numbers

Authorize.net publishes a small set of test numbers covering the major brands. The commonly used ones are 4007000000027 and 4012888818888 for Visa, 5424000000000015 for Mastercard, 370000000000002 for American Express, 6011000000000012 for Discover, and 3088000000000017 for JCB. The published list also includes numbers that trigger declines, card verification value mismatches, and address verification mismatches, which is the whole point of using it.

Pros

• Responses are deterministic, so a test that passes today passes tomorrow.
• The set covers approvals plus the failure paths you need for error handling.
• Brand coverage lets you test card type detection and formatting rules.

Cons

• The list is gateway specific, so it will not help you test a second processor.
• Some numbers are widely copied and occasionally retired, which breaks an old test suite.

Use this option for integration testing, regression suites, and any automated test you run in CI.

Option B: Generate your own Luhn valid numbers

You can compute a check digit that satisfies the Luhn formula and produce a number that looks structurally valid. It will pass client side validation and format checks in your own code.

Pros

• No dependency on a published list that might change.
• Useful for unit tests of form validation, masking, and input formatting.

Cons

• The sandbox does not recognize it, so you get a generic decline instead of the response you wanted.
• It teaches you nothing about how Authorize.net maps responses to your order state.

Use this option for front end validation tests only, and keep it away from any test that needs a real gateway response.

Option C: Turn on Test Mode in a live account

Authorize.net lets you enable Test Mode in the Merchant Interface so that transactions submitted through production credentials are processed as tests and never settle. This is a different mechanism from the sandbox account.

Pros

• You exercise the exact production endpoint, credentials, and configuration.
• Useful for confirming that a deployment reaches the right environment before you flip the switch.

Cons

• Test Mode is a setting a human can forget to turn off, which risks either blocked revenue or unintended live charges.
• It does not isolate your test data from live reporting.

Use this option for a single pre launch smoke test, then turn it off and verify the setting in writing.

Fields that decide the outcome

• Expiration date: must be in the future. An expired date can produce a decline before the gateway ever looks at the number.
• CVV: any three digits works in the sandbox unless you are deliberately testing a mismatch. American Express uses four.
• Billing ZIP and address: arbitrary in the sandbox, but send something plausible so address verification tests behave predictably.
• Amount: keep it small and obvious, such as 1.00, so test records are easy to spot in reports.

Mistakes that waste the most time

1. Mixing sandbox credentials with production card numbers, or the reverse. Both produce confusing errors.
2. Hard coding a test number into a fixture without a comment explaining which response it triggers.
3. Assuming a decline from an unrecognized number means your integration is broken. Check the response code first.
4. Committing sandbox keys to a public repository.

Checklist before you call the integration done

1. Confirm the number appears in the current sandbox reference and note the response it should produce.
2. Verify your credentials point at the sandbox host.
3. Run one approval, one decline, one refund, and one void.
4. Log the full response code and message, not just a pass or fail flag.
5. Replace every hard coded test number with a named constant before release.

Keep test data strictly synthetic. Real cardholder data has no place in a sandbox, a staging database, or a developer laptop, and payment card industry rules apply to test environments just as they do to production systems.