Pick the card from your own PayPal developer dashboard, not from a list you found in a forum. PayPal issues sandbox cards per sandbox account, and a number that belongs to someone else's sandbox will fail at checkout no matter how valid the digits look. Generate a fresh card in the dashboard, attach it to the sandbox buyer account you plan to test with, and use the matching billing postal code. That single step removes most of the decline noise developers run into.
What counts as a sandbox test card
A test card is a card number that exists only inside the PayPal sandbox. It is tied to a sandbox account, has no connection to a real issuer, and cannot authorize anything in the live environment. The number still has to pass format checks: correct length for the brand, a Luhn-valid check digit, a future expiry date, and a security code of the right length. The sandbox validates the shape of the data and its link to the sandbox account, then simulates an approval or a decline based on the scenario you configured.
Because the sandbox never contacts a real issuer, these numbers are safe to keep in a test fixtures file. They are not safe to treat as a live card, and they will be rejected outside the sandbox.
What to look for
- Origin: generated in the dashboard for the sandbox account you are testing, not copied from another project.
- Brand coverage: at least one Visa and one Mastercard, plus American Express if your checkout renders different fields for it.
- Decline behavior: a card you can force to fail so you can inspect the error path your users see.
- Determinism: a card that returns the same result on every run, so a failing test means a real bug.
Parameter bands that matter
- Expiry date: at least one year ahead. Past dates can fail before the request leaves your app.
- Security code: three digits for Visa and Mastercard, four for American Express.
- Card number length: 16 digits for Visa and Mastercard, 15 for American Express.
- Billing postal code: must match the address stored on the sandbox card record, or address verification fails.
- Market settings: match the sandbox account country. A US sandbox buyer paired with a card set to another market can trip a mismatch rule.
Pitfalls
- Mixing environments. Sandbox credentials against a live endpoint, or a live client ID against a sandbox card, produce an error that looks like a card problem and is not.
- Reusing a card across sandbox accounts. The card record belongs to one account.
- Ignoring the postal code field. Address verification is a separate failure from a card decline, and the messages differ.
- Testing only the happy path. Configure a decline scenario so retry logic and error messaging get exercised.
- Storing real card data in a repo while debugging. Test cards belong in fixtures; anything else belongs in a compliant vault or nowhere.
FAQ
Will a sandbox test card work on a live site?
No. Sandbox cards are not issued by a bank and no acquirer will authorize them.
Why is my sandbox card declined?
Check the environment first, then the expiry date, then the billing postal code and brand field lengths. A card generated for a different sandbox account is another frequent cause.
Can I use the well known published test numbers?
Yes for format testing, if the sandbox accepts them. Dashboard-generated cards work better because they are bound to your account and can be paired with negative test scenarios.
Do I need a funded sandbox buyer balance?
Funding rules differ by scenario. Some flows draw on the sandbox buyer balance, others simulate a card authorization. Set up the buyer account to match the flow you are testing.