Start with the source, not a storefront
A "test payment card v8" set is a versioned bundle of sandbox card numbers that a payment processor publishes so you can exercise checkout, authorization, capture, refund, and chargeback paths without moving real money. The correct place to get one is the processor's own developer documentation. Stripe, Adyen, Braintree, Checkout.com, and most regional acquirers each publish a table that maps a test number to an outcome: approved, insufficient funds, do not honor, expired card, incorrect CVV, or a 3D Secure challenge. Copy that table, pin it to the API version your integration targets, and re-read it after every gateway upgrade. Numbers on those lists are synthetic, they pass the Luhn check digit, and they route to a sandbox endpoint that never touches a live card network.
What you should not do is buy a bundle of card numbers, CVV values, and expiry dates from a marketplace or chat channel. Real card data is not a test instrument. Trafficking in it is a federal offense in the US under 18 U.S.C. section 1029, and retaining a CVV after authorization breaks PCI DSS. A sandbox card has no account behind it. A purchased CVV belongs to a real person, and using it against a live gateway is card fraud with extra steps.
What to look for in a test card set
- Decline coverage. The set should include a number for every response code your app branches on: hard decline, soft decline, expired card, incorrect CVV, and processing error. A bundle with five approval numbers and no declines tests almost nothing.
- Brand spread. Visa and Mastercard at 16 digits, Amex at 15 digits with a 4-digit security code, and a debit or co-badged case if you support either.
- 3D Secure profiles. Frictionless approval, challenge required, challenge failed, and authentication unavailable. These drive different code paths in your front end.
- AVS credentials. Postal code and street number values that produce match, partial match, and no match results.
- A version note. The v8 label means little on its own. What matters is which gateway API version the set was written for and whether the provider keeps a changelog when numbers are retired.
- Tokenization support. At least one number that returns a reusable token so you can test saved-card and subscription flows.
Parameter bands that matter
- PAN length: 15 digits for Amex, 16 for Visa and Mastercard, 19 for some co-badged cards. Check length before you run Luhn.
- Expiry: keep sandbox cards at least 12 months out. Test expired-card handling with a dedicated expired number, not by waiting for a date to pass.
- Security code: 3 digits for most brands, 4 for Amex. Many sandboxes accept any value, so do not assume your CVV field is validated there.
- Amounts: run approvals at small round values, and keep a written list of the trigger amounts that force declines in your specific gateway.
- Currencies: cover at least one multi-currency case and one zero-decimal currency such as JPY.
Pitfalls to avoid
- Loading test numbers while the live publishable key is active. Test PANs fail against live endpoints, and the failed attempts land in your risk logs.
- Reusing a stale number after the gateway retires it. The result is a confusing generic error that looks like an integration bug.
- Assuming the sandbox validates CVV or AVS the way production does. It often does not.
- Skipping partial approval and partial refund paths, which are the first things to break in production.
- Logging full PAN or CVV values from test traffic into shared systems and then carrying that habit into live traffic.
FAQ
Are test payment cards real cards?
No. They are synthetic numbers built to pass format and checksum rules so a sandbox can process them. They carry no account, no balance, and no cardholder.
What does the v8 in a test card set mean?
It is a provider's own revision label, usually tied to a gateway API version or a card-set refresh. Treat it as a compatibility marker and confirm it against the processor documentation you actually integrate.
Can I use a test card on a live store?
No. Live endpoints reject them, and attempting it repeatedly can flag your account for risk review. Use sandbox keys and sandbox endpoints together.
Is buying CVV data ever legal for testing?
No. Real card data cannot be purchased for testing under any framing. If you need decline and fraud scenarios, build them with sandbox numbers and your gateway's fraud tooling in test mode.