How a record is calculated

Methodology · v1.1

The same rules for every store. Every change is versioned and published.

Principles

Only facts from sources the store does not control. Disputes opened by the buyer's bank, transactions from the payment processor and timestamps from the platform's own system. Never reviews, tags, notes or data from apps the store has installed.

No volume figures. Volume is published only in bands rounded down ("more than 50,000"), never the exact figure nor counts it could be inferred from.

Only corroborated payments. Orders charged through a payment processor count. An order marked as paid by hand (manual cash bogus cash on delivery (cod) bank deposit money order) proves nothing and counts towards no metric.

Records from before installation. They are used going back up to 18 months, only from records the store cannot rewrite, and every record says so.

The "Verified store" status

A store is shown as verified when its observed rate of service-related bank disputes stays below the public threshold of 5 per 1,000 orders, with at least 200 orders measured. The minimum is 1 divided by the threshold: with fewer orders, a single dispute already reaches it and the percentage means nothing. The rule is the same for a store with 400 orders as for one with 50,000. The confidence interval is published in every record for reference, not as a filter. If the rule is not met, the store is shown as "under observation" and its figures remain public.

Exit criterion. If a verified store stops meeting the rule, it keeps the status for 30 days and the record declares it "under review". If it still does not meet the rule at the end, it moves to "under observation".

For reference: the Visa (VAMP, Europe) and Mastercard (ECM) monitoring programmes start at around 15 per 1,000 counting every dispute, fraud included. This threshold counts service reasons only, which makes it several times stricter, and it applies to small stores too.

Purchases disputed with the bank

Refunds money

Refund records where the money went back through the same processor it was charged with, measured against every one of the refund records in the window. These count as "no money proven": store credit (shopify_store_credit gift_card), vouchers or codes issued by apps outside the processor, exchanges, failed attempts and refunds through processors with no corroboration (manual cash bogus cash on delivery (cod) bank deposit money order). That way no voucher can be left out of the percentage. A window of 90 days; it is published with at least 10 records.

A "Yes" requires two proofs. First: bank disputes for refunds not processed (CREDIT_NOT_PROCESSED) stay below the public threshold of 2.5 per 1,000 orders (observed rate, with at least 400 orders measured). Second: the store really does refund money, with at least 3 refunds that returned money to the original payment method and that account for at least 10 % of all the refund records. That bar is deliberately low: offering a voucher the customer accepts is legal and is not penalised. If either proof is missing, the record shows "Unconfirmed", never "No"; with fewer orders or refunds, "Not enough data".

Other figures in the record

Orders charged: orders charged through a payment processor in the last 365 days that still stand (not cancelled, not fully refunded, and shipped), in bands. Cancellations: measured against the orders of the last 365 days. Order preparation: median from the order to the first recorded shipment, over a 90-day window ending 14 days before the calculation; orders not yet shipped count as slow. This figure is recorded by the store itself (level 2) and is shown as such.

Payment processors and coverage

Bank disputes can currently only be read from shopify_payments. Dispute percentages are calculated over the orders charged through those processors, and the share of orders they cover is stated. If that share is below 70 %, nothing is claimed about disputes or about "Refunds money", the store is listed as "no verifiable payment processor" and the product-page module is not offered.

Integrity signals

Every record publishes, with no personal data: the peak order count of the last 3 months against the median of the previous 9; the share of orders more than 30 days old with no shipment; the share of orders fully refunded within 7 days or less; and whether orders are missing from the months snapshotted at the first measurement. An order's creation date is set by the platform and cannot be backdated.

Transparency about these rules

The dispute threshold was set on 14 September 2026, before calculating the dispute reasons of the first store measured (its aggregate dispute rate was already known). The 90-day refund window was set after seeing that store's data, for a structural reason: when a store changes its process or its apps, its refunds from a year ago no longer describe how it works today. On 15 September 2026 the refund percentage was corrected: it previously counted only refunds that moved money through the processor and left out vouchers issued by external apps; it now counts every record. On 15 September 2026 the rules moved to an observed rate with a minimum of 1 divided by the threshold, so that stores of any size are measured the same way. That day also set the threshold for refunds not processed, before that figure had been looked up in any store, and the minimum number of refunds in money, the first store's aggregate percentage already being known. On the same day, the minimum processor coverage, the exclusion of manually marked payments, volume counted only from orders that still stand, and the integrity signals were added.