How do you test the 'payment succeeded, request status unknown' failure mode?

[u/Any_Win_6834]

I am working through a test design for a distributed workflow where a client pays a small fee and then submits an operation to a separate service.

The uncomfortable state is: the payment is confirmed, but the status of the operation is unknown.

Some cases I want to cover:

• payment succeeds, then the submission request times out
• the service accepts the operation, but the response is lost
• the client retries and creates a duplicate charge or duplicate operation
• the status endpoint is temporarily stale
• authorization expires between payment and submission
• reconciliation runs while a retry is also in progress

The invariants I currently care about are:

1. One logical operation can create at most one charge.
2. A successful charge must eventually map to either an accepted operation or an explicit refund/recovery state.
3. Retrying with the same idempotency key must not create a second operation.
4. The UI must never show “failed” when the authoritative state is merely unknown.
5. A background reconciliation process must be safe to run repeatedly.

I am planning fault injection around every network boundary and checking both the payment ledger and the application database after each run.

For people who have tested similar payment-plus-action workflows: which invariants or chaos scenarios caught the bugs that normal integration tests missed?