Didit pricing needs a date attached to it. On 22 October 2026, its public pricing page still describes the existing allowance, while a separate announcement explains changes taking effect on 1 November. If you are budgeting a new application, model the future conditions rather than building your forecast around an allowance that is about to change.
The useful number is your expected invoice for a defined workflow, not the smallest price on a product card. Count the checks your application runs, distinguish monthly credit from cash payments and keep operating costs outside the vendor-usage calculation.
This pricing explanation is part of a commissioned Didit editorial campaign. It uses published terms and clearly labelled examples; it is not a personalised quote or a record of our own billing experience.
The announced change and its effective date
Didit’s 2 October pricing announcement says the current 500-check allowance becomes $10 of monthly credit on 1 November 2026. It lists Free, Growth at $99 a month, Scale at $299 and a custom Enterprise option. Growth includes $115 of credit and a 4% price reduction; Scale includes $350 and a 10% reduction.
The announcement also distinguishes plans for Identity Verification from plans for Transaction Monitoring & Travel Rule, with a shared balance. That is why a budget should record which product carries which plan instead of assuming one paid subscription applies identically to everything.
These are announced future terms as of our research date. Confirm the conditions displayed in your account before purchasing. A dated summary helps explain the change, but the agreement and applicable billing rules should settle questions about your particular deployment.
A price per check is not a price per customer
A customer journey may run more than one chargeable operation. It can also stop before every configured step is reached. Your model therefore needs both the configured workflow and the events that actually trigger a charge.
The Didit billing guide explains prepaid credits and charges associated with completed features. It also distinguishes standalone API calls from the free-tier treatment. Check the current rules for the integration method you select rather than transferring assumptions from a hosted session to a direct API call.
Ask what happens when a document is declined, an external lookup returns no match or the person retries. A declined outcome is not necessarily an unbilled outcome. A pricing spreadsheet that counts only approved users can understate usage even when every rate in the sheet is correct.
Build a workflow-level cost model
Start with a list of events, not a total number of registered accounts. Separate first checks, rechecks, additional screening and any business-verification operations. Then record the price source, effective date and applicable allowance for each event type.
A lean model can use the following columns:
| Column | Reason to keep it |
|---|---|
| Event | Identifies exactly what is being billed |
| Expected count | Avoids treating all account registrations as checks |
| Unit price | Keeps the tariff separate from volume |
| Discount | Applies only where the plan says it applies |
| Credit allocation | Prevents counting the same balance twice |
| Cash paid | Separates subscription and top-up payments |
Add an uncertainty column for volumes you have not observed. For example, a new product may know its expected registrations but not its retry rate. Show a range of scenarios instead of presenting one highly precise forecast without evidence.
Work through a deliberately simple example
Imagine 1,000 billable operations at an assumed $0.33 each. Gross usage is $330. If the only credit available were $10, a simplified usage calculation would leave $320 to fund. This example excludes other checks, taxes and any account-specific terms.
Now model a hypothetical paid package with a $99 subscription, $115 of included credit and a 4% discount on those same operations. Discounted consumption would be $316.80. Subtracting only the $115 package credit leaves $201.80 of additional consumption; adding the subscription gives $300.80. This is an intentionally incomplete arithmetic exercise, not a forecast of a Didit invoice.
Why leave the model incomplete? It forces the reviewer to add any shared free credit, other products, existing balance and billing-cycle effects explicitly. The amount you top up and the amount consumed during a month can differ. A finance report should not silently treat them as the same thing.
Compare plans at realistic volumes
Run at least a quiet month, a normal month and a launch spike. A subscription can make sense at one volume and be unnecessary at another. The difference may also depend on team access or required operational capabilities, rather than usage discounts alone.
Do not use a single break-even figure unless every assumption is documented. Different module prices, product plans and support requirements can move the result. If a colleague cannot reproduce the calculation from the inputs, simplify the model before presenting the conclusion.
Include a stop rule for unexpected spend. The application owner should know who reviews a sudden change in usage and who can investigate repeated attempts. A billing alert is useful only when someone can connect it to a workflow and decide what action is appropriate.
Keep implementation costs in a separate budget
The API invoice does not pay for your application’s account states, error messages or support handover. A hosted verification experience may reduce interface work, but your software still needs to associate the outcome with the correct account and enforce the appropriate permissions.
Budget initial implementation separately from ongoing maintenance. Review whether your team needs custom interfaces, monitoring, audit exports or business-specific approval steps. Those choices can change the total project cost more than a modest difference between unit prices.
Our small-team KYC API guide provides a broader selection framework. Use it alongside this pricing model rather than asking a pricing table to answer questions about engineering ownership.
Reconcile the first billing period
Before expanding traffic, compare a small set of application events with the vendor’s usage record. The goal is to understand the unit being charged, not to prove a general price claim. Choose events whose outcome and configuration are known, then follow them through the accounting record.
Investigate discrepancies at the event level. A repeated operation, an additional module or a different billing period can explain why a simple total does not match. Keep notes on the explanation so the same question does not return every month.
Give finance a stable report with usage, credits consumed and cash payments shown separately. Give engineering the operational detail needed to investigate changes. Those views serve different tasks and do not need to expose the same personal information. A successful first reconciliation provides evidence for the budget model; it does not guarantee that future usage will stay constant.
Revisit the estimate when the workflow changes. A new screening step or a higher share of rechecks can alter cost even if the number of new accounts stays flat. Versioning the assumptions makes those changes visible.
Keep a separate note for currency conversion if your internal budget uses another currency. Exchange-rate assumptions should not be hidden inside the vendor unit price; otherwise a later change can look like a tariff increase when it is actually a budgeting difference.
Questions to settle before accepting a quote
Confirm which currency is charged, how applicable taxes appear, when monthly allowances reset and which credit expires. Ask whether negotiated terms replace public list pricing and which document controls if two pages appear inconsistent.
Record the exact workflow and environment used for the estimate. A sandbox trial can validate an integration without demonstrating what production invoices will contain. Before launch, reconcile a small production sample against your event log and the vendor’s usage record, using only authorised test participants and the appropriate data handling.
Finally, date the decision. A pricing article is useful because it explains how to reason about the bill, but the number that matters belongs to your configuration and billing period. Keep the LitenDev article index as a starting point for related implementation questions, and keep the current commercial terms with the project rather than in someone’s memory.