Wallet and UPI test cases, where the payment ends up in limbo

The ambiguous outcome is the defining problem of instant payments. A request is sent, the network drops, and the client has no idea whether the money moved. There are only two safe behaviours: show it as pending and resolve it, or resolve it before telling the user anything. What is never safe is showing it as failed, because the user will immediately pay again and the first payment may well have succeeded. That single design decision produces most duplicate payment disputes, and it is testable by cutting the connection at one specific moment. The follow up case matters just as much: on the next app launch, any pending payment must be queried and resolved rather than left as a stale row.

Idempotency is the mechanism that makes retries safe, and it has to be a key generated before the first attempt and reused on every subsequent one. A key generated per request is not a key. Client libraries retry automatically on timeout, users press pay again, and mobile networks drop responses constantly, so the retry path is the normal path rather than the exceptional one. The mirror image is worth its own case: a duplicated provider callback on a top up must not credit the wallet twice.

Caps and counters belong to the account, not to the device or the session. A daily limit checked per device is defeated by installing the app somewhere else, and a wrong credential counter held on the client is reset by reinstalling. The timezone boundary is a related case: a cap that resets according to the device clock can be reset early by changing the clock, so the account timezone is the only correct reference.

Finally, collect requests are a fraud surface rather than a feature, and the interface wording is the control. A request that will take money from the account must say so plainly and name the requester, because the whole attack depends on the recipient believing they are receiving funds. Expiry has to be enforced on the server, the payee name has to be shown before the credential is requested, and the credential itself must never appear in logs, crash reports or analytics payloads. Those four cases are cheap to run and they cover the ground where real losses happen.