vertical-fintech-mobile

# Money on a phone — spec it like the network will fail mid-transfer A field app that loses a photo is annoying. A money app that loses — or duplicates — a transfer is a loss, a support case, and sometimes a regulator. Everything in the generic mobile contract still applies (offline queue, idempotency, permissions); this pack is the part that is different **because it is money**, and it is the part community skill sets do not carry, because it is domain knowledge rather than framework knowledge. The through-line: **the phone is not the ledger.** It is a client with an opinion, and every screen must be honest about how strong that opinion is. ## 1. A balance has three states, never two `confirmed` · `pending` · `unknown`. A number rendered without which of the three it is, is a lie the user will act on. - **confirmed** — the server said so, and the app has heard from the server recently enough to say when. - **pending** — the app has applied its own optimistic change on top. It is a *display*, not a fact, and it is labelled. - **unknown** — the app has not reached the server. This is NOT the last confirmed number rendered as though it were current. A stale balance shown as live is the defect this whole pack exists to prevent. Every balance carries **as of when**. "£1,240.55" is not an answer; "£1,240.55, as of 14:02" is. ## 2. The idempotency key must outlive the process The generic rule is "client-generated id so a re-sync never duplicates". For money that is ...