What CVV do you use for a Worldpay test transaction?

Use 123 as the CVV for Worldpay test cards. It is the value Worldpay's documentation uses for sandbox Visa, Mastercard, and Discover test transactions, while American Express test cards take a four-digit code such as 1234.

These numbers exist only inside the test environment. A sandbox CVV is a fixed placeholder that a gateway recognizes as test data, so it never touches a real cardholder account or a live authorization network.

Why a Worldpay test CVV is not real card data

A CVV is the three or four digit verification code printed on a physical card. In a sandbox, that concept is replaced by a constant value the gateway maps to a predefined result.

Because test card numbers are published openly and never resolve to an issuing bank, the CVV attached to them has no financial value. It cannot be used to move money, and it cannot be reused outside the test merchant account it was issued for.

Which test cards pair with the test CVV?

Worldpay's sandbox accepts a short list of well-known card numbers. The CVV field stays the same across most of them.

  • Visa test card 4444 3333 2222 1111 with CVV 123
  • Visa decline card 4000 0000 0000 0002 with CVV 123
  • Mastercard test card 5555 5555 5555 4444 with CVV 123
  • American Express test card 3782 822463 10005 with CVV 1234

Some acquirer-specific test portfolios differ, so confirm the current list in your Worldpay developer dashboard before you script a full regression run.

How do test CVV values map to response codes?

Sandboxes often tie specific CVV inputs to specific outcomes. One value returns a CVV match, another returns a mismatch, and a third triggers a "not processed" response so you can test your decline handling.

That mapping lets developers verify that an order is only fulfilled when the CVV result is a match. Read the response code returned in the transaction payload instead of assuming the gateway behaved correctly.

Does the test CVV change the authorization result?

Yes, in most sandbox configurations. If you send an unrecognized CVV, the gateway may return a generic decline that masks the scenario you meant to test.

Common mistakes when testing CVV handling

  • Using a live card number with a sandbox merchant account, which fails immediately.
  • Hardcoding the CVV response instead of reading it from the gateway reply.
  • Storing the CVV value in your database, which violates PCI DSS rules even in test data.
  • Skipping the mismatch case and only testing successful matches.

Can you buy a real CVV to test with?

No. Purchasing or selling card verification values is illegal in the United States and most other jurisdictions, and it is never necessary for development.

Every payment gateway provides free sandbox credentials, test card numbers, and test CVV values for exactly this purpose. Testing with anything else creates legal exposure and puts real cardholders at risk, so keep all CVV work inside the sandbox.