Magento 2 Gift Card Fraud: Stop Code Brute-Forcing, Card Draining and Chargebacks Before Peak Season

In 2017, a bot network called GiftGhostBot tested gift card numbers on nearly 1,000 ecommerce sites at a reported 1.7 million guesses an hour, according to a security write-up of the attack. Nine years on, the tactic is routine: on November 26, 2025, the Illinois Attorney General warned shoppers that thieves copy codes from store gift cards and wait for the balance to be loaded. A gift card code is a bearer instrument. Whoever types it first gets the money.

Q4 is already underway, so this guide is ordered by speed: edge controls you can ship in a day, code and status rules you can ship this week, and process changes for the weeks after. It covers the three losses a Magento 2 store sees, with settings drawn from MageDelight’s Gift Card extension and its user manual.

It is general security guidance, not a guarantee, and it does not replace a penetration test or advice from your payment processor and counsel.

The Three Attacks, and Where They Hit a Magento Store

Security teams often call gift card guessing "card cracking", but OWASP catalogues it under Token Cracking (OAT-002): the mass enumeration of voucher codes. OAT-010 Card Cracking covers payment card security values, a different problem. The distinction matters because the defences differ.

Draining deserves a note. Police and state officials explain how this scam works in stores. Thieves take cards from the shelves, copy the card numbers and PINs, then put them back exactly as they were, sealing the packaging so it looks untouched. Once a customer buys the card and adds money, the thieves drain the balance. The same kind of thinking applies to cards sent by mail. It also applies to any activation code that a bot can monitor and steal.

What the Extension Gives You, and What Its Manual Does Not Say

Based on the user manual, last modified in August 2025, the extension provides:

• Gift card products with fixed prices or a price range with minimum and maximum amounts, a default Lifetime in days, and send-by-email or send-by-post options.

• A Manage Codes grid where admins can add a code, set main and remaining balance, change expiry, and set one of five statuses: Pending, Inactive, Sold, Active or Expired.

• A History tab for each gift card, showing order ID and value.

• A cart field for applying a code, and a My Account page where a customer enters a code to see its status, balances and expiry.

Two details shape your risk. First, when an admin creates a code manually, the manual says the name is usually a mix of text and numbers "but not compulsory", so a human can choose a guessable one. Second, the manual does not describe code length or randomness settings, failed-attempt limits, lockouts, CAPTCHA on the code fields, or purchase velocity limits. Ask MageDelight support what your version does for each before you assume protection exists. Customization is available for gaps. The configuration guide and FAQ page cover setup basics.

The product page shows Magento Open Source, Adobe Commerce and Adobe Commerce Cloud, all versions from 2.4.0 to 2.4.9. It says these are Hyvä-ready. Prices start at $249 per year for Magento Open Source, $499 for Adobe Commerce, and $599 for Adobe Commerce Cloud. After the year, updates and support cost $169 per year.

Prerequisites

• Staging store and a backup before you change anything.

• Access to your CDN or web application firewall, and to your web server configuration.

• An export of recent gift card activity: purchases, apply attempts and redemptions.

• Your payment processor’s fraud tools, chargeback reports and dispute deadlines.

• A named owner for gift card security and one for customer support escalation.

The Seven-Step Hardening Plan

Step 1: Map Everywhere a Code Is Accepted or Revealed

Success looks like this: a list of every URL and screen that accepts or shows a code with an owner, for each.

Step 2: Make Codes Impossible to Guess

Guessing succeeds when valid codes are a dense share of all possible values. The table shows the odds for a store with 100,000 live cards facing the 1.7 million guesses an hour reported for GiftGhostBot. These figures are this guide’s arithmetic, not a measurement of any store.

• Use long, random, machine-generated codes. Sixteen or more characters from an alphabet make them hard to guess by chance. Avoid visually similar characters, like 0 and O.

• Never hand-pick codes for sale. Admin-created names like SUMMER2026 or sequential numbers are guessable and widely tried. Reserve manual codes for promotions you can accept, with low values and short lives.

• Do not rely on a prefix or dashes. They make codes readable but add no strength. Count only the random part.

• Consider a second secret. Large retailers have moved from printed codes to PINs issued at the register, as NBC reported about Target. A code plus PIN squares the guessing work. Ask MageDelight whether your version can add one.

• Keep lifetimes sensible. The Lifetime and expiry fields shrink the window in which a stolen code matters.

Step 3: Throttle and Block the Guessing Channels

Even long codes need throttling, because attackers also test codes harvested elsewhere. Put limits at the edge first, since they need no code change.

• Rate limit per IP, per session and per customer on the apply route and the balance lookup. Start with a handful of failed attempts in ten minutes, then add a delay. One security write-up suggests three to five requests a minute per IP for balance checks. Tune these numbers to your real traffic.

• Add a challenge after repeated failures. CAPTCHA or bot scoring can stop scripts after only two or three wrong attempts. Magento’s built‑in reCAPTCHA settings apply to forms. Check whether the gift card fields are included in those settings. If the gift card fields are not covered, add a rule for the gift card fields.

• Use identical error messages and timing for unknown, expired and empty codes so the response does not give away any information.

• Require login for balance checks, and use OTP login, for high-risk actions.

• Block clear automation using your CDN or WAF. Look for datacenter IP ranges. Check for missing browser signals. Watch out for request speeds. IP geolocation tooling can give information. Make sure you know what it can block. Always confirm what it can block.

A server-level limit in nginx looks like this. The server-level limit path is a placeholder; locate the real path using your browser developer tools, as explained in Step 1.

limit_req_zone $binary_remote_addr zone=giftcode:10m rate=5r/m;

# replace with the real path of your apply or lookup request

location = /<gift-card-apply-or-lookup-path> {

    limit_req zone=giftcode burst=3 nodelay;

    # ...your normal Magento handling here

}

Step 4: Protect Codes After You Issue Them

• Use the status field on purpose. The extension supports the statuses Pending, Inactive, Sold, Active and Expired. Keep a code in the Pending or Inactive state until payment is verified and fraud checks pass, and then change it to Active only after that. Ask support how statuses change on order events in your version.

• For physical and combined cards, activate on shipment, not on purchase. A card stolen from the mail before activation is worth nothing. This is the same idea retailers use at the register.

• Ship physical cards safely. Use opaque, tamper‑evident packaging. Never display a code or PIN on the outside. Use tracked shipping for higher-value orders.

• Mind the email. Send codes only to the address on the order or the recipient the buyer named. Offer scheduled delivery so a code isn't sitting in an inbox for weeks.

• Limit who sees codes. Restrict Manage Codes to the few roles that need it, and log exports.

• Encourage fast use. Consumer guidance says you should spend a gift card soon after you get it. This helps keep the leaked code live for a while.

Step 5: Cut Chargeback Exposure at Purchase

Fraudsters get gift cards using stolen payment cards because the item is instant, digital and simple to sell. By the time the card owner says the charge is not theirs, the money is already gone. A card that is emptied does not lead to a chargeback. A card that is bought with stolen information does.

• Cap the exposure. Set the maximum price range. Add limits for each order each day and each customer. A custom rule might be required.

• Use the gateway’s tools. Enable address checks. Enable security code checks. Ask your processor about 3-D Secure. 3-D Secure can shift liability for fraud disputes when the cardholder authenticates.

• Score the order. Treat this combination as risk: a new account, high-value gift cards, instant email delivery, a free-mail or disposable address, and an IP that doesn't match the billing country.

• Add friction for the risky ones. Hold the code, require login, or send the order to manual review before status changes to Active.

• Watch velocity. Several gift card orders from one device, one card or one IP within an hour deserve a stop.

• Keep dispute evidence. Save the order, IP, device details, email delivery logs and the redemption time and IP. Order Attributes can help store extra fields. Check your processor’s dispute deadlines, since disputes can arrive long after purchase.

• Treat the redeemed value as lost. Once a code is used, it cannot be recovered. That’s why the hold in Step 4 protects you.

Step 6: Monitor and Alert

Log every failed attempt with the IP, session and time. If you use GA4 with GTM send events for both failed and successful code applications so the team can see trends, but never log the code itself.

Step 7: Prepare the Incident Playbook

1. Contain: set the affected codes to Inactive in the Manage Codes grid. Tighten the rate limits for codes. Turn on a challenge for the code fields.

2. Preserve: keep web, WAF and application logs, plus the History tab entries for the cards involved.

3. Reissue: create new, random codes for legitimate customers with proof of purchase, and decide your refund or replacement policy in advance.

4. Notify: tell affected customers plainly what happened and what you are doing about it.

5. Report: contact your payment processor, and consider reporting to the FTC at ReportFraud.ftc.gov and to the FBI’s Internet Crime Complaint Centre.

6. Review: find which surface leaked or was guessed, and fix the root cause before restoring service.

If you need hands-on help with any of this, MageDelight’s Magento support service and its code quality audit can review the custom work, and a performance audit can confirm that new limits do not slow checkout.

The Pre-Peak Checklist

Common Mistakes and Troubleshooting

• Short numeric codes. Twelve digits look fine until a bot makes a trillion cheap guesses a day across thousands of sites.

• A balance checker open to guests. It is a free oracle for attackers.

• Different error messages. Telling attackers that a code exists but is empty confirms they guessed right.

• Limits only on the page, not the API. Attackers skip the page.

• Rate limits that block real shoppers. Shared office or mobile IPs can look like one noisy user. Test with a staging group, and use sessions and accounts alongside IPs.

• Activating physical cards at purchase. A card stolen from the mail becomes spendable immediately.

• Codes in logs, subject lines and tickets. Mask them everywhere.

• Treating a drained card as a refund problem only. It is also a sign that a surface is exposed.

• Forgetting store credit. Redeemable gift card value can move into store credit, so apply the same protection there. See MageDelight’s Store Credit extension for that side of the flow.

Which Setup Fits Your Store

• Small store, virtual cards only: do Steps 2 to 4 and the edge limits in Step 3. Hold new-customer orders for review.

• Busy store with physical cards: add shipment-based activation and secure packaging. See also Gift Wrap and Custom Gift Box for how gift products ship.

• High volume or corporate gifting: add order scoring, velocity limits and a manual review queue, plus a second secret on each code.

• Omnichannel, with codes that are used across point-of-sale or loyalty systems: think of every channel as part of the area that needs protection and set limits at the shared service.

• Already hit by an attack: begin with Step 7, then change the exposed codes and work on rebuilding trust with the customers who were affected.

• Hyvä or headless front end: the product page says Hyvä ready. Re-check every route, because custom front ends add new API calls.

For most stores, the order is: map the surfaces, lengthen codes, throttle, hold activation until payment clears, then monitor. Gift Card for Magento 2 handles creating and tracking cards, and the controls above wrap it in layers.

FAQ

Is brute-forcing really a risk for a small store?

Yes. Attacks are automated and run against thousands of sites at once, so store size is irrelevant. Long random codes and basic throttling are inexpensive and cover most of the risk.

How long should a gift card code be?

Sixteen or more random characters from a large alphabet makes blind guessing impractical, based on the arithmetic above. Short numeric codes are the weak spot.

Should I disable the balance checker?

Not definitely. Keep it. Make people log in, limit how often they can use it, add a test after they fail, and show the same error message every time.

Can I reverse a chargeback if the code was already used?

You can dispute with evidence. The value spent is usually not recoverable. Therefore, activation should wait until payment and fraud checks clear.

Does the extension include fraud controls?

The manual documents code management, statuses, history and customer lookups. It does not describe failed-attempt limits, CAPTCHA or velocity rules, so the user should contact MageDelight support. Ask for customisation.