PayPal Sandbox Test Card: A Guide for Testing
Learn how to use a PayPal sandbox test card for testing transactions without real money.
Choose from any of our gift cards to give to your loved ones
PayPal Sandbox Card Test Platform: A Comprehensive Guide
Redeem your gift cards at any of our Merchants
Onyx Gift Cards is a Grenadian company designed to introduce, market and manage gift cards systems in Grenada for retailers and corporations. We are enthusiastic about the effect and influence we will have on the local market. We intend to expand our systems regionally with a range of product offerings and services.
Gift cards are the preferred way of giving and receiving gifts. They carry a monetary value that can be redeemed for gifts at your favorite store.
Onyx GiftCards are “Open Gift Cards” which means that they can be redeemed at multiple merchant locations. They are standard credit card size, can fit into the average wallet and made of PVC plastic. Onyx GiftCards are Barcoded for security and safety for the consumer and bear a disclaimer at the back.
Onyx Giftcards can be bought with a branded Card backer which is black in colour and is designed to fit the card. There is an area to write a brief message to the recipient as well.
PayPal's sandbox card generator inside the Developer Dashboard is the top pick for card testing, because each card it issues is bound to your sandbox buyer account and returns the exact response codes you need to verify. This guide compares that method with static documented test numbers and Braintree test cards, judged on three criteria: repeatability across runs, coverage of decline and error cases, and whether the card data stays inside a synthetic test environment.
Sandbox cards are fake numbers PayPal issues so you can run checkout, authorization, and capture flows without touching a real funding source. They move no money, work only against the sandbox API hosts, and stop working if you point them at live endpoints. Treat them as fixtures: record the number, expiration, security code, and billing ZIP that the dashboard shows, because that exact combination is what the sandbox validates.
Log into the PayPal Developer Dashboard, open Sandbox Accounts, pick a personal buyer account, and use the card generator to produce a number with its matching expiration and security code.
Use this when: you are running an end-to-end checkout test and want the least surprising result.
Older PayPal documentation and many internal test suites still ship with fixed card numbers, usually Visa and Mastercard ranges, plus a fixed expiration and security code.
Use this when: you want a fixed fixture in CI and you verify the request and response structure rather than the buyer identity.
If your integration runs through Braintree, its documented test cards cover specific processor outcomes: success, decline, and a challenge flow for 3D Secure. Common examples include Visa 4111 1111 1111 1111, Mastercard 5555 5555 5555 4444, and American Express 3782 822463 10005.
Use this when: you need to prove that your code handles declines and authentication prompts, not just the happy path.
Sandbox testing is a synthetic exercise, and it should stay that way. Never substitute a live card number, a real cardholder's billing address, or data pulled from anywhere other than the test environment. PCI DSS guidance is clear that production cardholder data must not be used in test systems, and buying, selling, or trading real card data is a crime in the United States and most other jurisdictions. If a test needs a decline, use a documented decline card rather than a real account. Store test fixtures in a config file, label them as sandbox-only, and keep them out of logs that ship to production. That habit keeps your test suite fast and keeps your team out of a compliance review it does not want.