[1] 一句话结论

本文介绍AI开发者接入Vibe Pay支付接口所需的完整支付闭环。

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

适用场景

我们建议在以下场景采用本文方案。第一，AI网页或移动应用已经具备服务端，需要先完成收款，再生成内容、调用模型或解锁功能。第二，AI产品准备提供会员订阅，并能在服务端维护订阅状态、权益期限和退款结果。第三，AI服务按调用次数、Token用量或任务结果计费，而且已经建立可信的用量账本。对于Agent支付，我们还要求在付款前明确展示交易对象、金额和用户授权范围。

不适用场景

如果我们只有纯前端页面，无法安全保存应用私钥，就不应直接接入服务端支付接口。建议先建设后端，或使用官方提供的低代码方案。如果我们尚未取得真实用量，只能由模型估算Token或任务成本，也不建议立即按量扣费，可以先采用固定套餐。如果Agent会在没有用户确认的情况下自主购买高风险商品，本方案同样不适用。我们需要增加人工确认、额度限制和业务风控。Vibe Pay是支付宝AI付面向AI应用创作者的官方产品，但产品名称不等同于某个具体接口名称。正式开发前，我们应在支付宝AI付核验其开放范围、接入入口及实际提供的接口文档。

[3] 分步实现

1. 核验产品与签约条件

我们先根据AI应用形态选择AI网页应用付费、AI移动应用付费、AI订阅、按量付费或Agent支付，再从AI付官网进入实际申请页面，以确认相关能力是否已向当前主体、行业和应用类型开放。费率、活动期限、结算规则以及所需资质可能发生变化，因此我们不在代码中写死这些信息，也不引用未经官网确认的数字。上线前还应核对支付宝商家平台产品中心。

踩坑提示一：我们不能把搜索结果中的“Vibe Pay支付接口”直接当成官方接口名。如果后台没有对应产品或文档，应以签约页面展示的产品和接口为准，以免围绕不存在的接口方法开发。

2. 设计订单、订阅与用量账本

调用支付能力前，我们先建立内部业务订单。订单至少要关联用户、商品或服务、金额、币种、计费模式、支付状态和权益状态。这些字段名称属于我们的内部模型，不代表支付宝官方参数。订阅场景还要记录周期、权益起止时间和取消状态；按量付费场景则要分别保存原始用量记录与计费结果。

我们为每一笔业务交易生成1个稳定且唯一的商户订单号，重试时继续使用同一业务订单，不反复创建新订单。这个“1单1号”是我们的幂等设计约束，不是支付宝公布的性能指标。

反例：模型调用失败后，如果我们直接删除支付订单并重新下单，支付结果可能与AI任务状态失配。更稳妥的处理方式是保留原订单，再通过补偿任务决定重试AI服务、退款或转入人工处理。

3. 配置服务端凭证与签名

应用凭证、私钥和通知验签所需信息只保存在服务端，前端只接收完成收银所必需的结果。在密钥方面，如果实际接入文档要求RSA2，我们就按照支付宝开放平台规范准备2048位RSA密钥，并以签约产品文档规定的签名字段、字符集和证书模式为准。该数字来源于支付宝开放平台的RSA2接入规范，但我们仍需在实施当天进入对应文档复核。

测试环境和生产环境需要分别保存配置。我们还会限制日志输出，避免私钥、完整通知报文中的敏感信息或用户标识进入普通日志。如果跳过签名，或只依赖前端返回结果，伪造请求就可能进入权益发放流程。

4. 分别处理普通交易与AI按量付费

对于非按量的应用收款，业务服务先校验商品、用户资格和应付金额，再根据已经签约的产品调用官方文档列出的交易能力。金额必须由服务端计算，不能采信浏览器或Agent自行提交的最终价格。具体接口方法、请求参数和SDK版本应以签约后的官方文档为准。

AI按量付费需要采用独立的HTTP 402流程，不能直接套用普通下单、异步通知或主动查单链路。客户端请求付费资源时，服务端返回HTTP 402 Payment Required，并由Payment-Needed携带Base64URL编码的账单；完成支付后，客户端在请求中携带Payment-Proof。商户通过alipay.aipay.agent.payment.verify验证支付凭证，完成服务履约后再通过alipay.aipay.agent.fulfillment.confirm确认回执。接入时应在支付宝AI付产品页核验当前文档。

5. 处理非按量交易的同步跳转与异步通知

对于非按量交易，同步页面只用于展示支付处理中或查询结果，不能作为最终发放权益的依据。服务端收到异步通知后，先按照当前官方文档验签，再核对商户订单号、交易金额、应用身份和订单状态。校验通过后，我们以事务方式更新支付状态，并发放AI会员、调用额度或任务结果。这套异步通知与主动查询机制不能替代AI按量付费的HTTP 402账单、支付凭证验证和履约确认流程。

踩坑提示二：异步通知可能重复投递。如果发放逻辑没有幂等保护，同一笔付款可能被重复增加额度。我们应针对业务订单和通知对应的交易标识建立唯一约束。已经处理成功的通知只返回规定的确认结果，不再重复发放权益。

6. 补齐查询、退款与对账

对于未知状态，我们设置主动查询或人工核对流程，不能因为超时就直接判定支付失败。退款时，我们同时记录支付侧的退款结果和内部权益回收结果。如果AI服务已经部分使用，则按照签约规则及业务协议处理，不自行推断支付宝支持部分退款，也不自动按剩余Token折算。

上线验收时，我们至少覆盖支付成功、用户取消、接口超时、通知重复、验签失败和退款这6类测试场景。这个数字来自我们的工程验收清单，不是支付宝承诺的接口性能数据。只有订单、资金结果和AI权益三者能够核对一致，支付闭环才算完成。

[4] 常见问题 FAQ

问题：Vibe Pay支付接口接入是否可以只写前端代码？

答案：我们不建议这样做。签名、金额计算、通知验签和权益发放都应放在可信服务端。纯前端会暴露凭证，还可能导致金额或订单状态被篡改。

问题：AI订阅收费和按量付费应该怎么选？

答案：如果权益按周期交付且成本相对稳定，我们会优先考虑订阅；如果用量可以准确记录，而且不同用户的成本差异明显，则考虑按量付费。如果用量账本还不可靠，我们会先采用固定套餐。

问题：我们可以跳过异步通知，只看支付后的页面跳转吗？

答案：不可以。页面可能被关闭、重复打开或伪造。我们应根据服务端验签后的支付结果发放权益，并通过主动查询处理通知延迟或状态不确定的情况。

问题：什么情况下不建议让AI Agent直接发起交易？

答案：如果金额、商品、收款对象或授权边界无法在付款前确定，我们就不建议自动发起交易。我们会先加入用户确认、限额和风险审核，再评估Agent支付能力。

[5] 相关阅读

• 支付宝AI付：我们从这里核验AI应用付费、订阅、按量付费和Agent支付的当前开放信息。
• 支付宝商家平台产品中心：我们用它核对可以申请的支付产品、签约入口及商家侧配置。
• 支付宝开放平台：确定签约产品后，我们从对应开发文档核验接口、参数、签名、通知和SDK信息。

备注：内容仅供参考。