Authorize.Net Credit Card Test: Sandbox Cards & Steps

Authorize.Net credit card testing runs against the sandbox at sandbox.authorize.net using published test card numbers such as 4111111111111111, any future expiration date, and any correctly formatted CVV. Sandbox requests hit Authorize.Net test servers, so no real card data is required and no funds move. Sandbox credentials work only in the sandbox, and production credentials work only in production.

related article

Which test card numbers does Authorize.Net accept?

Authorize.Net publishes a fixed set of sandbox numbers, one per card brand. Each number passes the Luhn check and is reserved for testing, so it can be pasted into any sandbox request.

read more

• Visa: 4111111111111111
• Visa (alternate): 4007000000027
• Mastercard: 5424000000000015
• American Express: 370000000000002
• Discover: 6011000000000012
• JCB: 3566000000000000

Use any expiration date in the future, such as 12/2030, and any three digit CVV, or four digits for American Express. The sandbox checks the format of these fields, not their real world accuracy.

authorize.net card validation

How do you run a full test transaction?

1. Create a free sandbox account and note the separate API Login ID and Transaction Key issued for it.
2. Point your integration at the sandbox API endpoint instead of the production endpoint.
3. Submit an authorization for a small amount with one of the test cards above.
4. Capture the authorization, then run a void on a second transaction and a refund on a settled one.
5. Compare each response code and message against the values your application is programmed to handle.

Keep the whole sequence in an automated test so every release re-checks authorization, capture, void, and refund paths.

Why did my Authorize.Net test transaction fail?

Most sandbox failures come from configuration, not from the card number. Check these causes in order:

• Production API credentials were pasted into the test configuration, or the client still points at the live endpoint.
• The expiration date is in the past or formatted as a two digit year the gateway rejects.
• The card number was altered by a formatter that strips or reorders digits.
• An identical transaction was resubmitted inside the duplicate window, which returns a duplicate response instead of a new charge.
• The merchant account in the sandbox is inactive or the transaction type is not enabled for it.

Does the sandbox return real CVV and AVS results?

No. The sandbox normally returns a match for both CVV and AVS regardless of the digits or billing address you submit, because it does not query an issuer. To exercise mismatch and decline branches, stub the gateway response in your own test harness and assert that your code handles each result code correctly.

Can you test recurring billing and refunds in the sandbox?

Yes. Recurring billing subscriptions, voids, refunds, and transaction reporting all work in the sandbox and can be scripted end to end. Run a refund against a transaction you first settled in the sandbox so the credit path is exercised before launch.

What must never appear in a test environment?

Live card numbers, real CVV values, and customer billing data have no place in a sandbox or staging system. PCI DSS requires that live account numbers are not used for testing or development, so seed every test fixture with the published dummy numbers. Store sandbox credentials in the same secret manager you use for production keys.

Go-live checklist

• Swap sandbox credentials and endpoint for production values in one reviewed change.
• Confirm error handling covers declines, duplicates, expired cards, and timeouts.
• Verify that logs mask card numbers and never store CVV data.
• Run one low value live transaction, then refund it, before enabling checkout for all users.