Zion 定位为统一 API 通道层，不处理支付回调；其核心职责是通过 TaoToken 收敛 Claude Code、Cursor、Codex 等 AI 编程工具的 Base URL 与认证凭证，解决多工具 Key 管理混乱问题，仅支持主动调用（如回调后本地触发 zion run），不监听 HTTP 端口、不替代真实回调接口。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Zion 本身不提供支付回调能力，它作为 CLI 工具链中的统一 API 通道层，不接收、不解析、不转发任何来自微信/支付宝等支付平台的异步通知。
什么是 Zion 的定位
Zion 的核心职责是收敛 AI 编程工作流中多个 Coding Agent（如 Claude Code、Cursor、Codex）对 BaaS 服务的调用入口，通过 TaoToken 统一 Base URL 和认证凭证，解决 Key 管理混乱问题。
它不监听 HTTP 端口，不暴露 Web 接口，【不处理任何外部 HTTP 回调请求】。支付回调必须由你自己的后端服务部署在公网可访问地址上，并配置到微信/支付宝开放平台的“异步通知 URL”字段中。
Zion 能否间接参与支付后的业务逻辑
可以，但仅限于主动触发场景：
方法一：在你自己的回调接口内完成验签和幂等校验后，通过本地 CLI 调用 Zion 命令触发下游动作。例如：支付成功后需自动开通某项 AI 权限，可在回调处理函数末尾执行 zion run --workflow=grant-ai-access --order-id=xxx。
方法二：将 Zion 封装为内部 RPC 客户端或 SDK，供你的交易服务调用。此时 Zion 是一个工具型依赖，不是回调接收方。
【注意：Zion CLI 的执行结果不会返回给微信/支付宝，它不替代你自己的回调接口】。支付平台只认你配置的那个 URL 是否返回 200 OK 并带正确响应体，Zion 不可能替你完成这个应答。
真正能触发业务逻辑的回调落地方案
第一步：部署一个独立的 HTTP 服务（如 Go Gin / Python FastAPI / Java Spring Boot），监听 /pay/callback 待命；
第二步：在该服务中实现验签 → 幂等键查重（推荐用渠道事件ID）→ 带条件 UPDATE 订单状态 → 写入支付事件表；
第三步：状态更新成功后，同步调用 Zion CLI 或其封装的 SDK 执行权限开通、额度发放等动作；
第四步：立即返回微信/支付宝要求的纯文本 success 或 JSON {“code”:0}，不等待 Zion 执行结束——Zion 动作必须异步化或超时兜底，否则会拖垮回调响应时间，引发渠道重试雪崩。
