amir taherkhani

Thanks, Ahmet. Testing a rejected charge of 150 followed by a valid charge of 20 in the same app instance would strengthen this example. I agree that checking only the error response is not enough: the balance should still be 100 after rejection, then 80 after the valid charge. The current tests use separate app instances, so they do not cover that sequence. The article focuses on closing a module-boundary bypass: every charge must go through WalletOperations, rather than access WalletStorage directly. In a production payment system, I would extend that principle into a shared transaction workflow with explicit states and handling rules for success, failure, pending or unknown outcomes, and duplicate requests. We cannot predict every external failure, but we can define how the system handles uncertainty. For example, if an external transfer succeeds but the internal balance update fails, we need reconciliation rather than another transfer. Stable idempotency keys and atomic balance updates also help prevent duplicate effects and concurrent overspending. This matters especially for direct crypto transfers, where a confirmed transfer generally cannot be reversed; returning funds usually requires a new transfer and the recipient’s cooperation. Your suggested test is a useful regression check, alongside those production controls.