Short answer

For Authorize.Net sandbox testing, send a well-formed dummy card code: three digits for Visa, Mastercard, Discover, JCB, and Diners Club; four digits for American Express. Pair it with an official test card number and any expiration date in the future. The sandbox does not check the card code against an issuer, so a random, non-real value such as 123 or 1234 is the correct choice. Never place a live card code in a test environment.

related article

Prerequisites

  • A sandbox account with an API Login ID and Transaction Key, or a public client key if you use a hosted tokenization flow.
  • The official test card numbers from the Authorize.Net testing guide.
  • An expiration date in the future, for example 12/2030.
  • An environment switch in your code that loads sandbox credentials only when the sandbox flag is set.

Steps

  1. Sign in to the sandbox Merchant Interface and copy the API Login ID and Transaction Key from the API credentials settings page.
  2. Choose a test card number from the list below. Use the number that matches the card type you want the response to report.
  3. Set the expiration date to any month and year in the future. The sandbox accepts pasted values such as 12/2030.
  4. Send the card code in the cardCode field of the payment request, or in x_card_code if you post a hosted form. Use three digits, or four for American Express.
  5. Submit the transaction and read responseCode, authCode, avsResultCode, and cvvResultCode from the response.
  6. Expect responseCode 1 (approved) and cvvResultCode M (match) when the code is well formed and the request is valid.
  7. Map every card code result in your handler: M match, N no match, P not processed, S should have been present, U issuer unable to process, X no response from the issuer.
  8. Force the mismatch path yourself. The sandbox returns M for well-formed codes, so stub the gateway response in unit tests or point your handler at a saved N response to prove the decline logic runs.
  9. Mask cardCode in every log line and drop the full request body after the test run.

Test card numbers

  • Visa: 4111111111111111
  • Mastercard: 5424000000000015
  • American Express: 370000000000002
  • Discover: 6011000000000012
  • JCB: 3566000000000000
  • Diners Club: 38000000000006

Verification checklist

  • The request reaches the sandbox endpoint, not the production endpoint.
  • A 3-digit code on a Visa test card returns M.
  • A 4-digit code on the American Express test card returns M.
  • A 2-digit code returns a validation error before the request leaves your application.
  • The N path shows a decline message to the user when you inject it.
  • No card code appears in plain text in application logs or error trackers.

Common mistakes

  • Using test card numbers that belong to another gateway. Each gateway publishes its own list, and a mismatch returns an error rather than a test result.
  • Sending an expired date and blaming the card code when the decline comes from the expiration check.
  • Trimming leading zeros from the card code field during validation.
  • Assuming the sandbox will produce a CVV mismatch on its own. It will not.
  • Storing the card code after authorization. That value is sensitive authentication data and must not persist past the authorization response.