Labels and reversal

A shop that has been defrauded gets to say so. A shop that was wrong about it has to be able to say that too, and the retraction has to travel as far and as fast as the accusation did. Three labels, one of them active at a time, and what happens to everything a label caused when the shop that applied it takes it back.

The property

Three labels exist: fraud, chargeback and real. One label is active per order at a time, and a newer label supersedes the older one. A real label creates no heat of any kind. A reversal propagates through everything the earlier label touched, so a mistake made in one shop does not follow a customer around.

Why it holds

The Friday a shop gets it wrong

Picture a shop on a Friday afternoon with orders to clear before the weekend. One looks wrong: a delivery address that does not match the billing address, a young account, a large basket. Someone in dispatch has seen that shape before, applies fraud, and moves on.

On Monday the customer telephones. They moved house in the spring, the bank still has the old address, and the explanation is as dull as it is true. The shop is now the origin of a claim about a person that is not correct, and unlike a note in its own back office, this claim has left the building.

What the shop does next is the point. It opens the incident, reverses it, and applies real. No support ticket, no permission, no waiting for a review. The reversal is the same endpoint as the label, with the same key, taken by the same shop, because the shop is the controller of the claim. A system in which the accusation is self service and the retraction goes through a queue should not be trusted with the accusation.

Supersede rather than accumulate

Labels replace each other. There is one active label on an order at any moment, and the newest one is it, so the question "what does this order say now" has one answer rather than a history to be totalled up. If labels accumulated, a shop that was hasty three times would out-weigh the shop that was careful once. There is no arithmetic in which three careless labels beat one careful correction, because there is no arithmetic here at all. Re-sending a label that is already active re-affirms it but does not deepen it.

Supersede is not always a retraction. A shop that labelled an order fraud and later received a formal dispute can move it to chargeback, a supersede in which the evidence improves rather than disappears. The other direction is deliberately not a plain supersede: a cleared order must be reversed explicitly before it can be labelled again, so that clearing a customer is never undone by accident.

One of the three behaves differently in the market than on the wire. chargeback is a label the API accepts, and it creates heat exactly as fraud does. In the market this product was built in, a dispute arrives by e-mail and ends as a movement on a bank account, so there is frequently no clean machine event to hang a label on. Shops therefore tend to apply fraud with the reason code chargeback_received, which carries the same meaning without asserting an event that did not happen. A shop whose provider does emit a dispute event should use chargeback, and it behaves exactly as documented.

A cleared order is an eraser, not a colour

real creates no heat of any kind. Not a small amount, not a negative amount, none. Only fraud and chargeback write heat. real writes the absence of a claim. If clearing an order could itself move a number in either direction, clearing would be a lever, and a shop that wanted to launder an identity would have been handed one.

The label exists for two reasons. The first is correction: a shop that got it wrong needs a way to say so that is as easy as getting it wrong was. The second has no mistake in it. A returning customer whose orders keep looking unusual for dull reasons, a forwarding address or a company card, is a customer this shop has already thought about once. Writing real records that judgement, so the next person working the queue inherits a decision instead of starting again from the same raw shape.

Figure 1

Labels replace each other, the last word wins, and the last word can be real. The newest chip is the only solid one, and it carries no colour at all.

A reversal reaches the consequences, not just the record

A correction that stopped at the record would be bookkeeping. A reversal propagates back through what the label caused: the heat it wrote for that shop, and whatever it contributed to what other shops could see. Claim and effects travel together, because a correction that leaves the effects in place is not a correction.

It also lifts something less visible. An active fraud claim is a thing a shop may have to defend, to a bank, a customer or an authority, so the records behind it are held past their ordinary expiry. That hold is an exception to ordinary erasure and it lasts exactly as long as the claim does. Reverse the label and the exception goes with it, and the records fall back onto the ordinary schedule described in forgetting on schedule. That is the sense in which being corrected is structural rather than promised: not an undertaking to tidy up later, but the removal of the thing that was holding the records in place.

Every label is a ledger event, carrying who applied it, a field the API requires the shop to fill in itself, and when. A reversal is another event, with its own actor and its own time, written after the first rather than over it. What the order claims changes, but the history of what was claimed, by whom, and when, does not.

Verify it

Check this on a test order with a label-scoped key. Label an order, label it again, then read the incident back. There is one active label, and the second call stacked nothing on top of it.

# 1. label the order
POST /v1/labels
{ "order_ref": "ord-10241", "label": "fraud", ... }

# response: one incident, one active label
{ "ok": true, "incident_id": "b4e1c7d2-...", "label": "fraud", "status": "active" }

# 2. same order, same label, sent again
POST /v1/labels
{ "order_ref": "ord-10241", "label": "fraud", ... }

# the same incident. Not a second one, and not a deeper one.

# 3. now correct it
POST /v1/labels/{incident_id}/reverse
POST /v1/labels
{ "order_ref": "ord-10241", "label": "real", ... }

# read it back in the portal: one active label, and it is real.

The payloads, the required fields, what a repeated label returns and the error you get for applying fraud over an order that has already been cleared are in the API reference, under POST /v1/labels and the reversal endpoint beside it. That is the contract. This page is the reasoning behind it.

Legal footing

Reversal is the mechanism behind Article 16 GDPR, the right to rectification, and behind Article 5(1)(d), the accuracy principle, for a signal that is shared between shops. A correction made in one shop reaches every consequence of the original label, which is what makes accuracy a property of the system rather than a duty owed by each shop separately. Reversal is rectification and not the right to object, and the two are worth keeping apart: an objection under Article 21 is an objection to the processing itself, which obliges the shop as controller to stop unless it can show compelling legitimate grounds that override. Both are exercised through the shop, and the shop can reverse its own label at any moment without asking the processor. A reversal also ends the Article 17(3)(e) basis, the establishment or defence of legal claims, that was holding the records past their ordinary retention, so erasure resumes on the schedule described in forgetting on schedule. See the data processing agreement.

Heat and what cools it, on what a fraud label creates, and what makes it go away without a correction.
Corroboration, on what one shop's label reaches in other shops on its own, and what it never reaches.
Forgetting on schedule, on the clock a reversal hands the records back to.