The component call is the easy part. A mobile integration is mostly native build setup, camera permission, mounting a dashboard workflow so changes skip the app store, and keeping results on your server rather than on the phone.
Drive your product from status, the outcome, and store checkStatus beside it as the explanation. Map each of the ten status values to one state in your own system, and take the latest status from verification.status_updated or polling.
Give every logical verification one requestId, save it before you send the request, and reuse it on every retry. A repeated requestId returns the existing verification instead of creating and charging a second one.
Put the publishable key in your app and keep the secret key on your server. A publishable key can start a verification and read minimal status, never identity data, so plan for it to leak and limit what a leak costs.
Use the published sandbox test IDs, whose last digits pick the outcome, to drive every result your code must handle, then test your webhook receiver with signed simulated events before switching to live keys.
Mount the SDK with a workflow ID and the flow's configuration is fetched from the server on each verification. Re-publishing changes the steps, checks, copy and decision rules for the next verification, with no app release.
When a verification finishes, the workflow's decision graph gathers the results, walks branches over a closed set of fields, and lands on approve, review or decline. The outcome sets the customer's disposition without rewriting what the checks found.
Treat submission as the start of a state machine, not the end of a request. Show a pending state keyed on the verification ID, update it from webhooks, and let the status change more than once.
Verify the V2 signature over the raw request bytes, reject timestamps outside the replay window, record the event ID under a unique constraint before doing any work, and return 2xx only once the event is durably stored.
Embed the SDK when verification happens inside your product; send a per-applicant hosted link when it happens outside it. Either way, run a published workflow so the choice is about delivery, not about the flow.
All three laws treat biometric data as a special category. Nigeria names facial images and limits sensitive data to listed grounds, Kenya treats biometric processing as high risk, and POPIA prohibits it unless an authorisation applies. Plan a lawful ground, a DPIA and minimisation.
Device and IP signals describe the handset and connection, not the person. Emulators and datacentre IPs are strong warnings; shared devices, IP velocity and IP location are weak. Use them as corroboration, and trust IP location at country level only.