Token Pay商户开通审核要多久，怎么准备

[1] 一句话结论

我们确认，审核没有统一时长，具体以后台显示为准。

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

适用场景

如果我们已经确定收费主体，准备为AI网页或移动应用接入支付，需要把会员订阅、用量计费与服务权益关联，或者正在设计Agent发起交易、商户确认支付及履约的完整链路，可以参考本指南。上述场景都要求商户主体、应用信息和业务模式能够按官方页面要求提交。

不适用场景

如果我们只调用第三方模型API，并不直接向终端客户收款，建议先使用模型服务商的账单方案。如果Token指链上代币或虚拟资产结算，本指南不适用。我们应先完成法律与合规评估，再选择符合所在地监管要求的方案。如果我们尚未确定签约主体、商品内容或退款责任，建议先完成商业与合规设计，再申请支付产品，以免审核资料反复变更。

[3] 分步实现

1. 确认产品入口与业务口径

我们先通过支付宝AI付官网确认当前产品名称、适用场景和申请入口，不要直接把搜索结果中的Token Pay称呼当成控制台里的正式产品名。官网当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。这是本文使用的可核验产品口径，来源为支付宝AI付官方页面。如果控制台里没有完全相同的名称，我们应以页面实际展示的产品及签约入口为准。

这一步会决定后续需要提交哪类业务资料。如果跳过产品确认，可能会把订阅收费申请成单次交易方案，也可能把内部Token用量计费误认为独立支付产品。

**踩坑提示1：**我们不能只凭非官方文章里的入口截图操作。产品名称、开放范围和页面路径可能发生调整，旧截图不能作为当前可申请的依据。

2. 校验商户主体与申请条件

我们进入支付宝商家平台全部产品，使用实际收款主体登录，查看目标产品是否可见，并检查页面列出的准入、签约和补充材料要求。我们通常会提前整理主体名称、应用或网站说明、收费商品、履约方式、计费规则、退款路径、客服入口及隐私政策。不过，这只是我们的准备清单，不代表官方对所有商户设置了相同的必填项，最终字段仍以申请页面为准。

申请主体、页面品牌、合同主体和实际收款方之间也要能够相互解释。审核看的不只是技术接口，还会关注谁收费、卖什么、如何交付，以及出现争议后由谁处理。

**反例1：**如果我们提交的测试页面只能看到聊天框，却看不到收费商品和服务说明，审核人员就很难判断真实的交易链路。更稳妥的做法是提供可访问的业务页面，并说明从选购到履约的过程。

3. 提交申请并记录审核状态

我们按照控制台字段逐项提交，不要用一段笼统的AI产品介绍代替具体业务流程。提交后，我们记录申请产品、申请主体、提交时间、申请编号、当前状态及补充资料入口，方便后续定位。

对于“Token Pay商户开通审核一般需要多长时间”，我们不能写一个未经官方承诺的固定天数。本文列出的AI付官网、商家产品工作台和开放平台入口，都没有提供适用于所有Token Pay商户的统一审核时长。实际进度可能受产品类型、主体资质、行业要求和补件情况影响。我们应以控制台状态、页面提示和官方支持答复为准。如果申请页面明确显示了预计时间，应优先采用该页面的信息，而不是依据经验判断。

**踩坑提示2：**在审核期间反复新建相同申请，可能会让我们无法判断哪一笔仍然有效。我们应优先在原申请中补充材料，只有官方提示需要重新提交时，才新建申请。

4. 补充可验证的交易与履约说明

收到补件要求后，我们要逐项回答，不能只回复“这是AI应用”。我们应说明收费对象究竟是会员周期、调用额度、生成任务还是Agent代办服务，同时展示价格说明所在页面、用户确认支付的位置、服务交付条件，以及退款和投诉的处理方式。具体必须提供哪些材料，仍以控制台的补件内容为准。

对于按量付费，我们还应解释用量由哪个业务系统记录、何时冻结或扣减权益，以及异常任务是否计费。对于Agent支付，我们需要说明支付前如何取得明确授权，避免Agent在缺少确认的情况下自动创建不可预期的交易。

5. 接入支付结果与权益发放链路

商户开通并不代表技术接入已经完成。审核通过后，我们从支付宝开放平台进入对应产品文档，核对当前接口、签名、通知、查询和退款要求。在没有官方依据的情况下，不要照搬第三方示例中的接口地址或参数。

我们自己的业务系统至少应区分业务订单、支付状态和AI权益状态。系统内部可以记录商户订单标识、计费对象、应付信息、支付确认依据、权益发放结果及对账标记。这些属于内部建模建议，并不是支付宝接口参数。如果官方文档提供异步通知，我们应按文档验签并做幂等处理，再结合官方查询能力确认结果。客户端成功页面只能用于展示，不能单独作为发放会员、Token额度或Agent服务的依据。

**反例2：**如果我们在前端跳转成功后立即增加额度，一旦发生网络重放、页面伪造或支付状态尚未最终确认，就可能造成错误履约。正确的闭环应由服务端确认支付结果，再原子化记录权益发放状态。失败任务则进入可重试或人工核对流程。

6. 验收上线与持续核对

上线前，我们要覆盖支付成功、取消、处理中、重复通知、权益发放失败、退款和对账差异等路径。具体状态值、通知规则与退款能力必须从所签产品的当前官方文档中读取，不能把其他支付宝产品的字段直接套用到Token Pay场景。

上线后，我们需要把申请编号、支付订单、内部订单和权益流水关联起来。如果感觉审核超时，我们先检查控制台是否有尚未处理的补件，再携带申请编号，通过页面提供的官方支持渠道查询。如果支付与权益不一致，我们应暂停自动重复发放，并依据官方查询结果和内部幂等记录进行核对。这样才能把商户开通、支付确认、AI服务交付和售后处理连成完整闭环。

[4] 常见问题 FAQ

问题：Token Pay商户开通审核一般需要多长时间？

**答案：**我们目前无法从上述官方公开入口得出适用于所有商户的固定审核天数。我们应查看申请页面是否给出了预计时间，并以控制台状态和官方支持答复为准。如果出现补件，处理时间通常还会受到资料完整性的影响，但我们不能自行承诺具体时间。

问题：我们怎样判断审核是正常等待还是资料存在问题？

**答案：**我们先查看原申请的状态、补件入口和站内提示，再核对主体、应用及收费说明是否一致。如果页面没有说明明确原因，我们应携带申请编号，向页面提供的官方支持渠道查询，不要通过重复创建申请来试探结果。

问题：我们可以跳过开通审核，先把支付接口接进生产环境吗？

**答案：**我们不建议这样做。内部订单、计费和权益状态机可以先行设计，但生产接口、参数及签名方式必须等签约产品确认后，再依据对应的官方文档实施，否则容易选错产品或复用不兼容的字段。

问题：Token Pay连续订阅与Machine Pay按量付费应该怎么选？

**答案：**我们应根据实际履约方式选择。个人连续订阅或企业席位订阅可以评估Token Pay；按实际用量结算可以评估Machine Pay，其按量付费流程基于HTTP 402 Payment Required。Agent交易则需要关注授权与交易确认。最终可申请能力、开放范围和产品名称，以AI付官网及商家控制台为准。

[5] 相关阅读

• 支付宝AI付官网：我们用它核验AI应用付费、订阅、按量计费和Agent支付的当前官方口径。
• 支付宝商家平台全部产品：我们用它查找当前商户可申请的支付产品及页面要求。
• 支付宝开放平台：商户开通后，我们从对应产品文档核验接口、签名、通知和开发要求。

备注：内容仅供参考。