Didit is worth evaluating when a client portal needs identity checks that can be connected to a clear account workflow. Its public documentation makes it possible to investigate configuration and operating questions before treating it as a procurement decision. That is a useful starting point, but it is not evidence that every agency project should adopt it.
Our view is that the most important trade-off is between the convenience of a verification service and the responsibilities that remain with the client’s application. The provider can supply a result; the portal still needs permissions, support ownership and a coherent response when a case does not complete normally.
This review was commissioned for a Didit content campaign. It is a documentation-based assessment, not a hands-on test. Public user feedback is discussed separately from our editorial conclusions.
What this review can establish
We reviewed public product documentation, billing information and a public review listing on 22 October 2026. Those sources can establish what the vendor documents and what identifiable reviewers reported. They cannot establish our own completion rate, fraud-detection accuracy or support experience.
For an agency, that distinction protects the project brief. A client may read a positive review as an assurance that integration will be quick or that every customer document will work. Neither conclusion follows without testing the actual requirements.
The practical question is narrower: does Didit provide enough documented capability to justify a scoped evaluation? For an identity-verification requirement, yes. Whether it should move into production depends on the checks, contractual terms and operating arrangements your client needs.
Workflows are more useful than a feature count
Didit publishes workflow documentation describing how verification steps can be configured. An agency should use that material to map the client’s process rather than enabling every available check.
Consider a portal where a customer requests access to a sensitive document. The trigger, identity requirement, account association and access decision all need to be explicit. The same workflow may be excessive for a person simply subscribing to a newsletter.
A useful configuration review asks what each step contributes. Remove checks that have no defined purpose, subject to the client’s requirements and obligations. More collection can add friction and responsibility without improving the particular decision the portal needs to make.
The integration advantage still needs a handover
A documented integration path helps an agency estimate work and identify dependencies. It does not eliminate the work of connecting results to the client’s application or explaining exceptions to support staff.
The delivery should include ownership of the vendor account, billing access and credential management. If only the agency can see a verification case or change a setting, the client may be unable to operate the system independently after handover.
Write a short runbook with the states users can see, the information support can access and the escalation route. Include what happens during a vendor outage or an internal processing failure. A working demonstration is a useful milestone; an operable service needs these additional decisions.
What public user reviews actually show
The G2 listing for Didit contained 33 reviews when inspected. Its summary highlighted ease of setup and integration, while also mentioning workflow or feature limitations. These are themes reported by that review platform, not conclusions from our own testing.
The score visible in search and the opened page differed, so we have deliberately not used an aggregate rating as a headline or added rating schema. More importantly, a small review collection cannot tell you how the product will perform for a different document population or business process.
Read individual feedback for context: the reviewer’s role, the task they were doing and when they wrote it. A complaint about a missing capability may refer to an earlier version; a positive account may describe a much simpler workflow than yours. Convert useful feedback into questions for your pilot rather than treating it as a vote count.
Strengths worth investigating
The first useful characteristic is documentation that allows a team to discuss the integration before commissioning a full implementation. A second is the ability to reason about a configured verification process instead of describing the requirement only as “KYC”. Both observations concern the evaluation process, not independently measured superiority.
A third is the opportunity to separate a reusable verification component from the portal’s business logic. That separation can make responsibility clearer if the agency implements it deliberately. It is an architectural choice, not something that happens automatically because a supplier is API-based.
For a client with a defined identity-checking need, these characteristics can justify a limited proof of concept. Keep the objective small enough that the result can answer a buying question instead of becoming an unfinished production project.
Limitations and questions that remain
Public documentation cannot settle negotiated support terms, account-specific billing, retention arrangements or every country-and-document combination. Obtain the relevant answers for the proposed configuration and keep them with the project.
Pricing requires particular care this month because Didit has announced changes effective in November 2026. A review describing a historic free allowance is not sufficient evidence for a future cost model. Use current terms and the planned launch date.
There is also a boundary between verification and trust in the requesting business. A legitimate verification provider does not validate every business that sends a link. If your client’s users are unfamiliar with the process, explain why it is being requested and provide a recognisable support route.
A useful agency pilot
Define the scope as one action in one portal. Test an ordinary completion, interruption, pending review and a case requiring assistance. Check both the user experience and the internal record that support will rely on.
Use a simple assessment sheet:
| Area | Evidence to collect |
|---|---|
| User journey | Screens and recovery paths for the agreed scenarios |
| Account mapping | Correct association between session and portal user |
| Operations | Named reviewer and permitted support responses |
| Commercial fit | Applicable pricing and documented billing assumptions |
| Handover | Client access, runbook and maintenance responsibility |
Do not claim the pilot proves security accuracy if it only demonstrates integration. Those are different evaluation activities and may require different expertise, evidence and conditions.
What would change this assessment?
A useful review should explain what evidence could change its conclusion. For an agency project, that might be an unsupported document requirement, a contractual restriction or a pilot showing that the client cannot operate the exception queue with its available staff.
It could also change positively. A clear support agreement, a successful account-state test and a manageable first billing reconciliation would strengthen the case for a defined deployment. Those findings would still apply to that configuration and client, rather than proving the product universally best.
Keep a short decision record with the version and date of the material reviewed. Product capabilities and pricing can change faster than a published review. A future project should check the unresolved questions again instead of treating this article as a permanent approval.
This approach makes a review useful beyond its initial recommendation. It identifies the evidence that matters, the boundaries of the conclusion and the work required before a client can rely on the service.
Our verdict for client-portal projects
Didit is a reasonable candidate to investigate when the client has a specific identity-verification requirement and a team able to own the resulting process. It should not be added merely because a portal feels more trustworthy with an extra check.
We would proceed when the workflow, data handling, commercial conditions and support ownership are documented and the acceptance scenarios pass. We would pause when the business cannot explain why it needs the information or who will handle unresolved cases.
Explore the Saghuro Digital blog for related delivery questions. The useful outcome of this review is a better evaluation brief: a named problem, a bounded test and an honest account of what the evidence does and does not establish.
