# Design states and recover interrupted requests

Distinguish business state, service outcomes and retry decisions in a signing journey.

Conceptual and implementation-planning guidance

## Define the meaning of each state

A business application may need to distinguish preparation, waiting for a user, completion and required intervention. These are discussion concepts, not Mobile-ID API state codes.

Map service results into application states. Define the user message, retained data and permitted next actions for each outcome.



## A missing response does not establish failure

After disconnection, the service outcome may be unknown. Use the specified reconciliation mechanism before creating a new request with business effects.

Record the relationship between case, request and attempt. Prevent the interface from encouraging repeated requests while an outcome is uncertain.



## Retry according to contract and effects

Separate read operations from operations that create or change data. Repetition is not automatically safe. Apply any deduplication or identity rules exactly as specified.

A result notification can arrive after a user leaves the screen. Design reconciliation and updates so a single timeout does not leave the application in an incorrect state.



## Create an exception test matrix

Test application closure, long waits, duplicate submissions, late notifications and cancellation. Record final source-system state and recovery actions.

The RSS resource includes status queries and result codes. Read the correct version and confirm applicability before using it with another service.



Source document:
- GoPaperless workflow overview: https://docs.mobile-id.vn/GoPaperless/Brochure_Datasheet/Brochure_GoPaperless_20250819.pdf

https://knowledge.mobile-id.vn/en/knowledge/states-and-recovery/