Onboarding flows that ask users to photograph a document create work on both sides. The user finds a document and takes a picture in poor light; someone or something at your end tries to read it and decide whether it is genuine. Neither step is reliable.
DigiLocker offers an alternative for documents issued by participating authorities. With the user's consent, an application can fetch the issued document directly, digitally signed by the issuer. The verification question largely disappears, because the signature answers it.
The consent flow is the part to design carefully. The user is redirected to authenticate and to approve sharing specific documents, then returns. Every redirect loses some proportion of users, so the request should be clearly explained beforehand and the return should land them exactly where they left off.
Not every document is available for every user. Coverage depends on the issuing authority participating and on the user's records being linked. Any flow built on this needs a fallback path — manual upload — for the cases where the fetch returns nothing, and that fallback needs to feel like a normal route rather than an error.
Store the minimum. The temptation is to keep the full document because it might be useful later. Under the DPDP framework, holding personal data without a purpose is exactly what you are being asked not to do. In many cases the verification result and a reference are sufficient, and the document itself does not need to be retained at all.
Test the failure modes deliberately: consent declined, document not found, session expired, service unavailable. These are common enough in production that a flow which handles only the success path will frustrate a meaningful share of users on their first interaction with you.
