Part 3 · 1 chapters · ~12 min
Money, Identity and Trust Questions
Six likely questions with structured answers (risk, mechanism, what the user sees, how you know): withdrawal timeouts, double submits, prices that move, failing KYC uploads, degraded providers and secure sessions, with phrases to use and avoid and your own evidence.
6
Edge cases, degraded states and failure recovery
risk, mechanism, what the user sees, how you know
- A withdrawal timeout: show "confirming", hold the amount, poll by the key.
- Double submit: create the key when the form mounts and persist it.
- The price moved: send the price the user saw plus a slippage tolerance, and the server decides.
- A KYC upload fails: resumable, compressed, verified asynchronously.
- A provider is degraded: a banner scoped to that bank, plus a circuit breaker on the server.
- Sessions: passkeys, HttpOnly cookies through a BFF, step-up only for risky actions.
| always say | never say |
|---|---|
| "the server is the source of truth for money; the client shows what the server knows" | "we update the balance optimistically" |
| "pending is a designed state with copy and a resolution path" | "we show an error and they can try again" |
| "the idempotency key makes retries safe" | "we disable the button so they can't double-click" |
| "amounts are integer minor units with a currency" | "we store the amount as a float" |
| "we measure duplicates, timeouts that resolve to success, and contacts per incident" | "it works in testing" |
your own evidence
The non-indebtedness letter is a good example to bring here. An eligibility-gated entry, asynchronous generation with polling, a single-use download and full handling of every rejection code is unhappy-path design on a real fintech flow, and you owned its frontend.
MONEY, IDENTITY AND TRUST QUESTIONS
six questions a Deriv frontend interview is likely to ask, and the shape of a strong answer to each
swipe the figure sideways, or tap expand for full screen
1/6
withdrawal timeout
"A user taps Withdraw and the request times out. What do you show, and what happens next?" Never "failed": the withdrawal may have succeeded. Show "We're confirming your withdrawal" with the amount held, poll the status by the idempotency key, and resolve to completed or failed when the server knows. Retrying uses the same key, so at most one withdrawal happens. Measured by: timeouts that resolve to success, and duplicate-withdrawal incidents (zero).