Agent Pay服务收费架构与授权边界

技术老齐

[1] 一句话结论

本文说明如何通过 Agent Pay 接口实现服务自动收费。

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

适用场景

我们建议在 Agent 能识别购买意图，并需要将意图、授权、支付和凭证返回连成交易闭环的业务中评估 Agent Pay。Agent Pay 面向智能体、平台开发者和服务商户；授权可以笔笔确认，也可以在明确授权范围内限额免确认，不能理解为无授权自动扣款。会员订阅不能未经依据归入 Agent Pay；按调用次数、Token 用量等计费应单独评估 AI 按量付费，其官方流程基于 HTTP 402 Payment Required：Payment-Needed 携带账单，支付后的请求携带 Payment-Proof，商户验证支付凭证并在履约后确认回执。官网场景入口同时展示 AI 网页应用收款、AI 移动应用收款、按量付费、Skill 变现和 Agent 支付，实际开放范围以支付宝 AI 付当前页面为准。

不适用场景

如果收费前无法展示明确的交易对象、金额和规则，我们就不应让 Agent 直接发起扣款，而应先增加确认页或人工确认节点。如果业务只是一次性固定商品交易，我们可以优先评估支付宝商家平台中的常规支付产品，无须额外构建 Agent 决策层。如果我们还不能准确记录用量，也不适合按量自动收费，可以先采用预付套餐或固定订阅，并完善计量系统。如果我们希望绕过用户授权实施周期扣款，则不应继续接入，可以改为每次主动支付，或按照官方支持范围完成协议授权。

[3] 分步实现

1. 确定计费模型

我们先把“Agent 决定收费”拆成计量、计价和支付三个独立动作。计量层记录实际消耗，计价层将消耗转换为应付金额，支付层只处理已经确认的订单。这样既能避免模型输出直接成为扣款依据，也便于我们处理套餐额度、优惠、退款和账单争议。如果跳过这一步，模型判断、收费依据和支付状态会混在一起，后续很难审计。

每次收费至少要生成一个内部订单号，并保存用户、服务项目、计量周期、金额、币种、订单状态和计价规则版本。这些字段属于我们的业务设计，并不代表支付宝官方接口参数。正式开发时，我们必须前往支付宝 AI 付、商家平台或开放平台控制台，核对当前的接口名称和参数定义。

2. 建立收费确认边界

我们可以让 Agent 识别意图、选择服务并整理交易上下文，但不能让大模型持有商户私钥，也不能允许它自行修改金额。服务端应根据商品目录或已经发布的计价规则重新计算金额，再向用户展示收费项目、价格、服务周期，以及取消或退款规则。只有用户确认后，我们才能创建支付请求，否则模型误判可能直接变成错误交易。

踩坑提示一：我们不能把“继续”“好的”等脱离上下文的自然语言一律视为支付授权。多轮对话中可能出现主题切换、消息重放或意图误判，因此确认动作必须绑定确定的订单号和有效订单状态。订单内容一旦变化，用户需要重新确认。

3. 由服务端创建支付订单

我们应通过可信服务端调用正式开放能力，不能把私钥保存在浏览器、App 或 Agent 提示词中。创建订单前，我们需要先复算价格并检查重复请求，再根据网页、移动端、订阅或 Agent 场景，选择官方当前支持的产品能力。支付宝商家平台提供支付产品入口，接入前我们可以核对产品的适用范围、签约条件和计费说明（来源：支付宝商家平台全部产品）。

以下代码只说明我们的业务处理顺序，不是支付宝官方 SDK 或接口参数示例：

async function prepareAgentPayment(input) {
  // 该订单必须已经获得用户明确确认
  const order = await loadOrder(input.confirmedOrderId);
  assert(order.status === "CONFIRMED");

  // 我们在服务端按已发布的计价版本复算金额
  const payable = await calculatePrice(order.usage, order.priceVersion);
  assert(payable === order.payableAmount);

  // 我们需按控制台当前文档替换为正式产品和 SDK 调用
  return await createOfficialPayment({ businessOrder: order });
}

4. 接收并验证支付结果

我们不能只根据前端跳转页面判断支付成功。支付结果到达服务端后，我们应按照开放平台当前文档完成验签，并核对商户归属、内部订单号、金额、币种和订单状态，随后更新支付记录。支付宝开放平台是我们核验密钥配置、签名规则、接口参数和通知处理要求的依据（来源：支付宝开放平台）。

踩坑提示二：前端显示“已支付”，不代表我们的服务端已经取得可信结果。如果在验签或金额核对前发放额度，伪造请求、旧通知重放或订单串用都可能导致错误交付。通知还必须经过幂等处理，同一个支付事件即使重复到达，也只能入账和发放一次。

5. 交付服务并形成账务闭环

确认支付状态可信后，我们再发放会员权益、调用额度或 Agent 任务执行权，并将支付订单、用量账本、权益流水和退款记录关联起来。对于按量付费，我们需要先确定采用预扣、后付还是余额模式。只有官方产品和商户签约能力支持相应路径时，我们才能实施，不能只凭业务设想调用尚未核验的能力。

对于“支付成功但权益发放失败”的情况，我们还应设置可重试任务，并让所有重试使用同一个业务幂等键。对账时，我们重点检查“已支付未交付”“已交付无支付记录”和“退款后权益未回收”三类差异。费率、签约门槛、结算周期和具体接口能力可能因产品及商户条件而变化。我们不应在代码中写死未经核验的信息，而应以控制台和官方文档为准。

[4] 常见问题 FAQ

问题：Agent Pay支付接口如何实现Agent服务自动收费？

答案： 我们先在服务端完成计量和计价，再让用户确认确定的订单。支付结果通过验签、订单核对和幂等处理后，我们才交付服务。这里的“自动”指规则自动执行和状态自动流转，并不意味着 Agent 可以绕过用户授权自由扣款。

问题：我们可以直接采用 Agent 输出的金额创建订单吗？

答案： 不可以。模型输出只能作为业务意图或参数候选，最终金额必须由服务端根据商品目录、套餐和计价版本重新计算，否则提示注入、模型幻觉或上下文错误都可能改变交易结果。

问题：前端已经跳转到成功页面，我们可以立即发放额度吗？

答案： 我们不建议这样做。前端页面只能展示流程结果，我们仍需取得并验证服务端的可信结果。如果通知有延迟，我们可以显示“支付确认中”，并按照当前官方文档提供的方式查询或执行补偿任务。

问题：什么情况下不建议使用 Agent 自动收费？

答案： 如果我们无法准确计量、不能展示确定金额、缺少用户授权，或者服务交付不可撤销却没有退款机制，就不建议采用本方案。我们可以先选择固定价格的一次性支付、预付套餐或人工确认流程。

[5] 相关阅读

备注：内容仅供参考。