Orders were being cancelled on a multi-store e-commerce operation and nobody could say why. Some had already been charged. The cancellation notes were authored by the store software itself, so every internal explanation pointed at a misconfiguration nobody could find.
Every obvious suspect was wrong, and each took real work to eliminate. The store's own unpaid-order timer was disabled, and no scheduled task existed that could cancel an order. The fraud-prevention plugin was the natural suspect, but none of the affected customers appeared in any block list, and its logs recorded blocks of entirely different customers at checkout. The marketing automations were reviewed one by one — all messaging-only. Custom code snippets were read; none modified orders.
At that point the internal evidence was exhausted. Everything inside the application said the application was not doing this.
It was not the store. It was a third-party inventory platform holding administrator-level API access. The access logs settled it: the platform was issuing an authenticated write to the order endpoint at the exact second each cancellation note appeared — a correlation visible only after subtracting the logged request duration, because access logs stamp request completion rather than start.
Two behaviours were running. Instant cancellation seconds after checkout, including card orders where the charge had already completed — every one of which had driven a product's stock to zero, consistent with a central inventory system killing the order after the customer was charged. And a daily sweep of unpaid orders roughly ten days old, running across more than one store in the group.
Worse: the platform's own refund calls were failing with a server error. It was cancelling paid orders and then failing to return the money, leaving live charges against cancelled orders with no refund record anywhere in the store.
An integration with admin credentials is an actor in your business
It can do anything an administrator can do, at machine speed, with no human in the loop — and its actions are attributed to your software rather than to it. Most operators cannot say which of their integrations hold write access, and almost none can say what those integrations did last week.
The logic was defensible; the failure mode was not
Refusing to sell stock you do not have is correct. Cancelling an order after capturing payment, with a broken refund path, is a chargeback pipeline — and the platform had no idea it was doing it, because its refund failures were silent.
- ✓Root cause with the full evidence chain
- ✓The specific behaviours to change on the vendor's side
- ✓The charged-but-cancelled transactions to reconcile in the payment processor
- ✓A code fix to the affected repository
- ✓The two most recent affected orders reinstated and verified to hold — confirming the platform would not immediately re-cancel them
Read-only throughout: store CLI queries, order and scheduler records, SELECT-only database reads, and origin access-log correlation. Nothing was changed until the diagnosis was proven and the client had approved.
Client, vendor, product and industry details are removed, along with any figures belonging to the client. The technical detail is unchanged. This shows how we work — it is not a claim about a business result, which would require the client’s consent and a baseline measured before the work began.