Worked metric
Run 100 synthetic intended operations. Suppose one operation creates two committed debits and the other 99 create one debit each. The duplicate-effect rate for this test is 1 out of 100 operations, or 1%. Count the extra debit, not a second HTTP response. If all 100 produce one debit, report zero duplicate effects in 100 tests, not zero risk. This numerical example is hypothetical. The downloadable CSV contains ten synthetic events across five intended operations and does not measure a live system.
Measure one intended effect
Choose a stable operation ID before sending the first request. For each test, count committed debit or credit entries tied to that ID. A duplicate API response is harmless only when the ledger still has one intended effect.
Checks to run
- Group test events by intended operation ID; count ledger effects rather than HTTP success responses.
- Inject retry, concurrent request, delayed webhook, and provider redelivery cases.
- Report test count, duplicate ledger effects, test environment, and the point of failure.
Metric and limits
For a test run, divide operations with extra committed money effects by completed intended operations tested; report unresolved operations separately. Also report the raw numerator and denominator. A test with no duplicate effect in a tiny sample does not prove the live risk is zero.
Compare ledger effects after all delayed events have arrived. Set a fixed wait window and state it in the report. The linked CSV is synthetic and does not measure any real provider or product.
Calculate both the rate and the count
Use 1,000 synthetic payment intents. Suppose 12 had a repeated request and 2 intents ended with two committed debit effects. The duplicate-effect rate is 2 ÷ 1,000 = 0.2%; the repeat-request rate is 12 ÷ 1,000 = 1.2%. Do not mix these numbers. Count one intent once in the denominator even if it was retried ten times. Show the reporting window, the source event table, and the definition of “committed debit effect.” In production analysis, exclude test payments or linked reversals only under a written rule; retain synthetic test operations in this test denominator. A low rate can hide one severe duplicate, so review the two cases as well as the percentage.
For risk-file revision 1.1, check the linked calculation guide before adding results; expected effects are per operation, not per event row. field guide and calculation rules.
Count one defined effect per operation
For this fixture, the effect is a committed debit for one intended transfer, excluding its matching credit and fee entries. Count distinct debit posting IDs for each operation_id after the fixed observation window. Exclude unresolved operations from the completed denominator and report their count beside it. An operation with more than expected_effects has a duplicate; one with fewer has a separate missing-effect failure. Use the same completed-operation denominator as the linked method. Do not switch the measurement to provider settlement without changing the definition. In a synthetic run, test payments are the population and must remain included. In production analysis, exclusions need their own written rule. The five-operation CSV is input, not measured evidence.
Primary sources
Download synthetic retry inputs.
Next step
Replay the synthetic operation, count committed ledger effects, and record the raw numerator and denominator. Read the related guide. For a review of your own system, request a security review.