A sandbox test card is a dummy card number published by a payment processor for use in its test environment. It passes the Luhn check, carries a real-looking BIN, and reaches simulated authorization logic instead of a bank. Each number maps to one outcome: approval, a specific decline code, an expired card, or a 3D Secure challenge. No funds move, no issuer sees the request, and the number dies the moment you switch from test keys to live keys. The right set to use is the one shipped by the processor that holds your merchant account, because decline mapping and 3DS simulation only match that processor's own test rails.

Criteria that matter when you pick a set

• Response coverage: can you force a soft decline, a hard decline, an expired card, and a processing error on demand?
• 3D Secure simulation: does the set include a card that triggers a challenge page and one that passes frictionless?
• Currency and region: some sets simulate US-issued cards only.
• Adjacent flows: tokenization, wallets, recurring charges, refunds, partial captures.
• Documentation freshness: processors retire test numbers when they change authorization engines.

Stripe

Stripe test mode accepts 4242 4242 4242 4242 with any future expiry, any three digit CVC, and any postal code for a plain approval. Decline behavior comes from other numbers in the same published ranges, and a separate group drives 3D Secure. Because so many tutorials build on Stripe, its numbers are the ones most developers already know.

Pros

• Widest published coverage of decline codes and authentication flows
• Same numbers work across PaymentIntents, Checkout, and Terminal
• Test clocks let you simulate renewal and dunning timelines

Cons

• Coverage is Stripe-specific and reveals nothing about another processor's decline mapping
• Test objects and live objects never mix, so seed scripts must be rebuilt per mode

Use it if your integration runs on Stripe or you need a demo environment fast.

Adyen

Adyen's test environment treats 4111 1111 1111 1111 as the default success card, with any future expiry and any CVC. The docs also list cards that force specific refusal reasons and both 3DS outcomes.

Pros

• Strong coverage of European card schemes and local payment methods
• Test cards pair with a webhook simulator, so async flows get exercised

Cons

• Heavier setup: you configure a test merchant account before the first authorization
• Fewer ready-made numbers for US-specific edge cases

Use it if your checkout serves multiple regions or you settle in more than one currency.

Braintree and PayPal

Braintree publishes a fixed list of test card numbers mapped to named responses, including successful verification, CVV mismatch, and processor declines. PayPal sandbox personas handle the wallet side of the same flow.

Pros

• The decline list is explicit, so assertions in automated tests stay readable
• Wallet and card paths are testable in one sandbox

Cons

• PayPal sandbox accounts and Braintree test gateways are separate objects you configure twice
• Sandbox state drifts, and old test accounts sometimes need to be recreated

Use it if you run Braintree with PayPal offered as a wallet.

Square

Square's sandbox uses its own test numbers and returns simulated responses through the same endpoints as production.

Pros

• Simple path for sellers who take payments in person and online
• Reader and online checkout share one test surface

Cons

• Fewer published decline variants than Stripe
• Less useful if you only need card-not-present flows

Use it if you test Square hardware alongside web checkout.

Rules that keep sandbox testing clean

1. Never put a real card number in a test environment. Live cardholder data in a sandbox drags that environment into full PCI DSS scope.
2. Keep test keys and live keys in separate config paths. Most accidental charges come from a key swap, not a logic bug.
3. Pin expiry years far out. A test card that expires in December breaks CI in January.
4. Assert on response codes, not on human readable messages. Wording changes without notice.
5. Purge test customers and payment methods before launch.

One clarification worth stating: a sandbox test card has nothing to do with buying card data. These numbers are public constants, they only resolve against a test endpoint, and the CVC field accepts any digits because no account sits behind them. Anything sold as a card with a matching CVV that authorizes in live mode is stolen cardholder data, and running it through your integration voids your processor agreement and puts your PCI posture at risk.