The pattern
Stamp every order with its identity
At each purchase, persist the visit’s
VisitorID, DeviceID, and UserHID next to the order record. This is the snapshot of who bought, captured at buy time, that you replay later.Wait for the dispute
Nothing happens until a chargeback arrives. The evidence sits in your own database, costing nothing, until you need it.
Reconstruct the buyer's history
When a dispute lands, pull that buyer’s prior visits from the History API by
user_hid or device_id, newest first, to show the disputed order and the undisputed ones came from the same device.Step 1: store the identity at purchase
The real-time score belongs to the checkout recipe. Here the only extra work is durable: when the order is confirmed, save the three identifiers from that visit’s scored result alongside the order. The shared webhook-cache helper (waitForScore plus scoreCache) already hands you these fields, so this recipe shows only what to persist.
order-stamp.js
The
DeviceID is server-derived, durable, and bound to the browser that made the visit. It is the field that gives the evidence its weight: a returning buyer on the same browser keeps the same DeviceID across sessions, which is exactly the continuity a dispute response wants to demonstrate.Step 2: reconstruct the buyer on dispute
When the chargeback notification arrives, look up the disputed order, then query the History API for that buyer’s other visits. Search byuser_hid to gather every visit tied to the account, or by device_id to gather every visit from that exact device. Both come back as an array of snapshots, newest first.
dispute-evidence.js
Score and its Details (an array of { Value, Description }), the DeviceID, VisitorID, UserHID, IP, Country, Browser, DeviceType, and LastRequestTime. Read the Score and each detail’s numeric Value, never the human-readable Description label, which can change. A run of clean or low scores from one device, across the disputed order and earlier undisputed ones, is the pattern that makes the package persuasive.
Step 3: export the evidence package
You do not have to script the export at all. The dashboard Data tab lets you search byuser_hid, visitor_id, or device_id, filter by date and score, and export the matching rows to CSV or JSON for free. That export is the attachment your dispute team hands to the processor. For an automated pipeline, serialize the rows from Step 2 into the same CSV or JSON your representment workflow expects.
A package that holds up tends to show, side by side:
| Evidence in the export | What it argues |
|---|---|
Same DeviceID on the disputed order and prior orders | The same physical device made the purchases, not a stranger. |
Consistent Country across those visits | No sudden geography change that would suggest a stolen card. |
Clean or low Score on each visit | None of these purchases carried strong anonymity signals. |
| Earlier orders that were never disputed | A pattern of legitimate use from this device. |
LastRequestTime spanning weeks or months | A relationship, not a one-off hit-and-run. |
What this evidence is, and is not
Device continuity is supplementary evidence. It strengthens a representment; it does not stand alone, and it is honest about its limits.- It is not proof of identity. A
DeviceIDties activity to a browser on a device, not to a named person. The same household member or a borrowed laptop produces the sameDeviceID. - A different browser or device is a different
DeviceID. A genuine buyer who switched laptops between purchases will not show device continuity, and its absence is not proof of fraud. - ShieldLabs does not decide the dispute. It supplies the device record. Your team writes the representment and the cardholder’s bank rules on it.
Next
Checkout protection
The real-time half: score the payment before the charge and gate it on the band.
Account takeover
Catch the new-device login that often precedes the fraudulent purchase in the first place.