What does gift card fraud bot traffic look like in a store's logs?
Gift card fraud bots do not browse. They hammer the balance-check endpoint with generated codes, thousands of requests from rotating IPs, at inhuman speed. The pattern is unmistakable once you know the signature.
The target is the balance checker, not the checkout
Most bot attacks aim at the checkout: card testing, scalping, credential stuffing. Gift card fraud is different. The target is usually the gift card balance-check endpoint, the quiet little form where shoppers type a code to see how much is on their card. Attackers feed it generated or stolen codes by the thousand, looking for cards with remaining balances to drain.
In the logs this looks like a flood of POST requests to a single endpoint, often /gift-card/balance, /check-balance, or an equivalent API route, with almost no other pageviews around them. A normal shopper checks one or two cards after browsing the store. The bot checks hundreds per minute and never looks at a product. The ratio of balance checks to pageviews is the first and loudest signal: when it inverts, you are under attack.
The requests are fast and regular. Human typing produces irregular intervals; bots produce metronomic ones. Look for request timing with suspiciously even spacing, dozens of attempts per second sustained over minutes or hours. Rate alone is diagnostic: no human checks gift card balances forty times a second.
The codes follow a pattern
Gift card codes have a structure: a fixed prefix, a set length, a character set. Fraud bots generate candidates that match that structure, so the attempted codes in your logs will share a format. Pull the attempted codes from the logs and look at them as a set. Real customer typos are random. Bot-generated candidates show structure: sequential runs, shared prefixes, systematic character rotation.
Watch the failure rate. A legitimate balance checker sees mostly successes with occasional typos. Under attack, the failure rate spikes toward total: thousands of invalid codes for every valid one. That ratio is the second signature. A balance endpoint suddenly returning 99 percent invalid-code errors is not a UX problem. It is an attack in progress.
Also watch for code reuse across IPs. The same candidate codes appearing from different IP addresses in rotation means a distributed operation working through a shared list. A single IP hammering is easy to block. A rotating pool sharing a code list is the professional version, and it needs a different response.
The infrastructure gives it away
Gift card fraud bots run on the same infrastructure as other fraud bots: datacenter IPs, often from hosting providers rather than residential ISPs, rotating through large pools. Check the ASN distribution of the balance-check traffic. A sudden surge from ASNs associated with cloud hosting, especially ones that never appeared in your normal traffic, is a strong indicator.
Headers tell the rest of the story. The requests often carry identical or near-identical user agent strings across thousands of requests, or user agents that do not match the claimed browser's other headers. Missing or static cookies across a high-volume session is another tell: real browsers accumulate cookies, bot sessions often start fresh every time. None of these signals is conclusive alone. Together they form a fingerprint that is hard to mistake.
Geography can help but do not rely on it. The IPs will often geolocate to countries unrelated to your customer base, but sophisticated operations route through residential proxies in your target markets. Treat geo as supporting evidence, not as a blocking rule, unless the mismatch is extreme and sustained.
What to do when you see the signature
First, rate-limit the balance endpoint aggressively. This is the rare case where strict rate limiting is clearly correct: no legitimate use case requires checking dozens of gift card balances per minute from one client. A tight per-IP and per-session limit stops the casual attacker immediately and forces the sophisticated one to slow down enough to become visible.
Second, add friction that humans pass and bots fail: a CAPTCHA on the balance form after a small number of attempts, or a requirement to solve a challenge before the endpoint responds. Balance checking is infrequent for real customers, so the friction cost is low and the bot cost is high. Consider also masking the response: return the same generic error for invalid codes and rate-limited requests, so the bot cannot distinguish 'wrong code' from 'blocked,' which degrades the value of its code list.
Third, alert on the signature, not just the volume. Build a monitor for the specific pattern: balance-check to pageview ratio, invalid-code rate, and code-format clustering. Volume-based alerting misses the slow, distributed version of this attack. Signature-based alerting catches it on day one. Gift card fraud is quiet compared to card testing, but the losses are real: every drained card is revenue walking out the door, and the logs always showed it coming.