Skip to main content
Grupo CB 主协议是 CBPay 为已验证企业账户生成的预填充文件。创建信封前, CBPay 会解析企业法定身份、已验证地址、已启用服务、费率以及当前 CBPay 签名。如果必填数据没有可信来源,系统不会创建信封。 签署仪式必须由企业账户的 owner 或 operator 人工完成,并要求明确同意和 一次性新 OTP。API key 不能用于签署。 测试请求请使用 https://cryptobank.qbank.cl/platform;只有生产环境使用 https://api.qbank.cl/platform。

资格与状态

账户必须是已激活且 KYB 已批准的企业账户。信封按组织和账户隔离;访问 其他账户的 ID 会返回 404 not_found。 系统不存在 draft 或通用的 pending 状态。 当 lang=en 时,组织必须设置 contract_counsel_approved_en=true。西班牙语 签发不需要该英文 counsel gate。模板版本为 v13.3,模板哈希和 CBPay 签名版本会冻结在信封快照中。

价格覆盖与显示金额

组织签发 endpoint 会在创建信封前检查价格覆盖。如果已启用的服务没有 effective fee row,系统返回 HTTP 422 contract_unfillable,并在 missing 数组中使用 pricing:<flag> 形式的值。明确的零百分比、零固定 费用表示有效的免费配置;没有 row 不满足覆盖。transfers 和 swaps 豁免此 fee-row gate。 在运营上,v13.3 正文不再嵌入固定价格表。附录 A 指向客户当前有效的佣金 计划,并按照与门户/管理员定价面板一致的本地化类别对适用条目分组,例如 法币支付、合规、卡片、银行业务、钱包和其他。签发时以 effective 配置为 准;组织管理员应修复缺少的价格覆盖后重新签发信封。 内部 margin fx_spread、settlement_spread 和 swap_spread 不会出现在 账户侧 fill_snapshot 或 PDF 价格附录中。org-admin 视图仍保留完整价格 snapshot 供审计。

签署仪式

1

列出并打开信封

调用 GET /v1/me/contracts/envelopes,再调用 GET /v1/me/contracts/envelopes/{envelopeID}。列表支持 page 和 page_size(默认 50,最大 200)。列表响应使用 items;详情包含只 追加的 events,每条事件的名称位于 event。
2

签署前下载文件

GET /v1/me/contracts/{envelopeID}/pdf 返回 PDF 二进制。保存并检查 法定名称、地址、服务和费率。文件已由 CBPay 预签名,但在仪式完成前 仍然是 pending_client。
3

提交签署人身份和同意

签署人姓名和职务放在 JSON 中。consent 必须是 JSON 布尔值 true。 客户的手写签名放在 signature_png 中,内容为 Base64 编码的 PNG。 可选的 data:image/png;base64, 前缀也会被接受。OTP 不是 JSON 中的 code 字段;请将新的一次性 token 放在 X-OTP-Token header 中。
4

确认完成

成功响应会将信封返回为 completed。再次读取资源并下载 PDF,保存 final_hash。contract_envelope_completed 事件发送给 org-admin audience。客户 claim 成功后,平台还会自动记录 Client Journey milestone contract_signed,actor 为 system:contract-ceremony; 这不是管理员手工 milestone。

客户签名图片

每次客户签署都必须提供 signature_png。API 接受带或不带 data:image/png;base64, 前缀的 Base64 PNG。claim 信封前,系统会解码并 验证图片:Base64 最多 700,000 个字符,解码后最多 512 KiB,最小尺寸 64×16 像素,并且至少包含 200 个有墨迹的像素。验证失败返回 HTTP 422 invalid_signature_image;message 会说明验证原因。 签署成功后,PNG 会嵌入最终 PDF 的客户签名区块。列表和详情响应只返回 布尔值 has_client_signature,不会返回签名字节或存储 key。没有图片的 早期信封继续按原有方式渲染文字签名区块。

签署通知

签发或重新签发信封时,账户会收到通知邮件,邮件附带预签署 PDF。配置门户 URL 后,邮件会显示 “Ir a firmar”(西班牙语)/“Review and sign”(英语) 按钮,并在纯文本中包含相同的 /contracts/{id} deep-link。邮件发送是 best-effort;请以信封资源和事件 作为事实来源。

响应示例

列表响应:
完成响应:

完成事件

订阅 contract_envelope_completed 来更新组织管理员的信封队列。该事件 只发送给 org-admin;账户会通过 email 收到最终 PDF,并可以通过自己的 信封 endpoint 读取。
签署时间和语言仍可从信封详情读取。不要用 email 到达作为完成判据;应 使用事件和资源状态。

错误与解决方案

合同公开验证

每份最终 PDF 都在签署页带有验证区块:含公开 oracle URL 的二维码,外加 同一 URL 和 12 位短文档哈希的说明。任何持有该代码的人都可以确认文件真伪, 无需账户或 API key。 verify_code 随附在信封详情(GET /v1/me/contracts/envelopes/{envelopeID})和 organization-admin 信封详情中,因此客户随时可以找回链接。代码以 K 开头,后接信封标识和 截断的 HMAC(1+32+20 个字符);无法伪造或枚举。 浏览器收到品牌 HTML 卡片;API 客户端发送 Accept: application/json(或不带 Accept 头)并收到 JSON:
该 oracle 仅公开验证事实:有效性、类别、信封状态、签发方、客户法定名称、 模板版本、语言、信封短 ID、两个哈希、时间戳以及双方签署情况。条款、 价格、地址、邮箱及任何其他运营数据绝不离开服务器。被篡改或虚构的代码 返回 HTTP 404 及通用消息 this verification code does not correspond to any contract issued by this platform;请求按 IP 限流(429 too_many_attempts)。

常见问题

不可以。必须是已激活且 KYB 已批准的企业账户,签署人必须是 owner 或 operator member。
不可以。当前 handler 从 X-OTP-Token header 读取新的一次性 token。 JSON code 不是当前签署合同的一部分。
信封返回 contract_unfillable;CBPay 不会发出必填字段未解析的签名 PDF。
不可以。completed 是终态。只有 pending_client 可以带原因 void, 然后重新签发。
可以使用同一信封和新的 OTP。原子 claim 会阻止第二次签署;完成的信封 返回 contract_invalid_state。
没有。HTTP 404 及 this verification code does not correspond to any contract issued by this platform 表示代码复制错误或属于另一个信封。 请从信封详情重新读取 verify_code,或扫描签署页上打印的二维码;该 oracle 从不确认或否认其他信封的存在。
不会。代码在信封的整个生命周期内有效。如果信封被作废,同一代码将返回 failed 而不是 ok。

双语下载 / Download in both languages

available_langs 是门户按钮的权威来源;以签发语言开头——西语签发的信封为 ["es"] 或 ["es", "en"](英语签发则镜像)。英文需要 counsel 批准和当前模板。
请求另一语言时,PDF 从冻结快照渲染,不会单独存储或计算哈希。封面说明签署 PDF、哈希、§11 的西班牙语优先规则和 oracle URL。它不是第二份签署文件。

FAQ / 常见问题

不是。签发语言 PDF 才是签署文件。
英文需要 counsel 和当前模板;请检查 available_langs。
最后修改于 2026年10月12日