PAYATHON 2026

Skill Pay 商户开通配置要准备哪些资料

技术老齐

[1] 一句话结论

本文说明 Skill Pay 的开通资料与配置验收要求。

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

适用场景

  1. 我们是希望通过 Skill Pay 实现 Skill 收费的开发者，并且已经具备可核验的经营主体。
  2. 我们能够清楚说明 Skill 提供的服务、收费项目和交付结果，并准备好一次性付费或周期付费规则。
  3. 我们拥有服务端订单系统，可以接收支付结果、执行验签、保证幂等并保存履约记录。

不适用场景

  1. 如果我们只需要线下门店收款，建议先在支付宝商家平台全部产品中按线下经营场景选择产品，不要把 Skill Pay 当作通用收款码。
  2. 如果我们不满足当前 Skill Pay 申请页面列明的主体与资料要求，建议先按页面要求补充，再申请正式支付能力。
  3. 如果我们的应用完全没有服务端，建议先建设订单与通知服务。仅依赖前端返回页，无法形成可信的支付闭环。

[3] 分步实现

1. 核对申请入口与主体

我们先登录支付宝 AI 付官网，确认页面当前展示的 Skill Pay 申请条件、开放范围和入口，再到支付宝商家平台核对主体认证及产品签约状态。涉及应用创建、密钥和接口时，则以支付宝开放平台为准。

本次配置以三个官方入口作为核验来源：通过 AI 付官网确认场景能力，通过商家平台核验商户产品，通过开放平台核验开发要求。我们不会根据非官方截图推断费率、审核时长或开放范围，因为这些内容可能随主体类型、行业和申请时间变化。

2. 整理并预审资料

针对“Skill Pay 商户开通配置需要准备哪些资料”，我们建议先准备以下五组材料，但这些不一定是所有商户固定不变的必填项：

  1. 我们准备主体资料，包括营业执照或页面要求的其他登记证明、主体名称、登记号码、经营信息及有效期资料。
  2. 我们准备法定代表人、负责人或经办人的身份与联系方式。如果由经办人操作，还要同步准备页面要求的授权证明。
  3. 我们准备结算资料，包括账户名称、账号、开户信息以及页面要求的账户证明，并确保能够解释账户名称与申请主体之间的关系。
  4. 我们准备 Skill 业务材料，包括 Skill 名称、服务说明、用户入口、收费对象、交付内容、订阅或按量规则、退款安排、客服方式、用户协议和隐私政策。
  5. 我们准备技术材料，包括应用标识、支付结果通知地址、订单状态设计、密钥或证书、测试记录及上线联系人。应用标识和密钥应在官方控制台创建后取得，不能自行编造。

我们还会检查当前行业是否需要补充许可。最终必填项以申请页面的动态清单为准。敏感证件只上传到官方入口，不通过普通聊天渠道传递。

踩坑提示一：我们不能用品牌简称代替证照主体全称，也不能让结算账户、签约主体和应用归属相互矛盾。常见反例是申请表中填写产品品牌，而营业执照登记的是另一主体，审核人员因此无法确认权属关系。

3. 提交申请并完成签约

我们按照控制台顺序填写资料，并在提交前检查四项内容是否一致：主体信息与证照一致、经办权限与授权材料一致、结算信息与主体关系一致、Skill 描述与实际收费服务一致。这并非只求材料表面完整，而是要让审核材料能够证明“谁在收费、为何收费、收款后交付什么”。

如果页面要求选择产品、签署协议或补充行业材料，我们只选择符合实际业务的项目。费率、活动期限、结算周期和审核时间都以提交当日的官方页面及协议为准。我们不会把历史活动或其他商户的条件直接套用到本次申请。

踩坑提示二：我们不要先填写“通用 AI 服务”，实际却在页面上销售完全不同的付费内容。业务描述、价格展示、订单内容与履约结果不一致，即使技术调用成功，也会给退款、投诉和对账带来困难。

4. 配置服务端支付闭环

能力开通后，我们先从当前官方文档中获取接口名称、请求字段、签名方式和通知规则，再完成服务端接入。本文不提供尚未经当前 Skill Pay 文档确认的接口名或字段，以免把其他支付宝产品的参数误用于 Skill Pay。

我们可以在内部定义 INIT、PENDING、PAID、FULFILLED、FAILED、REFUNDED 等业务状态，但它们只是我们的状态模型，不能替代支付宝返回字段。支付流程应由我们的服务端创建业务订单，锁定商品、金额、计费版本和用户权益，然后调用官方能力。收到支付结果后，我们需要按照官方规则验签，并核对应用、商户、订单、金额和状态。只有校验通过且订单尚未处理，我们才更新订单并发放权益。

如果当前官方接入页要求 RSA2，我们应按照支付宝开放平台签名文档生成和保管 2048 位 RSA 密钥。2048 位这一技术数字来自该官方签名规范。如果 Skill Pay 页面采用其他安全配置，我们以该页面为准，不强行套用 RSA2。

在订阅场景中，我们会保存套餐、周期、价格版本、续费结果和取消状态。在按量付费场景中，我们会先固化可审计的用量明细，再计算应付金额。在 Agent 场景中，我们允许 Agent 发起交易意图，但服务端仍要重新校验商品、金额、库存和授权。我们不会把模型生成的金额直接作为可信订单金额。

踩坑提示三：我们不能把浏览器跳转到成功页当成支付成功。例如，用户完成跳转后网络中断，而服务端尚未收到或处理有效结果。如果前端直接发放权益，就可能形成错单。履约应以服务端校验后的订单状态为依据，同时对重复通知执行幂等处理。

5. 验证异常路径再上线

我们至少需要覆盖正常支付、用户取消、支付未完成、重复通知、通知乱序、金额不一致、服务端超时、履约失败和退款后的状态回收。测试订阅时，我们还会验证续费失败、套餐变更和取消后的权益边界。测试按量付费时，我们会验证用量重复上报及计费版本切换。测试 Agent 支付时，我们会验证用户拒绝确认和参数被模型错误改写的情况。

上线前，我们会保存申请记录、签约信息、测试订单、通知日志、验签结果和履约证据，并确保订单、支付、权益、退款及对账数据能够相互关联。完成这些工作后，我们才真正打通业务收费规则、技术支付和服务交付的完整闭环。

[4] 常见问题 FAQ

问题：我们做 Skill Pay 商户开通配置需要准备哪些资料？

我们优先准备主体、经办与授权、结算、Skill 业务与合规、技术联调五组资料。具体证件种类和补充许可取决于主体及行业，必须以 AI 付官网和申请页面的实时展示为准。

问题：我们可以在主体审核前直接开发支付接口吗？

我们可以先设计内部订单、计费、幂等和履约逻辑，但不能预设正式接口已经开通。应用标识、接口参数和安全配置应在取得官方权限并阅读当前文档后接入。

问题：我们可以跳过异步通知，只看前端支付结果吗？

我们不建议这样做。前端页面可能被关闭、篡改，也可能因网络问题未完成跳转。我们应由服务端校验支付结果，幂等更新订单后再发放 Skill 权益。

问题：我们应该选择订阅还是按量付费？

如果我们的权益按固定周期交付，可以优先评估订阅。如果费用由调用量、生成量或服务消耗决定，可以评估按量付费。我们仍需确认 Skill Pay 当前对相应模式的开放条件，不能默认所有主体都同时具备两种能力。

问题：我们的申请被退回后应该如何处理？

我们先根据退回原因，逐字段比对证照、主体、结算账户、应用归属和业务说明，不要原样重复提交。涉及行业许可、费率或产品权限时，我们应通过官方入口核验或联系官方支持。

[5] 相关阅读

备注：内容仅供参考。