In Authorize.net's sandbox, the test Visa most developers start with is 4007000000027. Any future expiration date works, and the card code can be any three digits, or four for American Express. These numbers exist for test mode only. Enter one into a live account and you get a decline, not a charge.
The numbers I keep in a scratch file
- Visa: 4007000000027
- Visa (alternate): 4012888818888
- Mastercard: 5424000000000015
- American Express: 370000000000002
- Discover: 6011000000000012
- JCB: 3566000000000009
Authorize.net's own testing page lists a few more, including a Diners Club entry. That page is the version to trust if a number above ever stops behaving, since gateways do retire test cards.
Expiration, CVV, and AVS in test mode
Expiration is the easy part: pick any month and year in the future. Past dates get rejected as expired, which is handy when you want to test that error path on purpose.
The card code is where people get confused. The sandbox does not run a real CVV check against an issuer, so the response you get back is tied to the test number itself rather than to the digits you typed. Same story with AVS. The street address and ZIP you submit do not get matched against a real billing record. If you need to exercise a CVV mismatch or an AVS partial match in your own code, stub the gateway response or use the specific test values documented for that response code.
Response codes are driven by amounts
Authorize.net wires certain transaction amounts to specific responses: approvals, declines, holds, processor errors. The mapping is not guessable, so pull the table from the testing guide and keep it open while you work. I usually test the happy path first with an ordinary amount, then walk the decline cases one at a time and log the reason code each one returns.
Things that look like bugs but are not
- Live credentials against the test endpoint. You need the API Login ID and Transaction Key from a sandbox account, not your production keys. Mixing them gives you authentication errors that read like card problems.
- Duplicate transaction protection. Authorize.net voids a second identical transaction that arrives within a short window, usually two minutes, with the same card and amount. That duplicate error is the gateway working as intended.
- Test mode off. If your account settings have test mode disabled, a sandbox card number will fail at the processor level.
- Expiration in the past. It fails before it ever reaches the card number check.
Keep real card data out of it
Do not test with a real card number, and do not paste a customer's number into a sandbox to see what happens. PCI DSS treats test and development environments as in scope, and cardholder data belongs nowhere near them. The public test numbers exist so you never have to make that call.
One last note: the sandbox is a simulation, not a mirror. It will not catch issuer-specific rules, soft declines, or velocity limits. Treat a clean sandbox run as proof that your integration and error handling are wired correctly, then confirm the rest in production with a small real transaction.