要求提供证据
您的申请需要提供进行某项操作所需的证明——例如，已年满 18 岁或已通过人工验证。
集成模型
您的申请需要提供证明。Checkify 负责运行客户流程。您将收到结果并决定下一步操作。
您的申请需要提供进行某项操作所需的证明——例如，已年满 18 岁或已通过人工验证。
Checkify 确定是否存在足够的证明，或者客户是否需要完成额外的验证。
您的服务器确认结果，并允许、阻止或继续执行受保护的操作。
REAL API
客户完成 Pass 会话后，您的后端会使用站点 API 密钥验证 request_id。切勿将站点 API 密钥放在浏览器代码中。
要求
POST /v1/qr/results/verify
Authorization: Bearer YOUR_SITE_API_KEY
Content-Type: application/json
{
"request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
"required_claims": ["age_over_18"],
"consume": true
}
回复
{
"success": true,
"status": "completed",
"approved_claims": {
"age_over_18": true
}
}
浏览器或插件会存储一个请求 ID（通常作为 checkify_token）。您的服务器拥有最终权限——请在允许操作之前确认 approved_claims。
您可以提出哪些要求
更改每次旅程的请求类型或所需声明——无需重建验证基础设施。
要求设定年龄门槛，例如 13 岁以上、16 岁以上、18 岁以上或 25 岁以上。
age_over_18确保填写表格、登录和进行滥用控制时都是真人操作。
human_verified根据风险要求选择合适的保证级别——从基本保证到高保证。
basic → highAssurance保证级别和具体的证据选项取决于行程、设备和配置的策略。有关声明名称，请参阅服务器验证指南。
你如何整合
首先选择与你的技术栈相匹配的路径。所有生产环境路径都使用相同的证明模型。
WordPress、WooCommerce 和 Joomla / J2Commerce 用于常见的 CMS 和结账网关。
WordPress 指南 →CDN 嵌入和绑定表单，适用于自定义网站。启动 Pass 会话并将令牌写入表单。
嵌入文档 →使用 POST /v1/qr/results/verify 和站点 API 密钥 (csk_) 确认结果。
服务器验证 →使用 Pass 和 QR 交接实现场所和设备到设备的旅程。
后勤人员指南 →Shopify 和 Wix 处于候补名单/即将推出状态，此处未将其列为实时生产集成。
证书
Checkify 使用两种不同的凭据。在错误的地方使用错误的凭据是最常见的集成错误。
Browser embed, WordPress, Joomla — frontend only
Backend verify API — server only, never in JavaScript
结果交付
对于标准网站和结账流程，请在提交受保护操作时验证服务器上的 request_id。自定义前端可选择使用状态轮询。
您的页面或插件发起一个绑定到您网站的 Checkify Pass 请求。
客户在 Checkify 应用程序中进行验证或批准。
调用验证端点，检查 approved_claims，然后允许或阻止。
目前，标准集成无需使用通用验证 Webhook。合作伙伴出站 Webhook（例如 GoHighLevel）需要在业务控制面板中单独配置。
文件
请参考这些指南深入了解具体实施方案。本页主要介绍集成模型。
为您的第一个受保护操作嵌入密码并绑定表单。
打开快速入门指南 →公共集成使用的端点，包括验证和状态。
打开 API 文档 →数据检查属性、绑定表单选项和请求类型。
打开嵌入式文档 →站点 API 密钥、required_claims、consume 和 signed_result。
开放服务器指南 →