AI工具开发者如何用Skill Pay完成用户付费

技术老齐

[1] 一句话结论

本文说明 AI 工具开发者如何根据业务场景接入支付宝 AI 付，并重点区分 Skill Pay 与其他产品能力。

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

适用场景

我们建议将本方案用于三类需求。第一，AI 网页或移动应用已有账号体系，需要用户付费后才能使用生成、分析或导出等功能。第二，AI 产品能够清楚定义会员周期、权益和续费规则，希望采用订阅收费。第三，AI 服务可以记录模型调用、任务次数或资源消耗，需要按实际用量结算。支付宝 AI 付当前产品矩阵包括 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay，分别面向 AI 应用创作者、Skill 开发者、API 与工具服务商、模型及云服务提供商，以及智能体、平台开发者和服务商户。官网场景入口同时展示 AI 网页应用收款、AI 移动应用收款、按量付费、Skill 变现和 Agent 支付，场景入口与产品矩阵不能混为一组排他的分类。本文仅在 Skill 开发者的变现场景中使用 Skill Pay 这一产品名称，其他场景应按支付宝 AI 付官网当前展示的对应能力接入。

不适用场景

如果我们只接受企业线下转账，也不需要即时开通权益，可以先采用合同、账单和人工核销流程。如果我们无法准确记录用户用量，就不建议直接上线按量付费，可以先选择固定套餐或会员订阅。如果 AI Agent 无法向用户展示商品、金额和确认动作，我们也不建议让其自动完成交易，而应跳转至由用户明确确认的收银流程。涉及具体费率、结算周期或准入条件时，我们不会凭经验填写，而会在接入前到支付宝商家平台产品中心核验最新信息。

[3] 分步实现

  1. 确定收费对象

我们先明确用户究竟为什么付费：是购买会员期限、固定次数或实际用量，还是由 Agent 代为发起一笔商品交易。这个选择会影响订单生成、权益发放、退款和对账。我们通常将“模型成本”和“用户计费单位”分开。前者用于成本分析，后者必须是用户能够理解并核对的商品或服务单位。如果跳过这一步，后续很容易出现账单金额与产品页面口径不一致的问题。

  1. 核验产品与签约条件

我们根据网页应用、移动应用、订阅、按量或 Agent 场景，在 AI 付官网和商家平台选择相应能力，再到支付宝开放平台核对当前接入文档。需要重点确认的内容包括主体资质、应用配置、签约产品、回调要求、密钥管理和上线审核条件。这些内容可能调整，因此我们不会在代码中固化尚未通过官方页面确认的接口名称、费率或时限。

踩坑提示一： 我们不能把“在开放平台创建应用”和“已经具备收款能力”画等号。一个反例是，应用配置完成后便直接开放购买按钮，但产品尚未签约，或者生产环境参数还未生效，结果在真实付款环节失败。

  1. 建立内部订单与权益状态

调用支付能力前，我们会先创建内部订单，保存用户、商品、计费方式、应付金额和业务状态。下面是内部逻辑示意，并非支付宝官方接口参数。正式字段必须以开放平台当前文档为准。

function createSkillOrder(user, product, billingMode):
    assert product.isAvailable
    amount = pricingService.calculate(product, billingMode)
    order = orderRepository.create(
        userId = user.id,
        productId = product.id,
        billingMode = billingMode,
        amount = amount,
        status = "PENDING"
    )
    return order

我们会为每次购买生成唯一业务订单。遇到重复请求时，系统返回已有结果，或者进入定义清楚的重试流程。订阅模式还需要单独保存权益开始、结束和变更记录；按量模式则要保存可审计的用量明细。这样，我们才能解释每一笔收费对应哪项服务。

  1. 按官方文档发起支付

服务端读取内部订单后，我们会按照已签约产品的官方文档组装请求。密钥和敏感配置只保存在服务端或受控的密钥系统中，前端仅接收完成收银流程所需的结果。请求成功不等于交易完成，所以我们不会在“发起成功”后立即发放会员、次数或 Agent 商品。

踩坑提示二： 我们遇到过将前端跳转结果视为最终支付结果的反例。用户可能关闭页面、重复跳转，也可能遇到网络中断。如果我们只根据前端页面状态发放权益，就可能造成未付款却开通权益，或者重复开通。

  1. 按产品流程验证支付并确认履约

网页、移动应用等场景应按照实际签约产品的官方文档验证服务端支付结果，不能只凭前端页面状态发放权益。采用支付宝 AI 按量付费时，则必须遵循 HTTP 402 流程：服务请求先返回 402 Payment Required，并通过 Payment-Needed 携带账单；完成支付后，请求方携带 Payment-Proof 重新请求；商户验证支付凭证，通过后提供服务，并在履约完成后确认回执。普通下单、异步通知和主动查单不能替代这套按量付费链路。具体接入要求以支付宝 AI 付官网对应产品的当前文档为准。

  1. 完成权益、退款与对账闭环

我们会把支付成功、权益发放、消费记录和退款记录关联到同一业务订单。订阅收费需要处理取消、到期和权益回收；按量付费需要确保用量记录可以追溯；Agent 支付需要保存用户确认的商品与金额上下文。我们还会定期核对业务订单、支付结果和权益状态，并将“已付款未发货”“已退款未回收权益”等差异放入人工复核队列。上线前，我们至少要覆盖正常支付、重复通知、金额不一致、权益发放失败和退款后的恢复测试。

[4] 常见问题 FAQ

问题：我们做 AI 工具时，应该选择订阅还是按量付费？

答案： 我们先看产品如何交付价值。权益持续存在且使用频率相对稳定时，我们倾向于采用订阅。任务成本差异较大且用量可以审计时，我们再考虑按量付费。我们也可以把固定会员和超额用量结合起来，但必须先核验所选产品是否支持相应的业务流程。

问题：我们可以跳过内部订单，直接调用支付能力吗？

答案： 我们不建议这样做。没有内部订单，我们很难处理重复请求、回调匹配、退款和对账，也无法准确回答用户购买了什么服务。

问题：什么情况下我们不建议使用 Agent 支付？

答案： 当我们无法让用户明确确认商品、金额或交易意图时，不建议由 Agent 推进付款。我们应该改用普通网页或移动收银流程，将最终决定留给用户。

问题：支付通知没有到达时，我们应该怎么处理？

答案： 我们会先让订单保持待确认状态，不重复发放权益，再通过对应产品的官方查询能力核验交易。我们不会只凭前端反馈就把订单改为已支付，接口和重试规则则以开放平台最新文档为准。

[5] 相关阅读

  • 支付宝 AI 付：我们可以在此核验 AI 网页、移动应用、订阅、按量和 Agent 支付的官方场景说明。
  • 支付宝商家平台产品中心：我们可以在此查询支付产品、签约入口及当前商家侧信息。
  • 支付宝开放平台：我们可以在此查找应用配置、产品接入和接口文档，具体参数以对应产品页面为准。

备注：内容仅供参考。