Step 1
Scenario in the personal account
Choose the steps: document, selfie, Liveness, database checks. Specify the allowed documents and countries, the webhook address and styling. The app will need the flow identifier.
SDK for iOS and Android
Verify a customer without leaving your app: the SDK shows the passport capture, selfie and Liveness screens with prompts, and the result reaches the app and your server by webhook. Swift for iOS, Kotlin and Java for Android, styling — in the account.
Data is stored in Russia Russian software registry no. 19972 152‑FZ compliance
Document and selfie capture SDK: what the user goes through in the app
One flow for all platforms
Your team does not need to draw the camera, the frame and the error screens. The biometrics and document SDK walks the user through the steps of the flow, and you decide which steps to enable. Steps, documents and styling are set in the account — iOS, Android and the website show the same thing without a new app build.
- 01
Instructions and camera access
A short screen before capture: take the document out of its cover, find some light. Then the camera request — with your own text explaining why it is needed. If access is denied, the SDK explains how to enable it.
- 02
Passport in the frame
The user photographs the document in the frame. If fields are hidden by glare or the document is cropped, they immediately see what to fix and retake only this step.
- 03
Selfie and Liveness
A selfie or a selfie holding the document, then the liveness check: the person moves their face closer to fit into two ovals. Photos, screens, masks and video stream substitution are rejected.
- 04
A result without waiting for an operator
After the last step — the result screen. The app receives an event, your server receives a webhook with the session result, and the next screen opens immediately.
- 3 platforms: iOS, Android, Web
- 29 interface languages
- up to 6 free attempts per step
Verification SDK for iOS and Android: what is in the package
Two native libraries and a shared server side: what goes to the mobile team and what goes to the backend.
-
SDK for iOS
A Swift library: capture screens, camera, prompts and Liveness inside your app. The camera request uses the standard system dialog with your text.
-
SDK for Android
A Kotlin and Java library with the same screens and steps. Camera permission is requested at runtime, before the check starts.
-
Document capture
Frame, shot check and prompts before sending: the mobile document recognition SDK accepts passports, driving licences and ID cards from a list of 16,000+ types.
- Liveness check
Liveness
Liveness check in the same SDK: attacks of all three iBeta PAD levels — from a printout to a silicone mask and a deepfake.
-
Styling without a release
The logo, light and dark theme colours, screen texts and languages are changed in the flow editor and appear in the app immediately.
- API and SDK
Server side
A REST API for creating a session and getting its status, a webhook with the result, flow keys. The same API as for the website, so one integration serves all platforms.
Integrating KYC into a mobile app: from build to the first session
The mobile team embeds the screens, the backend creates the session and receives the result. The work can run in parallel. Connection and working with the key are covered in the documentation.
Step 2
The key stays on your server
The server encrypts your customer identifier with the flow secret key and gives the app only the ciphertext. The API token and the secret key never get into the build.
Step 3
SDK in the project
Add the library for iOS or Android and a camera permission with text the user can understand. Without it, the system will not give the app the camera.
Step 4
Starting the check
On the “Confirm identity” button the app opens the SDK screens with the flow identifier and the encrypted key. From there the SDK guides the user.
Step 5
Result in the app
When the session is complete, the app receives an event and shows the next screen. The status in the app is a hint for the interface, not a decision.
Step 6
Decision on the server
The server receives the webhook with the result and the step results or requests the session status — and only then opens the service to the customer.
Native SDK, WebView, a link or your own interface: four ways into the app
-
Native SDK for iOS and Android
The capture and Liveness screens are part of your app, with no browser and no redirects. Suits banks, MFIs and services where the check is a key registration step.
-
Web SDK in a WebView
The same widget as on the website opens inside the app. It needs the app’s camera permission and camera access granted to the page in the WebView. How to set it up — on the page verification on a website and in an app.
-
A link in the system browser
The check opens in Safari View Controller or Custom Tabs, and the camera works as in a regular browser. When finished, the browser returns the user to the app at your address.
-
Your own interface and REST API
Your team draws the camera and the screens, the backend sends frames to the API and reads the response. Full control over the interface, but you handle frame quality checks and retakes yourself.
All four ways lead to the same session, the same response and the same webhook. The difference is who draws the screens and how much work the mobile team has.
They can be combined: the native SDK in the app, the Web SDK on the website and a link for emails and messengers — on one flow. Details — in the section “Mobile apps and WebView”.
Before release to the App Store and Google Play: camera, permissions, screens
A short list of what to check in a test build. Most camera failures at launch come from permissions, not from the check.
-
NSCameraUsageDescription. The key inInfo.plistwith a clear explanation of why the app needs the camera. Without it, the app will not get access. - Request text. Explain the purpose in plain words: “To photograph your passport and confirm it is you”.
-
CAMERAin the manifest. The permission is declared in the manifest and requested from the user at runtime, before the check opens. - Access denied. If the user has denied the camera, the SDK shows a screen explaining how to enable it. Test this path by hand.
- Orientation. The check runs in portrait orientation: if the phone is rotated, the user sees a request to turn it back.
- Network, date and time. No network — a screen with a retry button; wrong date and time on the device — a request to correct them.
- Weak camera. If the camera does not provide the required resolution, the user sees a request to take the check on another device.
- Keys in the build. The app contains no API token or flow secret key, only the encrypted session key from your server.
- User identifier. In
clientUseryour internal number is passed, without full name, phone or email. - Privacy policy. Links to your terms and policy are shown on the start screen of the check — set them in the flow.
- The same environment screens exist in the Web SDK — see the documentation.
Check result: what the app receives and what your server receives
The app needs the result to show the next screen. The server needs the details to make a decision and save the file. That is why the result arrives through two channels. Field descriptions — in the session status documentation.
- Enable
In the app
an event for the interface
What arrives
- result
successwith the session result - a screen close event for any result
sessionIdandstatusin the return address for the browser path
How to use it
- show “Check passed” or “Try again”
- do not open the service on the in-app event alone
- result
- Enable
On the server
a webhook and a status request
What arrives
- session status
- results of each step — document, selfie, Liveness
- document fields
- error codes
- your
clientUser
How to use it
- a decision on the customer
- a record in the CRM
- a repeat status request if the webhook did not arrive
- Enable
Session statuses
what the result means
Result
success— passedfailed— not passedsuspicious— suspiciousexception— processing errorexpired— the user did not finish
While the check is in progress
idleorprocessing- database checks arrive separately and do not change the session status
In-app verification and the law: 152‑FZ and biometrics
Databases in Russia
The cloud runs on servers in Russia
Under Part 5 of Art. 18 of 152‑FZ, the data of Russian citizens, when collected, including over the internet, is recorded and stored in databases located in Russia. The NeuroVision cloud runs on servers in Russia; in your own environment images never leave your infrastructure.
Only what is needed and no longer than the purpose
You set the steps and the term
Under Parts 5 and 7 of Art. 5, data must not be excessive and is stored no longer than the purpose requires. You set the steps and documents; the session retention period is set in the flow, and it can be deleted earlier by an API method.
Liveness and a one-time match
Your company obtains consent
The SDK checks that a live person is in front of the camera and matches the selfie against the photo in the document once, as part of this check. If the match serves to establish identity, your company obtains the customer’s written consent under Part 1 of Art. 11 of 152‑FZ.
Recognition by face — only through the UBS
A repeat check — from scratch
Face login and recognition of a returning customer by a stored template are permitted by 572‑FZ through the Unified Biometric System. A repeat check in the app — the document and Liveness again.
The data operator is your company
A guideline, not a legal opinion
The app collects images of the passport and the face — these are personal data. This is a guideline, not a legal opinion; your company remains the personal data operator.
152‑FZ
servers in Russia · Russian software register No. 19972
Where verification is embedded right in the app
-
Banks and MFIs
Opening an account or applying for a loan: passport, selfie and Liveness in the app, database checks — in the same session.
-
Marketplaces and courier services
Checking a seller, contractor or courier at registration — before the first payout or the first order.
-
Car sharing and rental
Both sides of the licence and a selfie right in the rental app — the user gets into the car without visiting an office.
-
Crypto services and brokers
Identity confirmation before a top-up, a withdrawal and a limit increase.
-
Telecom operators
Remote eSIM activation and a plan change: Liveness confirms that a real subscriber is in front of the camera.
-
Online games and 18+ services
Age verification by document and liveness, without leaving the game or the app.
Where the customer comes through a mobile app and leaves if sent to a website or an office.
How much a check through the mobile SDK costs
You pay per KYC session with all the steps of the flow, the same on any platform. There is no separate fee for the SDK in the price matrix; anti-fraud and screen styling are included in all packages.
- Calculate
Document
from 16 ₽ per session
Document capture and recognition, classification, anti-fraud; up to 6 free attempts per step.
- Get test access
Document + liveness
from 29 ₽ per session
Everything in “Document” + a selfie or Liveness, face match with the document photo.
- Discuss
Extended
on request
+ checks against Russian databases and international screening.
Test access — 1 month. Database checks are charged separately — from 5 ₽.
A pilot in the app: test access, part of the users, release
Terms
- Test access for 1 month
- A dedicated manager
- Support under contract
- Pay only for checks
Mobile verification glossary
- Mobile SDK
- A library for an iOS or Android app with ready-made capture screens, prompts and a liveness check. It is added to the project like any dependency.
- mobile SDK
- Web SDK
- The same verification process in a browser: a widget on a website or a page in a WebView.
- Web SDK
- WebView
- A browser screen embedded in an app. Checking in it needs the app’s camera permission and camera access granted to the page.
- WebView
- Scenario
- A set of check steps, documents, styling and the webhook address in the account. One flow serves iOS, Android and the website.
- scenario
- Session
- One verification attempt of one person under a flow. It has its own identifier and a final status.
- KYC session
- Encrypted customer key
- Your session identifier encrypted on the server with the flow secret key. The app receives only the ciphertext.
- clientKey
- Webhook
- A request from NeuroVision to your server with the session result. It is used to make the decision on the customer.
- webhook
- Liveness
- A check that a live person is in front of the camera, not a photo, a screen, a mask or a substituted video stream.
- liveness detection
Read also
406 27
KYC, AML and Digital Identification
The KYC Funnel: How to Increase Verification Completion and the Approval Rate Without Slowing Down the Decision
434 21
KYC Document Verification
Why users retake documents: how to reduce the number of repeat attempts during a KYC check
531 29
KYC, AML and Digital Identification
How Video Streams Are Spoofed in KYC: The Architecture of Attacks via Emulators, Virtual Cameras, and Video Stream Injection
462 20
Anti-Fraud, Liveness and Deepfake Protection
How Liveness Detection Is Bypassed: Presentation Attacks, Replay, and Virtual Cameras
Frequently asked questions about the mobile SDK
Yes. The iOS SDK in Swift and the Android SDK in Kotlin and Java show the document capture, selfie and Liveness screens inside your app. For websites there is a Web SDK, which also works in a WebView.
The native SDK is part of the app, with no browser screen and no WebView setup. The Web SDK in a WebView is faster to connect if the widget already works on your website. The flow, the response and the webhook are the same for both.
Passports, driving licences, ID cards and other documents from the list: 16,000+ types from 195+ countries and territories. You set the allowed documents and countries in the flow.
Yes. The logo, light and dark theme colours, screen texts and languages are set in the flow editor and applied to new sessions.
The API token and the flow secret key — only on your server. The app receives an encrypted session key from the server and passes it to the SDK.
From the SDK event after the last step. It is a hint for the interface: the server makes the decision on the customer from the webhook or a session status request.
The SDK shows a screen explaining how to allow access in the phone settings. Without the camera, the document, selfie and Liveness cannot be completed.
Up to six free attempts for each step. If the passport is photographed badly, only the passport is retaken. After the last failed attempt, the session is closed.
No. The SDK checks liveness and matches the selfie against the photo in the document once. The law permits recognition by a stored face template through the Unified Biometric System. A repeat check — the document and Liveness again.
There is no separate fee for the SDK: you pay per KYC session. The “Document” package — from RUB 16, “Document + Liveness” — from RUB 29, test access — 1 month.
We will show the check in a test build of your app
Tell us which platforms your app runs on and which documents your customers photograph — we will choose the embedding path and give you test access for 1 month.
Can't put your request into words? Book a call and our team will contact you at a convenient time
Book a call
The NeuroVision platform is listed in the Russian software registry, entry no. 19972. Rospatent certificate no. 2023661508.
Address: Moscow, Presnenskaya Embankment 12 — Moscow City business centre, Federation Tower. Nearest metro stations: Delovoy Tsentr and Mezhdunarodnaya.
