The cost of adding identity verification to a website has three parts: the checks you buy, the integration you build and the work required to keep the process running. A low API price can be useful, but it does not tell you what your developer must deliver or who will help a customer whose document is rejected.
For a small organisation, the most useful budget is a scoped implementation with a monthly operating model. Ask for a quote that separates the hosted verification flow, your website’s account logic, support tools and ongoing maintenance. That makes competing proposals comparable before anyone starts coding.
This article was commissioned for a Didit content campaign. It explains budgeting using public documentation and hypothetical calculations, without claiming a deployment or supplier quote.
Start with the action you need to protect
“Add KYC” is too broad to price. A website that checks a seller before their first payout has a different project from one that verifies every visitor before they can browse. Write down the action, the consequence of a failed check and the information your organisation genuinely needs.
Consider a directory that allows businesses to publish listings. The requirement might be to verify the person requesting control of an existing profile. That still leaves a second question: does the person have authority to represent the business? A document check alone cannot settle both questions. If the quote assumes it can, the scope is incomplete.
A useful brief also describes the website you already have. Include its login system, database, hosting arrangement and the person responsible for releases. A supplier can price a connection more accurately when they know which parts exist and which must be created. Our guide to website development explains the wider handover considerations.
Separate usage fees from delivery costs
The vendor bill normally relates to a defined unit: a completed check, verification session, lookup or package. Your project bill pays for implementation work. Treating those units as interchangeable leads to misleading comparisons.
A practical request for quotation separates these items:
| Budget item | What the proposal should describe |
|---|---|
| Verification usage | Checks enabled, chargeable events and monthly commitment |
| Initial integration | Session creation, account association and result handling |
| User interface | Start, return, waiting, retry and support states |
| Administration | Review permissions and a traceable decision history |
| Maintenance | Dependency updates, monitoring and change ownership |
| Exit | Export, retention decisions and replacement procedure |
An agency that quotes only a button and redirect may be cheaper because it has omitted the operational work. Ask where the result is stored, how duplicate notifications are handled and what happens if the customer closes the browser. Those questions expose differences in scope without requiring you to evaluate source code.
Use the same verification package in every quote
A document check is not automatically equivalent to document verification plus liveness, face matching and additional screening. List the checks your use case requires before comparing prices. A supplier’s smallest advertised unit may cover only part of that list.
For example, Didit’s published pricing lists a full KYC bundle at $0.33 on the date checked, 22 October 2026. That is a usage reference, not an installation price or a guarantee that every additional check is included. Confirm billing treatment for your chosen workflow and agreement.
Didit also has a dated pricing change scheduled for November. A budget covering several months should use the conditions that will apply in each period, rather than carrying a launch allowance forward indefinitely. Keep the exact pricing page and effective date with the estimate so finance can understand why the model changes.
Build an illustrative monthly calculation
Suppose a website expects 2,000 completed verification packages in a month. At an illustrative rate of $0.33, the gross usage calculation is $660 before any allowances, discounts, additional modules or taxes. This example is arithmetic, not a forecast of a Didit invoice.
Now suppose your team spends 12 hours handling exceptions and maintaining the integration, and you budget that work at an internal $40 per hour. That adds $480, bringing the illustrative operating total to $1,140. Neither the hours nor the labour rate is a market benchmark; replace both with your own observations.
The lesson is that a change in exception workload can matter as much as a change in API price. Record both costs separately. If the number of failed captures rises, you need to know whether the increase came from devices, document coverage, unclear instructions or a new customer population before buying a different package.
What the initial implementation should include
A hosted flow can reduce how much document-capture interface your developer must maintain. It does not remove the need to connect the result to the correct account. The Didit quick-start documentation describes creating a workflow, launching a session and configuring notifications; it also says API keys must remain on the server.
Your acceptance criteria should go beyond a successful demonstration. Ask the developer to show a completed check, a declined outcome, a pending review and a customer returning after closing the page. The website should communicate each state clearly without treating every problem as a permanent refusal.
Include a safe test environment, release instructions and a recovery procedure. A named person should be able to disable a broken verification entry point without disabling the whole website. Define what users will see during that interruption and how pending requests will be reconciled afterwards.
Budget for ownership after handover
Someone must own the vendor account, billing alerts and access permissions. That should be an organisation-controlled account with an agreed administrator, not an inaccessible account belonging solely to a departing contractor. The quote should state which credentials are handed over and how access can be revoked.
Support staff need a usable reference number and an explanation of what they may tell the customer. They do not automatically need copies of identity documents. Give each role enough information to perform its task and establish an escalation route for cases that cannot be resolved from the ordinary website interface.
Maintenance terms should identify covered work. Fixing a broken notification handler, adapting to an API revision and designing a new business-verification workflow are different tasks. A monthly maintenance allowance is only meaningful when both parties know what it includes and how additional work is approved.
Put change requests into the estimate
A quote should explain what happens when requirements change after launch. Adding business verification, introducing another country or changing the action that requires a check can affect both the vendor bill and the application. Ask for a clear boundary between a configuration change and a new development task.
Give the supplier a worked example of a future request. Suppose a verified account needs to invite another administrator. Does the proposed implementation support separate identities and permissions, or would that require restructuring the database? You do not need to build every future feature now, but you should understand the assumptions that make the initial quote small.
Also agree how acceptance is recorded. A short checklist with evidence for each delivered state is easier to use than a general statement that integration is complete. Keep the release date, outstanding issues and maintenance contact with the website handover. That record helps the next developer distinguish an intentional limitation from an unfinished task.
Compare proposals by deliverables, not headline totals
Ask every bidder to price the same set of states and responsibilities. If one proposal includes monitoring and another does not, either add that scope or compare them as different products. Do not average unlike quotes and call the result a normal integration cost.
For a first release, choose a narrow, useful action and measure what happens. Record started sessions, completed sessions, support cases and staff time. Those observations provide a stronger basis for expansion than an optimistic assumption that every user will finish on the first attempt.
Use the website brief worksheet to record the protected action, checks, user states, monthly volume assumptions and support owner. A good budget ends with those decisions written down. It should tell you what the website will do, who will maintain it and which costs remain variable.