Skip to content

SDKs: Android, iOS, React Native, Flutter and web

One SDK for Android, iOS, React Native, Flutter and web. Each is installed once, started when the app opens and called at each moment, and each returns the same decision object. The verification modules run inside the same SDK where your journey needs them.

Names and fields are illustrative and agreed in the sandbox before any contract.

On this page

What the SDK reads

Once started, the SDK reads the session for you. Your app passes its own identifiers and the event’s details, never the signals. What the server decides is read against everything the session has bound and read before.

What the SDK reads, module by module
ModuleWhat it reads
Silent network verification
  • Network check: the carrier confirms the number over mobile data, even on Wi-Fi, with nothing for the customer to do
  • SIM check: the phone sends one text to DeepID from its own SIM, silently once permission is given
  • Aadhaar consent: the customer approves in the Aadhaar app
  • One-time code, typed or auto-filled, as the last fallback
  • The bank chooses the steps for each attempt, or requires all of them
  • A single-use token that the bank’s server redeems with DeepID before signing anyone in
SIM and device binding
  • The account bound to one device and its SIM at sign-up
  • Dual-SIM phones handled: the right SIM, or the customer’s choice
  • Re-binding on a new SIM or phone, after the customer proves it is them
  • UPI registration on the bound SIM
  • Cooling-off after a new device or SIM, set per market
Liveness and face match
  • Catches photos, videos, masks, deepfakes and injected camera streams
  • An instant answer on the phone, then a final verdict from the server before the bank acts
  • When in doubt it fails closed: deny or send for review, never pass
  • A signed record of every session, replayable for audit
  • The live face matched to Aadhaar or the document’s portrait
  • Face search across your customers, so one face behind many accounts is caught
Device intelligence
  • Device ID that survives reinstall and factory reset
  • Root, jailbreak, emulator, hooking and cloned-app detection
  • Remote-access and screen-sharing detection
  • Malware and overlay signals
Behavioural biometrics
  • Typing, touch and navigation rhythm
  • Hesitation, dictation pauses and repeated cancels
  • Bot, script and AI-agent detection
  • Drift from the customer’s usual session
Scam signals
  • Active call during a payment or payee change
  • Screen sharing or remote control while money moves
  • Payee details pasted or dictated, urgency, unusual amounts
  • In-app interventions: warn, cool off, hold and call back
Payee and mule graph
  • Payee and mule-ring graph across accounts and devices
  • Recipient risk scored before the payment is sent
  • New accounts that receive from many unrelated senders

The verification modules, eKYC, document verification, liveness and face match, video KYC, KYB, AML screening and bank account verification, run at sign-up and wherever your journey calls for them again, through the same SDK. See the platform overview.

Android

Kotlin. Install the package, start the SDK once, then call decide at each moment. The first call here is the login.

Install

build.gradle.kts

dependencies {
  implementation(
    "com.deepidsdk:deepid-android:<version>"
  )
}

Start once

App.kt

// Application.onCreate: once, before the first screen
DeepID.start(this, key = BuildConfig.DEEPID_SANDBOX_KEY)

First call

LoginViewModel.kt

val decision = DeepID.decide(
  Event.LoginAttempt(customer = user.id)
)

when (decision.action) {
  Action.ALLOW -> signIn()
  else -> show(decision.message)
}

iOS

Swift. Install the package, start the SDK once, then call decide at each moment. The first call here is the login.

Install

Package.swift

dependencies: [
  .package(
    url: "<package-url>",
    from: "<version>"
  )
]

Start once

App.swift

// App init: once, before the first screen
DeepID.start(key: Config.deepidSandboxKey)

First call

LoginModel.swift

let decision = try await DeepID.decide(
  .loginAttempt(customer: user.id)
)

switch decision.action {
case .allow: signIn()
default: show(decision.message)
}

React Native

TypeScript. Install the package, start the SDK once, then call decide at each moment. The first call here is the login.

Install

Terminal

npm install @deepid/react-native

Start once

app.ts

import { DeepID } from "@deepid/react-native"

// Once, before the first screen
DeepID.start({ key: DEEPID_SANDBOX_KEY })

First call

login.ts

const decision = await DeepID.decide(
  "login.attempt",
  { customer: user.id },
)

if (decision.action === "allow") signIn()
else show(decision.message)

Flutter

Dart. Install the package, start the SDK once, then call decide at each moment. The first call here is the login.

Install

Terminal

flutter pub add deepid_flutter

Start once

main.dart

import 'package:deepid_flutter/deepid.dart';

// Once, before the first screen
await DeepID.start(key: deepidSandboxKey);

First call

login.dart

final decision = await DeepID.decide(
  LoginAttempt(customer: user.id),
);

if (decision.action == DecisionAction.allow) {
  signIn();
} else {
  show(decision.message);
}

Web

TypeScript. Install the package, start the SDK once, then call decide at each moment. The first call here is the login.

Install

Terminal

npm install @deepid/web

Start once

app.ts

import { createDeepID } from "@deepid/web"

// Once, as the page loads
const deepid = createDeepID({ key: DEEPID_SANDBOX_KEY })

First call

login.ts

const decision = await deepid.decide(
  "login.attempt",
  { customer: user.id },
)

if (decision.action === "allow") signIn()
else show(decision.message)

What each route asks for

The SDK asks the customer for a permission only at the moment the route that needs it runs, and never for a route your policy does not use. The routes are the network check, the SIM check, Aadhaar consent and a one-time code, in that order, with the first that verifies ending it; a face check runs where the policy steps up.

What the SDK asks the customer for, per platform
PlatformAsks for
Android
  • Mobile data for the network check, which runs over the mobile network even when the phone is on Wi-Fi.
  • Permission to send one text, asked once, for the SIM check; the text goes silently from the phone’s own SIM.
  • The camera for a face check, asked at the moment the check runs.
iOS
  • Mobile data for the network check, which runs over the mobile network even when the phone is on Wi-Fi.
  • The camera for a face check, asked at the moment the check runs.
  • The SIM check and Aadhaar consent run as your policy allows on this platform; the one-time code is the last fallback.
React Native
  • The native module for each platform, so the network check, the SIM check and the face check run as they do on Android and iOS.
  • The same permissions as the native SDKs, asked at the moment each route runs.
Flutter
  • The platform plugin for Android and iOS, so every route runs natively.
  • The same permissions as the native SDKs, asked at the moment each route runs.
Web
  • The browser’s camera for a face check, asked at the moment the check runs.
  • On the web the network check needs the browser to be on mobile data; otherwise the next route takes over, down to the one-time code.

Packages and versions

The <version> and <package-url> placeholders are filled in with your sandbox access, together with the minimum Android and iOS versions each SDK supports.

What the SDK adds to your app’s size and start-up, and how long a decision takes inside your journey, are measured in the sandbox on your own app and traffic. No figure for either is published on this site.

Wire one moment in the sandbox, before any contract.

Sign-up or login end to end, with the decision back in the app and as an event, so your engineers see the shape of it before anyone signs anything.