Reading your checkout events after an attack

The attack has stopped, or at least slowed. You have a CSV of checkout events and a spreadsheet open. Now you need to know what happened, whether your rules held, and whether any real buyer got caught in the middle.

This note is a reading guide for that file. Column names differ between tools, so treat the fields below as types of information to look for, not exact headers.

Start with the shape of the file

Before reading single rows, get the outline. Sort by time and note the first and last events of the attack. Count rows per hour across that window and the day before it. A normal day gives you the baseline, and the attack shows up as a block of hours far above it.

A spreadsheet pivot table or a few lines of code will do this. Here is a quick version with Python and pandas:

import pandas as pd

df = pd.read_csv('events.csv', parse_dates=['time'])
# events per hour, split by outcome
print(df.groupby([df['time'].dt.floor('h'), 'result']).size().unstack(fill_value=0))

Change time and result to whatever your export calls them.

Fields that matter most

Time

Bots keep steady intervals or burst in tight clusters. Real shoppers spread out. Look at the gap between consecutive events in the attack window. Gaps of exactly the same few seconds, or dozens of events inside one minute, point to a script.

Result or action

This tells you what the rule did: allowed, blocked, or logged in monitor mode. During an attack, most events should be blocks. If allowed events climb at the same moment as blocks, some attempts are passing your checks.

Score

If the tool records a reCAPTCHA v3 score, plot how many events fall at each score. Bot traffic usually piles up at the low end. If many attack events sit near or just above your threshold, the attacker may be tuning to pass, and a small threshold change could help.

Route

Note which checkout route each event came from: classic checkout, Checkout block, pay-for-order, or add payment method. Attackers often switch routes when one is blocked. If blocks on the classic checkout drop off and events on another route start right after, that is the same attacker moving.

Gateway

Card testers pick a gateway that does a real card check. If one payment method dominates the attack events, consider tighter rules on that gateway only, and leave the others alone.

IP or IP bucket

Many tools hash or shorten IPs for privacy, which is fine for this job. You only need to know whether events share a source. A handful of sources with hundreds of events each suggests a simple script. Hundreds of sources with a few events each suggests a proxy network, where per-IP limits will not help much.

Email or email digest

Repeated emails, or repeated digests if emails are hashed, show the same identity trying over and over. Random new emails on every event show a script generating them.

Questions to answer

1. When did the attack start and end, and was it one run or several?
2. How many attempts did your rules block, and how many got through?
3. Which route and gateway did the attempts use?
4. Did the attacker change approach partway through, such as a new route or more sources?
5. Did any real buyer get blocked during the window?

The last question takes the most care. Filter for blocked events in the attack window, then match them against your order list and customer emails. A blocked event followed by a successful order from the same email a minute later is a real buyer who retried. That is a sign your threshold might be a little strict.

Match events against the gateway

Your events file shows what reached your site. Your gateway dashboard shows what reached the card network. Compare the counts for the attack window.

If the gateway shows far more declines than your file shows allowed events, some attempts took a route your tool does not log. Check for another checkout page, a payment plugin endpoint, or the add payment method page. If the counts line up, your logging covers the routes that matter.

What to change afterward

• If attempts passed with scores just above the threshold, raise it slightly and run in monitor mode for a few days to check real buyers.
• If one gateway took all the traffic, add rules for that gateway.
• If the attacker moved to a route you did not protect, protect it or block it.
• If the file covers less time than the attack, extend the retention or export more often during an incident.

Save a copy of the export with the date in the file name. If a gateway or acquirer asks what happened, a clear timeline with counts helps that conversation.

Where Checkout Bouncer fits

Checkout Bouncer keeps an events log with seven-day stats and a CSV export. The logs are anonymized: throttle buckets are hashed, emails become salted digests, and a daily purge clears old entries. You can still tell repeat sources apart, which is what the steps above need. Because of the purge, export the file during or right after an attack.