哪种 Shufti 集成模式最适合您的技术栈？API、SDK 和 Web 客户端详解

根据 Postman 发布的《2024 年 API 现状报告》，43% 的开发者认为 API 集成是他们最耗时的开发任务。对于在受监管产品中添加身份验证功能的团队而言，错误的集成方案不仅会延缓交付速度，还会造成合规性漏洞，而这些漏洞日后弥补起来代价高昂。

Shufti 提供五种不同的集成模式，每种模式都针对不同的技术要求、部署限制和上线时间表而设计。本指南将每种模式与其最适用的场景对应起来，以便您的团队只需做出一次决策即可快速部署。

为什么 SDK 或 API 二进制文件无法达到预期效果？

大多数面向开发者的身份验证内容将集成决策简化为二元选择：SDK 或 API。这种框架忽略了其他三种模式，而这三种模式的存在恰恰是因为并非所有产品都是后端服务，也并非每个团队都有数周的工程开发时间。

Shufti 的集成架构围绕着需要验证的产品的实际分布而构建：原生移动应用、基于 Web 的用户引导流程、无代码合规性堆栈以及具有数据主权要求的企业部署。每种模式都服务于其中一种场景。RESTful API 本身并不比 Web 客户端更好；它更适合特定类型的团队构建特定类型的产品。

舒夫提的五种整合模式

1. RESTful API

Shufti 的 RESTful API 让您的后端能够完全掌控验证流程。您的服务器提交验证请求，Shufti 处理该请求，并将结果通过 Webhook 异步返回（验证完成后，HTTP POST 请求体将发送到您的端点）。同一个 API 端点涵盖所有 Shufti 产品：文件验证、人脸匹配、反洗钱筛查、KYB（了解你的客户）等等。

在以下情况下使用此方案：需要服务器间验证、批量处理或与现有编排层紧密耦合。金融科技和金融服务公司的后端工程师通常会选择此方案，因为验证逻辑需要位于他们自己的用户生命周期管理流程中，而不是客户端。此方案的技术难度在五种模式中最高，但控制程度也最高。 超过 83% 的企业工作负载依赖 API 进行数据通信和自动化。Shufti 的 API 从一开始就被设计成可以运行在该基础设施内。

2. 移动 SDK

Shufti 的移动 SDK 适用于 Android、iOS、Flutter、React Native 和 Cordova。它们直接在设备上管理文档捕获、活体检测和面部生物识别，并将处理后的结果传递给 Shufti 的验证流程。

在以下情况下使用此功能：您正在构建原生移动应用程序，并且生物特征采集质量至关重要。移动 SDK 直接访问设备摄像头管道，这意味着它们可以检测到基于浏览器的渠道无法比拟的摄像头注入和呈现攻击。这符合身份验证器保证原则。 NIST SP 800-63B它认可原生设备访问是生物识别验证的最强渠道。SDK 负责处理采集用户体验；您的应用程序负责管理会话流程。

3. Web客户端（定制验证页面/iFrame）

Shufti 的托管 Web 客户端是一个预构建的验证流程，您可以通过 iFrame 将其嵌入到浏览器会话中。 舒夫提 负责用户界面、文档和生物特征采集以及结果交付。验证完成后，您会收到一个 webhook，无需自行构建或维护验证用户界面。

适用于以下情况：您需要基于 Web 的注册流程，但又不想构建和维护验证 UI。这通常是 Web 产品最快的方案：集成只需几天而不是几周，数据处理义务也无需承担。 GDPR 第 32 条 这些功能由 Shufti 端管理，无需构建移动 SDK。技术难度为低到中等。

4. 旅程构建器

旅程建设者 是 Shufti 的无代码验证流程配置器。合规团队和运营主管可以通过可视化界面组装多步骤验证工作流程（文件检查、人脸匹配、反洗钱筛查、地址验证），而无需编写任何代码。

在以下情况下使用此功能：您需要快速部署或迭代验证流程，但受限于工程能力而非技术可行性。对于需要多个特定市场流程的团队来说，这也是理想之选：不同国家/地区、不同文档类型、不同反洗钱观察名单，所有流程均可独立配置。 Journey Builder 库 包含覆盖 30 多个市场的预置流程。上线时间：首次部署只需数小时到一天。

5. 本地

Shufti 的本地部署方案将整个验证堆栈运行在您自己的基础设施内。所有验证数据都不会离开您的环境。它采用相同的 RESTful API 接口，您可以完全控制计算层、数据驻留和审计跟踪。

适用于以下情况：数据主权是硬性要求。银行和金融机构，尤其是在数据驻留要求严格的司法管辖区，或者受限制云端数据传输的特定行业框架约束的企业，通常会选择此方案。此方案上线时间最长，但安全性也最高：完全消除了云端数据暴露的风险。

选择合适的模式：一个实用的框架

两个问题就能迅速缩小选择范围。

• 首先，您的产品部署在哪里？原生移动应用指向移动 SDK。Web 产品默认使用 Web 客户端或 RESTful API。缺乏工程时间的团队可以从 Journey Builder 开始。受监管且有数据驻留要求的企业需要部署在本地。
• 其次，有多少工程时间可用？如果时间以小时计算，Journey Builder 是切实可行的选择。几天到一周：Web 客户端或 API。一到两周：API 或移动 SDK。开放式企业部署：本地部署。

将 KYC 功能集成到金融产品中的团队通常会先使用 Web 客户端以实现最快的合规上线，然后在核心工作流程验证无误后迁移到 API。有关规划该生命周期的更详细指南，请参阅[此处]。 KYC 集成 实现顺利合规入职的策略。

同时使用多种模式

在单个产品中使用多种 Shufti 集成模式是常见且符合架构设计原则的。例如，金融服务应用程序可能运行 Web 客户端进行基于浏览器的用户注册，在其原生应用程序中运行移动 SDK，以及运行 RESTful API 进行后台反洗钱复查，这三种模式都连接到同一平台、仪表板和合规数据。要深入了解 API 层如何在更广泛的架构中运行，请参阅相关文档。 身份验证服务 堆栈，见 KYC API：它是什么，它是如何工作的，集成和用例。