品牌为商品加入 NFC 防伪时，往往不只希望顾客看到一个“验证通过”的提示。顾客还需要核对手中的商品、找到使用说明，必要时联系售后。如果这些内容已经在你的官网上，把验证放在同一网站，就能让顾客顺着完成这些事情。
BrandGuard 提供三种安排：由我们托管验证页面；由我们验证成功后，带顾客进入你的产品页面；或者让顾客先访问你的官网，再由你的网站向我们请求验证。这篇文章重点介绍第三种，也就是 Live Verification API：你保留官网的设计和内容，由 BrandGuard 核验标签提供的安全信息。
顾客碰一下标签，接下来会发生什么？
以一件带安全 NFC 封签的限量商品为例。顾客收到商品后，用支持 NFC 的手机轻触封签并打开链接。这个链接首先访问品牌自己的域名，让这次查验从品牌官网开始。
接下来，品牌的网站服务器，也就是网站后端，将本次读取信息发送给 BrandGuard。我们检查标签的安全凭据及其与已登记单件记录的关联，把核验结果返回给品牌的网站后端。品牌网站再根据这份响应，在自己的页面上显示结果，并在能识别单件时关联相应产品资料。
- 手机轻触 NFC 标签顾客用支持 NFC 的手机读取标签，打开其中的链接。
- 访问品牌网站链接中的首个访问地址属于品牌自己的网站域名。
- 品牌网站后端请求核验品牌的网站后端把本次读取信息发送给 BrandGuard。
- BrandGuard 返回核验结果核验完成后，BrandGuard 把判定和可提供的信息返回给品牌的网站后端。
- 品牌网页显示结果品牌的网站后端将结果交给页面呈现，顾客在品牌官网查看本次查验信息。
使用前，需先完成网站接入和标签写入。
网站可以等验证完成后再呈现页面，也可以先显示“正在验证”的提示。两种做法都应在取得本次判定后才显示结论；暂时无法取得结果时，应说明尚未完成验证，避免让顾客把网络问题理解成商品是假货。
结果区要回答顾客真正关心的问题
“这次标签读取通过了吗？对应的是我手里的这件商品吗？”一个有用的验证区，首先要帮助顾客回答这两个问题。完成验证后，API 返回判定，并在可提供时附带单件标识、验证次数和封条信息。无法识别标签或验证未通过时，其中一些资料可能没有值；网站应如实显示当前状态。
取得单件标识后，网站可以把结果与自己的商品资料对应起来，在旁边放上照片、型号和使用说明，方便顾客核对。API 提供的是验证信息；商品图文由品牌提供。没有取得可确认的单件资料时，不能把某件商品的介绍当作已经验证过的关联。
有效验证次数统计的是 BrandGuard 接受并记录的验证，不是买家人数或销量。显示次数和验证时间时，页面应使用这次响应中可提供的数据；刷新页面、重试同一次请求或查看历史记录，都不代表手机又读取了一次实体标签。
核对之后，顾客还能在同一网站做什么？
顾客已经拿着商品来到你的官网，验证结果可以成为后续服务的入口。例如，限量收藏品旁边可以放上系列介绍和保养建议；配件产品可以提供安装说明；已有保修登记的品牌，可以在结果旁边提供登记入口。顾客不用再寻找另一个网站或重新搜索型号。
这些内容和服务由品牌网站安排，验证 API 为页面提供本次查验信息。这样既能延续品牌原有的页面设计，也能让顾客在有疑问时直接联系售后。保修资格、购买凭证和会员权益，仍按品牌自己的业务规则处理。
选择官网 API 接入，双方各自做什么？
BrandGuard 根据产品和包装准备合适的安全 NFC 标签，为每枚标签按选定方式完成写入，并提供在线验证服务。托管、验证后进入品牌网站，以及官网 API 接入，都使用 BrandGuard 的验证服务；标签的首个访问地址则按项目选择准备。
采用本文介绍的 API 方式时，你的网站团队负责后端连接、接收 BrandGuard 返回的结果，以及页面上的显示和产品资料对应。现有网站可以继续使用；只有前端页面的静态站，也可以由开发人员增加后端或同域名的服务器处理功能后接入。若选择 BrandGuard 托管，则不需要客户网站或客户侧 API 开发。
需要说明的是，我们检查的是标签的安全凭据及其与已登记单件记录的关联，并没有隔空检验商品实物。品牌仍需确保标签正确结合到商品上、登记资料准确。成分、品质或历史来源等信息，需要相应证据支持。
托管、验证后进入官网，还是官网 API：怎样选择？
选择哪种方式，首先看你希望顾客在哪里完成查验，以及是否已有负责网站的团队。没有官网，或希望直接使用现成结果页，可以选择 BrandGuard 托管；希望验证后回到自己的产品页面，可以选择由 BrandGuard 验证成功后再跳转；希望从第一次访问开始就在自己的域名上完成流程，则选择 Live Verification API。
Solution C把这三种安排分别列为 C1、C2、C3。它们都由 BrandGuard 核验标签，区别在于顾客从哪里进入、在哪里看结果，以及客户网站需要完成哪些工作。
左右滑动查看完整表格
| 选择 | 顾客在哪里查看 | 客户需要准备什么 |
|---|---|---|
| C1 · BrandGuard 托管的品牌验证页 | 在 BrandGuard 域名下、按您的品牌资料配置的页面查看结果。验证成功且资料可用时，可显示您的 Logo、产品图片和公开属性。 | 品牌标志和产品资料；无需客户网站或客户侧 API 开发。 |
| C2 · BrandGuard 验证后进入客户网站 | 先经 BrandGuard 验证，成功后进入客户指定的静态或动态产品页面。 | 准备目标页面；如果还要显示本次验证结果，接入官方组件或 WordPress 插件。 |
| C3 · 客户网站通过 API 验证 | 手机先访问客户域名；客户后端向 BrandGuard 请求验证，收到响应后由客户网页显示结果。 | 准备后端调用、响应处理、结果页面，以及单件编号与自有产品资料的对应关系。 |
每枚标签按选定方式写入。修改网站设置，不会自动改掉已写入标签的首个访问地址。
C2 的目标可以是你的静态或动态产品页面，具体连接方式根据网站和目标地址来配置。若希望目标页同时显示本次验证结果，可以接入官方验证组件；WordPress 或 WooCommerce 网站也可以使用官方插件。仅跳转到网页，并不会自动把验证结果显示在那里。
一个实际测试：标签通过了，封条却已经打开
对于有封签的商品，顾客还会关心包装是否已经打开。这与标签是否通过认证，是两项不同的检查。一个真实标签在封签被撕开后，仍可能通过标签认证，同时报告封条已打开或发生变化。
在一次测试环境联调中，我们用 Android 手机先后读取同一枚采用 Secure E 配置的 NTAG® 424 DNA TT 标签三次。前两次没有报告开启；撕开封签后，第三次报告了开启，有效验证次数依次为 1、2、3。这个测试确认了客户网站发起验证、接收判定并显示封条变化的流程，范围限于该标签、手机和测试环境。
网站应把标签认证结果与可提供的封条状态分开显示，方便顾客决定是否检查包装或联系品牌。普通 NTAG® 424 DNA 没有 DNA TT 的电子开封检测功能。如果你的买家也需要核对包装状态，可以结合防拆封签的安装位置和打开方式，一起做实物测试。
先用一件样品，把顾客会遇到的情况走一遍
准备接入时，把网站地址、商品情况和希望顾客看到的信息交给 BrandGuard，并请网站负责人一起参与。双方确认标签、访问路线和页面安排后，先用少量样品把整个流程跑通。
验收时，不只看一次成功读取。还要检查无法识别标签、暂时取不到结果、重复访问，以及适用标签开封后的显示。结果清楚、资料对应正确、下一步提示容易理解，顾客才知道这次核对了什么，以及有疑问时该找谁。
常见问题
只有静态网页，也能接入 Live Verification API（C3）吗？
可以由开发人员增加后端或同域名的边缘服务后接入。验证请求由服务器发出，所需凭据也保存在服务器端；只在网页里加入一段显示脚本还不够。
已经在用 WordPress 插件，还需要换成 API 吗？
不一定。插件适合先由 BrandGuard 验证，成功后进入网站，由官方面板显示这次结果。若希望手机先访问自己的域名，并由网站团队自行设计结果界面，再考虑 Live Verification API。
只改网站设置，就能让已写标签先访问我的域名吗？
网站设置不会改掉标签中已写入的首个访问地址。若原标签先访问 BrandGuard，改用 C3 前需要检查写入配置，并确认标签如何准备。这与调整验证成功后打开哪个页面，是不同的事。
普通跳转会把验证结果自动带到我的网页吗？
不会。C2 的普通跳转负责在成功验证后打开你的网页；如需在该页显示本次结果，还要接入官方组件或 WordPress 插件。C3 则由你的网站后端调用 Live Verification API、接收 BrandGuard 返回的结果，再交给网页显示。C1 的结果直接显示在 BrandGuard 托管页面。
业务资料 API 或历史验证记录能代替实时验证吗？
不能。业务资料接口用于同步单件资料或查询历史记录；实时验证 API 核验的是这次标签读取。过去一次成功记录，不能作为新的读取已经通过验证的依据。
讨论你的官网 NFC 验证方案
BrandGuard 可以与你的网站团队一起确认适合的标签、接入方式和样品验收范围。
讨论网站验证接入 →