You should consider Didit when your application has a specific identity-checking requirement, the documented capabilities fit that requirement and your team can own the decisions that follow. You should not adopt it merely because another product uses verification or because a free allowance makes experimentation inexpensive.
The decision becomes clearer when you separate four questions: what evidence you need, how the application will use it, who will handle exceptions and whether the commercial terms fit the expected workload. If one of those questions has no owner, production integration is premature.
This article is commissioned Didit content. It offers a source-based decision framework rather than a hands-on recommendation, security certification or claim that we have measured production performance.
Can you name the action that requires verification?
Start with one sentence: “Before a user can do this, we need to establish this.” For example, a marketplace may need to identify the person requesting a particular account action. The requirement should explain both the action and the consequence of an incorrect decision.
If the sentence instead reads “we want users to feel safer”, investigate the underlying problem before choosing a tool. Better account permissions, clearer dispute handling or stronger authentication may address a different need. Identity verification is not a substitute for all of them.
A well-defined action also keeps scope manageable. You can evaluate one workflow and its exceptions without redesigning every registration or support process. Expansion should follow evidence from that release rather than the availability of more modules.
Does the documented scope match your requirement?
Didit’s documentation is the starting point for checking product scope. Build a requirement list and identify the specific evidence supporting each item. Mark uncertain items as questions instead of assuming that a broad product description covers them.
Document coverage needs to match the people you intend to serve. Check the country, document type, language and device requirements relevant to that population. A global coverage statement is not a substitute for this more precise assessment.
Distinguish an available feature from an announced one. If a planned capability is essential to your launch, obtain a confirmed availability and contractual position before depending on it. A roadmap entry should not silently become a production acceptance criterion.
Is your application ready to consume the result?
The software needs to know which account requested a verification, how to recognise a trusted result and what state transition is allowed. A browser redirect alone is not a sufficient account-control design.
Use an application-owned model for states and permissions. A supplier’s decision can be translated into that model, but it should not automatically dictate every business action. For example, identity evidence may be complete while authority to represent a company remains unresolved.
Test repeated and delayed notifications. The application should not create duplicate records or reverse a newer decision because an older event arrives late. These are integration responsibilities that remain important even when the provider’s capture experience is hosted.
Who will operate the exceptions?
Every proposed workflow needs an answer for people who cannot complete it normally. Decide who reads support requests, who can review evidence and who may change a decision. A small team can operate a limited process, but only if those responsibilities are explicit.
Didit’s manual-review documentation helps identify questions for that operating model. Review the available functions in the package you intend to use and distinguish them from procedures your own team must provide.
Give support staff a useful case reference and approved explanations. They should not need broad access to identity documents merely to tell a user which step is pending. Restrict detailed evidence to roles that have a defined need for it.
Can you explain the data arrangement?
Before launch, your team should know what data is collected, where it is processed, what your application retains and which deletion or retention rules apply. The relevant agreements and configuration should be available to the people responsible for the decision.
Do not copy every returned field into analytics and customer-support tools by default. Choose the minimum internal record that supports the account state and operational task. More storage can create more maintenance and access-control work without improving the user journey.
Public security claims can guide diligence, but the decision should refer to the actual evidence and scope needed for your organisation. If a report is available only under agreement, record whether it has been reviewed rather than implying that a logo completed the assessment.
Does the forward budget work?
Calculate expected use for the workflow you will run. Separate initial checks, retries, additional operations and your own staff time. The number of registered accounts is not automatically the number of billable events.
Because Didit has announced a November 2026 pricing change, a launch budget should use the terms applicable to the launch period. Do not rely on an older review’s description of free usage. Keep the effective date with the estimate and verify account-specific conditions.
Compare the resulting cost with alternatives that meet the same requirements. A supplier with a higher unit price may include capabilities you need; a broader package may also be unnecessary for your use case. The purpose is to choose an appropriate operating arrangement, not win a headline-price comparison.
When a limited pilot makes sense
A pilot is useful when the major requirements are understood but the team needs evidence about integration and user behaviour. Choose a narrow cohort and define the questions the exercise must answer.
A practical pilot record can look like this:
| Decision question | Evidence required |
|---|---|
| Can users finish the intended task? | Completion and recovery observations |
| Does the account state stay correct? | Tests of normal, repeated and delayed events |
| Can the team handle exceptions? | Review and support walkthroughs |
| Is usage predictable? | Reconciliation between events and billed operations |
| Can the release be paused safely? | Documented stop and recovery procedure |
These tests do not establish fraud-detection accuracy unless a separate, suitable evaluation is designed for that purpose. Be precise about what a successful pilot demonstrates and what it leaves unanswered.
When you should wait or choose another approach
Wait if the business cannot justify collecting identity evidence, if a required document combination is unsupported or unconfirmed, or if nobody can own unresolved cases. Those are material gaps, not details to fix after all users enter the flow.
Consider another supplier when it can satisfy a requirement that Didit cannot meet under the proposed configuration or terms. Consider improving your own application first when the main problem is permissions, account recovery or unclear support rather than identity evidence.
Write the reason down in neutral language. “Did not meet our required deployment condition” is more useful than a general claim that a product is bad. It also makes it possible to revisit the decision if the requirement or offering changes.
Assign a review date to the decision
A supplier decision should have a reason to be revisited. That might be a material workflow change, a new country requirement, a different user population or a contract renewal. Without a trigger, an early experiment can become a permanent dependency that nobody actively owns.
Keep the original acceptance criteria so a later review can distinguish changed requirements from a regression. If the application begins serving businesses as well as individuals, the original personal-identity evaluation may no longer cover the product. That is a scope change, not evidence that the original decision was necessarily wrong.
Name a person responsible for maintaining the decision record. They do not need to perform every technical or legal review themselves, but they should know where the evidence lives and which specialists must be involved when something changes. This makes the adoption decision part of ordinary product maintenance rather than a one-time purchasing event.
A decision your team can revisit
Use Didit when the evidence supports a defined role in your application and the surrounding process is ready. Keep the workflow version, commercial assumptions, data arrangements and acceptance results together so future maintainers can understand the choice.
Our technology articles cover related software decisions, and the Veriff alternatives comparison provides another perspective on supplier evaluation. Neither replaces checking your own requirements.
The best outcome is a decision with boundaries: what Didit will do, what your team will do and what would cause you to reconsider. That is more durable than an unconditional recommendation and more useful when the product, user population or pricing changes.