PayPal Sandbox CVV Steps: Get a Test Card That Works

In the PayPal sandbox there is no real CVV to look up. The code comes from the test card itself: you open the Developer Dashboard, generate a sandbox credit card, and PayPal returns the number, expiry and 3-digit code as one record. Use that code exactly as issued. Type a random value and the sandbox rejects the payment.

related article

What "sandbox CVV" actually means

The sandbox mirrors the live payment flow with fake money and fake cards. Card checks in a test environment are not connected to any issuer, so the CVV validation is a format and record check, not a fraud check. PayPal issues test cards through the dashboard, and the code bundled with a generated card is the one that clears for that number.

related article

That catches people coming from other processors. Some test environments accept any three digits. PayPal's tends to tie the code to the generated card, which is why 123 works for one test card and fails for another.

more on this topic

Steps to get a working sandbox card and CVV

1. Sign in to the PayPal Developer Dashboard with your normal PayPal login.
2. Open Apps & Credentials and confirm the toggle is set to Sandbox.
3. Under Testing Tools, open Sandbox Accounts. Create a personal buyer account if you do not have one. Business accounts play the merchant.
4. Under Testing Tools, open the credit card generator. It returns a card number, card type, expiry date and CVV.
5. Copy all three payment values into your checkout form as separate fields.
6. Set a plausible billing address. Use a real-looking street and ZIP, not a single character. Address checks can still trip a test.
7. Submit the payment and read the response in the dashboard API logs.

Where the CVV field trips people

• American Express uses a 4-digit code and a different field label. If your form hardcodes three digits, validation fails before the request leaves your app.
• Expiry dates. The generator returns a future date, but not a distant one. A hardcoded fixture from last year will fail.
• Mixing account sets. A card generated under one sandbox account set will not always clear against a different merchant app. Regenerate instead of retrying.
• Trimming. Leading zeros matter. If your form parses the CVV as an integer, 012 becomes 12 and gets rejected.
• Live mode. Sandbox cards only work in sandbox. Swap the client ID to live and reuse the number, and you get a generic decline with no useful detail.

Test the declines on purpose

You want the failure paths too. The sandbox lets you drive specific error responses, and the dashboard documents which values or amounts trigger which outcomes. Walk through a bad CVV, an expired card and an address mismatch one at a time, then check that your UI prints a message a customer can act on.

Keep it in the sandbox

Everything above applies to test cards only. Real card numbers do not belong in a sandbox request, and sandbox credentials do not belong in a live environment. Treat test card data like any other fixture: kept in your repo's test config, out of screenshots and out of support tickets.