PayPal Sandbox Test Card Guide: Test Numbers Explained

What a PayPal sandbox test card actually is

A PayPal sandbox test card is a synthetic card number that PayPal publishes for use in its developer sandbox, the simulated payment environment you use to build and debug checkout flows. It passes the same basic validation a real card would: length checks, Luhn, brand detection, expiry, and a security code field. It also returns a result, approved or declined, so you can test both paths of your logic. Then it stops. There is no issuing bank behind it, no account, and no money.

If you found this page while shopping for card data, understand that sandbox numbers are the one category of card number that is freely published and completely worthless outside the sandbox. They are a testing tool, not inventory.

Where PayPal keeps the numbers

I look in the sandbox section of the PayPal Developer Dashboard first, because the docs and the dashboard occasionally drift apart. Both places hold what you need.

• Developer Dashboard, then Sandbox, then Accounts, shows your test buyer and test seller profiles along with the funding instruments attached to them.
• The Card Testing page in the PayPal developer documentation lists a test number for each supported brand: Visa, Mastercard, American Express, and Discover.
• Braintree, which PayPal owns, publishes its own test card list plus the response codes each number produces, including cards designed to always decline.

Expiry dates on these numbers must be in the future. The security code is a fixed value from the docs, three digits for Visa and Mastercard, four for American Express. Any other value returns a CVV failure, which is often what you want when you are verifying that your error handling fires.

Why they never work in production

Live card networks route transactions to an issuer. Sandbox numbers have no issuer. The Bank Identification Number on a test card either belongs to a range reserved for testing or maps to nothing at all, and the authorization request dies at the network before a real account is ever touched. Anyone claiming otherwise is either confused or selling something. Swapping a sandbox number into live checkout gets you a decline code, not a payment.

This is also why the numbers are safe to publish. The PCI Security Standards Council draws the line between account data, which carries real obligations, and test values that have no cardholder behind them.

Common mistakes when testing with sandbox cards

• Currency mismatch. Your sandbox business account has a primary currency, and a test transaction in a different one either fails or converts at a rate that confuses your reporting.
• Brand not enabled. If the card type is switched off in your sandbox account settings, the number declines for reasons that have nothing to do with your code.
• Reusing a one-time test token. Some sandbox instruments are single use, so the second run of your test suite fails for no visible reason.
• Testing only the happy path. The most useful sandbox cards are the ones that decline, trigger AVS mismatches, or return specific processor error codes. Test those first.

What these numbers are not

They are not a shortcut, not a source of free funds, and not something you can resell. If a marketplace offers you a "test card" for anything other than sandbox development, it is a scam aimed at buyers. Real card data lives behind PCI controls for a reason, and sandbox data lives in public docs for the opposite reason: nobody can do anything with it except test software.