How do bots exploit gift card balance checkers?

September 30, 2026 - BotBulwark

Short answer: Gift card balance checkers answer a yes-or-no question for anyone who asks: is this card number valid, and what is it worth? Bots exploit that by submitting thousands of guessed or stolen card numbers and recording which ones return balances. The valid ones get drained immediately, often resold within minutes. The fix is treating the checker as a sensitive endpoint: aggressive rate limiting, velocity checks per IP and device, account requirements for high-value lookups, and response design that gives attackers as little information as possible.

Why balance checkers are perfect bot targets

A balance checker is an oracle: it takes a guess and returns ground truth. For an attacker holding a list of possibly-valid card numbers from a breach or a generator, that oracle is the difference between a useless list and a shopping spree. Every legitimate use case, a shopper checking a gift they received, is indistinguishable at the request level from an attacker validating stolen numbers.

The economics favor the attacker heavily. Each check costs them nothing, while each hit is worth the full card balance. Even a one percent hit rate on a large list is profitable, and the checker never gets tired. The store is effectively running a free validation service for gift card fraud.

How the guessing operation works

The basic attack is a credential-stuffing pattern applied to card numbers. The bot submits numbers from a list, often with common PIN patterns, and logs the responses. Modern operations are patient: they spread checks across IPs and time windows to stay under naive rate limits, and they rotate user agents and fingerprints to look like a crowd of shoppers.

The advanced version is selective. Instead of brute-forcing the whole space, attackers buy lists of numbers that are likely valid, from breaches or insider leaks, and use the checker only to confirm balances before draining. The checker traffic looks small because it is: the guessing happened elsewhere. This is why checker logs alone undercount the problem.

What stolen balances cost beyond the fraud

The direct loss is the drained card value, which the store usually honors because the card was legitimate when issued. But the secondary costs add up fast: support tickets from gift recipients whose cards show zero balance, chargebacks when the original purchaser disputes, and the operational load of investigating each case.

There is also a trust cost that is harder to measure. Gift cards are bought by people who trust your store enough to prepay. When recipients discover empty balances, that trust transfers to suspicion of the store, not the attacker. A balance checker that leaks value is quietly taxing your most loyal customer acquisition channel.

Locking down the checker without hurting shoppers

Start with the response itself. The checker should confirm as little as possible: avoid returning full balances to unauthenticated sessions, and never distinguish between invalid numbers and valid-but-empty cards in a way that helps enumeration. Every bit of information in the response is a bit the attacker uses.

Then add friction proportional to risk. Rate limit aggressively per IP, device, and session; require account login for repeated or high-value checks; and flag velocity anomalies for review. Real shoppers check one or two cards occasionally. Anyone checking fifty is not shopping. The design principle is simple: make the oracle expensive to query and cheap to use legitimately.

Do CAPTCHAs on the balance page stop these bots?

They slow down the simplest bots but professional operations route around them with solving services. Rate limiting, velocity checks, and response design do more work than a puzzle, because they attack the economics of the guessing rather than one step of it.

Should you remove the balance checker entirely?

Not necessarily, but it should be treated as a sensitive endpoint, not a convenience widget. Strict rate limits, account requirements for high-value checks, and monitoring turn it from an oracle into a dead end for bots while keeping it useful for shoppers.

How do you tell legitimate checks from bot traffic?

Look at volume and pattern per session: one or two checks from a shopper session is normal, dozens from one fingerprint is not. Cross-reference with purchase history and account age. The cleanest signal is the ratio of checks to redemptions; bots check far more than they redeem.