ECOMMERCE REPAIR SERVICE — FICTIONAL INCIDENT HANDOVER EXAMPLE

Original teaching data. Nine invented provider records, eight invented store orders and nine review rows. Snapshot: 20 October 2026 at 12:00 UTC. No WordPress, payment provider, customer, card, capture, refund, webhook, stock, email or fulfilment system was accessed or changed.

Amounts use integer minor units. The example uses EUR and USD with two decimal places, but never converts or aggregates currencies. captured_minor is gross captured amount; refunded_minor is separately recorded. O106 has 100.00 EUR captured and 20.00 EUR refunded, leaving 80.00 EUR before fees; its local refund is missing. The original 100.00 order total is not treated as an 80.00 total discrepancy.

Join only on the invented order_ref. This example assumes one full captured payment per order; legitimate split payments require another rule. processing/completed are the only example paid store states. Actual gateways, custom statuses and data exports need their own mapping. Classification reports the first applicable issue, not every possible issue.

O101 aligns in this limited sample. O102 paid state needs review. O103 has no matching store row in this export. O104 has two captures requiring review, not automatic refund. O105 is authorization without capture, not a proven collected payment. O106 refund differs. O107 currency differs and is not converted. O108 gross amount differs. O109 has no provider reference in this export, not proof of nonpayment.

Seven review rows, one authorization-only row and one aligned row. Every automatic_action is none. Matching records is not proof of stock, email, fulfilment, settlement, full accounting reconciliation or incident closure. Three CSVs and notes are a fictional worksheet, not production import instructions or an automated repair tool. Field names and these notes are in English.
