12 questions to ask before choosing an identity verification SDK

Identity verification SDKs look remarkably similar in a demo. The differences show up after integration — usually at the point where switching has become expensive.

These twelve questions are for seeing those differences early.

Technical

1. How much does it add to app size?

Ask per platform and ask for numbers. SDKs that ship on-device models can add 20–60 MB. That can push you past the App Store cellular download threshold and directly affect your install rate.

Follow-up: can the model files be downloaded on demand, or are they baked into the bundle?

2. What dependencies does it drag in?

An SDK that brings its own networking layer, its own image library or its own analytics client raises your risk of version conflicts. Ask to see the dependency tree.

Ask specifically: is there third-party analytics sending data out of the app?

3. How far can the UI be customised?

There are three levels and the gap between them is large:

• Theme level — colours and fonts change, layout is fixed.
• Component level — individual screens can be replaced.
• Headless — the SDK gives you camera and verification logic only; you write the entire interface.

Do not buy more than you need, but do not settle for less either. If brand consistency matters, theme level is usually not enough.

4. What minimum OS versions does it support?

If the SDK’s minimum is higher than your app’s, you lose a slice of users. Compare it against the version distribution of your actual user base.

5. How much works offline?

Card capture and initial processing can usually happen on the device. Passive authentication needs certificate checks. Ask how the flow behaves on a weak connection — and test it if you can.

6. How do you debug a failure?

When a user gets stuck in the field, what do you have? Is there a session id? Can you reach the logs? An answer of “contact our support team” costs hours in production.

Security

7. Where is the decision made?

If the liveness and matching verdict is produced on the device, it can be tampered with on a rooted one. The final decision belongs on the server; the device only collects data.

8. What is there against injection attacks?

Virtual camera detection, device integrity checks, app signature validation. “We detect deepfakes” is not an answer — ask at which layer.

9. Where is biometric data stored, and for how long?

Under GDPR and its Turkish equivalent, biometric data is a special category of personal data. Retention period, storage location and deletion procedure all need to be explicit. If “how long is it kept?” does not get a specific number, treat that as a flag.

Whether servers sit in a particular jurisdiction is a separate question, and decisive in some sectors.

Operational and commercial

10. What event does pricing bill on?

Is a failed attempt by the same user billed again? Are the NFC read and the liveness check counted separately? At volume this detail can double your estimate.

11. How does the test environment work?

Does the sandbox need a real ID card, or are test documents provided? Can it run in CI? This directly shapes how fast your team can move.

12. Who provides support?

Is the person you talk to during integration from the team that writes the product, or from a support tier? That difference is the difference between a bug resolved in hours and one resolved in days.

How to evaluate

Get written answers to all twelve from three vendors and put them side by side. The vendor who was most impressive in the demo is often not the one who wins that table.

Then run a real integration trial with the two that make the shortlist. Set aside a day, install into your own app, run it on your own devices. The quality of the documentation and how long first setup takes are the best available predictors of long-term cost.