Authorize.Net Test Card Numbers for Sandbox Testing

The quickest way to exercise a full transaction against the Authorize.Net sandbox is the Visa test number 4007000000027 paired with your sandbox API Login ID and Transaction Key. Pick a test card by the response you need to see (approved, declined, or a specific AVS or CVV result) and by the card brand your checkout has to handle. Every number here is a published sandbox value that cannot move real money, and none of them belong in a live account.

Top pick: Visa 4007000000027

This 13-digit Visa is the default approved card in Authorize.Net's testing documentation and the one most SDK samples ship with. It returns an approval against the sandbox endpoint when the expiration date is any future date and the CVV is any three digits.

Pros

• Approves by default, so it isolates integration bugs from response-code handling.
• Works with the transaction key from any sandbox account, no special configuration.
• Appears in the official testing guide, so it stays valid as the API changes.

Cons

• Only proves the approved path, so it says nothing about your decline or error UI.
• Visa rules for AVS and CVV differ from Amex and Discover behavior.
• Its 13-digit length is unusual today and can hide formatting bugs in your form.

Use it when: you are wiring up the payment request for the first time and just need to see a transaction ID come back.

Test numbers for the other card brands

Run at least one card per brand you accept, because response formatting, field lengths, and CVV requirements vary.

• Mastercard: 5424000000000015
• American Express: 370000000000002 (15 digits, four-digit CVV)
• Discover: 6011000000000012
• JCB: 3088000000000017

Pros

• Catches length and CVV-field assumptions that a single Visa run will miss.
• Lets you verify how your receipt and reconciliation code labels each brand.

Cons

• More test data to maintain, and brand numbers occasionally change in the guide.
• American Express billing fields behave differently in some client libraries.

Use them when: you are preparing for launch and need proof that every accepted brand clears the same code path.

Declines, AVS, and CVV responses

A charge that approves every time never tests your failure handling. Authorize.Net publishes dedicated cards for a declined authorization and for specific card verification and address verification results, including a card that returns a CVV mismatch and one that returns CVV not processed. Confirm the current list in the testing guide before you hardcode anything, because the mapping between a card and a response code is set by Authorize.Net, not by you.

Pros

• Lets you test the exact message a customer sees when a card is refused.
• Exposes logic bugs in your retry, void, and refund flows before real money is involved.

Cons

• Cards tied to one response code are easy to mix up with the approval card.
• The sandbox may return a different code text than production for the same condition.

Use them when: your code branches on the response code and you need to prove each branch works.

Sandbox setup checklist

1. Create a sandbox account separate from your production account.
2. Copy the API Login ID and generate a Transaction Key in the sandbox merchant interface.
3. Point your client at the sandbox endpoint, not the production host.
4. Use any expiration date in the future and any well-formed CVV.
5. Log the full response object, not just the approval flag.

Use this order every time: credentials first, endpoint second, cards third. Most failed test runs come from production credentials hitting the sandbox host.

Mistakes that break a test run

• Posting to the live endpoint with sandbox credentials, which returns a loud authentication error.
• Passing a test card in a live-mode transaction, which produces a decline and, on some accounts, a risk flag.
• Ignoring the response object and reading only the boolean, which hides AVS and CVV detail.
• Testing with a real card number you own at a live gateway while debugging a sandbox bug.

Test data is not card data

Sandbox numbers are published so developers can test software. They authorize nothing, hold no funds, and carry no account behind them. Entering a real card number that does not belong to you into any system, test or live, is payment fraud under federal law and a violation of card network rules. Storing live card data outside a PCI DSS compliant environment is a separate violation, and card brands and processors enforce both. If you handle payments, use the sandbox for everything except a controlled live transaction on a card you are authorized to use.