Authorize.net test card numbers are the sandbox card numbers the gateway publishes for developers: Visa 4007000000027, Visa 4012888818888, Mastercard 5424000000000015, American Express 370000000000002, Discover 6011000000000012, and JCB 3566002020360505. They return an Approved response only when the account is in Test Mode or the integration points at the sandbox environment. No funds move and no real cardholder is ever charged.
What are the standard Authorize.net test card numbers?
- Visa: 4007000000027 and 4012888818888
- Mastercard: 5424000000000015
- American Express: 370000000000002
- Discover: 6011000000000012
- JCB: 3566002020360505
Every one of these numbers passes the Luhn check and sits inside a real issuer identification range, so your validation logic treats them exactly like a live card. Use any future expiration month and year. Use any three digit CVV, or any four digit code for American Express.
How do you run a test transaction?
- Sign in to the Merchant Interface and switch the account to Test Mode, or point your API calls at the sandbox endpoint.
- Submit one of the card numbers above with a future expiration date and any valid CVV length.
- Check the response code and transaction ID in the sandbox reports, then void or refund that transaction to exercise those flows too.
Do Authorize.net test cards work in live mode?
No. These numbers are registered to the sandbox, so a live-mode request either declines or returns an error instead of an approval. Test Mode also short-circuits settlement, which means an approval in Test Mode never reaches the card networks. Keep test credentials and production credentials in separate configuration sets so a release cannot mix them.
authorize.net test card generator
How do you test declines, AVS, and CVV failures?
The testing documentation lists additional sandbox card numbers that map to specific response codes, including declines, expired card errors, and AVS or CVV mismatches. Pair those with odd billing addresses and unusual amounts to cover your error handling paths. Never exercise a failure path by submitting a real card number.
How to Use a Free Authorize.Net Test Card for Secure Testing
What mistakes break sandbox testing?
- Leaving the account in Live Mode, which makes a valid test card look like a fraud or decline case.
- Using a past expiration date, which returns an expired card error before any approval logic runs.
- Sending a CVV of the wrong length for the brand, which forces an unrequested CVV failure.
Key takeaways
Authorize.net test cards are fixed sandbox identifiers that behave like approved cards when Test Mode is on. Store them in your test fixtures, not in production configuration. Treat production cardholder data as off limits in every sandbox, development, and QA environment.