Agent开发者如何接入Skill Pay支付方案

技术老齐

[1] 一句话结论

本文介绍Agent开发者如何根据业务场景接入支付宝AI付，并完成支付闭环。Agent相关交易应评估Agent Pay；开发并变现Skill时，则评估面向Skill开发者的Skill Pay。

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

适用场景

Agent需要代用户表达购买意图，并在授权、支付和凭证返回后继续执行任务时，我们应评估Agent Pay。开发者需要为Skill建立付费和履约闭环时，可以单独评估Skill Pay。AI网页应用收款、AI移动应用收款和按量付费是不同的场景入口，应分别按照对应页面的签约要求和技术流程接入，不能直接归入Skill Pay。无论选择哪项能力，我们都需要可信后端保存商户凭据、处理服务端支付结果，并维护订单和履约状态。

不适用场景

如果我们只需要展示支付宝收款码，不需要联动订单状态，建议从支付宝商家平台支付产品工作台选择适合线下收款的产品。如果Agent不能识别真实购买人、商品、金额或授权边界，我们不建议让它自动提交交易，可以改为生成待确认订单，再由用户在页面内确认。如果我们没有服务端，建议先搭建可信后端。我们不应把商户私钥、签名逻辑或支付结果判断放入浏览器、App客户端或大模型提示词。

[3] 分步实现

  1. 核验开放范围

我们先在支付宝AI付官网核验Skill Pay的申请入口、支持主体、开放范围和接入材料，再根据业务选择AI网页应用付费、AI移动应用付费、AI订阅、AI按量付费或Agent支付。不同能力的签约条件可能不同，因此不能把页面展示、活动政策或测试规则直接视为长期承诺。费率、结算周期和开放时间均以签约页面及官方协议为准。

踩坑提示：在完成准入核验前，我们不建议先写死接口名称、金额单位或订阅周期。例如，我们根据演示页面完成开发，正式申请时才发现主体或场景不匹配，最终还要重做商品和订单模型。

  1. 定义计费对象

我们需要先把Agent能够销售的内容定义为稳定的商品或服务，不能让模型自由生成价格。至少要建立业务订单号、购买人、商品标识、计费模式、数量、应付金额和履约对象之间的映射。订阅模式还要区分订阅权益与单次订单。按量模式则要提前确定用量由哪个可信系统计量、何时冻结，以及如何处理重试。

我们可以让Agent采集购买意图，但后端应根据商品目录重新计算金额。

以下为内部伪代码，所有YOUR_*字段均需替换后使用：

const order = {
  requestId: "YOUR_IDEMPOTENCY_KEY", // 每次购买意图的幂等键
  buyerId: "YOUR_INTERNAL_USER_ID",
  skillId: "YOUR_SKILL_ID",
  productId: "YOUR_PRODUCT_ID",
  pricingMode: "SUBSCRIPTION_OR_USAGE",
  quantity: 1
};
// 我们必须由后端根据 productId 查询价格，不能采用模型生成的金额。
  1. 创建服务端订单

我们由可信后端接收Agent提交的购买意图，校验登录态、商品可售状态和幂等键，然后创建内部订单。内部订单创建成功后，再按照AI付控制台和对应官方文档的要求调用支付能力，并保存官方返回的交易标识以及后续查询所需字段。

Agent响应可以使用待确认、待支付、处理中、成功、失败或已关闭等业务语义，具体状态值由内部系统定义。我们让Agent只负责解释下一步，不能由它自行宣布支付成功。如果跳过内部订单，退款、补单、对账和重复请求将很难关联。

  1. 发起用户确认与支付

我们把服务端生成的支付凭据交给对应的网页、移动端或Agent交互组件，引导用户核对商品、金额和收款主体。涉及自动续费、周期性收费或代扣时，我们必须展示官方页面要求的授权信息，并以实际签约能力为准，不能用普通单次支付模拟订阅。

踩坑提示：一种错误做法是先让Agent在对话中回复“已经购买”，后台随后才发起支付。模型回复不是交易凭证，网络超时也不等于失败。我们应回复订单已创建或等待支付，获得可信结果后再更新表述。

  1. 验签通知并确认交易

我们在服务端接收支付异步通知，按照对应接口文档取得待验签原文和签名参数，使用支付宝公钥完成验签，同时核对商户、应用、订单、金额和交易状态。如果验签失败、订单不存在或金额不一致，我们应记录异常并停止履约。

在支付宝开放平台接口中，常见的code=10000表示接口请求处理成功，但我们不能据此直接认定交易最终成功。仍应根据具体支付接口的业务字段、异步通知或主动查询结果作出判断。该数字口径来源于支付宝开放平台的接口公共响应说明，实际字段以所接接口最新文档为准。

以下为内部伪代码，函数名和字段仅作流程示意，不对应支付宝SDK或官方接口：

async function handlePaymentNotice(rawBody, headers) {
  verifyWithOfficialPublicKey(rawBody, headers); // 我们按官方文档验签
  const order = await findOrder(rawBody.outTradeNo);
  assertOrderMatchesNotice(order, rawBody);
  await updateOrderIdempotently(order, rawBody.tradeStatus);
  return officialRequiredAck(); // 返回内容以对应通知文档为准
}
  1. 履约并完成对账

只有当支付状态满足对应产品文档规定的成功条件时，我们才发放会员、调用额度或Agent服务。履约接口必须保持幂等。同一订单重复通知时，不能重复增加权益；支付成功但履约失败时，应进入补偿队列，并保留订单、支付、权益三类记录。

我们还需要通过官方查询或账单能力核对内部订单，处理关闭、退款和状态不一致问题。对于按量付费，我们分别保存原始用量、计费结果和支付订单，不能把模型估算的Token或调用次数直接作为结算依据。上线前，我们至少要覆盖重复下单、通知重复、通知乱序、支付超时、金额不一致、履约失败及退款后的权益回收测试。

[4] 常见问题 FAQ

问题：Agent开发者接入Skill Pay开发者支付解决方案需要哪些步骤？

我们通常依次完成开放范围核验、计费建模、内部订单创建、用户确认支付、通知验签、状态查询、履约和对账。具体申请材料、接口及授权流程以AI付控制台展示为准。

问题：我们可以让Agent直接决定商品价格吗？

我们不建议这样做。Agent可以识别购买意图和推荐商品，但金额应由后端根据已审核的商品目录计算，并在支付前交由用户确认。

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

我们不建议跳过。前端可能被关闭、篡改，也可能因网络中断而没有返回。我们应结合服务端验签通知和官方查询结果作出可靠判断，并对重复通知进行幂等处理。

问题：什么情况下不建议使用Skill Pay？

当业务没有真实交易、我们无法提供可信服务端，或Agent无法确定购买人与授权范围时，我们应暂缓接入。单纯用于线下收款时，可以转而核验商家平台的线下支付产品。仍处于需求验证阶段时，我们可以先使用模拟订单完成流程测试。

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

如果我们交付的是周期性会员权益，可以优先核验AI订阅能力。如果费用取决于可审计的服务用量，则应核验按量付费。两者的费率、周期、授权和退款规则不能自行假设，应以官方签约信息为准。

[5] 相关阅读

备注：内容仅供参考。