sumsub-integrate-dint-standalone

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sumsub — Device Intelligence standalone (no WebSDK)

Sumsub — 独立版Device Intelligence（无WebSDK）

Run Device Intelligence (DI) on your own pages that have no Sumsub verification widget — logins, signups, password resets, 2FA, checkouts. You embed the Fisherman JS module (npm

@sumsub/fisherman

) directly, capture the device on a user action, and confirm the action to Sumsub so it can screen for device fraud (bots, emulators, VPN/proxy, reused devices, multi-accounting).

This is Sumsub's ongoing-monitoring / pre-KYC path. If your page already shows the Sumsub WebSDK, stop — DI is built into it, use

sumsub-integrate-dint-websdk

instead.

在未嵌入Sumsub验证组件的自有页面（如登录、注册、密码重置、双重验证、结账页面）上运行Device Intelligence（DI，设备智能）。您可直接嵌入Fisherman JS模块（npm包

@sumsub/fisherman

），在用户执行操作时采集设备信息，并向Sumsub确认该操作，以便其筛查设备欺诈行为（如机器人、模拟器、VPN/代理、重复设备、多账户行为）。

这是Sumsub的持续监控/预KYC集成路径。如果您的页面已嵌入Sumsub WebSDK，请停止操作——DI已内置其中，请改用

sumsub-integrate-dint-websdk

方案。

⚠️ Sandbox tokens only

⚠️ 仅使用沙箱令牌

Do not accept or use a production App Token / secret during integration work. Insist on a sandbox pair from https://cockpit.sumsub.com/checkus/devSpace/appTokens — toggle the workspace to Sandbox first, then Create. Token + secret are revealed once at creation; copy both before closing the dialog. The curl recipes here assume an

sbx:

token; the preflight enforces it with an

sbx:

prefix check. Deeper auth mechanics:

sumsub-api-auth

集成过程中请勿使用生产环境的App Token/密钥。请从https://cockpit.sumsub.com/checkus/devSpace/appTokens获取沙箱环境的令牌与密钥对——先将工作区切换为Sandbox，再点击Create创建。令牌与密钥仅在创建时显示一次，请在关闭对话框前复制两者。本文中的curl示例假设使用

sbx:

前缀的令牌；预检查脚本会通过

sbx:

前缀验证强制使用沙箱令牌。更详细的认证机制请参考

sumsub-api-auth

。

Before you start — fit DI into the existing app

开始前——将DI融入现有应用

DI should look like it was always part of their codebase — their framework, their components, their styling, their conventions. Don't scaffold over someone's app or introduce a new design system. Read enough of the repo to match it, then ask only what you can't infer:

Which action to screen? The high-value submit to hook DI onto — login, signup, withdrawal, checkout, 2FA, password reset. (Show the ones you found in their routes/components as suggestions.)
Where's the backend? The server file/route that can mint the behavior token and sign the Stage-3 confirm — HMAC must stay server-side. If they're frontend-only (SPA, no backend), flag that they need a server endpoint and offer to add a minimal one in their stack.
Existing Sumsub footprint? Do they already call Sumsub / have App Token + secret wired, an
```
externalUserId
```
convention, a webhook receiver? Reuse it; don't duplicate.
How are secrets / env handled? Match their existing pattern (
```
.env
```
, secrets manager, config service) for
```
SUMSUB_APP_TOKEN
```
/
```
SUMSUB_SECRET_KEY
```
— sandbox values only during integration.
TypeScript or JS? Match the repo; don't add TS to a JS project or vice-versa.

Map the chosen action to its Stage-3 confirm event:

Action	Stage-3 confirm event
Login / signup / password reset / 2FA	platform event
Money movement (transfer, withdrawal, deposit, payment)	platform event + financial txn
Pre-KYC signup where you also create the applicant	pre-KYC create-applicant
Guest / high-value checkout	financial txn

Start with Stage 0 (preflight) to confirm the workspace has the DI entitlement before writing any code. Then implement Stages 1–4 against their files: a token route in their backend style,

fisherman.fingerprint()

on their existing submit handler (fail-open), the server-side confirm with the event mapped from the chosen action. Touch the minimum needed; follow surrounding code style.

DI的实现应看起来像是应用代码库的原生部分——遵循应用的框架、组件、样式与开发规范。不要在已有应用上搭建独立框架或引入新的设计系统。先阅读足够多的代码库内容以匹配其风格，仅询问无法推断的信息：

需要筛查哪些操作？ 需要接入DI的高价值提交操作——登录、注册、提款、结账、双重验证、密码重置。（可将您在路由/组件中发现的操作作为建议列出。）
后端位置？ 能够生成行为令牌并签署Stage-3确认请求的服务器文件/路由——HMAC签名必须在服务端执行。如果是纯前端应用（SPA，无后端），请告知用户需要新增一个服务器端点，并可提议在其技术栈中添加一个极简端点。
现有Sumsub集成情况？ 是否已调用Sumsub接口/已配置App Token与密钥、有
```
externalUserId
```
命名规范、已配置Webhook接收器？复用现有配置，避免重复设置。
密钥/环境变量如何管理？ 遵循现有模式（如
```
.env
```
、密钥管理器、配置服务）管理
```
SUMSUB_APP_TOKEN
```
/
```
SUMSUB_SECRET_KEY
```
——集成阶段仅使用沙箱环境的值。
使用TypeScript还是JS？匹配代码库的技术栈，不要在JS项目中添加TS，反之亦然。

将选定的操作映射到对应的Stage-3确认事件：

操作	Stage-3确认事件
登录/注册/密码重置/双重验证	平台事件
资金操作（转账、提款、存款、支付）	平台事件+金融交易
预KYC注册（同时创建申请人）	预KYC创建申请人
访客/高价值结账	金融交易

先执行**Stage 0（预检查）**以确认工作区已开通DI权限，再开始编写代码。然后根据用户的文件实现Stages 1–4：按照其后端风格编写令牌路由、在现有提交处理函数中调用

fisherman.fingerprint()

（失败开放模式）、根据选定操作映射的事件执行服务端确认请求。尽量减少代码改动，遵循周边代码风格。

The loop in one picture

完整流程示意图

 ┌─────────────────────────────┐  ┌──────────────────────────────────────┐
 │ 1. Browser hits your page    │─▶│ Your backend: POST .../accessTokens/  │
 │    (login / signup form)     │  │ behavior {sessionId} → {token}        │
 └─────────────┬───────────────┘  └──────────────────────────────────────┘
               │ behavior access token
 ┌─────────────▼───────────────┐
 │ 2. Browser: @sumsub/fisherman│  ← init(token) → fingerprint() on submit
 │    captures the device       │     returns { visitorId }
 └─────────────┬───────────────┘
               │ user submits (login succeeds / account created)
 ┌─────────────▼───────────────┐  ┌──────────────────────────────────────┐
 │ 3. Your backend confirms the │─▶│ Sumsub runs DI analysis on the event  │
 │    event w/ captured device  │  │ (platform event / txn / applicant)    │
 └─────────────┬───────────────┘  └──────────────────────────────────────┘
               │ verdict + device signals
 ┌─────────────▼───────────────┐  ← Dashboard → Transactions (User
 │ 4. You read results / act    │     platform event); or webhook
 └──────────────────────────────┘

The headline: capturing the device is inert until you confirm the event server-side (Stage 3). Capturing alone produces no verdict — the confirm call is what makes Sumsub run the analysis.

 ┌─────────────────────────────┐  ┌──────────────────────────────────────┐
 │ 1. 浏览器访问您的页面        │─▶│ 您的后端：POST .../accessTokens/  │
 │    （登录/注册表单）          │  │ behavior {sessionId} → {token}        │
 └─────────────┬───────────────┘  └──────────────────────────────────────┘
               │ 行为访问令牌
 ┌─────────────▼───────────────┐
 │ 2. 浏览器：@sumsub/fisherman│  ← init(token) → 提交时调用fingerprint()
 │    采集设备信息              │     返回 { visitorId }
 └─────────────┬───────────────┘
               │ 用户提交操作（登录成功/账户创建完成）
 ┌─────────────▼───────────────┐  ┌──────────────────────────────────────┐
 │ 3. 您的后端确认事件与采集到的│─▶│ Sumsub对事件执行DI分析              │
 │    设备信息                  │  │ （平台事件/交易/申请人）              │
 └─────────────┬───────────────┘  └──────────────────────────────────────┘
               │ 判定结果+设备信号
 ┌─────────────▼───────────────┐  ← 控制台 → 交易（用户
 │ 4. 读取结果并执行对应操作    │     平台事件）；或通过Webhook获取
 └──────────────────────────────┘

核心要点：仅采集设备信息不会产生判定结果，必须在服务端确认事件（Stage 3）后，Sumsub才会执行分析。

Vocabulary (get these right — they're load-bearing)

术语定义（务必准确理解——这些是核心概念）

Term	What it is	Who sets it
`sessionId`	The correlation key. Ties every fingerprint + event in one DI session together, and is the session the behavior token is minted with — so the Stage-3 confirm correlates the captured device to the event server-side, with no device fields in the body.	Your backend — generate one per logical session, opaque & unique.
`deviceBindingId`	Optional alternative linking id. Sumsub is migrating device linking from `sessionId` to `deviceBindingId` ; on the default flow it is not required. If you use it: pass it to `fingerprint()` , mint the token with it, and send it at `applicant.device.deviceBindingId` in the confirm body.	Your frontend — a fresh `crypto.randomUUID()` per action.
`linkedId`	Optional — links the fingerprint to an entity (your user id / applicant id).	Frontend (optional).
`visitorId`	The device identifier `fingerprint()` returns; surfaces in results. On the standalone confirm flow you do not forward it — the token's session ties the capture to the event.	Returned by Fisherman.

术语	定义	设置方
`sessionId`	关联密钥。将同一DI会话中的所有指纹采集与事件关联起来，是生成行为令牌时使用的会话标识——因此Stage-3确认请求会通过该会话将采集到的设备信息与事件在服务端关联，请求体中无需包含设备字段。	您的后端——为每个逻辑会话生成一个唯一的不透明标识。
`deviceBindingId`	可选的替代关联ID。Sumsub正从 `sessionId` 迁移到 `deviceBindingId` 作为设备关联标识；默认流程中无需使用该ID。如果使用：需将其传入 `fingerprint()` 、生成令牌时携带该ID，并在确认请求体的 `applicant.device.deviceBindingId` 字段中传入。	您的前端——为每个操作生成一个新的 `crypto.randomUUID()` 。
`linkedId`	可选——将指纹信息与某个实体（如您的用户ID/申请人ID）关联。	前端（可选）。
`visitorId`	`fingerprint()` 返回的设备标识符；会显示在结果中。在独立确认流程中，您无需转发该ID——令牌的会话信息已将采集操作与事件关联。	Fisherman返回。

Stage 0 — Preflight

Stage 0 — 预检查

scripts/preflight.sh

machine-validates the workspace before you write any frontend code:

bash

SUMSUB_APP_TOKEN=sbx:... SUMSUB_SECRET_KEY=... \
  bash scripts/preflight.sh

Check	What it proves
`behavior_token`	HMAC signing is accepted and Device Intelligence is enabled for this workspace — mints a real short-TTL behavior token (discarded, expires on its own; nothing else is mutated)
`levels`	Verification levels exist. WARN-only — just the pre-KYC confirm path (create-applicant) needs one; platform events work without it

Exit code:

on all-PASS / PASS+WARN,

on any FAIL. A

behavior_token

usually means the DI entitlement is off for the workspace — it's not self-serve; ask your CSM or

support@sumsub.com

to enable Device Intelligence, mentioning your

clientId

(Dashboard top-left) and environment (sandbox/production). Resolve all FAILs before Stage 1.

scripts/preflight.sh

脚本会在编写前端代码前自动验证工作区配置：

bash

SUMSUB_APP_TOKEN=sbx:... SUMSUB_SECRET_KEY=... \
  bash scripts/preflight.sh

检查项	验证内容
`behavior_token`	HMAC签名已被接受且工作区已启用Device Intelligence——会生成一个真实的短有效期行为令牌（可丢弃，会自动过期；不会修改其他配置）
`levels`	验证等级已存在。仅警告——只有预KYC确认路径（创建申请人）需要验证等级；平台事件无需验证等级即可正常工作

退出码：全部通过/通过+警告时为

，任何失败时为

。

behavior_token

检查返回

通常意味着工作区未开通DI权限——该权限无法自助开通，请联系您的客户成功经理或发送邮件至

support@sumsub.com

申请启用Device Intelligence，并提供您的

clientId

（控制台左上角）与环境（沙箱/生产）信息。解决所有失败项后再进入Stage 1。

Stage 1 — Backend: mint a behavior access token

Stage 1 — 后端：生成行为访问令牌

Separate endpoint from the WebSDK token — note the

/behavior

suffix and the JSON body:

POST https://api.sumsub.com/resources/accessTokens/behavior
Content-Type: application/json
{ "sessionId": "<your-session-id>", "ttlInSecs": 1800 }

Auth: App Token + HMAC. The body is part of the signature — sign
```
ts + "POST" + path + body
```
(the empty-body shortcut from the WebSDK skill does not apply here). See
```
examples/behavior-token.sh
```
.
Response:
```
{ "token": "_act-jwt-..." }
```
— the JWT is the
```
token
```
field, not
```
accessToken
```
. (Behavior tokens carry no
```
userId
```
, unlike the WebSDK access-token endpoint.)
TTL defaults to 1800s. Mint on demand per session; don't cache globally.

Wire it as an auth-gated route on your backend (e.g.

POST /api/di/token

) that generates/looks up the

sessionId

, signs, calls Sumsub, and returns the response

token

to the browser.

与WebSDK令牌的端点分离——注意路径后缀

/behavior

与JSON请求体：

POST https://api.sumsub.com/resources/accessTokens/behavior
Content-Type: application/json
{ "sessionId": "<your-session-id>", "ttlInSecs": 1800 }

认证方式：App Token + HMAC签名。请求体是签名的一部分——需对
```
ts + "POST" + path + body
```
进行签名（WebSDK技能中的空请求体快捷方式不适用于此）。示例请参考
```
examples/behavior-token.sh
```
。
响应：
```
{ "token": "_act-jwt-..." }
```
——JWT位于
```
token
```
字段，不是
```
accessToken
```
字段。（与WebSDK访问令牌端点不同，行为令牌不包含
```
userId
```
信息。）
默认有效期为1800秒。按需为每个会话生成，不要全局缓存。

在您的后端实现一个受认证保护的路由（如

POST /api/di/token

），该路由负责生成/查询

sessionId

、签名、调用Sumsub接口，并将响应中的

token

返回给浏览器。

Stage 2 — Frontend: capture the device with Fisherman

Stage 2 — 前端：使用Fisherman采集设备信息

bash

npm i @sumsub/fisherman --save

// Shape only — the full impl (fail-open try/catch, React StrictMode teardown) is in
// examples/fisherman-vanilla.html and examples/fisherman-react.tsx.
import { init, destroy } from '@sumsub/fisherman'

// init once when the page / form mounts — getBehaviorToken() calls your Stage-1 route
const fisherman = await init({
  token: await getBehaviorToken(),
  baseUrl: 'https://api.sumsub.com',          // region-specific API host
  accessTokenUpdateHandler: getBehaviorToken, // refresh near expiry
  onError: () => destroy(),                   // never let DI block your form
})

// on the user action (e.g. login submit) — gate, fresh deviceBindingId, then confirm server-side
if (fisherman?.isDeviceIntelligenceEnabled) {
  const deviceBindingId = crypto.randomUUID()
  await fisherman.fingerprint({ deviceBindingId /*, linkedId: userId */ })
  // Fisherman posts the capture under the token's session — your Stage-3 confirm
  // call needs only the same accessToken to tie this device to the event.
}
destroy() // re-init for the next action

Rules:

Gate
```
fingerprint()
```
on
```
isDeviceIntelligenceEnabled
```
— skip silently if DI is off for the workspace.
A fresh
deviceBindingId
per action. Correlation of the capture to the confirm call is the token's
```
sessionId
```
, not this id — only the
```
deviceBindingId
```
migration path needs it echoed in the confirm body (Stage 3).
DI must never block your real flow — wrap in try/catch, fail open.
```
destroy()
```
after the action; re-
```
init()
```
for the next one. Refresh tokens via
```
accessTokenUpdateHandler
```
(or call
```
updateAccessToken(newToken)
```
manually).

Runnable starting points:

examples/fisherman-vanilla.html

examples/fisherman-react.tsx

bash

npm i @sumsub/fisherman --save

// 仅展示代码结构——完整实现（失败开放的try/catch、React StrictMode销毁逻辑）请参考
// examples/fisherman-vanilla.html与examples/fisherman-react.tsx。
import { init, destroy } from '@sumsub/fisherman'

// 页面/表单挂载时初始化一次——getBehaviorToken()调用您的Stage-1路由
const fisherman = await init({
  token: await getBehaviorToken(),
  baseUrl: 'https://api.sumsub.com',          // 特定区域的API主机
  accessTokenUpdateHandler: getBehaviorToken, // 令牌即将过期时刷新
  onError: () => destroy(),                   // 绝不让DI阻塞表单流程
})

// 用户执行操作时（如登录提交）——判断权限、生成新的deviceBindingId、然后调用服务端确认
if (fisherman?.isDeviceIntelligenceEnabled) {
  const deviceBindingId = crypto.randomUUID()
  await fisherman.fingerprint({ deviceBindingId /*, linkedId: userId */ })
  // Fisherman会将采集信息提交到令牌对应的会话中——您的Stage-3确认请求
  // 只需携带相同的accessToken即可将该设备信息与事件关联。
}
destroy() // 下次操作前重新初始化

规则：

通过
```
isDeviceIntelligenceEnabled
```
判断是否调用
```
fingerprint()
```
——如果工作区未启用DI则静默跳过。
为每个操作生成新的
deviceBindingId
。采集操作与确认请求的关联依赖令牌的
```
sessionId
```
，而非该ID——仅在迁移到
```
deviceBindingId
```
关联路径时，才需要在确认请求体中传入该ID（Stage 3）。
DI绝不能阻塞核心业务流程——用try/catch包裹，采用失败开放模式。
操作完成后调用
```
destroy()
```
；下次操作前重新调用
```
init()
```
。通过
```
accessTokenUpdateHandler
```
刷新令牌（或手动调用
```
updateAccessToken(newToken)
```
）。

可运行的示例：

examples/fisherman-vanilla.html

、

examples/fisherman-react.tsx

。

Stage 3 — Backend: confirm the event with the captured device

Stage 3 — 后端：确认事件与采集到的设备信息

Tell Sumsub the action happened; the captured device rides along via the token's session. Pick the call that matches the action — all use your standard App Token + HMAC signing (sign

ts + "POST" + path + body

, exactly like every other Sumsub API call), and additionally carry the behavior access token as the

?accessToken=

query param so Sumsub ties the captured device to the event. The

accessToken

does not replace signing — it rides alongside it:

Action	Endpoint	Doc
Login / signup / password reset / 2FA	`POST /resources/applicants/-/kyt/txns/-/data?accessToken=…`	platform event
Financial transaction	`POST /resources/applicants/-/kyt/txns/-/data?accessToken=…`	financial txn
Pre-KYC signup (create the applicant)	create applicant with `levelName` + `accessToken` + `externalUserId`	pre-KYC check

How the device links: the confirm call is App-Token + HMAC signed and carries the same behavior access token as

?accessToken=

. Sumsub correlates the captured fingerprint to the event server-side using the session the token was minted with (it reconstructs the key from your

externalUserId

; the token scopes the session). You do not put

visitorId

or a device block in the body — just identify the user + the event:

json

{
  "txnId": "<unique-id-you-generate>",
  "type": "userPlatformEvent",
  "applicant": { "externalUserId": "<your-user-id>", "type": "individual" },
  "userPlatformEventInfo": { "type": "login" }
}

Runnable:

examples/submit-platform-event.sh

. Financial-transaction and pre-KYC bodies + full field lists:

references/standalone-flow.md

deviceBindingId
-based linking (Sumsub is migrating to it) is the exception: mint the token with a
deviceBindingId
, pass the same one to
fingerprint()
, and send it at
applicant.device.deviceBindingId
. The default flow keys on
sessionId
and needs none of that.

For pre-KYC, also add

creationTrackingData.ip

to the applicant if you want Advanced IP verification, then request the applicant check to trigger the DI analysis.

告知Sumsub操作已发生；采集到的设备信息通过令牌的会话关联。根据操作选择对应的请求——所有请求均使用标准的App Token + HMAC签名（对

ts + "POST" + path + body

签名，与其他Sumsub API请求完全一致），并额外携带行为访问令牌作为

?accessToken=

查询参数，以便Sumsub将采集到的设备信息与事件关联。

accessToken

不会替代签名——两者需同时携带：

操作	端点	文档
登录/注册/密码重置/双重验证	`POST /resources/applicants/-/kyt/txns/-/data?accessToken=…`	平台事件
金融交易	`POST /resources/applicants/-/kyt/txns/-/data?accessToken=…`	金融交易
预KYC注册（创建申请人）	创建申请人时携带 `levelName` + `accessToken` + `externalUserId`	预KYC检查

设备信息关联方式：确认请求需使用App Token + HMAC签名并携带相同的行为访问令牌作为

?accessToken=

参数。Sumsub会通过令牌生成时使用的会话在服务端将采集到的指纹与事件关联（通过您的

externalUserId

重建密钥；令牌限定会话范围）。您无需在请求体中传入

visitorId

或设备相关字段——只需标识用户与事件即可：

json

{
  "txnId": "<unique-id-you-generate>",
  "type": "userPlatformEvent",
  "applicant": { "externalUserId": "<your-user-id>", "type": "individual" },
  "userPlatformEventInfo": { "type": "login" }
}

可运行示例：

examples/submit-platform-event.sh

。金融交易与预KYC的请求体及完整字段列表请参考

references/standalone-flow.md

。

基于
deviceBindingId
的关联方式（Sumsub正在迁移至此）是例外情况：生成令牌时携带
deviceBindingId
、将同一ID传入
fingerprint()
、并在确认请求体的
applicant.device.deviceBindingId
字段中传入。默认流程基于
sessionId
关联，无需上述操作。

对于预KYC场景，如果需要高级IP验证，还需在申请人信息中添加

creationTrackingData.ip

字段，然后请求申请人检查以触发DI分析。

Stage 4 — Read the results

Stage 4 — 读取结果

Dashboard: Transactions and Travel Rule → Transactions, filter by type User platform event → open the row → device details + risk labels.
Webhooks: subscribe to the transaction/event reviewed webhooks to gate programmatically (same signature-verification rules as the WebSDK skill — verify on raw bytes).
Device risk labels + scoring are the same catalog as the WebSDK path:
```
references/standalone-flow.md
```
. Full signal definitions are in the
```
sumsub-integrate-dint-websdk
```
skill's
```
references/device-signals.md
```
(install that skill for the file).

Decide which device labels are blocking (refuse / step-up) vs informational (log) — that policy is yours.

控制台：交易与旅行规则 → 交易，按类型用户平台事件筛选 → 打开对应行查看设备详情与风险标签。
Webhook：订阅交易/事件审核完成的Webhook以实现程序化控制（签名验证规则与WebSDK技能相同——需基于原始字节验证）。
设备风险标签与评分体系与WebSDK路径一致：
```
references/standalone-flow.md
```
。完整信号定义请参考
```
sumsub-integrate-dint-websdk
```
技能的
```
references/device-signals.md
```
文件（安装该技能即可获取）。

由您决定哪些设备标签需要拦截（拒绝/升级验证）、哪些仅作为信息记录（日志）——该策略由您制定。

Sandbox testing

沙箱测试

Sandbox has no real device signals; Fingerprint is simulated. Use the
```
simulationConfig
```
(
```
FpSimulationConf
```
) option on
```
init
```
to force specific signals for deterministic test outcomes.
Run the full loop in sandbox (token → fingerprint → confirm) and confirm a User platform event transaction appears in the dashboard.

沙箱环境无真实设备信号；指纹采集是模拟的。可在
```
init
```
时使用
```
simulationConfig
```
（
```
FpSimulationConf
```
）参数强制设置特定信号，以获得可预测的测试结果。
在沙箱环境中运行完整流程（令牌→指纹采集→确认），并确认用户平台事件交易已显示在控制台中。

Going live checklist

上线检查清单

Backend mints the behavior token (
```
/accessTokens/behavior
```
), signing the body, with a unique per-session
```
sessionId
```
.
Token endpoint is auth-gated (only your authenticated context can mint).
Frontend fails open — a Fisherman error never blocks login/signup.
Unique
```
sessionId
```
per session in the behavior token — it's what correlates the captured device to the confirm call (no device fields needed in the body).
You confirm the event server-side (platform event / txn / applicant) so Sumsub actually runs the analysis — capturing alone produces no verdict.
Results read from the dashboard / webhook, not from the browser.
Production App Token + secret in the prod store; sandbox values stay in dev.

后端生成行为令牌（
```
/accessTokens/behavior
```
），对请求体进行签名，且每个会话使用唯一的
```
sessionId
```
。
令牌端点受认证保护（仅您的已认证上下文可生成令牌）。
前端采用失败开放模式——Fisherman错误绝不会阻塞登录/注册流程。
行为令牌中使用每个会话唯一的
```
sessionId
```
——这是将采集到的设备信息与确认请求关联的关键（请求体中无需包含设备字段）。
在服务端确认事件（平台事件/交易/申请人），以便Sumsub实际执行分析——仅采集设备信息不会产生判定结果。
从控制台/Webhook读取结果，而非从浏览器读取。
生产环境存储中使用生产环境的App Token与密钥；沙箱环境的值仅用于开发阶段。

参考链接

```
sumsub-integrate-dint-websdk
```
— DI when the page already embeds the Sumsub WebSDK widget.
```
sumsub-integrate-websdk
```
— the base KYC WebSDK embed (token signing, webhook patterns reused here).
```
sumsub-api-auth
```
— HMAC signing shared by every Sumsub skill.
```
scripts/preflight.sh
```
— workspace validator (run before Stage 1).
```
references/standalone-flow.md
```
— concepts, event types, result reading, pre-KYC and financial-txn variants.
Get started with Device Intelligence, Generate access token,
```
@sumsub/fisherman
```
— authoritative source if this skill drifts.

```
sumsub-integrate-dint-websdk
```
——页面已嵌入Sumsub WebSDK组件时的DI集成方案。
```
sumsub-integrate-websdk
```
——基础KYC WebSDK嵌入方案（令牌签名、Webhook模式可复用至本方案）。
```
sumsub-api-auth
```
——所有Sumsub技能共享的HMAC签名方案。
```
scripts/preflight.sh
```
——工作区验证脚本（Stage 1前运行）。
```
references/standalone-flow.md
```
——概念、事件类型、结果读取、预KYC与金融交易变体。
Device Intelligence快速入门、生成访问令牌、
```
@sumsub/fisherman
```
——如果本方案内容有偏差，请以这些官方文档为准。

sumsub-integrate-dint-standalone

Original

Translation

Sumsub — Device Intelligence standalone (no WebSDK)

Sumsub — 独立版Device Intelligence（无WebSDK）

⚠️ Sandbox tokens only

⚠️ 仅使用沙箱令牌

Before you start — fit DI into the existing app

开始前——将DI融入现有应用

The loop in one picture

完整流程示意图

Vocabulary (get these right — they're load-bearing)

术语定义（务必准确理解——这些是核心概念）

Stage 0 — Preflight

Stage 0 — 预检查

Stage 1 — Backend: mint a behavior access token

Stage 1 — 后端：生成行为访问令牌

Stage 2 — Frontend: capture the device with Fisherman

Stage 2 — 前端：使用Fisherman采集设备信息

Stage 3 — Backend: confirm the event with the captured device

Stage 3 — 后端：确认事件与采集到的设备信息

Stage 4 — Read the results

Stage 4 — 读取结果

Sandbox testing

沙箱测试

Going live checklist

上线检查清单

See also

参考链接