Card Testing Log Analysis: A Comprehensive Guide
Learn how to effectively analyze card testing logs for accurate and secure transactions.
Redeem your gift cards at any of our Merchants
You can purchase a gift card from any of these locations
Onyx Gift Cards is a Grenadian company designed to introduce, market and manage gift cards systems in Grenada for retailers and corporations. We are enthusiastic about the effect and influence we will have on the local market. We intend to expand our systems regionally with a range of product offerings and services.
Gift cards are the preferred way of giving and receiving gifts. They carry a monetary value that can be redeemed for gifts at your favorite store.
Onyx GiftCards are “Open Gift Cards” which means that they can be redeemed at multiple merchant locations. They are standard credit card size, can fit into the average wallet and made of PVC plastic. Onyx GiftCards are Barcoded for security and safety for the consumer and bear a disclaimer at the back.
Onyx Giftcards can be bought with a branded Card backer which is black in colour and is designed to fit the card. There is an area to write a brief message to the recipient as well.
Card testing log analysis techniques are the methods fraud and security teams use to find the small, repeated authorization attempts that reveal someone validating stolen card numbers. The work starts with payment gateway, web server, and application logs, then narrows on velocity, response codes, and shared fingerprints across many attempts. Good log analysis turns a flood of failed transactions into a short list of indicators you can act on.
A card testing run rarely looks like normal shopping. The pattern is many attempts, few completed orders, and a strong preference for the cheapest item or a donation field. Because the attacker only needs an approve or decline answer, sessions are short and shallow.
No single log tells the whole story. Correlating a few sources gives you the context that separates an attack from a run of honest mistyped cards.
Count attempts over sliding windows and group them by IP, subnet, device ID, account, email, and BIN. Attackers rotate one attribute while holding another steady, so a matrix of counts by pair often exposes them faster than any single dimension.
Sort authorization results by response and reason code. A burst of declines concentrated on one code, especially one that signals a closed account or a mismatch, is a strong signal. Compare the decline rate on the checkout endpoint against the site-wide baseline.
Legitimate customers draw from a wide spread of issuers. A test run often leans on a handful of BINs because the attacker bought or generated numbers in blocks. Track issuer diversity per hour and flag sudden narrowness.
Look at inter-arrival times between attempts. Scripted runs often show tight, regular intervals, or a fixed delay that holds across hundreds of requests. Human shoppers are far more irregular. Plot a histogram of gaps and check for a spike at a single value.
Group sessions by IP, ASN, autonomous system owner, device fingerprint, user agent, and TLS handshake characteristics. Attacks frequently reuse a hosting provider range even while changing the visible IP. Cluster analysis surfaces that reuse.
Map which endpoints each session touches and in what order. Testers skip the browse and cart stages and call the authorization or order API soon after landing. A session that reaches payment in a few seconds with no product views stands out.
Start from your own baseline rather than generic numbers. Measure the normal hourly distribution of authorization attempts per IP, per device, and per BIN, then set a threshold at the far tail of that distribution. For example, a rule that fires when one IP produces more than a dozen distinct card attempts in an hour may suit a small merchant and be far too loose for a high-volume one.
Layer rules. A single signal should not page anyone. Two or three weak signals together, such as high velocity plus an unfamiliar ASN plus a shallow session, justify a closer look.
Once a pattern is confirmed, respond at the layer that costs you least. Rate limit the endpoint, challenge suspicious sessions with step-up verification, require the security code and address verification on first orders, and block the network ranges that keep reappearing. Keep a record of what you blocked and why, so you can revisit decisions after the traffic shifts.
Keep authorization and application logs long enough to trace a pattern backward, and store them somewhere searchable. Card testing campaigns return with the same tooling, so a short written summary of each incident, with the fields and thresholds that caught it, is often the most useful artifact your team produces.