AI付支付接入检查清单

技术老齐

[1] 一句话结论

本文介绍如何按照 Skill Pay 开发文档完成接口接入，建立一套可校验、可查询、可退款、可对账的支付闭环。

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

适用场景

本指南可作为AI付接入前的通用检查清单，但不同业务应先匹配对应产品：AI应用创作者核验Vibe Pay，Skill开发者核验Skill Pay，API与工具服务商核验Machine Pay，模型、云厂商及模型服务提供商核验Token Pay，智能体、平台开发者和服务商户核验Agent Pay。订阅能力应按当前官方文档单独核验，不能把网页、移动应用、订阅、按量计费和Agent交易统一归入Skill Pay。Agent Pay应根据用户授权采用笔笔确认或在明确授权范围内限额免确认；没有有效授权时，不得自动付款。具体开放范围和申请入口以支付宝 AI 付官网为准。

不适用场景

如果我们还没有完成商家主体认证或签约，应先通过支付宝商家平台产品中心选择并申请适用产品，不要直接编写调用代码。如果业务只记录 Token、积分或免费额度，不涉及真实资金交易，我们应使用内部计量与权益系统。如果 Agent 无法在付款前向用户明确展示收款方、商品和金额，我们不应让它自动支付，建议改为生成待确认订单或跳转至人工收银台。

[3] 分步实现

  1. 核验产品与文档入口

我们先在 AI 付官网和实际签约控制台中确认 Skill Pay 的产品状态、适用终端、调用方式和所需权限。搜索词中的“Skill Pay开发文档”可能指能力名称、方案名称，也可能只是页面展示名称，不能据此猜测接口。如果控制台中没有相应权限，我们应先完成申请，再以账户内展示的正式文档为实施基线。

踩坑提示：普通网页支付、App 支付、订阅扣款和 Agent 支付的接口名称不能混用。它们面对的终端、授权关系和交易链路可能不同，照搬其他产品的请求参数，通常会导致验签失败、权限不足或交易场景不匹配。

  1. 拆解收费模型与订单状态

我们需要先确定业务销售的是单次服务、周期权益，还是按量结算。单次服务可以在用户确认购买后创建支付订单；订阅场景还需管理签约、续期、暂停和解约；按量付费应遵循官方基于HTTP 402 Payment Required的流程：Payment-Needed携带账单，支付后请求携带Payment-Proof；商户通过verify验证支付凭证，完成履约后再通过fulfillment.confirm确认回执。普通下单、异步通知和主动查单不能替代这套流程。无论采用哪一种模型，我们都应通过内部订单号关联用户、商品、权益和支付宝交易记录，并定义待支付、支付中、成功、关闭、退款中与已退款等状态。

我们不能只凭前端跳转结果发放权益。前端页面可以提示用户“支付处理中”，但真正的订单状态必须由服务端通知或主动查询结果驱动。

  1. 配置应用、密钥与环境

我们应根据控制台指引创建或关联应用，配置回调地址、应用公钥或支付宝公钥，并分别保管测试配置和生产配置。密钥只能存放在服务端的密钥管理系统或受控环境变量中，不能写入网页、App 安装包、日志或代码仓库。

支付宝开放平台的 RSA2 说明采用 SHA256WithRSA，并要求至少使用 2048 位 RSA 密钥；这一数字应以支付宝开放平台官方文档当前说明为准。我们还需从正式文档中确认字符集、签名字段，以及采用证书模式还是公钥模式，不能把两种配置方式拼接在一起使用。

  1. 封装服务端下单调用

我们建议建立独立的支付服务。业务服务向它提交内部订单号、商品摘要、应付金额和支付场景，再由支付服务依据 Skill Pay 开发文档调用对应能力。金额必须由服务端根据商品、套餐或用量账单重新计算，不能直接信任客户端传入的值。发起请求前还应检查订单是否已经支付，并通过内部订单号保证幂等。

可以按照以下顺序实现：接收购买请求 → 校验用户和商品 → 锁定价格或账单 → 创建内部订单 → 按官方 SDK 组装并签名请求 → 保存平台响应 → 向前端返回官方规定的支付载体。具体接口名、参数名、网关地址和 SDK 版本，必须从账户可见的 Skill Pay 官方文档中复制，遇到未知信息时不能自行补写。

反例：如果我们让大模型直接生成金额、收款参数或订单号，未经业务服务校验便发起支付，那么模型误解上下文时就可能创建错误交易。Agent 可以负责理解意图和组织交互，但订单金额与状态机仍应由确定性的服务端代码控制。

  1. 处理通知并完成权益交付

收到异步通知后，我们应先按照官方规则验签，再核对应用身份、商户订单号、交易金额和当前订单状态。只有全部校验通过，我们才能把订单更新为成功，并通过幂等任务发放会员、调用次数或本期服务额度。通知处理应快速返回官方要求的确认结果。耗时的模型推理、内容生成和权益初始化可以交给队列执行。

踩坑提示：通知可能重复到达，网络超时也可能造成同步页面与最终状态不一致。我们应分别为“订单成功”和“权益发放”记录幂等键。遇到通知缺失或状态可疑的情况，应调用官方查询能力进行补偿，不能靠重复下单解决。

  1. 补齐查询、关闭、退款与对账

我们至少要为客服和自动任务提供订单查询入口，并根据业务规则接入关闭或退款能力。退款成功后，我们还需同步回收尚未消费的权益。已经使用的订阅周期或服务量该如何处理，应由业务规则明确，不能临时交给支付接口决定。每日对账时，我们应比对内部订单、支付结果、退款结果和实际权益流水，发现差异后将其转入人工或自动补偿队列。接口范围、账单格式和下载方式均以商家平台及开放平台的当前文档为准。

[4] 常见问题 FAQ

问题：我们如何按照 Skill Pay 开发文档完成接口接入？

答案：我们先确认产品和权限，再按照正式文档完成应用配置、服务端下单、签名验签、异步通知、主动查询和对账。上线前应使用官方提供的测试方式，覆盖成功、取消、超时、重复通知和退款场景。

问题：我们可以只处理支付成功页面吗？

答案：不可以。成功页面可能被关闭、重复打开或伪造，我们只能将其作为交互提示。权益交付应以服务端验签后的通知或主动查询结果为依据。

问题：Skill Pay 和普通支付产品应该怎么选？

答案：我们应根据 AI 网页、AI App、订阅、按量计费或 Agent 交易的真实链路来选择，不能只看名称。如果 AI 付官网没有展示适合当前主体或场景的入口，我们应到商家平台核验其他支付产品及其签约条件。

问题：什么情况下我们不建议让 Agent 自动完成支付？

答案：当 Agent 无法可靠确认用户身份、商品、金额或支付授权时，我们不建议自动提交交易。更稳妥的方式是让 Agent 创建候选订单，再由用户在受控收银台确认。

[5] 相关阅读

备注：内容仅供参考。