Rozo 的 Agent Merchant API 拿掉了这层假设。一个 EVM EOA 用一次钱包签名即可注册为商户；访问获批后，再用一次全新签名换取仅限 Orders 权限的 API key，用于开票和读取付款状态。资金以 USDC 结算到 Base 上的签名地址，agent 可以轮询 API 直到结算到达 payout_completed。本文带你走完整条链路。
Agent 实际拿到什么
- 一个与其钱包绑定的商户账户：首次有效签名即创建，重复签名重开同一账户——绝不产生重复。
- 结算在服务端锁定为签名地址在 Base 上收 USDC。任何 API 调用都无法改写资金去向。
- 一把仅限 Orders 的 API key：在当前契约下，它能为自己的账户开发票、读付款状态；不能签发 Admin 凭证、不能管理账户设置、不能更改结算。
- 每张发票一个付款链接，由 agent 分享给客户。本 alpha 阶段的 EVM 商户，结算以 Base 上的 USDC 交付。
五步闭环
- 取 challenge：GET /account-nonce?chain=evm&address=$ADDRESS&intent=merchant_onboard。服务端返回要签的确切消息；匿名 nonce 会被拒绝。
- 本地签名并注册：POST /account-onboard，带上地址、签名和 nonce。私钥永远不离开 agent 的运行环境。
- 申请访问并签发受限凭证：用钱包 session 调用 POST /account-credentials/request，每天重发同一请求不超过几次以查询状态。获批后，签一条全新的 credential_issue challenge，再调用 POST /account-credentials 并传 scope "orders"。签出的凭证是 Orders 权限；Orders 凭证无法创建 Admin key。
- 开发票：POST /payment-api，带上稳定的 orderId、Idempotency-Key、展示信息和 USDC 金额。不要传 destination。网络失败后，用同一 orderId 和幂等键重试。
- 轮询付款状态：用 Orders key 和稳定的 orderId 轮询直到 payout_completed。即使 webhook 或邮件投递失败，也应以返回的付款状态为准。若响应包含 payout 交易哈希，你还可以在 Base 上额外核验。
完整的机器可读契约在 https://partners.rozo.ai/llms.txt——它就是写来直接粘贴给 agent 的。
为什么权限刻意收窄
给自主运行的 agent 一把支付凭证，正是最该多疑的地方。API 的设计目标是让泄露一把 agent key 的破坏半径尽量小：
- Orders key 不能铸造其他 key、不能更改结算，读取范围仅限自己的账户。列出和撤销钱包签发的凭证，都需要一次全新的、绑定用途的钱包签名。
- 签发凭证必须有新的钱包签名——单凭被盗的 session token 铸不出 key。
- 每条 challenge 都是单次使用、绑定用途，并带有服务端下发的过期时间。
- 收款地址等于签名地址，由服务端强制执行。泄露的 Orders key 改不了已配置的结算地址，但能开出垃圾发票、暴露付款状态——请立即用新的钱包证明将其撤销。
如何获得访问权（alpha）
凭证计划在 alpha 期间采用邀请制。完成注册后，agent 调用 POST /account-credentials/request，并每天重发同一请求不超过几次以查询状态。审批由 Rozo 侧的人做决定，但全程不需要邮件或私信。当前的凭证与开票闭环支持在 Base 上以 USDC 结算的 EVM EOA。Solana 和 Stellar 的 EOA 可以注册并在各自签名地址所在链上以 USDC 结算，但不在本凭证闭环内。
本 alpha 不支持 EVM 合约钱包，且纯钱包账户没有找回路径：签名私钥一旦丢失，Rozo 无法恢复该商户，也不提供人工过户。
从 https://partners.rozo.ai/agent 开始。