Heatrail

Product

Heatrail answers inside the checkout and decides nothing.

An order arrives. Your server hashes the contact details, asks Heatrail, and gets a score and the reasons behind it back inside an 800 ms budget. This page follows that path from your checkout to the network and back. The integration itself, the plugin, the SDK and the REST API, is in the docs.

01

The check

The answer arrives inside the budget, or the order goes on without it.

Your server hashes the e-mail address and the phone number with a keyed hash before the request leaves. The raw values stay in your shop. Heatrail hashes that digest a second time with argon2id, 12 MiB of memory per attempt, under a key that never leaves our servers, and stores the second value only.

The call has 800 ms. Inside it your checkout has a score and the reasons in plain words. Outside it your checkout stops waiting, the order goes through without a signal, and the check goes to a queue. The capability to stop, delay or cancel a purchase is not in the system.

On the first working day in production, 1 September 2026, the median round trip was 386 ms, the 95th percentile 610 ms, and the slowest check finished at 799 ms. In a staging drill with the service made unreachable on purpose, checkout finished in 16 ms.

Figure 1

The request leaves your server already hashed, the answer comes back inside an 800 ms budget, and past the budget the order goes through without a signal.A box on the left reads your shop server, first hash with HMAC, and says the raw e-mail and phone never leave it. A solid arrow to the right carries only the hashed digest to a box labelled Heatrail, which reads argon2id, 12 MiB, second hash under a key that never leaves. A second solid arrow returns to the shop carrying the score and the reasons. Between the two arrows stands the number 800 ms, the budget. A dashed line drops from the shop box to a wide box below, reached when nothing arrives inside the budget, which reads that the order goes through without a signal and the check goes to a queue. A line at the foot gives the first working day in production, median 386 ms, 95th percentile 610 ms, slowest 799 ms.Your shop serverfirst hash, keyed HMACraw e-mail and phonenever leave this boxHeatrailargon2id, 12 MiBsecond hash, under a keythat never leaves the serverhashed digest only800 msthe score and the reasonsnothing arrives inside the budgetThe order goes through without a signalThe checkout never waits past the budget. The check goes to a queue.First working day in production: median 386 ms, 95th percentile 610 ms, slowest 799 ms.
The raw contact details stop at your server, and the budget stops the wait.
02

The network

A fraud one shop confirms is a warning in the next checkout.

A fraud label makes the buyer's device and IP hot for every Pro shop at once. An e-mail address or a phone number, which anyone can type in anyone's name, carries full weight elsewhere once it is verified or tied to that same device.

Above that sits the network tier, the statement that a trail is known across the market. It is written when two independently owned shops confirm the same trail, and there is no other way in. One owner does not reach it, however many labels that owner sends.

Signal records are deleted after 90 days. The derived risk memory runs on a published curve: full weight to day 90, down to a third by day 365, and the record is gone on day 400.

Figure 2

One shop confirms a fraud, the buyer's device and IP turn hot for every Pro shop, and the next checkout elsewhere already carries the warning. The network tier above that needs two independently owned shops.In the top row, a box labelled Shop A confirms an order as fraud. A heat coloured arrow runs to a heat coloured box reading device and IP, hot for every Pro shop. A second heat coloured arrow runs on to a box labelled Shop B, whose next checkout carries the warning. Below a dividing line, two rows show the tier above. One owner, with any number of labels, is joined by a dashed line that ends in a cross, so the path does not happen. Two independently owned shops confirming the same trail are joined by a solid heat coloured arrow to a heat coloured box labelled network tier, known across the market.one label, and the next checkout elsewhere already knowsShop Aconfirms an order asfrauddevice and IPhot for everyPro shopShop Bthe next checkoutcarries the warningand the tier above itOne ownerany number of labelsTwo independent ownersconfirm the same trailnetwork tierknown across the market
One label reaches every Pro checkout at once. The tier above it needs a second owner.
03

The mechanism

One property, one article.

Twelve articles, each stating one property of the system and how to check it from outside. They are in an order and each leans on the one before it.

01

Why a shared signal

Repeat fraud crosses the shop boundary days before it crosses the payment boundary. A shop sees the basket, a payment provider sees the card, and neither sees the other shops.

02

Advisory by construction

The degraded response is the same code path as the healthy one, which is what makes the advisory promise structural rather than a policy we could revise.

03

Identity without identities

The value we hold is not the value your shop computed. A hash of an e-mail address is still personal data, and it is handled as personal data.

04

Trails

A link is a property of history, not of a person. Traits that appeared together in confirmed harm stay linked, and a fresh trait that touches them inherits the link.

05

Heat, and what cools it

Only confirmed harm creates heat. Time cools it, and so does replacing every trait at once. Partial replacement is itself a pattern.

06

Corroboration

Device and IP travel on one label. A typed e-mail or phone has to be corroborated first, and independence is decided by an operator rather than by the shop making the claim.

07

Labels and reversal

A real label creates nothing. One label is active per order, and a correction propagates back through everything it touched.

08

Reasons you can read

A score comes from a rule that can be named. There is no machine learning in the scoring path. A person decides what happens to the order.

09

Why the network cannot be enumerated

Every check is anchored to a real order, and an answer is a category rather than a record. The one bulk exception is a single history scan per Pro shop, at most 250,000 rows, written down as the ceiling it is.

10

Evidence in minutes

An append-only history, signed nightly, sits behind every incident, and the memo for the authorities is read and sent by a person. Minutes, not weeks.

11

Forgetting on schedule

A scheduled job deletes signal data after 90 days. An active incident holds a record and a reversal releases it, so an immutable history and deletion are true at the same time.

12

Density beats volume

A small, dense market gives a cross-shop signal disproportionate power. The network effect starts at the second independently owned shop, not the thousandth.

Read the library in order

04

What it rests on

The parts a reviewer asks about first.

Hashed identifiers are personal data
We process them as your processor, on your instructions, under a data processing agreement, in the EU.
Controls mapped to OWASP ASVS Level 2
Each control names the code that implements it and the test that proves it.
Three ways in
A WooCommerce plugin, a PHP SDK with no dependencies that runs on PHP 7.3 to 8.5, and a REST API. Every request is signed with an HR1 HMAC over a canonical string.

The security architecture in full

Heatrail

This site is not public yet

Heatrail is in a private pre-launch period. Enter the access password to continue.

Enquiries: hello@heatrail.eu