Card Testing for Merchant Services: A Detection and Prevention Guide
Card testing is a fraud attack that floods merchant accounts with low-value authorizations to validate stolen card numbers. Learn the signs and how to stop it.
Redeem your gift cards at any of our Merchants
You can purchase a gift card from any of these locations
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 merchant card verification test checks whether your payment setup handles card verification data the way you expect. You send a transaction through a gateway sandbox using published test card numbers, then confirm that each response code triggers the right behavior in your checkout: approve, decline, hold for review, or ask the buyer to try again. It tests your system, not the customer's card. Nothing about it requires a real card number, and it should never be run against cards you do not own.
Card verification is a message exchange. Your gateway passes the CVV code and the billing address to the issuer, and the issuer returns a result code for each check. Those codes come back separately, which trips people up. A transaction can pass CVV and fail AVS, or pass both and still decline on the authorization itself. A good test maps every combination.
Every major processor publishes test card numbers whose CVV values, expiration dates, and address data are designed to trigger specific outcomes. That is the whole point of them. In test mode you can force a CVV failure, an AVS failure, an insufficient funds decline, and a processor timeout without touching a real account.
I check three things first when I audit a setup: the raw response stored in the transaction log, the customer-facing message, and the order status. If those three disagree, the merchant loses money quietly. A transaction marked approved in the gateway but failed in the order system is the classic version of this.
Issuer responses for CVV and AVS are letter codes, and they are not binary. A match is clean. A no-match usually means a typo or a fraud signal depending on context. An unavailable response means the issuer could not answer, which is common outside the United States and on some card products. A not-supported response appears on card types that do not carry verification data at all.
Your policy should be written down before you write the code. Which combinations auto-approve? Which go to manual review? Which hard-decline? Most merchants treat CVV no-match as a review trigger rather than an automatic decline, because a surprising share of them are honest typos.
The printed card verification code is classified as sensitive authentication data. It cannot be stored after authorization, even encrypted, under PCI DSS. Log the response code, never the value. Keep test credentials in test mode, keep production credentials out of developer machines, and treat any verification workflow that stores the code as a finding to fix, not a feature to ship.