Veriff alternatives need to fit more than your capture screen. We would compare the bill, the API and what happens when a verification result arrives late.
The capture demo works. The user closes the tab. A webhook arrives twice, another arrives late, and the account still says “pending.” That is the kind of scenario we would bring to an identity-provider evaluation.
Didit leads this API-focused shortlist, with public module pricing and documented signed webhooks. The rest of the selection comes down to where the application needs help: running rules, supporting operations, or keeping a deliberately small verification surface.
A verification API does not end at the HTTP response. Your backend must associate a session with the correct account, receive updates, reject forged notifications and preserve an understandable decision history. Changing vendors without designing that path can move complexity from the supplier into your own event pipeline.
Seven Veriff alternatives by integration question
| Provider | Reason to investigate | Question for the integration owner |
|---|---|---|
| Didit | Full-payload signed webhooks, test scenarios and versioned workflows | How will we verify, deduplicate and reconcile each result? |
| Persona | Configurable verification workflows | Which orchestration belongs in the platform versus our backend? |
| Sumsub | Verification within a broader compliance offering | Which additional operational stages are in scope? |
| Stripe Identity | A focused identity product with a public rate | Can a narrower product replace the current requirements? |
| Entrust Identity Verification | Document and biometric identity checks | Which version and product configuration will we implement? |
| Jumio | Document verification and face-based liveness | What evidence and reasons will operators receive? |
| iDenfy | API, SDK and no-code integration choices | Which review and screening extras affect the operating cost? |
Veriff's own self-service plans provide a public baseline: Essential lists $0.80 per verification with a $49 monthly minimum. Use that as your baseline. A replacement needs to improve something you care about—cost at your volume, the workflow, or the way your team operates it.
1. Didit: best for an API integration you can inspect
Didit leads this shortlist because the documented integration goes beyond creating a session and waiting for an answer. New webhook integrations use X-Signature-V2, which authenticates the full payload through a defined JSON representation. Console test scenarios let engineers exercise their receiver before routing live traffic through it.
That is useful engineering detail. It tells the team what to implement, what to test, and where to look when delivery fails. The documentation also specifies bounded retries, so reconciliation belongs in your application design. Use the current full-payload signature method; the older Simple variant is deprecated and does not authenticate the decision body.
The sandbox provides controlled session outcomes without running real verification providers or billing the calls. Workflow versions remain attached to the sessions created with them. Together, those features make it easier to reproduce an integration problem and identify the rules behind a result. A sandbox pass establishes application behavior, not the effectiveness of the live fraud models.
For that separate security question, Didit describes in-house controls for deepfakes, document manipulation and injection attacks. Its published iBeta letter gives a narrower independently tested result: Level 1 presentation-attack compliance for Biometric Authentication v2.0. We would use the report and the selected capture method to scope the live pilot.
The core four-feature KYC bundle is publicly priced at $0.33 after eligible allowances. Add that to the inspectable event handling and testing tools, and Didit is the strongest starting point here for a team replacing Veriff on a defined engineering budget.
- Pros: Full-payload signed events, console webhook tests, deterministic sandbox outcomes and public core pricing.
- Cons: Your backend still needs reconciliation after exhausted retries; simulated checks do not measure live fraud resistance.
2. Persona: evaluate where workflow logic should live
Persona is interesting here because it lets you reconsider where verification rules live. Its documented workflows support verification and API triggers. Moving a branching process into that environment may make ownership clearer, provided your backend stops trying to run a second version of the same rules.
Take a hypothetical result that passes identity checks but leaves a business requirement unresolved. Which system decides the account's next state? Write that answer down before building the adapter. Otherwise, a later workflow edit can change product behavior without anyone touching the application repository. The evaluation should establish how changes are reviewed and how the applied rules remain traceable.
- Pros: Configurable workflows can centralize branching verification rules.
- Cons: Moving rules into the platform creates configuration and ownership decisions.
3. Sumsub: include the operational stages in the design
Sumsub publishes separate Basic and Compliance packages, with distinct checks and monthly commitments. Its pricing page also identifies broader products such as business verification and transaction monitoring. It is worth evaluating when the proposed change extends beyond the verification endpoint into a larger operational process.
Model those stages separately in your application. Individual identity verification, business onboarding and ongoing screening should not collapse into one permanent boolean. Their evidence, owners and update cycles may differ even when one vendor supplies the services.
Sumsub makes more sense when someone owns those additional stages. If nobody will operate them, they become extra concepts for the backend to carry. Use its published plans to scope the purchase, then confirm the selected package in writing.
- Pros: Products extend into business verification and transaction monitoring.
- Cons: Broader scope adds operating responsibilities and separate commercial requirements.
4. Stripe Identity: assess a narrower replacement
Stripe Identity is a narrower candidate, with a published US document-and-selfie rate of $1.50. It suits the comparison when the Veriff deployment performs a bounded check rather than coordinating a wider operation.
For this candidate, make a status translation sheet the first engineering deliverable. Include a capture the user never finished, a completed verification, and a completed check requiring attention. Decide what each means to your application; do not force every outcome into an approved-or-rejected boolean. Screening and other dependencies need their own scope review. Familiarity with Stripe's payment products can help a team get oriented, but it cannot fill missing requirements.
- Pros: A focused verification product with a published US rate.
- Cons: Screening and other operational requirements need a separate scope check.
5. Entrust Identity Verification: one candidate, including Onfido
Entrust identifies its current identity-verification offering as formerly Onfido IDV. It describes document and biometric verification along with other identity use cases. Do not list Entrust and Onfido as independent alternatives in a migration matrix: clarify the present product and its integration path.
Ask for the relevant SDK and backend versioning documentation before estimating migration work. An identity provider sits at the boundary between a user device and your application, so the capture component and the result-processing service both need owners.
Entrust's product overview leaves the comparable per-check price to a quote. Request it alongside support expectations and upgrade responsibilities. Those details matter when one team owns the mobile release and another owns the service receiving results.
- Pros: Document and biometric checks within the former Onfido offering.
- Cons: Pricing requires a quote; SDK upgrade responsibilities need agreement.
6. Jumio: examine the evidence returned to operations
Jumio's document verification and face-based liveness put it on the list. The interesting engineering question is what happens to the evidence after the check.
Ask for representative responses from the proposed configuration. Then sketch two views of the same unresolved case: what the user should see and what an authorized operator needs to investigate. Those views should not expose the same information. In particular, a convenient debug payload should not become a permanent entry in a general-purpose log.
The quote should identify both the checks purchased and the operating arrangement for difficult cases. Establish who takes responsibility after a result returns, and which fields your own software can rely on. That is how the evaluation moves beyond whether the endpoint responds.
- Pros: Document and liveness checks address common verification requirements.
- Cons: Pricing and the operator-facing evidence need evaluation for the selected configuration.
7. iDenfy: account for review work and optional services
iDenfy's plans describe API, SDK and no-code integration options. Selected extras, including manual review, are priced separately. That makes it useful to evaluate both the straightforward automatic path and the cases that require assistance before forecasting costs.
Prepare a small workload description with retries, additional screening and unresolved submissions. Ask the vendor to explain which events create charges and how those events appear in operational reports. The billable unit should be understandable to the team reconciling usage.
The calculator on iDenfy's pricing page returned inconsistent amounts during research. Get the final calculation confirmed, including any approved-only billing option. For the engineer reconciling usage, the important outcome is being able to connect each charge to a documented event.
- Pros: API, SDK and no-code routes offer implementation choice.
- Cons: Review extras complicate the cost model; calculator figures need confirmation.
Build an event path that survives retries
We would settle four parts of the backend design before wiring a new capture screen into production. They are where a small integration can acquire a surprisingly long support tail.
First, create a durable association between your internal account and the provider session. Use an opaque reference where possible. Avoid placing identity documents or personal details inside identifiers that spread into logs, queues and analytics.
Second, authenticate incoming notifications using the selected provider's current specification. For Didit, implement the recommended V2 method and timestamp checks. Other signature methods may require the untouched request bytes. Do not assume that every signing variant protects the same fields.
Third, make processing idempotent. Store an appropriate event identifier or documented deduplication key, and ensure a retry cannot grant an entitlement twice. Persist accepted work before acknowledging it if losing that work would leave the account in an incorrect state. Our guide to production CDC failure modes explains the related need to reason explicitly about duplicates and recovery.
Finally, plan reconciliation. Your application should be able to discover a session that remains unresolved after a delivery problem, using the provider's supported retrieval mechanism. If events enter a Kafka-based pipeline, keep identity evidence out of broadly accessible analytical streams. Send the minimum operational fields needed for the downstream task.
Compare security evidence separately from speed
Ask each supplier what its published tests actually cover: presentation attacks, injection attacks, document manipulation or a specific biometric component. Record the tested product version and conditions. A badge alone does not answer whether your chosen integration receives the same protection.
Also distinguish processing latency from the user's complete journey and from manual handling time. Measure these in an agreed pilot. Compare legitimate-user completion alongside the threats relevant to the application. A quick response is useful; so is knowing exactly what the response proves. Keep both questions in the acceptance criteria.
Make the cutover reversible
Introduce a provider adapter with explicit statuses rather than scattering vendor-specific values throughout the app. Preserve old identifiers and policy history. Define the conditions under which new sessions return to the previous integration, without silently re-verifying existing users or duplicating charges.
Start the evaluation with Didit if its documented scope and pricing match the job. Select a second candidate based on the most important missing capability, then run the same acceptance cases against both. For help reviewing the event architecture, contact Zamh Tech. A successful migration leaves the account state explainable after retries, delays and vendor changes.