PayPal sandbox CVV sample: the short answer

There is no separate "PayPal CVV sample." In sandbox mode PayPal does not validate the CVV field at all, so you can enter 123, 999, or 000 and the test payment still completes. What you actually need is a sandbox test card number, an expiry date in the future, and any 3-digit code. If your form is set up for American Express style cards, use any 4 digits instead.

paypal sandbox cvv sample

That is the whole trick. People spend hours hunting for a magic CVV when the real answer is that the field is a stub in test mode. Nothing about the digits you type changes the outcome.

more on this topic

Test card numbers the sandbox accepts

The card networks publish test ranges that every major gateway, PayPal included, treats as fake. These are the same numbers developers have pasted into test forms for years.

PayPal Sandbox CVV Example Guide

  • 4111 1111 1111 1111 (Visa)
  • 4012 8888 8888 1881 (Visa)
  • 5555 5555 5555 4444 (Mastercard)
  • 3782 822463 10005 (Amex, 4-digit CID)
  • 6011 1111 1111 1117 (Discover)

Pair any of them with a future expiry and a CVV of your choosing. The gateway reads the card number and the date; the security code is decorative in this environment.

paypal sandbox cvv example

A setup order that saves time

  1. Open the PayPal developer dashboard and create a business sandbox account.
  2. Create a matching personal sandbox account for the buyer side.
  3. Confirm the test buyer has a starting balance, since card payments in sandbox route through the gateway mock.
  4. Run a test order with a number from the list above and a CVV you invent.
  5. Check the sandbox transaction log to confirm what the gateway recorded.

If the payment fails, the cause is almost always the card number, a past expiry, or a currency and country mismatch. The CVV is the last thing to suspect.

Where the CVV field finally matters

Negative testing. If you want to confirm that your checkout surfaces a CVV error instead of a generic failure, you need the sandbox trigger values rather than a real decline. PayPal documents those separately and the list shifts over time, so check the current test card page before you hard-code anything. Do not assume the sandbox mimics live CVV checks. It does not, and a checkout that works in test can still fail the first real card.

Mistakes I see over and over

  • Using a sandbox card against the live endpoint. It declines right away and can put a flag on the account.
  • Storing the CVV in a test database, then shipping the same schema to production. PCI rules treat security codes as sensitive authentication data, and they cannot be kept after authorization.
  • Treating sandbox behavior as a spec for live behavior. Test mode is lenient on purpose.
  • Reusing one buyer account for dozens of unrelated scenarios until the balance and history make the results impossible to read.

Sandbox numbers have no life outside sandbox

These card numbers are published, reused by thousands of developers, and rejected by every production processor on the planet. They are not fresh, they are not tied to an account, and they authorize nothing. Anyone offering them as something else is selling you a text file. For integration work, keep the whole set in a fixtures file, label each one with the failure it triggers, and move on to the parts of the checkout that real users will actually touch.