The best Onfido alternative for a mobile or web app depends on what you need to replace: the camera experience, the rules behind the identity decision, or the entire provider. Onfido is now Entrust Identity Verification. If your reason for shopping is a legacy Smart Capture SDK, compare Entrust's documented upgrade with a vendor move before you commit. Didit, Persona, Veriff and Stripe Identity are practical candidates for different capture and integration requirements.
Older app releases will still be out there when the new flow rolls out. Before calling a demo successful, open the flow on the oldest phone you support. On the web, open the link from a messaging app and try it again with camera permissions denied.
For a team trying to remove a native capture dependency, we'd give Didit Hosted 8/10. It gives us a way to trial browser capture while keeping the existing identity policy on our server. Before moving real users, we'd break a deep link and interrupt a session on an older phone. Both times, the user should be able to get back to the right account. If the current Entrust workflow already handles recovery well, we'd price the SDK upgrade first.
Compare an Entrust upgrade with a provider switch
Entrust's documentation describes a move from the older Onfido Smart Capture SDKs to newer Entrust IDV SDKs. Its migration guide provides separate notes by platform and version, including changed minimums in its migration examples. The Web SDK is described separately in that guide. Check the current status for each SDK you use; do not assume the Android, iOS, React Native, Flutter and Web schedules are identical.
If you stay with Entrust, you may be able to keep the current backend and operator workflow. Trace how your app creates an applicant, starts the run and passes the capture token. Then close the app halfway through and see how it recovers. If you also move from Classic checks and reports to Workflow Studio, plan and test that change separately.
A full switch may be justified if the new vendor gives you a better capture shape or reduces maintenance on a channel you will keep for years. Compare that with a hosted path from the current provider or candidate. A secure handoff to the browser can avoid maintaining another native dependency, but it makes return links and cross-device handling part of the product.
Compare alternatives by capture surface
| Option | When to evaluate it | Mobile and web question |
|---|---|---|
| Entrust IDV upgrade | Your current policy and operator flow work and the issue is an older capture SDK | What changes in supported OS versions, configuration and workflow initialization? |
| Didit | A hosted flow or a modular capture and checking arrangement would reduce work | Can the hosted return reliably recover the right account in your app? |
| Persona | You need hosted or embedded inquiries with a configurable flow | Which app surface can present the required template and handle fallback? |
| Veriff | You want a document and selfie workflow with a hosted option or SDK | Which supported devices and review features are available for your integration? |
| Stripe Identity | You already use Stripe and the available identity checks match your policy | Do the available countries, documents and capture experience fit your app? |
Didit distinguishes standalone checks from hosted sessions in its integration material. Standalone means the application may own capture and evidence handling, which can increase work even if the response is simpler. Persona documents an embedded inquiry flow with an SDK and a separately hosted flow. The comparison is between the way each option fits your software, not between the number of SDK logos on the product page.
Veriff lists a hosted verification page in its public plans. Stripe Identity documents checks that include government-issued IDs and document-to-selfie matching. A payment integration does not by itself prove that Identity meets your onboarding scope. Check both product access and capture behavior. Use the identity verification cost guide to compare the work to build and support each path as well as any usage fees.
Build a release matrix before touching the SDK
List every supported operating system and client version that can start verification today. Include web browsers, app web views, language settings and permissions. Then mark which capture route each version will take after the change. A release can keep older clients on the existing path, switch eligible clients to a hosted experience or require an update for specific features. Make that policy explicit before sending users to the new route.
In the test matrix, include a low-memory device, a camera permission previously denied, a customer who receives a link in a messaging app and a person who starts on a phone and resumes on a laptop. Exercise back navigation during capture and a callback that arrives after the app has been killed. Verify that the app can fetch the current state from the server without guessing from what it last displayed.
If the native library changes, verify that build and app signing still work across the supported toolchains. Inspect how the SDK responds when a capture screen is dismissed. A failure may return an error to your code, open a support path or return the user to the beginning. Decide which state your UI should display before you test the integration with live users.
Make the cutover compatible with pending attempts
Keep the vendor assignment on the verification attempt, not just in an account setting. An applicant who starts with Entrust before the change might finish after the change. Keep the old result endpoint and callback handling available for those attempts. Do not create a second flow just because the same account opens the latest release on another device.
Send the browser redirect or app link to a status screen. The server should verify the provider's result against the attempt before granting access. If the decision webhook arrives late or twice, the record for that attempt should still make sense.
Use a staged rollout controlled by app version or another approved cohort definition. Track completion, retries and support contacts by channel, because a browser improvement can hide a native regression. During rollback, send new attempts to the previous route and retain the handling needed for existing attempts. This avoids losing decisions or making customers repeat a sensitive capture step.
Test the return link as a product feature
Send a link to a test account through the same channel you intend to use in production. Open it first on a phone where the app is installed, then on one where it is not. Verify what happens when a customer opens it twice, follows it after expiration or signs in to a different account. Bind the token to the right attempt, and keep credentials and document data out of the link and browser logs.
If the native and hosted flows have different recovery behavior, document that difference for support. Give staff an attempt reference and the channel that created it, rather than expecting them to infer the flow from a screenshot. This makes compatibility a measurable release condition and makes it easier to compare an SDK upgrade to a hosted migration.
Decide which project you are actually buying
Run a small trial of an Entrust upgrade and one alternative with a different capture model. Compare supported clients, the work needed on the backend, the way the user recovers and how an operator can retrieve a decision. Include an estimate for updates and support, not only the first integration.
If you want to discuss the migration through the AJM contact page, send the oldest app versions you support, the evidence you need and one real example of a failed retry. Those details make it easier to tell whether an SDK upgrade will fix the issue or a browser flow would save more work.