Bots Abusing Gift Card Balance Check Endpoints
A balance checker is a perfect oracle for testing stolen gift card numbers: valid or invalid, and by how much. Why this quiet endpoint draws credential style abuse and how retailers blunt it.
A gift card balance checker asks for a card number and, often, a PIN, and answers with a number. To a retailer it is a customer service page. To an operator holding a list of card numbers obtained from a breach, a phishing kit, or a guessing run, it is an oracle: a free, unlimited way to learn which numbers are live and exactly how much each one is worth, sorted by value before a single purchase is attempted.
That is why this unglamorous endpoint sees abuse out of proportion to its place in the store. Stolen balances are spent quickly, in a burst, usually on goods that resell easily, and the legitimate card holder discovers the theft when they try to spend a card that a checker already told someone else was worth draining.
Enumeration is the attack, not the purchase
The checker attack is enumeration. Scripts submit numbers at volume, varying the final digits or working through a stolen list, and record the responses. Defences aimed only at the checkout miss it entirely, because by the time the spending starts, the valuable work, finding live balances, is already done. Protecting the checker itself, with rate limits per IP and per session, progressive challenges after a small number of attempts, and monitoring for sequential number patterns, is where the attack is actually interrupted.
Distinguish a shopper checking two or three cards after a holiday from an enumerator checking hundreds. Behaviour separates them plainly: request rate, number patterns, failed attempt ratios, and whether the session does anything else on the site at all. A control that treats both the same, locking the page for everyone, punishes the customer service function out of existence, which is its own kind of loss.
The PIN and the response give away too much
Checkers that validate a card number before asking for its PIN, or that respond differently to a nonexistent number and a real number with a wrong PIN, hand the attacker a filter. They can establish which numbers exist cheaply, then spend their effort only on those. Error responses should be uniform: a single message that does not confirm whether the number exists, the PIN was wrong, or the balance is zero.
How much balance detail to show is a second decision. Showing an exact balance to anyone holding the number and PIN is the service customers expect, so the control belongs at access, rate and challenge, rather than at withholding the answer from a legitimate holder. What should not be available is bulk speed. No human needs to check sixty cards a minute, and a limit set at human pace costs real shoppers nothing.
Watch the drain pattern, not just the check
Checker abuse and balance draining are two halves of one incident, and the teams watching them are often different. Join them. A spike in balance checks, especially from new networks or a narrow set of user agents, followed within hours by high value purchases paid entirely in gift cards, is a pattern that should raise the same alert. Stores that review only the purchases see fraud. Stores that review only the checker see scraping. It is one operation.
Customers need a route back that assumes this happens. A clear process for a holder whose balance was drained, with the card number, purchase receipts, and a record of when the balance was checked and spent, is what separates a recoverable incident from a story a customer tells other people. The checker logs that detected the abuse are the same logs that prove the customer's case, which is a good reason to retain them properly.
Related reading: Bot Traffic Index, Answers, Glossary.
Frequently asked questions
Why do attackers target gift card balance checkers?
Because the checker confirms which card numbers are live and what each balance is worth, for free and at scale. That lets stolen or guessed numbers be sorted by value before any spending, which happens later and quickly.
How can a balance checker be protected without blocking shoppers?
With rate limits set at human pace per IP and session, progressive challenges after a few attempts, uniform error messages that do not reveal whether a number exists, and monitoring for sequential numbers and high failure ratios.
Why should error messages on a checker be uniform?
Different responses for a nonexistent number versus a wrong PIN let an attacker filter a list down to real cards cheaply. A single, non specific message removes that oracle.
What pattern links balance checks to fraud losses?
A surge in balance checks followed shortly by purchases paid entirely in gift cards, often for easily resold goods. Watching checks and spending together reveals one operation that either view alone only partly shows.