No client-side SDK

The final SDK choice is the simplest: not using a client-side SDK of any kind.

This means you allow your users to upload images directly (or you don't have live end-users), and they're fully responsible for the quality and nature of images they upload.

This usually comes with a lot of downsides, and we heavily discourage it. That said, there are some use cases where this is the only option, or where it has fewer downsides than usual.

If this is your only (or preferred for some reason) option, the Verify API is compatible with it.

Important

Even if you're not using a client side SDK, the uploaded images still need to meet the API's image requirements. Most importantly, make sure they're always in the correct formats, correctly sized, and if possible, contain documents.

Downsides

It's important to understand all the downsides of this approach:

• Poor UX - your end users will likely experience a lot of retries and incomplete verifications
• False rejections - not using a capture SDK causes lower image quality on average, and lower image quality leads to more false rejections
• Insecure - when uploading directly, end users have full control over the input images. They can be edited, generated, or otherwise manipulated to bypass verification. Verify does have mechanisms in place against this, but they're not as effective as when using the Verify SDK
• More expensive - since a lot of images will not be verifiable, you'll be paying for your end-users' mistakes
• Out of domain uploads - without a capture SDK, invariably, some images will be of completely random things. A client-side SDK usually makes sure they're at least document-like (or fully verifiable in the case of the Verify SDK). Without one, you'll have to deal with the unexpected consequences of out of domain images.

The bottom line is, make sure you have a very good reason to not use a client-side SDK. If you don't, use the Verify SDK.

Configuration

If you're using this option, set the CaptureCondition UseCase parameter to NoControl (because you don't control the end user's capture process) so we can tweak Verify behavior to accomodate the conditions as much as possible.