SellstampFraud shield
Two hashed facts, five flags,
and exactly one rule that blocks.
There is no risk score here, because there is no arithmetic worth doing with these facts: three flags are three separate things to think about, not a score of three. Every one of them is surfaced to a human who decides — with one exception, which has a clock as its reason.
Order · risk flags
Shared device
4 addresses on this device in 7 days
Provider spread
3 providers from this address
Two flags, no total. The order is paid and the buttons are yours.
The five flags
Each is a plain function of stored facts with a sentence saying what it means. Every threshold below is a calibration knob reasoned about against the shape of this platform — not fitted to observed traffic, because a household, a shared office and a fraud ring can all produce the same row.
- Shared device
- Three or more distinct customer addresses on the most-shared of this customer's device hashes, inside a seven-day window. Grouped per hash and taken at its peak, so a shared laptop and a shared office are two ordinary facts rather than one three-address ring.
- Shared network
- Four or more addresses on one network hash in the same window. The bar is higher than the device's because a public address is shared by whole buildings, carriers and VPN exits.
- High refund rate
- Half or more of this customer's paid orders refunded, once there are at least three paid orders — below that a rate means nothing.
- Lost dispute
- This customer has had a chargeback decided against you before.
- Provider spread
- Three or more distinct payment providers used from one address.
What is collected, and what is not
- Two facts, both hashed before they are stored
- A fingerprint the customer's own browser computes from standard APIs, and the address the request already arrived with. Both are HMAC'd under a key used for nothing else, so one purpose's secret can never unlock another's hashes, and nothing raw is ever written down.
- Ninety days, then gone
- Swept hourly, and sooner on request — a customer's own erasure deletes their rows outright rather than leaving them to run out the clock. Ninety is above the window the correlation rules use and above the span most card disputes arrive in, and below anything resembling indefinite. The honest cost: a dispute landing on day 100 finds no device signal left.
- You can switch it off
- One setting turns collection off for your store entirely. It is an opt-out with a stated cost — the card-testing refusal counts these rows, so a store with none can never trip it, and turning collection off turns that defence off too.
- A customer who cannot be fingerprinted still buys
- A restricted browser, a canvas-blocking extension or a hardened build simply sends nothing, and the checkout proceeds exactly as it always did. Being measurable is never a condition of purchase.
- Nothing leaves
- No Radar, no Sift, no MaxMind, no hosted fingerprinting service and no model. The fingerprint is computed by the page; the address is the one the request came with.
The one rule that refuses a checkout
Every rule above describes a shape that takes hours or days to form, so a merchant reading a flag the next morning is a perfectly good response. Card testing does not work on that clock: a scripted run fires hundreds of small authorisations in minutes to find which stolen numbers are still live, and by the time anyone reads a notification it is finished.
- What trips it
- Fifteen checkouts from one browser, or fifty from one network, at one store, inside ten minutes. Nobody buys fifteen times in ten minutes; a customer retrying a declined card does it three or four times.
- What it blocks
- That device or that network, at that store, for a few minutes. Nothing here reads or writes your store's status — automated code does not get to take a merchant's storefront offline on a heuristic.
- How long
- Five minutes, doubling on each repeat trip to a cap of an hour, and remembered for a day so the ladder has a memory. An operator genuinely retrying is long since done; a script is talking to a door that opens less and less often.
- What the person sees
- A 429 with a sentence and a Retry-After — not a mysterious error and not a silent failure. Somebody who trips this from a shared office needs to know it is temporary and roughly how temporary.
- Nothing new is collected for it
- It counts the same rows the flags use, over a much tighter window. No card number, no BIN, no challenge, no third party.
Your own rule holds the goods, not the payment
“Hold orders over €500 from a new device” can be read two ways, and the difference is the whole design. Read as refusing the checkout, a false positive is a legitimate buyer's purchase declined at the till, on a threshold you typed, for a condition with no clock on it. Read as holding the delivery, you get what you asked for and the customer does not pay for the mistake.
Two conditions, not a rule language
An amount, and optionally “only devices this store has not taken a payment from”. Set the amount to zero if you want every new-device order reviewed. There is no expression evaluator and no user-authored predicate.
The order still charges
It settles and reaches paid down the paths it already took. What waits is the download grant, the licence key, the parcel — which is the thing you were actually worried about.
“New” means the last ninety days
Because signals are swept at ninety days, and a prior sighting only counts if it paid. A customer who last bought a year ago is new again, and the setting says so rather than implying a memory this store does not have.
An unmeasured order is not a new one
An order with no fingerprint at all is never held on that condition. Being fingerprintable is not a condition of being delivered to.
One choke point
The check runs inside the one function that answers “may this order be delivered”, so every path — the worker, your test purchase, the approval screen — is covered by construction.
The cost, stated
You take on a payment you may end up refunding, and your provider may keep its fee on that refund. That is a real cost, paid by the party who chose the rule.
And the platform's own desk
Some shapes are only visible above one store. Sellstamp staff see correlations across merchants — and see them as facts to read, not buttons to press.
- Cross-store clusters
- One device seen at four or more shops, or one network at six or more, inside three days. There is no button on those rows: nobody filed them, they name no listing to take down, and next week's query simply will not return them. Acting on one means opening the store and using the tools that already demand a typed reason.
- A payout change buys a day
- Changing where an existing connection's money lands pauses that connection for 24 hours. Step-up proves someone knew the password a minute ago; it cannot tell a stolen session from its owner, and a day is the window in which the alert already sitting in your inbox can be read and acted on. Your other connections are untouched, and a first-ever connection is never held.
- A staff hold is not a timer
- The 24-hour hold expires by being in the past, so a stopped worker cannot leave a store frozen. A hold a staff member places expires only when a named person clears it with a typed reason — because “a human needs to look at this” is not something a clock can decide it has done.
- Disputes keep their deadline
- When a provider reports a chargeback, its own words are kept unmapped beside Sellstamp's three-value summary, and the evidence deadline is the one field of the evidence block that is stored — missing it is an automatic loss, and a merchant who is not told a clock exists cannot beat it.
Limits worth knowing before you build on it
What this does not do
- No risk score, no weighting and no sum. Flags are separate facts, and nothing anywhere adds them up.
- No automatic blocking outside the card-testing rule. Not on amount, not on country, not on a flag, not on a pattern.
- No geolocation of any kind. There is no IP-to-country table and no region on any event, so nothing here can say where somebody was.
- No third-party fraud service and no machine-learning model. Two hashed signals, counted.
- No indefinite retention, and no waiting for the clock. Ninety days is the ceiling; a customer who erases their data with the store takes these rows with them on the spot, from a portal link, with no support ticket and no merchant in the loop.
Open a store and try it.
Everything on this page is in the product today. Connect a provider in test mode and put a real order through it before you decide.