When a dispute lands

A dispute response built on purchase history

One PDF answering a fraud chargeback: earlier orders on the store that share identity elements with the disputed one, which elements matched, and which the criteria do not count. It carries no laboratory result.

This is the dispute that costs the most and is argued the worst. It is not about the product, so everything you have recorded about lots and laboratories is beside the point. Sending a certificate of analysis here does not help. It reads as an answer from someone who did not understand the question.

What decides this dispute under Compelling Evidence 3.0 is identity linkage: earlier undisputed transactions by the same cardholder that share identifying elements with the disputed one. The elements are the IP address, a device identifier, the customer account, and the shipping address. The evidence is the store's own order history, assembled from records it already holds.

The chain, assembled from what the checkout already recorded

Every checkout writes an event holding the identity elements at the moment of purchase. So the chain is a query rather than an investigation. It finds the earlier orders on the store that share elements with the disputed one, inside the window the criteria set out. It then shows which elements each one matched on.

Two earlier orders match the one below on IP address, account and shipping address, both inside the window the criteria ask for. The response does not call them undisputed. A store can record the dispute notices its processor sends, so an empty record now reflects what the store recorded rather than the absence of any way to record it. What it still cannot reach is what the criteria actually ask about: the issuer’s own fraud reporting, which goes to the card network rather than to the store. So the response says no dispute was recorded, and leaves the question to the issuer. No personal data appears. Matching runs on fingerprints computed inside the store before transmission, so the underlying email and address are not held here.

A page of a generated dispute response, headed 'Dispute response', showing its 'Linked transactions' section with a table of two earlier orders at 174 and 246 days before the disputed order, each listing matching elements: IP address, customer account ID, shipping address, plus email address and browser user agent both marked 'not counted'. Below it, the consent record for the disputed order and a section headed 'Limits of this evidence'. — The identity chain. Email and user agent are shown and explicitly not counted, because the sources that agree on the four qualifying elements do not include them. Demonstration data: the store and the laboratory are invented and the purity figures measure nothing.

Those two not counted labels are the small decision that makes the rest credible. Counting email would have strengthened every packet this product has ever produced, but the sources that agree with one another on the qualifying elements do not list it. Where sources disagree, the conservative reading is the one encoded, and the disagreement is written down rather than resolved in our favour.

The assessment, with its own hedging attached

The response then states the claim: how many earlier orders, on which elements, inside which window, and whether that meets the criteria. In the same paragraph it adds, immediately, that these are the criteria as this store understands them. Whether the order qualifies is the issuer's determination, not the document's.

It also names which reading it applied. “Two matching elements” has a strict reading, where the same two elements match across every transaction counted, and a looser one, where each transaction matches any two. The strict reading is the default, because a claim that holds under it holds under either. Where the strict reading fails and the loose one would pass, the response says so and names the transactions.

A page of the dispute response headed 'The linkage claim', stating two earlier transactions with no dispute recorded by this store share the same IP and shipping address, placed between 174 and 246 days before the disputed order, and that on the Compelling Evidence 3.0 criteria as this store understands them the order meets those criteria, followed by 'Whether it qualifies is the issuer's determination, not this document's'. Sections follow headed 'How these criteria were applied' and 'Points this store could not settle'. — The claim and its qualifications, on one page. The section naming open questions is part of the document, not a footnote we hope nobody reads. Demonstration data: the store and the laboratory are invented and the purity figures measure nothing.

The weakest part, printed in the packet

The plugin captures a device identifier at checkout, from version 0.4.0, and it cannot be added to an order after the fact. So until your own orders carrying one are more than 120 days old, every qualification rests on the IP address alone — the most volatile of the four elements. Mobile networks, carrier-grade NAT and VPNs all change an address between two orders placed by the same person. Where an element was never recorded for an order, the response says it was not captured rather than reporting a mismatch. Those are different statements.

So the response states this in its own section, in the same type as everything else. An element that was never captured is reported as not captured, never as a mismatch, because only one of those is true here.

A section of the dispute response headed 'Elements not captured by this store', stating that a device identifier was not captured for this order so it is neither matched nor counted, that this is a gap in what was captured rather than a mismatch, that no comparison was performed on it, and that nothing below should be read as one. — Four lines, and the reason this page is worth trusting. The disclosure disappears on its own once your orders carrying a device identifier are old enough for the criteria to count them. Demonstration data: the store and the laboratory are invented and the purity figures measure nothing.

One further limit, stated in every response. This system stores no card, BIN, last four digits or payment-method identifier, so whether the earlier transactions were on the same card cannot be answered from its data. The linkage establishes a shared customer identity, and the document says exactly that rather than the stronger thing it would be convenient to say.

The device identifier is the element that would carry the most weight here, and the plugin already records one at every checkout. What it cannot do is reach backwards. An identifier is written by the checkout that placed the order, so an order placed before the plugin was installed has none. Until a store’s own orders carrying one are old enough to fall inside the window the criteria set, the element is captured and cannot yet be counted.

That resolves itself with time rather than with work on our side. The disclosure above is computed for each response rather than written into a template. It stops printing on its own once the orders behind a claim are old enough to count.