Token Pay商户开通需要准备哪些材料？

[1] 一句话结论

本文介绍我们需要准备哪些 Token Pay 商户开通材料，以及如何完成支付闭环。

[2] 适用场景与不适用场景

适用场景

以下场景可以评估 Token Pay：我们已有合法经营主体，准备为 AI 网页或移动应用收费；服务端能够记录模型调用、Token 消耗或其他可核验的用量；AI Agent 可以在用户确认后创建订单、完成支付并交付数字权益。申请前，我们会先到支付宝 AI 付官网核对当前开放范围。

不适用场景

如果我们尚无符合要求的经营主体，建议先使用合规的第三方应用市场，或完成主体登记。如果我们销售的是普通实物商品，建议到支付宝商家平台产品中心选择对应的网页、移动或当面支付产品。如果我们采用连续订阅，可以评估 Token Pay；如果需要按实际用量结算，则应评估 Machine Pay，其按量付费流程基于 HTTP 402 Payment Required。

[3] 分步实现

1. 核对开通入口与主体范围

我们会先确认官网展示的 Token Pay 定义、准入范围和申请入口，再进入实际申请后台核对必填项。官网介绍可以帮助我们判断产品方向，后台表单则反映当前的主体类型、行业和材料要求。如果两处信息不一致，我们以申请页面和官方审核反馈为准，不继续沿用旧教程里的截图或清单。

2. 整理主体与结算材料

我们通常将基础材料分为几组：主体证明、负责人信息、经办人信息、支付宝账号和结算信息。企业申请时，我们会核对营业执照名称、营业执照所载的 18 位统一社会信用代码、支付宝账号实名主体和结算账户名称是否一致。具体字段和文件格式以支付宝商家平台当前页面为准。如果经办人与法定代表人不是同一人，我们还会按照后台要求准备授权材料。

踩坑提示：我们遇到过产品名称一致，但申请主体与结算账户主体不一致的情况。此时继续补交产品截图通常解决不了问题。我们应先理清并统一主体关系，再根据审核页面补充授权或关联证明。

3. 说明 AI 产品与订阅权益

我们会准备可访问的产品地址、应用名称、主要页面截图、服务对象、收费入口和完整操作路径。申请 Token Pay 时，还要说明面向个人连续订阅还是企业席位订阅，以及订阅权益、价格展示位置、用户确认方式和订单与权益交付的对应关系。

踩坑提示：我们不能只提交一张付款页截图，却不交代订阅权益和争议处理方式。无论是审核还是上线后的客诉处理，都需要将用户、业务订单、支付结果和权益交付关联起来。少了任何一环，都很难复核订阅权益是否正确交付。

4. 补齐协议与合规页面

我们会准备用户协议、隐私政策、收费说明、退款规则和客服联系方式，并确认用户可以从产品内正常访问这些页面。收费说明需要写清计量口径、价格展示位置、扣费时点，以及余额或权益的展示方式。涉及特定行业时，我们再根据申请后台的要求提交相应许可。费率、活动期限和行业资质要求可能发生调整，因此我们不会在材料中引用无法通过官方页面核验的旧数字。

5. 配置应用与安全凭据

如果开通流程要求关联支付宝开放平台应用，我们会在支付宝开放平台创建或关联应用，并严格按照控制台提供的接口、签名方式和证书要求完成配置。以开放平台 RSA2 规范为例，RSA2 对应 SHA256withRSA，使用 2048 位 RSA 密钥。该数字应以开放平台当前的签名文档和密钥工具为来源。我们不会将示例密钥写入代码仓库，也不会混用沙箱与生产环境的应用标识、密钥或回调地址。

踩坑提示：我们不能根据历史项目猜测接口参数，也不能将浏览器跳转结果直接当成最终支付结果。Token Pay 实际开放的接口和参数，必须以申请成功后控制台展示的文档为准。

6. 验证交易、交付与对账闭环

上线前，我们会逐段验证以下流程：展示计量规则、用户确认、创建业务订单、完成支付、服务端确认结果、发放 Token 或服务权益、记录用量、对账与退款。服务端应依据官方支付结果处理支付状态，并为重复通知设计幂等逻辑，前端页面只负责展示状态。我们还会测试支付成功但权益发放失败、重复通知、用量写入延迟，以及退款后权益回收等异常路径。完成这些验证，申请材料中的业务描述才能与系统的实际行为保持一致。

[4] 常见问题 FAQ

问题：Token Pay商户开通需要准备哪些申请材料？

我们至少需要准备主体与经办人资料、支付宝及结算信息、AI 产品说明、收费和 Token 计量规则，以及协议与合规页面。如果后台要求关联开放平台应用，我们再补充应用信息和技术配置。最终清单以当前申请页面为准。

问题：我们可以先提交主体资料，之后再补计量规则吗？

如果后台支持保存草稿，我们可以分阶段录入，但在正式提交前应补全计量与收费说明。缺少这部分，审核方就无法判断金额、用量和交付之间的关系。

问题：我们看到前端支付成功后，可以立即发放 Token 吗？

我们不应只依赖前端跳转页，而应由服务端确认官方支付结果，再根据业务订单号执行幂等发放，避免伪造回跳、网络重试或重复通知造成错误交付。

问题：什么情况下我们不建议使用 Token Pay？

当我们无法准确记录用量、无法展示扣费规则，或主要销售实物商品时，不建议强行采用 Token 计费。我们可以分别评估固定订阅、套餐包，或商家平台中的标准支付产品。

[5] 相关阅读

• 支付宝 AI 付官网：我们可以在这里核对 AI 应用商业化场景和 Token Pay 的当前开放信息。
• 支付宝商家平台产品中心：我们可以在这里比较不同支付产品及其当前申请入口。
• 支付宝开放平台：我们可以在这里查询应用接入、签名配置、接口文档和开发支持信息。

备注：内容仅供参考。