Quick answer

In the Authorize.Net sandbox, a test CVV is any 3-digit number (4 digits for American Express card types) submitted with a documented test card number. The sandbox does not check the code against a real issuer. It echoes a card code result back in the transaction response so you can confirm your integration reads, stores, and reacts to that field correctly.

Use the sandbox test card numbers published in Authorize.Net's developer documentation, and keep live card data out of test mode entirely. If your account is in test mode, any format-valid code will process; the interesting part is the response value, not the digits themselves.

Prerequisites

  • A sandbox account from the Authorize.Net developer portal
  • Your sandbox API Login ID and Transaction Key
  • A test client that can post a transaction request (AIM/XML, JSON, or an SDK)
  • Access to the sandbox transaction log in the Merchant Interface

Steps

  1. Sign in to the sandbox Merchant Interface and confirm the account is set to Test mode, not Live mode.
  2. Copy the sandbox API Login ID and Transaction Key into your test configuration, keeping them separate from any production credentials.
  3. Point your request at the sandbox endpoint rather than the production gateway host.
  4. Insert one of the published sandbox test card numbers into the card number field.
  5. Set the expiration date to any future date, such as 12/2030, since the sandbox accepts future dates on test cards.
  6. Send the card code field with a 3-digit value such as 123, or a 4-digit value if the card type is American Express.
  7. Submit the transaction and read the card code response returned in the reply.
  8. Open the sandbox transaction log and verify the card code value and response were recorded as your application expects.
  9. Repeat the request with a code that is too short, too long, non-numeric, and blank to see how your validation layer handles each case.

What the response field returns

  • M: the card code matched
  • N: the card code did not match
  • P: the card code was not processed
  • S: the card type does not support card code verification
  • U: the issuer could not process the verification
  • X: the card code was not returned by the issuer

A test CVV field that passes format validation will usually come back as M in the sandbox. The N and U results are what you want to exercise in your decline handling, because that is where most integrations silently drop the error and approve the order anyway.

Field names by API

  • AIM and XML: x_card_code
  • JSON transaction API: cardCode inside the payment object
  • Hosted and Accept.js flows: the opaque data blob carries the code, so your server never touches it

Common mistakes

  • Sending a real card code to the sandbox, which violates PCI DSS requirements for handling sensitive authentication data
  • Storing the card code after authorization, which is prohibited after the transaction is complete
  • Testing only the approved path and never forcing a mismatch or an unsupported card type
  • Mixng production keys with sandbox endpoints and generating confusing errors
  • Treating a blank card code as a decline when the issuer simply does not require one

Log the card code response alongside your order record, but never log the card code itself. That single habit prevents most audit findings.