CVV Attack Defense Best Practices
Learn the essential best practices for defending against CVV attacks and keeping your transactions secure.
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.
Short answer: a CVV attack is a burst of card-not-present authorization attempts where someone pushes stolen card numbers and guessed security codes through your payment form. The attacker usually does not want your product. They want to learn which cards still work, then resell or cash out the ones that do. Defense comes down to five controls: real rate limiting, BIN and velocity monitoring, graduated challenges, payment errors that do not leak information, and alerting on decline patterns before chargebacks show up.
You will rarely see it on a dashboard labeled as an attack. What you see is a spike in failed authorizations, often at 2 a.m. to 5 a.m. local time. Orders are small, frequently under ten dollars. Card numbers arrive in rough sequence or share a BIN range. Shipping details look thin or duplicated. One device fingerprint touches twenty different cards in ten minutes.
The tell is the ratio, not the volume. A normal store runs a decline rate in the single digits or low teens. During enumeration it can jump to 60, 80, even 95 percent, because most of the cards are dead or the CVV guess is wrong.
IP throttling alone is close to useless now. Proxies and residential botnets are cheap. I look at several dimensions at once and apply sliding windows to each:
Then I require a real browsing session before the payment form will accept a submission. A bot that jumps straight to checkout with no cart activity, no page dwell time, and no mouse movement is easy to flag.
Fraud scoring catches stolen cards used for a purchase. It often misses enumeration, because the attacker never completes a sale. Track your approve-to-decline ratio per hour and per BIN. When a single BIN produces thirty declines in five minutes, that is not customer behavior. Set thresholds that trigger a temporary block on that BIN and page your risk team.
Also watch response codes for CVV mismatch specifically. A cluster of those on one device is a strong enumeration signal, even if the overall decline rate looks normal.
Do not throw a CAPTCHA at everyone. It costs conversions and attackers solve them anyway. Use a ladder:
The goal is friction aimed at the attacker, not the customer. A shopper on a home connection with a normal cart should never see step two.
Error messages are a gift. If your checkout returns distinct responses for bad card number, bad expiration, bad CVV, and insufficient funds, the attacker can confirm the card is live and just needs a different code. Return one generic failure to the browser. Log the real decline reason server side for your own analysis. This single change slows enumeration more than most people expect.
Card verification values must never be stored after authorization, and that is a hard requirement under PCI DSS. Stored payment credentials should be replaced with tokens, and where your processor supports it, network tokens that the card brands manage. The practical effect is that a database breach does not hand anyone a working card with its security code attached.
Country blocking alone fails because attackers route through local proxies. Static blocklists fail because infrastructure rotates. Adding 3-D Secure to every transaction kills conversion while attackers move to another merchant. Ignoring sub-dollar test charges is the most common mistake I see, because those small approvals are the attacker's proof of concept.
The pattern that holds up: layered limits, quiet error handling, graduated friction, and fast human review of the anomalies your monitoring surfaces.