Bots Targeting Gift Card Balance Checks
Balance check endpoints are a quiet favourite for automated abuse. How attackers enumerate card numbers and how stores defend the checker.
A gift card balance checker looks harmless: a small form, a number, a balance. To an automated operator it is something else, a verification oracle. Submit a card number, learn whether it is real and what it holds, repeat a million times. Stolen and guessed numbers become spendable cash at machine speed.
This guide explains how balance check attacks work, the signals they leave in traffic, and the defences that protect the checker without punishing the recipient who just wants to know what grandma sent.
How enumeration against a checker works
Attackers feed the checker generated or leaked card numbers, often paired with PINs from breaches or guessable patterns. Each response divides the list: invalid numbers are discarded, valid ones with balances are kept, drained, or sold. The checker does the expensive verification work for free, at whatever rate the store allows.
The attack is cheap because the form is simple and the response is binary. Any checker that answers instantly, unlimited times, with a clear valid or invalid distinction is an invitation, whether or not money has been lost yet.
Signals in the traffic data
Look for high request rates to the balance endpoint relative to its normal, low traffic baseline, repeated failures from shared infrastructure, requests at machine regular intervals, and checking patterns that never continue to a purchase. Legitimate recipients check once and go shopping. Enumerators check thousands and never buy.
Seasonality is a tell as well. Balance attacks spike after the holidays, when newly issued cards fill the number space with live balances. A January spike in checker traffic with flat gift card sales is a pattern worth an immediate look.
Defences that preserve the honest check
Rate limit per card, per session, and per network source, with limits that tighten after failures. Add a challenge after a small number of attempts rather than on the first check, so honest recipients are rarely touched while enumeration, which needs volume, is stopped cold.
Response design helps too: avoid confirming which part of the credential failed, lock a card temporarily after repeated failures and tell its owner through a separate channel, and log every check with enough detail to support investigation. Speed is the attackers economics. Any friction that scales with attempts breaks the model.
Prepare the January playbook now
Gift card issuance peaks in December and abuse follows in January. Set thresholds, alerts, and the lockout response before the peak, assign an owner for checker anomalies, and agree in advance what evidence triggers a temporary checker restriction versus a support led workaround for recipients.
Communicate the assisted route: recipients locked out by defences need a human path to a balance, through support with reasonable proof. Defences that strand honest recipients during the busiest month create the support storm they were meant to prevent.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Price Scraping Bots: Reading the Traffic and Protecting Your Catalogue, Bot Traffic During Holiday Sales: Separating Hype From Harm, and Credential Stuffing Bots Are Flooding Your Login Pages.
Frequently asked questions
Why do bots attack balance checkers instead of checkout?
A checker verifies card numbers and balances for free, at speed, with a simple form. That turns guessed or leaked numbers into confirmed spendable value. Checkout involves payment and fulfilment friction. The checker is the cheap oracle attackers prefer.
What traffic signals suggest enumeration?
Request volume far above the checkers quiet baseline, high failure rates from shared sources, machine regular timing, and checks that never lead to shopping. Post holiday spikes are a particular warning sign, when many newly issued cards hold balances.
How can a checker be defended without annoying recipients?
Rate limits that tighten after failures, a challenge step after a few attempts rather than on the first check, vague failure messages, and temporary card locks with owner notification. Honest recipients check once. Attackers need thousands of attempts, so attempt scaled friction separates them.
What should be ready before January?
Thresholds and alerts on checker traffic, a named owner for anomalies, an agreed lockout and restriction playbook, and a staffed assisted route so locked out recipients can still get a balance from support with reasonable proof.