Steps to Locate a Genuine CVV Merchant
Discover the essential steps to identify a reliable CVV merchant for secure transactions.
Our Cards
Choose from any of our gift cards to give to your loved ones
Choose from any of our gift cards to give to your loved ones
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.
A card test case is a written check that confirms how a payment system handles one card scenario, such as an approved charge, a decline, or an expired card. Testers run these cases in a processor sandbox with published test card numbers, not with real cardholder data.
Each case pairs one input set with one expected response. The input covers the card number, expiry, CVC, postal code, amount, and currency. The expected response is what the gateway should return, such as an approval code or a specific decline reason.
A useful case also records what happened during the run: pass, fail, blocked, or skipped. That record is what turns a random click-through into a repeatable test.
Payment processors publish test numbers for their sandboxes. Stripe, Adyen, Braintree, and Authorize.Net all list numbers that trigger approvals, declines, and fraud checks on demand. These numbers pass format checks but belong to no real account, so a charge on them costs nothing and reaches no bank.
No. Running charges on card numbers you do not own is carding, and US federal law treats it as access device fraud under 18 U.S.C. § 1029. Buying CVV or full card data falls under the same statute, and card networks cut off merchants whose traffic looks like card testing. A sandbox case covers the same logic with none of the legal exposure.
Most teams use a simple template: ID, title, preconditions, steps, input data, expected result, actual result, and status. The steps below follow that order.
Cover the happy path first, then the failures your support team sees most. A starting set:
Processors map specific test numbers to specific responses. One number returns an approval, another returns insufficient funds, and a third triggers a fraud block. Some sandboxes also let you set the response with a header or an API flag, which removes the need to swap numbers between runs.
Decline codes matter because your app must show the right message and keep the order recoverable. A failed charge should not empty the cart or lock the customer account.
Yes, for the parts that do not need a live processor. Format checks, Luhn validation, and form validation run in milliseconds on every commit. Network calls to a sandbox belong in a nightly job so a slow gateway does not block a build. PCI DSS also expects testing after any change to systems that touch card data.
A test card number is a fake card number a processor publishes for its sandbox. It passes Luhn and format checks and routes to a simulated response. It is not tied to a bank account or a person.
Testing your own systems with sandbox numbers is legal and standard practice. Testing real cards you do not own is a federal crime in the US and a violation of card network rules.
Enough to cover each card state your product accepts plus each decline reason your gateway can return. Many teams start with 10 to 15 cases and add one for every payment bug found in production.
Keep the suite small, name each case after the scenario it proves, and run it with sandbox numbers only. That gives you coverage of real card behavior with no real card data in play.