在不发布应用版本的情况下更改验证流程

安装验证 SDK 使用工作流 ID 而不是在代码中详细说明流程，并且每次验证开始时，流程配置都从服务器获取。当您在控制面板中重新发布工作流时，您的应用的每个已安装副本中的下一次验证都会运行新版本。无需构建、无需应用商店审核、无需强制更新。

正因如此，在周二下午收紧人脸识别门槛，或者在某个市场增加地址验证步骤，而无需移动端发布流程，才是切实可行的。它并不能完全取消发布流程，而明确界限正是确保该方法安全性的关键。

如何 SDK 获取其配置

通过属性配置的挂载点承载着代码中的流程：国家/地区、ID 类型、运行步骤、品牌标识和文案。更改其中任何一项都意味着要修改代码，而在移动端，这意味着需要向应用商店提交一次更新，之后用户还要继续使用旧版本数周。

工作流挂载点携带一个标识符。 SDK 挂载时将其发送到服务器：

GET /api/kyc/workflows/:workflowId
Authorization: Bearer pk_…

响应包含已发布的配置、为您的组织启用的 ID 类型和品牌标识，以及 SDK 并以此构建流程。根据工作流文档 （在新标签页中打开），工作流必须属于…… API 关键的组织和环境将被发布；其他任何操作都会返回一个无法区分的结果。404 workflow_not_found，以及 SDK 报告通过onError而不是默默地运行另一个流程。

在 React Native 应用中，整个集成过程如下：

import { MyazaKYC } from "@myazahq/kyc-sdk-react-native";

<MyazaKYC
  apiKey="pk_live_…"
  workflowId="wf_AbC123dEf456"
  userId="user_42"
  userData={{ firstName: "Jane", lastName: "Doe" }}
  metadata={{ requestId: "order_1001" }}
  onSubmit={(submission) => console.log(submission.verificationId)}
  onError={(err) => console.error(err.code, err.message)}
>
  Verify Identity
</MyazaKYC>

工作流程的设置会优先于任何重叠的属性。如果您传递一个country如果工作流设置了某个值，则使用该工作流的值。

重新发布可以改变什么

一切用来描述流程而非人物的事物：

• 国家/地区、身份证类型以及每种身份证的验证规则。

• 采集步骤和附加信息：联系代码、地址证明、 NFC 芯片采集步骤、问卷调查、地址采集、一次运行采集多个 ID。

• 实时性检测方法（手势、屏幕闪烁序列或两者兼有）。

• 品牌文案、征求意见文案和成功文案。

• 政策包括年龄限制以及如何处理不匹配的身份信息。

• 决策图 （在新标签页中打开）：哪些结果获得批准，哪些结果需要审核，哪些结果被拒绝。

举个例子来说明这种变更如何使之成为常规操作：贷款机构发现一系列自拍照片因光线不足而匹配失败，他们希望这些申请能够进入审核流程，而不是直接拒绝。他们在应用构建器中添加了一条规则，在沙盒环境中进行测试，然后重新发布。之后，每个应用版本都会在下一次验证时应用这条新规则。

还有什么需要发布

有五样东西存在于你的代码或二进制文件中，无论你如何重新发布，它们都不会消失。

每个用户的数据。 userId，userData和metadata这些都是运行时值。工作流是一个模板，所有运行它的人都可以共享它，因此它无法承载这些值。

回调函数以及你的应用如何处理结果。你如何处理onSubmit，onError后端 webhook 就是你的代码。

SDK 版本。工作流只能使用已安装版本的功能。 SDK 明白。已记录的最低要求workflowId网页版版本为 2.2.0 SDK React Native 版本为 2.1.0，Flutter 版本为 2.2.0。早期版本的 Web 和 React Native 会忽略 ID，仅使用 props 运行，如果工作流嵌入似乎没有任何效果，这是首先要检查的地方。

原生功能和权限。读取护照芯片需要 React Native 或 Flutter。 SDK 浏览器无法做到这一点。iOS 上的地址捕获需要应用中包含位置使用字符串，否则权限请求会崩溃。如果您计划启用需要原生权限的步骤，请先提供相应的权限。

工作流 ID 本身。工作流的作用域限定于特定环境，因此沙箱和生产环境的工作流是不同的。请将 ID 保存在配置中，而不是硬编码，这样迁移到新的工作流只需更改配置，而无需更改代码。

为什么更改实时流量仍然安全

更改所有用户在仪表盘上看到的内容听起来很冒险。但工作流版本控制的四个特性使其易于管理。

草稿与正式发布版本是相互独立的。编辑已发布的流程只会更改其草稿版本。集成会一直读取上次发布的快照，直到您再次发布为止。

每次发布都会进行版本控制。每次发布都会更新版本号，并添加一个不可变的历史记录条目，您可以查看该条目或从中恢复。如果更改出错，您只需恢复一个已知版本，而无需重新构建一个新版本。

正在进行的工作不会被移动。每个申请人的会话链接都包含创建时冻结的已发布配置，因此重新发布不会更改已存在于用户收件箱中的链接。决策运行会锁定到其初始版本，因此更严格的图表不会重新决定正在进行中的申请。

每个结果都可追溯。每次验证都会记录工作流 ID 和运行版本，这两项信息都会显示在验证 Webhook 中。workflowId和workflowVersion保存这两份文件。六个月后，如果有人问起为什么某个申请人在较宽松的规则下获得批准，这份文件就能准确地告诉你具体适用的是哪些规则。

一项有意设置的限制是：工作流的范围（即其验证内容，例如仅验证地址或人脸重新认证流程）在首次发布前可编辑，发布后将被锁定，因为验证和链接都依赖于该 ID 的含义。要更改范围，请创建一个限定范围的副本，该副本将以新工作流 ID 下的新草稿形式创建。

推出一项变革

工作流程的变更会在用户下次验证时生效，这非常强大，同时也意味着无需按应用版本逐步推出。将发布操作视为部署操作：

1. 在沙盒工作流程中进行更改，并使用已发布的测试 ID 测试每个受影响的路径。

2. 检查决策图的每个分支是否都以某个状态结束，以及任何新步骤的原生权限是否已包含在您发布的应用程序中。

3. 将相同的更改应用到生产工作流程并发布。

4. 观看首批结果workflowVersion：批准率、审核率和拒绝率，以及审核队列容量。

5. 如果出现问题，请从历史记录中恢复之前的版本并发布。

6. 告诉您的支持团队发生了哪些变化；用户会在您的控制面板之前注意到新的步骤。

经验法则

如果它描述的是流程，请将其放入工作流中，并通过发布进行更改。如果它描述的是人员、设备或您的应用如何处理结果，则应将其放在代码中，并通过版本发布进行更改。围绕某个主题构建一次集成。workflowId保持你的 SDK 相当新，以前的大部分发布内容现在都变成了正式发布。