If your application already has the document images, start with a standalone check such as Didit's. Veriff documents a document-only session and decision webhook. Sumsub organizes verification around an applicant and a verification level, while Entrust uses workflow runs with capture SDKs or a hosted option. Before choosing, decide where the camera runs and what a successful response lets the customer do.
Reading the expiry date extracts a field. Checking whether the document appears authentic validates evidence. A match between the applicant and the portrait needs its own evidence. Write the specific claim in your project brief, especially if a successful check will unlock a sensitive account action.
For a document-only intake, we'd trial Veriff first (8/10 editorial fit). The documented decision webhook and extracted fields make it easy to specify what the product needs from the integration. We'd hold back two points until we've seen the outcome for a missing reverse image and the fields returned for the specific documents in scope. If our capture team already had an approved image pipeline, we'd run the same fixtures against Didit's standalone endpoint.
Choose a capture model before choosing the platform
A hosted session is a useful default if you want the provider to guide camera placement, handle the transition between front and back, and return a result without routing the original image through your servers. The handoff still needs a reference that ties the result to the right user. Test whether the user can leave and resume without losing the current attempt, especially if an email or phone message opens a separate browser.
An SDK can preserve more of the surrounding product experience while keeping capture components under the vendor's control. That is useful when the application owns accessibility settings, translations or navigation between steps, but does not want to own the image pipeline. Review what happens when a camera permission is denied or a client version remains in use after the provider changes its SDK.
A standalone document API can fit when capture is already part of a staffed intake or a separately approved internal system. The price of this freedom is operational: files may move through your storage, observability, backups or dead-letter queues unless you design each boundary deliberately. Document where a failed upload lives and when it disappears.
Compare four document verification approaches
| Platform | Public integration model | Question for the integration trial |
|---|---|---|
| Didit | Hosted workflow sessions or standalone checks | Can your approved intake submit the expected images and extract only the fields you need? |
| Veriff | Document-only verification session and decision webhook | Which outcomes and extracted fields are delivered in your chosen configuration? |
| Sumsub | Applicant and verification level, then document upload and result handling | Which market-specific document rules can the level express without custom code? |
| Entrust | Workflow run, capture via SDK or hosted experience, and result retrieval | Can your team maintain the workflow version and distinguish individual report outcomes? |
Didit's integration guide covers hosted workflows for vendor-managed capture and standalone calls for images you already have permission to collect. Confirm which checks run in the path you use. A standalone response and a workflow decision can report different evidence.
Veriff's document-only documentation describes analysis of document images, a decision and extracted data. It also directs integrations to the corresponding decision webhook. That is a fit for a project where the required claim concerns the document. If the problem is account impersonation, specify how evidence about the person will be obtained rather than promoting the document decision to a broader result.
Sumsub's walkthrough separates applicant creation, level selection and document upload. That structure is useful when the same customer may move through several checks. Entrust's REST API offers workflow runs and results, with a workflow composition layer. Check how each system represents a workflow change: a decision has more value when your own record can show what was evaluated at the time.
Specify the result before selecting fields
For a document submitted during onboarding, you may need its type, issuing country, expiry status and a provider decision reference. A record of an extracted name may be appropriate if it is needed for a match. A database copy of the entire OCR result is a different commitment. Consider which fields a reviewer can legitimately see and which only the upstream decision needs.
Keep extracted values and application values separate. If an applicant types a name without diacritics, do not overwrite the original extraction simply to make a comparison pass. Use explicit normalization rules and preserve the reason for a reviewed match. The same principle applies to date formats and transliteration: a blank field, an unsupported field and a mismatch should lead to different downstream actions.
NIST's identity proofing guidance separates resolving an identity, validating evidence and verifying a link between the person and the evidence. In a product design review, that separation exposes a common mistake: a readable document and a positive authenticity result get converted directly into permission to change a sensitive account setting. Put your own decision after the evidence stage.
Build a document test matrix from real requirements
List the issuing country, document generation, sides, script and capture method for each document you expect. Two generations of a resident permit can use different field layouts. A passport flow may use optical capture or NFC depending on the product. Test the format your users actually bring.
Add negative fixtures: an expired document, a missing back, a blurred photo and an unsupported format. Each failure should produce either a safe retry, a review or a clear stop. A request timed out before acknowledgement is also worth testing. Your retry must not create two distinct cases for one upload or make an old attempt look current after a replacement is accepted.
For an assisted workflow, observe a reviewer doing the task. Can they find the exact image being discussed without exporting it? Can they record why a different document was accepted? Can you inspect or export the review trail without handing the entire document archive to the support team? These questions are part of the integration contract, even when they never appear in the OpenAPI schema.
Keep the application independent of the vendor response
Use a small adapter that maps vendor results into fields your product understands: source, attempt reference, policy version, disposition and an internal reason. Keep the original provider ID for retrieval and support. If the vendor splits one case into several reports, aggregate the evidence under an application attempt rather than letting the last callback win.
On return from a hosted flow, let the user see “submitted” while the backend waits for an authenticated result. On a standalone API, track retries at the request boundary and check what a temporary failure means before uploading the file again. The software testing and automation practice is a useful companion when deciding which of these paths belong in a release test suite.
Compare the cost of an exception
Have procurement price three cases: one accepted document, one repeated upload inside the same attempt and one case with a human decision. For each, ask which operation counts toward the minimum and which triggers an extra fee. If raw evidence moves through your own system, include the work to enforce access, deletion and audit. A narrower endpoint can save money on checks while adding operational cost, especially when your internal help desk is the only way to resolve a failure.
Pick the smallest check that proves the claim
For a narrow document intake, trial a standalone or document-only option first. For onboarding that will soon require additional evidence, trial the same document with an applicant or workflow model so you can compare the extra setup against the cost of building orchestration yourself. Do not compare pricing until the providers agree on which images, results and review actions are in scope.
Use the identity verification API comparison if the project also needs to identify the person. For a document-only trial, ask each provider to show the source of its decision and what it returns when a permit is unsupported or the reverse image is missing.