How do gift-card bots drain store balances?

How the attack actually works

A gift-card code is usually a short alphanumeric string, and the total space of possible codes is far smaller than customers assume. Bots do not guess randomly. They generate candidate codes in bulk, submit them to the store's balance-check page or apply them at checkout, and record which ones return a positive balance. A botnet running thousands of attempts per minute can chew through a meaningful slice of the code space in days.

Once a valid code is found, the bot either spends it immediately on resalable merchandise or lists the code on a gray-market marketplace. The legitimate buyer often discovers the theft only when they try to use a card they received as a gift, which makes this one of the most brand-damaging bot attacks: the victim's first contact with your support team is an accusation that you stole their money.

Attackers also harvest codes from data breaches, phishing, and leaked databases, then validate them in bulk against your store. In that variant the guessing is replaced by credential-stuffing logic, but the endpoint abuse looks the same.

Why stores leave the door open

Balance-check pages are the softest target in most stores. They were built as a convenience feature, so they accept unlimited guesses, return clear valid-or-invalid responses, and sit outside the fraud tooling that protects checkout. Many stores add rate limiting to login but forget the gift-card validator entirely.

Checkout application of gift cards is the second path. Each attempt reveals whether a code is valid, and failed attempts cost the attacker nothing. Without velocity checks, a single endpoint becomes an oracle the bot can query millions of times.

Predictable code formats make everything worse. Sequential or low-entropy codes shrink the search space dramatically. If your codes are generated with a weak random source or embed a check digit the attacker can reverse, the bot's job gets much easier.

What the damage looks like

The direct cost is the stolen balance, which the store usually has to honor twice: once to the fraudster who spent it and once to the legitimate cardholder after a support escalation. Then there is the merchandise cost when stolen balances convert into shipped goods.

The indirect cost is support load and trust. Gift-card complaints are emotionally charged and time-consuming to resolve, because each one requires verifying purchase records and deciding who to believe. A wave of drained cards can dominate a support queue for weeks.

There is also a quieter metric: gift-card breakage revenue disappears. Cards that would have gone partially unredeemed get fully drained by bots, which sounds like a wash until you realize the redemptions are fraudulent and the legitimate holders still expect their balances.

How to shut the attack down

The highest-leverage fix is on the validation endpoint. Rate-limit balance checks per IP, per device, and per session, and make the limits aggressive: no legitimate shopper checks more than a handful of codes. Add progressive friction so the tenth guess in a minute looks very different from the first.

Response design matters as much as rate limiting. Stop confirming valid-or-invalid with distinct responses where possible, and never reveal partial matches. Every bit of information the endpoint returns is training data for the bot.

On code generation, use high-entropy random codes from a cryptographic source and consider longer codes for high-denomination cards. Then watch the aggregate: a sudden spike in balance-check volume, especially from datacenter IPs or at odd hours, is the attack's signature, and it is visible long before balances start disappearing.