You test a payment card on Authorize.net by pointing your integration at the sandbox, sending one of the published test card numbers, any future expiration date, and a well-formed CVV. No money moves. The number itself still has to pass the Luhn check, though, and that one detail is behind a large share of the failed test transactions people ask about. A random string of 16 digits is not a test card.
authorize.net payment card verification
Sandbox account or Test Mode?
These are two different things and mixing them up costs hours.
authorize.net credit card test
- Sandbox. A separate account you create at sandbox.authorize.net. Separate API Login ID, separate Transaction Key, separate endpoints. Nothing there reaches production.
- Test Mode. A toggle inside your production merchant interface. You use your live credentials and the live endpoint, but each transaction is flagged as a test and never settles.
Build in the sandbox. Reach for Test Mode when you want to confirm a live integration can talk to the gateway without charging a customer. Keep straight which key belongs where, because a sandbox key pasted into a production config produces an authentication error that looks like a card problem and is not.
authorize.net payment card check
The test card numbers
Authorize.net publishes a short list. These are the ones I keep coming back to:
- Visa: 4007000000027, 4012888818888, 4111111111111111
- Mastercard: 5424000000000015, 5555555555554444
- American Express: 370000000000002
- Discover: 6011000990139424
- Diners Club: 38000000000006
Expiration date: anything in the future, in MMYY or MM/YYYY depending on your field format. CVV: any three digits for Visa, Mastercard, and Discover, four for American Express. The sandbox does not check the CVV against an issuer, so typing the wrong digits will not produce a mismatch. If you need the CVV failure branch, test it by mocking the response rather than hoping the sandbox cooperates.
Forcing declines, errors, and review holds
The gateway returns a numeric response code you should branch on: 1 approved, 2 declined, 3 error, 4 held for review. The sandbox gives you a documented set of amounts and field values that produce each one. Read the current testing guide for those values instead of guessing, because the magic amounts have changed over time and half the blog posts out there are stale.
Before blaming the card, run a credentials check. Authorize.net exposes an authenticateTestRequest call that verifies your API Login ID and Transaction Key without touching a card at all. If that fails, your test card was never the problem.
AVS and CVV results in the sandbox
Address verification and CVV responses are simulated, and for well-formed input they usually come back as a match. That is convenient, and also misleading. Passing in the sandbox proves your request shape and your parsing. It does not prove your production rules for partial matches and soft declines are right. Write the branch logic while you are in the sandbox, then confirm it with one small real transaction after launch and refund it.
Error codes worth memorizing
- E00007: authentication failed, almost always a key from the wrong environment.
- E00003: malformed request, usually a missing or misnamed field.
- E00027: transaction unsuccessful, read the accompanying text before assuming it is a decline.
Checklist before going live
- Swap endpoint, API Login ID, and Transaction Key together.
- Turn Test Mode off in the merchant interface.
- Send one low-value real transaction and void it.
- Keep real cardholder data out of every test environment, no exceptions.