商户接入

A2B 设计成商户不需要懂区块链。链上那层完全活在用户的智能账户和 A2B 合约之间。从商户这边看,接入就跟其他现代"支付 + 交付"API 差不多。

谁可以接入

任何提供以下内容的商户:

• 一个公开 API,用来列商品和创建发票;以及
• 一种交付确认机制 —— webhook、轮询端点,或任何能告诉 Platform "订单已完成"的方式。

这就是最小接入面。商户不需要钱包、DID、智能合约、签名密钥,也不需要链上存在。

我们研究过多个品类的接入路径 —— 数字充值、打车、旅行、电商、SaaS、长尾商业、Agent 虚拟卡基础设施。协议本身不偏袒任何特定类别。

集成长什么样

商户至少需要暴露:

1. 目录 / 搜索端点。Agent 查询可售商品。
2. 发票端点。给定一个选择,商户返回:
   • 支付目标(地址,或 Platform 能转换的路由信息)
   • 支付金额(以商户接受的结算币种)
   • 唯一发票 id
3. 交付信号。订单完成时,商户发出交付物(码、URL、确认号、收据),并把订单标记为已交付。

其余 —— 资金托管、策略强制、用户同意、审计记录 —— 都由 ATEL Platform 在协议侧处理。商户收到结算的方式,和其他支付处理商没区别。

商户得到什么

• 接入 Agent 驱动的流量。 用户跟 AI Agent 对话就能从你这里买东西,不用离开对话。你不搭 Agent 技术栈就成为 Agent 生态的一部分。
• 密码学交付证明。 商户履约的每一单都有履约哈希的链上记录。退单、事后争议都可以用数据说话,而不是讲故事。
• 稳定的结算行为。 只有在合约看到一张和商户报价一致的已提交发票之后,钱才会到账。链上流程不允许部分抽走或静默改向。
• 比原生加密集成更简单的接入面。 商户不需要管钱包、签名密钥、链上手续费。链上的复杂度被 Platform 吸收。

商户需要承诺什么

• 幂等的交付确认。 合约和审计记录假设一单要么进 DELIVERED、要么进 FAILED —— 状态来回跳会让 Platform 在审计里打标。
• 诚实的截止时间。 你报多长交付窗口,Intent 的 deadlineUnix 就尊重它。错过窗口的订单自动退款;过期订单商户收不到钱。
• 密封交付物。 敏感交付物(礼品卡码、凭证)通过 Platform 的交付端点返回,会被密封到用户公钥。加密不用商户自己实现 —— Platform 搞定 —— 但商户要把交付物的明文返回,信封才能被构造出来。

集成模式变体

不同商户 API 适合不同集成模式。我们一般区分:

• 直接 Platform-商户集成。 Platform 调商户 API,接收 webhook。最简单,覆盖常见场景。
• 第三方聚合器集成。 商户通过聚合器 API 触达(比如覆盖很多礼品卡品牌的聚合器)时,聚合器从协议角度扮演商户同样的角色。
• Agent 虚拟卡集成 (基础设施变体)。Agent 发行的虚拟卡可以在任何接受该卡网络的商户使用;链上这边管的是卡的充值与单次消费授权。

开启集成对话

如果你运营商户或聚合器,想接入 A2B,请通过 Resources · Changelog 列出的渠道联系我们。技术细节 —— webhook 形状、认证、币种处理、退单语义 —— 一起讨论解决;协议本身不规定超过本页所述的内容。