The SaaS Founder’s Guide to Choosing an Identity Verification API Without Breaking the Product Experience

This is a situation that most SaaS founders are not prepared for. You take months to create a nice flow for your users to sign up, you run the A/B tests, you optimize all the seconds of the process and then you add an identity verification step and your signups plummet. It’s not that your product is bad. The process of verifying the experience was like it was a different application altogether.

When considering identity verification solutions for the first time, it’s typically one of the three following factors that will be your main criteria: speed of the API, accuracy of the API, or the cost per check. Those are factors, but they’re not the only factors. The API you select will impact each individual who subscribes to your product. It will decide when, if ever, they finish onboarding, whether they drop out during the process, and whether your customer support queue will be overrun with verifications in week one.

Written for founders and product leads who care about the user experience as much as the compliance checkbox, this guide will take you through what really matters when making that call.

Your verification step is part of your product, not a layer on top of it

The worst thing founders do is think of identity verification as a “plug and play” feature that they can simply install and never touch again. In real terms, it’s in the most critical part of your funnel, the second the user realizes they need your product – until the second that they get inside it.

Adding a step for users to take a picture of a passport, wait for some result, and then be redirected to a generic holding screen with no estimated wait time, will result in higher drop off. How accurate the underlying technology is doesn’t matter. If it’s disjointed, users believe that your product is in some way broken or unreliable.

Write down one sentence about how your verification step should feel to a user who has never heard of it.Write one sentence about how your verification step should feel to a user who has never heard of KYC in his/her life. You make that the filter for your evaluation.

The four things a verification API actually does to your conversion rate

When talking about IDV APIs, the primary concern is usually around catching fraud and ensuring compliance coverage. Less is known about the conversion effect. The four mechanics that make determining if a verification step is an asset or a liability to your funnel.

Completion time. The longer a verification takes, the more drop-off you’ll have, particularly on mobile. An automated check that returns a result within 30 seconds or less will do much more than one that’s in the queue for manual check.

Document coverage. You will turn away real customers if you have 40 countries of users and only support the top 20 countries. Document coverage is not only a compliance challenge; it’s a global challenge.

False decline rate. If the filters are too strict, they will catch genuine users. Each time you see a customer who was trying to pass you money but failed, that’s one more churned customer for you. Don’t just ask vendors for their fraud catch rate; ask them for their false decline benchmarks as well.

Retry flow quality. What do you do if a verification is unsuccessful? Some APIs throw users into a generic error. Better ones take the user through step-by-step what they did wrong, bad lighting, document too close, expired ID. The experience of a user who makes a mistake and tries again is a crucial part of the experience that can make the difference between a recovered user and a lost user.

What GDPR compliance actually means for an API you’re integrating?

If you have users in the EU, GDPR-compliant IDV is not an option. However, the meaning of this phrase is not always understood. Compliance is not only in the vendor’s data center but also in the way your integration is configured.

Before signing a contract, there are three things that you have to check with the vendor.

Data residency. Do you know where biometric and document data are stored, and if you can, do you know what is allowed for EU-only storage? This is available as an option in some or is enabled by default on others and is routed through US servers.

Retention policy. When a check is made, how long does the vendor keep verification data? GDPR requires that you do not keep biometric data for longer than is necessary. Ensure that the default retention period is in line with your privacy policy.

Data processing agreement. You are a data controller. The data processor is the IDV vendor. A signed DPA must be submitted prior to going live. If the vendor does not provide one or if they make it difficult, that’s a red flag.

How a biometric identification system fits into a SaaS onboarding flow?

Usually, you’re importing at least three elements with a modern identity verification API: document verification, biometric identification system, and liveness check. Each impact on your onboarding flow is different.

Document verification validates and verifies a government-issued ID. Biometric: Matches the face on the document to a live selfie. Liveness detection verifies that the photo is from a living person and not a photo or a replay of the photo by a deepfake.

The difficulty founders have is considering them as individual calls to individual services. Verification times are slower, there are more points of failure, and a more complex SDK to maintain. A single API session that performs all three steps is much easier to build API wrappers around and provides a better, faster user experience.

Additionally, look for the ability to verify digital IDs with jurisdictions that are no longer relying on paper IDs. The document landscape is evolving with the mobile driver’s license in the US and the EU Digital Identity Wallet that is rolling out across Europe. Making a decision today to use only physical documents with an API could lead to a significant API integration change in 12 months.

The questions your engineering team will ask that your sales team won’t

Often, the vendor decision is made before engineering has even had a chance to review the API. This causes issues in integration. Below are some questions to ask before you invest.

What should the webhook payload be exactly like? Other APIs provide a pass/fail response. The better ones return a confidence score, a failure reason code, and structured data from the extracted document. The more there is in the payload, the more things your product can do with it.

Does there exist a sandbox environment that is representative of the production environment? It is impossible to conduct tests in a real verification environment using real documents. A sandbox with test scenarios that are configured to pass, fail, have low confidence, and retry will save weeks of integration time.

What is the API Uptime SLA? Verification is a step that you will have to complete if you are going to start your onboarding. New signups cease when the API goes down. Fully hosted and embeddable SDK options let you keep users inside your UI throughout.

Pricing models and what they actually cost at scale

The identity verification API vendors typically charge per verification. The headline rate appears reasonable at low volume. The issue is that when it comes to pricing pages, there are a few things that get left out that really do cost a lot of money added up.

Retry pricing. Does the second time a user fails a check and tries again get counted? Some vendors even charge for all of their API calls, whether they are successful or not. With a reasonable failure rate at scale, the cost of retries starts to factor into the budget.

Document type surcharges. Costs may vary when verifying a UK passport and verifying a government issued ID from a less common document type. When your audience is global, think about what you want to verify against the headline rate, since it may not be the same amount.

AML or watchlist screening. Most APIs that are purely IDV won’t have AML screening as a standard feature. If you need sanctions or PEP checks, then these are typically an additional charge. Plan for both from the beginning.

Before you sign anything, run a verification yourself as a new user would

All shortlisted vendors should be given a demo/trial environment. But before you check out feature matrices or pricing sheets, you should go through a complete verification process as a brand new user, on a phone in a normal light, without reading the user’s manual.

Count the number of steps it takes. Observe the consequences of taking a small step incorrectly. Pay attention to how responsive the loading states are, or if they believe that it crashed. Pay attention to the error messages and whether an individual would understand the errors without context for how verification works.

The vendors that really have a great product experience will be quickly distinguished from the vendors that were designed simply for compliance teams. In a SaaS product where friction at the beginning of the user’s journey is a measure of your growth rate, that’s as crucial as one of your technical specs.

It’s not the feature-richest API that is the right one. This is the one that your users will use without realizing it.