SHANTANUPAWAR✳

A successful checkout is only one moment in a payment lifecycle. The backend still needs to connect a transaction to the right registration, verify its authenticity, and decide what state a ticket should be in.

Treat incoming events as things that can repeat. Give each event a stable identity, verify it before acting, and make the state change safe to run again. A repeated notification should not create a second ticket or a second charge record.

Keep the payment record and ticket state easy to inspect. Clear logs and explicit states make it much easier to understand a failure than a single success flag ever will.

The same product can exist in several warehouses. Keeping a product separate from its inventory lets each warehouse hold its own quantity without duplicating the product itself.

A junction table makes that relationship explicit. An inventory movement then becomes a change to a particular product and warehouse pair, with a record explaining what changed.

Correctness matters as much as query speed. Use atomic transactions for related writes, keep an audit trail, and store money in a decimal representation. These choices support the multi-warehouse model used in StockFlow.

AI can help brainstorm edge cases, draft test ideas, and explain an unfamiliar failure. It is most useful when the task is specific and the expected behaviour is clear.

Generated tests still need review. A test that repeats an implementation may prove very little. A stronger test describes the behaviour that matters: an unauthorised request is rejected, a repeated event stays safe, or an invalid input leaves stored data unchanged.

Keep the feedback loop grounded in running code. Use AI to widen the search for mistakes, then use test results, logs, and the actual system behaviour to decide whether the work is correct.