The required order
A merchant may act on a payment notification immediately. If it arrives before the ledger entry exists, goods could leave before the payment appears in the books. Our test therefore required the ledger entry before the success notification. Eventual completion does not remove that ordering fault.
The required order
Record the payment. Then notify the merchant.
- 01Payment accepted
- 02Ledger recorded
- 03Merchant notified
The injected fault reverses steps 2 and 3. Both still finish.
What Clutta identified
We tested whether Clutta could identify that broken sequence even when the payment eventually completed. Of 12,000 payments, 90 deliberately sent the notification before the ledger entry. Clutta identified all 90 ordering faults and named the affected payment and step. It raised no alarms on the 11,790 healthy payments in this test. Another 120 payments carried deliberate delays or stalls and were also flagged.
The healthy group included retries and duplicate notifications. A control group also delivered log lines late while keeping the events in the correct order. These did not raise alarms.
12,000 synthetic payments
No alarms in this test.Another 120 payments carried different injected faults.
Method and limits
We checked Clutta’s findings against the application’s database. A seeded plan selected the faults, and Clutta did not read the fault-control log. It used application logs without code changes. We configured the payment ID to link the steps and reviewed the deadlines.
The grading rule was set before this 12,000-payment run, after the first run informed the requirement. In one of two fresh setups, Clutta proposed the wrong field for linking steps. The configured payment ID corrected that setup.
This study used one pre-release Clutta build on a lab backend, with one collector per run. This 12,000-payment run was not repeated. Three other runs are excluded: a short smoke test and two higher-rate trials stopped early, one because of a test-harness fault and one because processing fell behind. This is not a production-capacity result.
No goods were released and no real money moved. The merchant action above explains the risk; it was not an observed outcome. We did not compare other tools or measure avoided losses, time saved or ordering-fault detection speed.
A specific payment to investigate
For payment engineers, the result is a specific deviation to investigate: which payment broke the required order, at which step, with the recorded events to inspect.
Start with the requirement that matters to your workflow. Here, it was simple: record the payment before telling the merchant “paid”.
Try it yourself
Run the payment-ordering scenario in Clutta Playground locally on Linux or in GitHub Codespaces. Verify healthy payments, inject a notification-before-ledger fault, inspect the cited Case File, then check recovery.
The walkthrough uses your own Clutta account and a dedicated project. You review and activate the learned flow. It is a small, interactive lab with fake payments, not a replay of the 12,000-payment study above. Repair verifies later healthy runs; it does not erase the original violation.