An Authorize.net test card is a published card number that works only inside the Authorize.net sandbox, which lets you run approvals, declines, refunds, and voids without moving real money. The most widely used one is the Visa number 4007000000027, paired with any future expiration date and any 3-digit CVV.

What Makes a Test Card Different

These numbers are issued by Authorize.net for developer testing. They are not tied to a bank account, they cannot be used to buy anything in a live store, and a real payment gateway will reject them once you switch to production credentials. Their only job is to let you confirm that your checkout form, API request, and response handling all work before you go live.

Standard Authorize.net Test Card Numbers

Authorize.net publishes approved test numbers for each major card brand. The card type in the response matches the number you send.

• Visa: 4007000000027 (approved)
• Visa: 4012888818888 (approved)
• Mastercard: 5424000000000015 (approved)
• American Express: 370000000000002 (approved, 4-digit CVV)
• Discover: 6011000000000012 (approved)
• JCB: 3566002020360505 (approved)
• Diners Club: 38000000000006 (approved)
• Visa decline: 4222222222222 (declined)

Use any expiration date in the future. The CVV can be any three digits, except for American Express where you enter four.

How to Run a Test Transaction

1. Sign in to your sandbox account at the Authorize.net developer portal and copy the sandbox API Login ID and Transaction Key.
2. Point your integration at the sandbox endpoint instead of the production endpoint.
3. Submit a charge with one of the test cards above and a future expiration date.
4. Confirm the response fields: response code, auth code, transaction ID, and card type.
5. Run a refund and a void against the same transaction to check those paths too.

Never mix credentials. Sandbox keys with a live endpoint, or the reverse, will fail and can look like a broken integration.

Testing Declines, AVS, and CVV Results

A gateway that only ever returns approvals is not really tested. The Authorize.net testing guide documents the values that trigger specific response codes, so you can force declines, AVS mismatches, and CVV mismatches on purpose.

• Use the decline test card to check your error messaging.
• Use specific test amounts or address values to produce AVS mismatch codes.
• Use specific CVV values to produce CVV mismatch codes.
• Log every response code your code receives so you can map each one to a customer-facing message.

Sandbox Versus Live Test Mode

A sandbox account is a separate environment with its own login, transactions, and reports. Test mode inside a live account is different: it lets you send test transactions through production credentials, but it is not meant for building an integration from scratch. Most teams do the heavy work in the sandbox and use test mode only for a final check.

Rules to Keep in Mind

• Test numbers are for development only. A real customer card is never a test card.
• Store only what you need, even in a sandbox. Keep the same data habits you use in production.
• Clear sandbox data before launch so old test transactions do not confuse your reporting.
• Re-run your test suite after any change to your checkout flow, currency handling, or API version.
• If a real card is ever entered into a test form by mistake, treat it as you would any card data exposure.

Used this way, an Authorize.net test card gives you a repeatable way to prove your payment flow works before a single real dollar moves.