How we built KYC for a fintech onboarding flow with Didit: one document-and-selfie check reused everywhere, plus a free tier of 500 verifications a month.
Key findings
One Didit verification, built once, is reused at sign-up, during onboarding, and for a second applicant on the same account - one integration instead of three.
Didit's free tier covers 500 verifications a month, forever, with no card; paid usage is about $0.33 per KYC check, plus roughly $0.20 for AML screening.
Coverage is broad: 220+ countries, 14,000+ document types, and text recognition in 130+ languages.
Every result is confirmed on our own server, never the browser, and returns parsed ID data (name, date of birth, address) that pre-fills the rest of onboarding.
Didit holds ISO 27001/27017/27018, iBeta Level 1 liveness, and SOC 2 Type I (Type II in progress), and its free tier undercuts Persona, Onfido, and Jumio.
Identity verification is where onboarding quietly breaks: too strict and real users drop off, too loose and fraud walks in. This is how we built KYC for a fintech onboarding flow with Didit, one document-and-selfie check reused everywhere, and why a free tier of 500 verifications a month reshaped the build.
Why did this fintech need identity verification at onboarding?
The platform handles exactly the data identity thieves want - Social Security numbers, government IDs, bank details - so the single most important question at onboarding is whether the person on the other side is who they claim to be. Get that wrong and everything downstream, from payouts to tax filing, inherits the mistake.
That question comes up in more than one place: at sign-up, during onboarding, and again when a second person is added to the same account. The answer had to be trustworthy enough to build compliance on, simple enough to finish on a phone, and forgiving when a first attempt fails for an innocent reason like a blurry photo or bad lighting.
At DesignKey Studio, we treated identity verification as one shared capability rather than three separate features. The brief was to confirm a genuine government ID, match it to a live selfie, capture the data off the ID so people are not retyping it, and do all of it inside our own app. Didit became the engine for that check, and its pricing made it realistic to run on every flow rather than only the highest-risk one.
What is Didit, and how much does it cost?
Didit is an identity verification service: the user photographs a government ID and takes a live selfie, and Didit confirms the document is genuine and that the face matches, returning an approve-or-decline decision plus the parsed ID details. It is the same "Know Your Customer" (KYC) check banks run before opening an account, exposed as an API.
The pricing is what sets it apart. According to Didit's pricing page, the free tier covers 500 verifications a month, forever, with no credit card, and that quota includes the full bundle: ID verification, passive liveness, face match, and IP analysis. Beyond the free tier it is pay-as-you-go at roughly $0.33 per core KYC check, with AML screening available for about $0.20 more. For a product still finding volume, that means identity verification can cost nothing for months.
Coverage is broad enough for an international user base: 220+ countries, 14,000+ document types, and text recognition across 130+ languages and 50+ scripts. On compliance, Didit is GDPR-ready and holds ISO 27001, ISO 27017, and ISO 27018, plus iBeta Level 1 certification for liveness anti-spoofing; it reports SOC 2 Type I with Type II in progress. Integration is API-first: a REST API with hosted verification sessions, SDKs for Web, iOS, Android, React Native, and Flutter, signed webhooks, and an OpenAPI 3 spec.
The closest comparison most teams reach for is Persona. The short version: Didit competes on price and a permanent free tier, where Persona competes on a low-code workflow builder. We weigh both in the alternatives section below.
What did we build?
We built a single Didit verification and reused it everywhere identity needed confirming, instead of rebuilding the check three times. When a flow needs to verify someone, it opens a Didit session tagged with our own reference ID, which ties the result back to the right person and lets a restarted attempt resume cleanly. The same setup serves sign-up, onboarding, and a second applicant on one account.
One Didit verification, set up once, covers all three moments.
One verification, reused everywhere
Every check runs through one shared setup. Each session carries our reference ID so Didit's result maps back to the correct person and a retried attempt does not collide with an earlier one. Building the verification once, rather than per flow, is the difference between one integration to maintain and three that drift apart.
Embedded in the app, not redirected
The verification renders inside our own screens rather than bouncing the user to an external page, so they see our wording and design, pick a document type, and work through capture without leaving the app. On mobile especially, every redirect is a chance to lose someone, so keeping it in-app directly protects the conversion rate that KYC otherwise threatens.
How identity verification works, in three steps.
Verified on the server, not the browser
When the verification finishes, the browser only reports that it is done; it never gets to declare itself "verified." Our server independently asks Didit for the authoritative decision through the API, and only a genuine approval counts. Every outcome - approved, declined, or an error retrieving the result - is logged, so there is a record of who was verified, when, and how. That log doubles as the compliance artifact: when an auditor asks how a given user cleared KYC, the answer is a timestamped record tied to a Didit session ID, not a screenshot or a trust-me, which is the kind of evidence a compliance review actually accepts. Didit's signed webhooks back this up by pushing status changes rather than relying on the client to report them.
The check also captures data, and tolerates retries
Because the verification reads a government ID, an approval returns the person's name, date of birth, document type, and address. We feed that forward so verification is not a dead-end checkbox; it is where the rest of onboarding gets pre-filled. Real ID data is messy, so it is tidied on the way in: names split into parts, states normalized to standard codes, street lines reordered to US postal conventions. And because phone-camera capture fails for innocent reasons, honest retries are not penalized; only repeated attempts get a short delay, with a hard cap to limit abuse.
Webhooks and idempotent results
The verification result arrives two ways, and we trust the slower, authoritative one. The embedded flow tells the browser the check is done, but the decision we act on comes from Didit's signed webhook to our server, which fires when the verification is actually adjudicated. We verify the webhook signature, look the session up by our own reference ID, and apply the result idempotently, so a duplicate delivery or a user who refreshes mid-flow never double-creates a record or flips a decision. Because each session is keyed to our reference ID rather than Didit's, a retried attempt maps back to the same person and supersedes the earlier try instead of forking it. This matters more than it sounds: identity is exactly the kind of state where a race condition, the browser reporting "approved" while a webhook later returns "declined," can let the wrong person through. Treating the webhook as the source of truth and the browser as a hint closes that gap, and it is the same idempotent-by-reference-ID pattern we reuse for the other third-party integrations in the stack.
Where did Didit excel?
Didit's biggest advantage was cost: a permanent free tier (500 checks a month) plus paid checks at about $0.33 made identity verification cheap enough to run on every flow, not just the riskiest. Compared with competitors charging $2 to $5 per check, that is roughly a 6x to 15x difference at the unit level, which adds up fast at volume.
The other major win was reuse. Because one verification setup serves every flow, identity is a single thing to build, test, and maintain, and a change to what a check requires lands everywhere at once - leverage that pays back across a product's life, not just at launch.
Coverage and developer experience were the quieter wins. Support for 220+ countries and 14,000+ document types meant we did not hit a wall on international users, and the API-first design (REST, hosted sessions, SDKs, signed webhooks, OpenAPI 3) made the server-side confirmation straightforward. Key takeaway: a permanent free tier plus broad coverage let us treat identity verification as infrastructure rather than a line item to minimize, which in turn let us verify in more places and raise the overall fraud bar without watching a per-check meter.
Where did it struggle?
Liveness and capture remain the friction points, as they are with any document-and-selfie vendor. Glare, low light, worn documents, and older phone cameras all produce declines that have nothing to do with fraud, which is exactly why the retry path and a fallback to manual review are non-optional rather than nice-to-haves. A verification flow with no graceful failure mode quietly bleeds real customers.
The free tier has edges worth planning around: 500 verifications a month is generous for early volume but is a ceiling you will cross, and AML screening is billed separately, so "free KYC" is not the same as "free compliance." Identity verification also is not AML - a matched ID does not screen anyone against sanctions or watchlists, so it must be paired with screening, not mistaken for it. Finally, SOC 2 Type II was reported as in progress rather than complete when we integrated, and data-residency and retention details should be confirmed against your own obligations before launch rather than assumed. Operationally, the free-tier ceiling needs a guardrail rather than good intentions: we metered our own usage and alerted well before the monthly cap, because a marketing spike or a wave of bot signups can otherwise exhaust the quota in a day and turn verification into a wall of silent failures at the worst moment. None of these blocked us, but each is a question a compliance reviewer will ask.
What are the alternatives to Didit?
We weighed Didit mainly against Persona, with Onfido and Jumio as the enterprise reference points. Persona is the closest competitor: it also offers around 500 free verifications a month, but its paid rate is higher (commonly near $1.50 per check, with a minimum around $250 a month on annual plans). Its real draw is a low-code, drag-and-drop workflow builder, which suits teams that want to configure flows without engineering time.
Onfido (now part of Entrust) and Jumio are the established enterprise options. Neither offers a standing free tier, and per-check pricing typically runs from about $2 to $5; their pull is mature fraud tooling and procurement-friendly credibility for large regulated buyers. For a product that wanted broad coverage, an API-first integration, and costs that scale from zero, Didit's free tier and ~$0.33 per check were decisive.
Provider
Free tier
Approx. per check
Standout
Didit
500/month, ongoing
~$0.33 (core KYC)
Permanent free tier; lowest cost; broad coverage
Persona
~500/month
~$1.50 ($250/mo min)
Low-code workflow builder
Onfido (Entrust)
Trial only
~$2-3
Enterprise fraud tooling
Jumio
Trial only
~$3-5
Longest-established, procurement fit
Frequently asked questions
Does Didit have a free tier?
Yes. Didit offers 500 identity verifications per month free, with no credit card, and the free quota covers the full KYC bundle: ID verification, passive liveness, face match, and IP analysis. Beyond 500 a month it is pay-as-you-go, and enterprise contracts add SLAs and custom terms. For low-volume products, the free tier is enough to run in production indefinitely.
How much does Didit cost per verification?
Didit's published rate is about $0.33 per core KYC check (ID verification plus liveness and face match), with AML screening available as an add-on for roughly $0.20 more per check. The first 500 verifications each month are free, which keeps early-stage costs near zero and makes it cheap to verify in more than one place.
Didit vs Persona - which is cheaper for identity verification?
Both offer roughly 500 free verifications a month, but Didit's paid rate of about $0.33 per check is well below Persona's, which is commonly around $1.50 with a minimum near $250 a month on annual plans. Persona's main advantage is its low-code workflow builder, so the choice is price-and-API-first (Didit) versus configurable flows (Persona).
How many countries and document types does Didit support?
Didit supports identity documents from 220+ countries and 14,000+ document types, including passports, national IDs, driver's licenses, and residence permits, with text recognition across 130+ languages and 50+ scripts. That breadth is a practical reason to pick it for products onboarding users internationally rather than in a single market.
Is Didit GDPR and SOC 2 compliant?
Didit is GDPR-ready and holds ISO 27001, ISO 27017, and ISO 27018, plus iBeta Level 1 certification for liveness anti-spoofing. It reports SOC 2 Type I today with Type II in progress, so confirm the current report against your own compliance requirements before launch rather than assuming Type II coverage.
Does identity verification replace KYC or AML screening?
No. A document-and-selfie check proves the person in front of the camera matches a genuine ID, but it does not screen them against sanctions, PEP, or watchlists. That is AML screening, which Didit offers as a separate add-on. Treat identity verification and AML screening as two layers, not one.
