The PayPal sandbox has no official list of test card numbers. Card fields inside the sandbox accept the same test numbers the card networks hand out for test traffic, such as Visa 4111111111111111, Mastercard 5555555555554444, and Amex 378282246310005, entered with any future expiry date and any CVV. Most PayPal checkout flows in sandbox skip cards altogether and run through sandbox buyer accounts instead.
What test card numbers work in the PayPal sandbox?
PayPal does not publish a table of sandbox card numbers. The numbers below are standard card-network test PANs, used by payment processors around the world for test traffic. Acceptance varies by sandbox account country and product, so treat each one as a starting point.
- Visa credit: 4111111111111111
- Visa debit: 4012888888881881
- Mastercard: 5555555555554444
- Mastercard 2-series: 2223003122003222
- American Express: 378282246310005
- Discover: 6011111111111117
- JCB: 3566002020360505
Decline numbers from other processors do not carry over. A number like 4000000000000002 forces a decline on Stripe test mode because Stripe maps it to an error code. PayPal does not honor that mapping.
Why does the PayPal sandbox handle cards differently from Stripe?
PayPal built its sandbox around accounts, not cards. A sandbox buyer account carries a fake balance and linked funding sources, so a checkout test finishes with a login and a "Pay Now" click. The card entry form shows up only when you test Advanced Credit and Debit Card Payments, hosted fields, or a guest checkout with no PayPal account.
That difference trips up developers who come from Stripe. Stripe test mode is a card-first environment: you type 4242 4242 4242 4242 and read the response. PayPal test mode is a login-first environment, and cards are a side path.
How do you run a card test in the PayPal sandbox?
- Sign in to developer.paypal.com and switch the dashboard to Sandbox.
- Open Accounts and create a sandbox business account in a country where card payments are supported.
- Open Apps & Credentials, create a REST app, and copy the client ID and secret.
- Create a sandbox personal account to act as the buyer.
- Load your card form or hosted checkout, then enter a test PAN, a future expiry, and any three-digit CVV.
- Read the API response or the sandbox notification to see the result code.
Negative testing sits in the sandbox account profile. Switch it on when you need a forced decline or a set error code, then switch it off before the next run.
What expiry date, CVV, and billing address should you use?
Use any month and year in the future. For the CVV, any three digits pass, and Amex takes four. The sandbox does not check either field against a real issuer, so the values exist only to satisfy form validation on your side.
Billing address checks run through Address Verification System settings in your sandbox account. A mismatched ZIP returns a pass unless you turn on the failure you want to simulate.
Which sandbox account do you need for card testing?
You need a sandbox business account, not a personal one. Card payments under Advanced Credit and Debit Card Payments require the business account to sit in a supported country and to have the product enabled in the app settings. A sandbox personal account plays the buyer. Keep the two separate, and create several buyer accounts when you need to test other countries or funding sources.
Why does a sandbox test card get declined?
- The sandbox business account is registered in a country that does not support card payments for that product.
- The account is unverified, limited, or missing a confirmed email.
- Negative testing is on, which forces the decline you asked for earlier.
- The number comes from another processor's decline list and has no meaning inside PayPal.
- The buyer and seller accounts sit in different countries with an unsupported currency pair.
Check the sandbox account status first. Most "card declined" reports trace back to a country or product restriction, not to the number.
Does a sandbox test card work for subscriptions and billing agreements?
The answer is mixed. Billing agreements in the sandbox run through sandbox buyer accounts, and card-funded agreements need the same country and product checks as one-time payments. Recurring charges fire on the sandbox schedule, which you can shorten in the billing plan settings. If a charge fails on the second cycle, check the account balance and the agreement status before you blame the card.
Sandbox test card vs live card: what changes?
A sandbox card number never touches a real issuer. PayPal routes the request inside its test environment, so no money moves and no authorization hits a bank. Live mode runs the same form against real networks, and a test PAN returns a decline.
Sandbox approvals say nothing about live approval rates. Real issuers weigh fraud scores, velocity, and account history, none of which the sandbox models.
What should you never do with a sandbox test card?
- Do not type a real card number into a sandbox form. Live PANs in test environments break PCI rules.
- Do not reuse sandbox API credentials in production code.
- Do not treat a sandbox pass as proof that your payment flow works with real issuers.
The PayPal sandbox is a simulation. It checks your integration logic, your error handling, and your order flow. It does not check the card.