Gift card fraud bots: how balance checking attacks work and how to slow them
Why balance lookup is the perfect bot endpoint
A balance checker must answer a simple question quickly for genuine customers, including customers with no account and no login. That openness is what attackers use. Given a list of stolen partial card details, or a way to generate plausible numbers, a script can test thousands of combinations and keep only the ones that return a balance. Each successful test is silent. The loss appears later, at redemption.
The economics favour the attacker until you change them. One request costs almost nothing, and a single drained card can pay for millions of attempts. Defence therefore aims to raise the cost per attempt and lower the value of a success, through throttling, proof of work or challenge steps for suspicious sessions, and alerts that freeze a card when its balance is queried in an unusual pattern.
Enumeration leaves a recognisable shape
Bot enumeration rarely looks like human checking. Humans check one card, mistype once, and stop. Scripts check many distinct card numbers from one session, device, or network, at regular intervals, with a very low success rate, and they often ignore images and other page assets. Logging distinct card numbers per session and per network is the single most useful detection signal.
Watch the surrounding behaviour too: balance checks with no other browsing, repeated checks at exact intervals through the night, and user agents that claim to be common browsers but fail basic consistency checks. None of these proves fraud alone. Together, they justify stepping up friction for that session while leaving normal shoppers untouched.
Design cards that are harder to guess
Long, random card numbers and a separate PIN or scratch panel value make brute force far less practical, because the attacker must guess a pair, not a sequence. Avoid sequential numbering that reveals how many cards exist and where a valid range sits. If your numbers follow a pattern an attacker can learn from two purchased cards, the whole issued range is at risk.
At redemption, require the same pair, monitor velocity per card, and alert on balance checks from distant locations in quick succession. For digital cards delivered by email, consider showing the full credential only after account login. Convenience matters for genuine buyers, but a balance that anyone with a number can spend will eventually be spent by someone else.
Respond to a draining incident without harming customers
When an attack is found, act on evidence: block the abusive sessions and networks, step up challenges on the lookup, and identify cards whose balances were checked in the attack window. Freezing every card in a range punishes customers for your incident. Targeted holds on demonstrably probed cards, with a fast replacement route for the real owners, contain loss without a public relations problem.
Tell affected customers plainly what happened and what you have done, and make reissue easy. Gift card buyers are often givers, so the person discovering an empty card may be a recipient at a till, in front of a queue. A support team briefed with a one step remedy turns an embarrassing moment into a story about being looked after.
Keep reading: Sale day bot spikes: preparing a store for launch traffic that is half human, half automated, API abuse bots: why your mobile and checkout APIs get attacked even when the website looks fine, and Inventory hoarding bots: how automated carts lock up stock real shoppers cannot buy cover the nearby cases in this series.
Frequently asked questions
How do bots drain gift cards they have never seen?
They enumerate. Scripts test large numbers of card and PIN combinations against the public balance checker, keep the combinations that return a balance, and spend those balances quickly, often on resalable goods or by reselling the card details.
What is the best first control on a balance checker?
Rate limiting based on distinct card numbers per session and network, backed by logging. A human checks one or two cards. A script checks hundreds, and that difference is visible if you measure it.
Should balance checks require a login?
Not always, because recipients may not have accounts. A middle path is to allow a small number of anonymous checks, then require a challenge or login when behaviour looks automated or volume rises.
What should we do for customers whose cards were drained?
Replace the value quickly on a new card, explain briefly what happened, and check whether the card was probed in an attack window. Fast, generous handling protects trust while controls are tightened.