The reference set most teams reach for is Stripe's published sandbox test cards, because every number is documented, works only against test-mode API keys, and maps to a specific decline or 3DS outcome. The criteria that matter more than any version label are: the numbers are publicly published by a processor, they run in an isolated test environment, the set covers approvals, declines, and authentication flows, and nothing in the set is a real cardholder account. Below is how a "v3" sample is usually structured, how to evaluate one, and where each option fits.

What "card test sample v3" usually means

Payment providers and QA teams version their test fixtures. A v3 sample set is typically the third revision of a documented list of test primary account numbers (PANs), each paired with an expected result: approved, insufficient funds, expired card, incorrect CVC, or a 3D Secure challenge. The numbers pass the Luhn checksum so client-side validation does not reject them, but they are routed to a simulator instead of the card networks. Treat the version label as a changelog pointer, not a quality signal. What matters is whether the provider still supports the numbers and whether the expected outcomes are documented next to them.

The line between test data and stolen card data

Published sandbox numbers and cards offered for sale in underground markets are not the same category of thing, and mixing them up has legal consequences. Buying, selling, or testing stolen payment card data, including CVVs, is a criminal offense in the US and most other jurisdictions, and card testing attacks are actively prosecuted. If a set of numbers claims to be "live" or "validated," that is a warning sign, not a feature. Legitimate test samples are always tied to a sandbox, a test merchant account, or a simulator you control. Use those and nothing else.

Criteria I used to compare the options

  • Publication: the provider documents the numbers in public developer docs, so you can verify expected behavior.
  • Isolation: the numbers cannot authorize against a production account or move real money.
  • Coverage: approvals, soft declines, hard declines, incorrect CVC, expired cards, and 3DS challenge flows.
  • Stability: the set has survived multiple API versions and still returns the same results.
  • Tooling: test clocks, webhook simulation, and the ability to replay a scenario.

Option 1: Stripe test cards

The most widely used sample set. Stripe documents a short list of PANs in its testing guide, and the same numbers trigger different outcomes depending on which test API key and which amount you use.

Pros

  • Publicly documented with expected outcomes next to each number.
  • Covers declines, CVC failures, and 3D Secure challenge flows.
  • Test clocks let you simulate subscription renewals and expiry over time.

Cons

  • Tied to Stripe's own API surface, so it does not validate a different gateway's behavior.
  • Outcome logic can shift between API versions, which is exactly why versioned sample sets exist.

Use case: any team integrating Stripe, and the fastest way to reproduce a payment bug in a support ticket.

Option 2: Adyen and Braintree sandbox sets

Both processors publish their own test card lists for their sandbox environments, with local payment method variants that Stripe's set does not cover.

Pros

  • Reflects that gateway's real decline reason codes and error mapping.
  • Covers regional payment methods and currencies you may need for a US merchant selling abroad.

Cons

  • Documentation is spread across several pages and less consistent about expected outcomes.
  • Fewer built-in time-travel tools than Stripe's test clocks.

Use case: teams already contracted with that processor, or teams validating a multi-gateway failover setup.

Option 3: Your own Luhn-valid synthetic PANs

You can generate numbers that pass the Luhn check and feed them to a mock or a locally hosted simulator. Passing Luhn only means the checksum is correct, not that any account exists.

Pros

  • Full control over the exact scenario and the exact response.
  • No dependency on a third party's test list changing under you.

Cons

  • You must build and maintain the simulator and its edge cases.
  • It cannot tell you how a real processor will behave.

Use case: CI pipelines that need deterministic, offline payment tests on every commit.

Running a test pass

  1. Confirm you are on a sandbox or test-mode key, and log the key prefix in your test report.
  2. Pick one approved number and one decline number from the provider's published list.
  3. Run the happy path first, then force the CVC failure and the expired card case.
  4. Assert on the decline reason code, not just on the failure message.
  5. Verify the webhook payload and the order state after each outcome.
  6. Repeat the suite against the next API version and diff the results before upgrading.

Common pitfalls

Three issues account for most confusing test runs. First, mixing a live key with a test PAN, which fails in a way that looks like a decline but is really a configuration error. Second, asserting on the human-readable error text instead of the machine-readable code, which breaks on every copy edit. Third, expecting a published test number to behave identically across gateways. Store the sample set and its expected outcomes in version control alongside the integration code, and the "v3" in the filename becomes a useful record instead of a guess.