What Is a 2Checkout Test Card?

A 2Checkout test card is a sandbox card number that lets you push payments through the 2Checkout (now Verifone) checkout without moving real money. You enter it in the payment form while the account sits in test mode, and the gateway returns a simulated approval, decline, or error. No funds move, no cardholder is charged, and the transaction never reaches the card networks.

2checkout cvv validation

Test cards exist because live card numbers should never appear in a development environment. The card networks reserve a small set of numbers for this purpose, and every gateway publishes them.

Test 2Checkout CVV

How 2Checkout Test Mode Works

Test mode is a toggle inside the merchant control panel. When it is on, the gateway routes every order to a simulator instead of the live processor.

2Checkout CVV Test Card: The Ultimate Guide

The simulator behaves like the real thing from your code's point of view. You get an order reference, a response code, a status, and a webhook or return URL callback. What you do not get is a settlement file or a deposit.

2checkout cvv test card

• Test mode on: orders are simulated, nothing is charged.
• Test mode off: orders authorize against real issuing banks.
• Keys stay separate: sandbox credentials do not work in live mode, and the reverse is also true.
• Records persist: test orders show in the dashboard and can confuse reporting if you forget to filter them.

Common Test Card Numbers for Sandbox Testing

These numbers pass the Luhn check and are published for testing across most gateways. Confirm them against the current Verifone developer documentation before you hard-code anything, since ranges change.

• Visa: 4111 1111 1111 1111
• Mastercard: 5555 5555 5555 4444
• American Express: 3782 822463 10005
• Discover: 6011 1111 1111 1117

Use a future expiry date, such as 12/30. For the security code, enter three digits on Visa and Mastercard, and four on American Express.

Gateways also ship dedicated decline numbers. A decline card triggers an issuer rejection so you can test your error path without breaking a real payment. Look for the decline and error scenarios listed in the same doc page as the approval numbers.

Why a Real Card Fails in the Sandbox

Merchants often paste a personal card into test mode, get a rejection, and assume the integration is broken. The rejection is the expected result.

• Live card numbers are not part of the sandbox test set, so the simulator does not recognize them.
• Real issuing banks never see the request, so no authorization can happen.
• Storing live card data in a test system breaks PCI DSS scope rules and creates an audit problem.
• Some processors block known live BINs in test mode as a safety measure.

The fix is simple: use the published test numbers, and keep live cards out of development systems entirely.

CVV, Expiry, and Address Fields in Test Orders

Address Verification System (AVS) and CVV checks behave in one of two ways in a sandbox. Either the simulator ignores them, or it returns fixed results based on the values you send.

Most setups let you force a CVV mismatch by entering a wrong-length code, and force an AVS failure with a postal code that does not match. Test both paths, because a declined CVV is a common real-world outcome and your checkout page needs a clean message for it.

• Test a matching AVS and CVV: expect approval.
• Test a CVV mismatch: expect a specific decline code, not a generic error.
• Test a ZIP mismatch: check whether the order still passes or fails.
• Test a missing expiry: confirm the form blocks submission before the request leaves your server.

Steps to Run a Full Test Cycle

1. Switch the account to test mode and copy the sandbox credentials.
2. Load your checkout page and pay with a published test card.
3. Confirm the order lands in your system with the correct amount and currency.
4. Trigger a decline and check the message your customer sees.
5. Test the return URL and the webhook or IPN listener, including a retry.
6. Test a refund and a partial refund against the test order.
7. Repeat in every currency and language you plan to support.

Write down each result. A short checklist saves hours when you switch to live keys and something small breaks.

When Should You Move From Test Cards to Live Payments?

Move to live mode when approvals, declines, refunds, webhooks, and currency handling all work in the sandbox. Do a final pass with a small real transaction on your own card, then refund it.

Keep the test suite in place. Gateways change endpoints and response codes, and a working sandbox run is the fastest way to spot a regression before customers do.

Frequently Asked Questions

Do 2Checkout test cards work in live mode?

No. Test numbers are rejected once the account is live, and live numbers are rejected in the sandbox. The two environments do not overlap.

Is it safe to use a real card number in the sandbox?

No. It creates a PCI DSS compliance gap, and the transaction will fail anyway. Use the published test numbers.

Why does my test card get declined?

Common causes are a past expiry date, a wrong digit count in the security code, an incorrect card type selection, or an expired sandbox key. Check those four before you debug the code.

Does a sandbox transaction cost anything?

No. No authorization reaches an issuing bank, so no fee applies. Test orders appear in reports but never settle.