CVV Verification Guide: How to Safely Buy CVV
Learn how to verify CVV codes safely when buying CVV online. This guide provides essential steps and tips 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 CVV test response code is the single-letter result a payment gateway returns when it checks the card verification value during a sandbox transaction. The standard values are M (match), N (no match), P (not processed), S (should be present), U (issuer unable to process), and X (no response from the issuer). These codes appear in test mode only, where no real card is charged.
If you are building or debugging a checkout, the code tells you whether your integration sent the CVV field at all, and how your gateway maps the answer. Real card data never belongs in a test.
The code is one part of the authorization response, not a payment result on its own. A gateway sends the CVV check alongside the amount, the card number, and the expiry date.
Visa calls it CVV2, Mastercard calls it CVC2, and American Express calls it CID. All three confirm the three or four digits printed on the card.
That printed value never sits in the magnetic stripe or the chip. A thief who clones a card gets the account number but not the verification digits, which is why issuers treat a mismatch as a fraud signal.
Most processors use the same letter set. Your gateway documentation is the source of truth for your account.
A blank result points at your code, not the card. Inspect the request payload before you chase the issuer.
In test mode, your gateway skips the card network and returns a canned response. The answer comes from the test card number and test CVV you typed, not from any bank.
Providers publish fixed test card numbers, such as 4242 4242 4242 4242, plus a table of test CVVs. Each test CVV maps to one response code.
There is no industry-wide mapping. Stripe, Adyen, Braintree, and Authorize.Net each pick their own test values, and the value can change with the card number you use.
Read the test card table for your processor before you write assertions. Copying a CVV list from a blog post or forum produces failed tests, because the numbers belong to a different sandbox.
An N in test mode means you sent a CVV the sandbox does not recognize. A U in test mode means the sandbox is not set up to run that check.
Confirm three things: the card number is a published test number, the CVV comes from the same test table, and your API key belongs to the sandbox.
If all three are correct and the code still looks wrong, check where your gateway places the CVV result in the response. Many integrations read the wrong level of the response object and report a false failure.
Not by itself. The CVV result is one signal, and your account settings decide what happens next.
Most processors let you choose between rejecting the charge or accepting it and flagging the mismatch for review. Rejecting cuts fraud losses; accepting cuts false declines. Pick one policy and apply it the same way across every channel.
AVS (address verification) is a separate check with its own response codes. A match on one and a mismatch on the other is normal.
Do not test with card numbers you do not own. Using someone else's card details, even in a so-called test, is card fraud in the United States and most other countries, and it carries criminal penalties.
If you need a live check, use your own card or a processor-issued test card that behaves like a real one.
PCI DSS also bars storing the card verification value after authorization. Keep it out of logs, databases, and error messages, and mask it on any receipt your system prints.
S means the request reached the issuer with no CVV attached. Your form or API call dropped the field before it left your server.
Yes, in sandbox. Use the test CVV your processor pairs with that outcome. Live networks do not accept forced codes.
No. CVV codes describe the verification check. Decline codes describe the whole authorization, which can fail for reasons that have nothing to do with the CVV.
It rides along with the authorization request, so it adds no extra round trip. A code of X or P points to an issuer problem, not a slow network.
M and N tell you the digits matched or did not. P, S, U, and X tell you the check never ran. In sandbox, those results come from test card tables, not from banks.
Match your test values to your processor, log the raw response, and keep real CVV data out of your system.