Build a version matrix
List each supported app build, its API route, and the security rule used for sign-in, new beneficiaries, and transfers. Keep one build from before the fix and one current build. Give both the same test account and request data. A pass means the server makes the same security decision for both builds. If an old screen cannot collect the proof needed for a transfer, the server must stop that action and tell the customer how to update.
Check version enforcement at the API, not only in the app. An old client can keep sending requests after it skips an update screen. OWASP's enforced-update guidance calls for a backend minimum version, and Android offers immediate and flexible update flows. Pick the flow that fits the risk, then test the case where the app store is closed or the update is interrupted. The customer should still have a clear path back to service.
Test an interrupted update
Start an update on a test phone, then stop the network before the new build installs. Reopen the old app and try sign-in, balance view, and transfer as separate actions. The server must keep the current transfer rule even when the app cannot update yet. The screen should tell the customer how to try again when service returns. If the product allows a safe read-only mode, test it without making money actions available. Then finish the update and check that the same account can continue without a duplicate transfer.
Test cases and proof
| Case | Expected result | Proof to keep |
|---|---|---|
| Old build skips new step-up field | Server enforces rule | Transfer response |
| Unsupported build signs in | Show update path | App screen |
| Rollback reuses old token | Apply current session policy | Auth event |
Test old data after an app downgrade
Install version N with a fake saved transfer, upgrade to N+1, then try the supported rollback path or a device restore to N. Check database schema, queued actions, and token version. If rollback is blocked, make the failure safe and clear. If allowed, old code must not replay a transfer that new code already sent. Keep version codes, migration ID, queue item ID, provider reference, and final ledger state. A rollback plan includes server API compatibility and key rotation, not only reinstalling an old binary. (Android Room migrations).
Do not treat a version header as proof
Call a sensitive staging endpoint with the old build’s request, then change only its version header to the current value. The current authorization and approval rule must still apply. A minimum-version header can guide normal clients but cannot prove that the code on a caller’s device is current. For rollback testing, record the actual supported route: a managed distribution rollback, explicit test downgrade, or restore. Store schema version before and after each step. If old code cannot read the new schema, stop safely; do not use destructive migration to erase a pending transfer queue. Query the server for every uncertain queued operation before presenting a final result.