Heatrail
Sign in Create account

Concept

How Heatrail works, one property at a time.

Repeat fraud crosses the shop boundary days before it crosses the payment boundary. A payment provider sees the card. A shop sees the basket, the session and the account. Neither of them sees the other shops, so the same trace collects a second loss and a third before anyone joins them up. This section is the machine that closes that gap, written as properties you can check from outside rather than as a specification.

Figure 1

A shop confirms fraud on one order, the traits of that order go hot, and the next shop that sees the same traits gets a warning on its own check. The network tier is separate and needs two independently owned shops.Across the top, three boxes in a row. Shop A, on the left, confirms fraud on one order. A heat coloured arrow leads to a heat coloured box in the middle reading traits go hot, device, IP, hashed e-mail and phone. A second heat coloured arrow leads to Shop B on the right, whose next check returns a warning. Below a rule, the network tier. A sunk box reads one owner, any number of labels, device and IP still warn every Pro shop, and a dashed line runs from it to the words never reaches the network tier. Underneath, a second box reads two independently owned shops confirm the same trail, and a solid heat coloured arrow leads from it to a heat coloured box reading network heat, the only path to it.Shop Aconfirms fraudon one orderTraits go hotdevice, IP, hashede-mail and phoneShop Bnext check returnsa warningthe network tierOne owner, any number of labelsdevice and IP still warn every Pro shopnever reachesthe network tierTwo independently owned shopsconfirm the same trailNetwork heatthe only path to it
What the section explains, in one picture: a confirmed fraud in one shop reaches the next shop's checkout, and the network tier needs two independent owners.

How to read it

Read it from the top. Each article leans on the one before it, and the reading path below groups the twelve into four movements. The glossary at the end defines every term the rest of them use, each with a stable anchor you can link to.

Every article carries the same five headings. The property is one claim. Why it holds is the structure behind it, what was removed and what is required. Verify it is how to check the claim without trusting us, which is the only kind of checking that counts. Five of the articles also carry what it costs to evade, because a fraud control that cannot state its own cost of evasion has not been thought through. Legal footing names the articles of the Regulation the claim rests on.

Weights, thresholds and scoring windows are not published here, and every property below is checkable without them. What an integrator has to build against is documented in full in the API reference and the PHP SDK.

The reading path

First, what the thing is and what it cannot do

  1. Why a shared signal sets out the gap between what a payment provider sees and what a shop sees.
  2. Advisory by construction removes the capability to stop a purchase instead of promising not to use it.
  3. Identity without identities explains why raw contact details never arrive, and why a hashed e-mail address is still personal data.

Then, how one confirmed fraud travels

  1. Trails makes a link a property of history rather than of a person.
  2. Heat, and what cools it gives confirmed harm the only path to a raised score, and time the only ordinary path back down.
  3. Corroboration separates what one shop can raise on its own from the network tier, which needs a second, independently owned shop.
  4. Labels and reversal shows a correction travelling back through everything the original label touched.

Then, what an answer is made of

  1. Reasons you can read ties every score to a rule that can be named and returned.
  2. Why the network cannot be enumerated anchors every check to a real order and answers in categories, never in records.

Last, evidence, deletion and where the strength comes from

  1. Evidence in minutes puts an append-only, nightly signed history behind every incident.
  2. Forgetting on schedule shows how an immutable history and scheduled deletion are both true at once.
  3. Density beats volume explains why the network effect starts at the second independently owned shop rather than the thousandth.

The glossary defines check, trail, heat, label, corroboration, degraded, reason, incident, network heat, operator and score.

Where else to look

  • The integration hub if you are implementing. The WooCommerce plugin, the PHP SDK and the REST API, with the mechanisms this section states as properties.
  • Security and architecture if you are the person who has to sign off on us. The threat model, the ledger and the control framework.
  • The trust center if you are running a procurement review. Sub-processors, residency, retention and the customer-facing disclosure page.

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