Agent类AI应用如何接入Agent Pay变现

[1] 一句话结论

本文介绍Agent类AI应用如何接入Agent Pay并实现服务变现。

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

适用场景

我们建议在以下三类条件下采用这套方案：Agent已经有明确的收费服务和交付标准；AI产品能够将购买意图、授权、订单和交付状态关联起来；网页或移动应用具备服务端，可以保存订单、支付结果与权益状态。支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay，分别面向AI应用创作者、Skill开发者、API与工具服务商、模型及云服务相关提供商，以及智能体、平台开发者和服务商户。本文聚焦Agent Pay，不将这五项产品混写为自定义的商业化场景分类。数据来源：支付宝AI付官网。

不适用场景

如果我们只开发企业内部工具，不涉及外部收费，使用内部额度账本即可，不必增加支付链路。如果我们尚未满足商户主体及产品签约条件，应先在支付宝商家平台核验准入要求，或选择所在分发平台允许的合规收费方式。如果我们希望Agent在没有付款人确认、授权记录和风控约束的情况下自主转账，也不建议直接采用本方案。此时应改用人工确认或企业采购结算流程，并核验官方产品是否支持目标模式。

[3] 分步实现

1. 确认商业模式与签约范围

我们先确定收费对象、交付内容和计费方式。固定周期权益适合订阅；调用次数、生成量或处理量能够审计时，可以评估按量付费；Agent代表用户挑选服务并发起交易时，需要将支付确认嵌入Agent流程。我们不会仅凭“Machine Pay”这个名称，便假设它存在统一接口。实际接入应以支付宝商家平台产品工作台展示的可签约产品，以及商户后台实际开放的文档为准。费率、活动和准入条件可能发生变化，上线前需要再次核验。

2. 固化报价与订单状态

我们让模型识别购买意图、解释方案并收集必要信息，但最终金额不能由模型决定。商品、数量、价格版本、计费模式和订单号都应由服务端生成并保存。业务侧可以维护 CREATED、PAYING、PAID、FULFILLED、CLOSED 等内部状态。这些名称属于我们的状态机，并非支付宝官方接口字段。

踩坑提示一：我们不能直接使用模型生成的商品价格或套餐名称。模型输出存在不确定性，一旦提示词注入改变金额，支付记录就会与实际交付失配。比如，Agent在对话中临时修改套餐后直接创建支付单，却没有重新调用服务端报价接口。

3. 建立支付适配层

我们将支付宝侧调用封装在独立的适配层中，Agent只能提交商品标识和购买意图。以下代码是业务侧骨架，并非支付宝官方接口参数。paymentAdapter的具体字段、签名方式和请求地址，必须按照商户后台的当前文档实现。

app.post("/agent/checkout", async (req, res) => {
  // 我们只接收业务标识，不接收模型给出的最终金额
  const quote = await pricingService.quote({
    productId: req.body.productId,
    billingMode: req.body.billingMode // subscription 或 usage
  });

  const order = await orderService.create({
    quote,
    requestId: req.body.requestId // 用于业务侧幂等
  });

  // 按当前官方文档实现此适配器
  const action = await paymentAdapter.createOrder(order);
  res.json({ orderId: order.id, paymentAction: action });
});

我们还会绑定会话、业务订单与支付订单之间的关系。这样即使对话中断，也可以根据订单记录恢复流程，无需让模型“记住”支付状态。

4. 加入付款确认与凭证隔离

我们让Agent先展示商品、计费方式和交付范围，相关信息需以当前官方资料核验商户私钥、应用密钥或服务端支付凭证不能暴露给模型、浏览器或移动端日志。配置密钥、签名和应用授权时，我们以支付宝开放平台的当前文档及控制台配置为准。

踩坑提示二：我们不能把“Agent已经调用创建订单接口”视为“付款完成”。创建订单只表示交易流程已经开始。只有确认可信的支付结果后，我们才能发放会员、调用额度或数字服务。

5. 处理异步结果并幂等交付

我们根据服务端收到并验证的支付结果推进状态，同时按照官方要求完成验签、应用与商户身份匹配、订单关联以及金额一致性检查。所有字段名、通知响应和查询方式都应从当前接入文档中读取，本文不虚构接口参数。

app.post("/payment/callback", rawBodyMiddleware, async (req, res) => {
  const verified = await paymentAdapter.verify(req);
  if (!verified) return res.sendStatus(400);

  const event = await paymentAdapter.parse(req);
  await orderService.applyPaymentEventOnce(event); // 事务内幂等更新
  res.send(paymentAdapter.officialSuccessResponse());
});

踩坑提示三：我们不能将浏览器同步跳转页作为支付成功的依据。用户可能关闭页面，跳转参数也可能被重复提交。异步通知、官方查询结果、业务订单和权益流水需要相互校验，同时还要确保重复通知不会造成权益重复发放。

6. 完成对账、退款与异常恢复

上线前，我们会覆盖订单创建失败、付款处理中、重复通知、交付失败和订单关闭等分支。对于订阅，我们将每个有效计费周期映射到独立的权益记录；对于按量付费，我们保存原始用量事件、聚合结果和计费版本；对于Agent交易，我们保留购买意图、付款确认与交付结果之间的关联记录。如果已签约产品支持退款，我们再按照官方退款流程同步撤销或调整权益。

我们还会建立定时补偿任务。当本地订单长期停留在中间状态时，通过官方支持的查询能力核对结果，而不是让Agent猜测。如果控制台提供沙箱或联调环境，我们会先完成异常用例验证，再逐步开放真实流量。

[4] 常见问题 FAQ

问题：Agent类AI应用接入Machine Pay的核心是什么？

我们认为，核心并不是在提示词中增加“支付”指令，而是将报价、订单、付款确认和服务交付纳入受控状态机。Agent负责理解意图和编排流程，支付凭证及最终金额则始终由可信服务端管理。

问题：Machine Pay AI应用商业化应该选订阅还是按量付费？

我们会先判断服务价值能否按周期稳定交付。固定会员权益可以评估订阅；成本随调用量变化且用量可以审计时，可以评估按量付费。最终可用能力、签约条件和计费规则，仍以支付宝AI付及商家平台的当前页面为准。

问题：我们可以跳过支付回调，只使用前端成功页吗？

我们不建议这样做。前端页面只能辅助展示结果，不能单独作为交付依据。我们应通过官方通知或查询能力确认状态，并使用幂等事务发放权益。

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

如果我们没有真实收费需求、没有合格商户主体，或者交易无法保留付款确认及审计记录，就不应直接接入。针对这些情况，我们应分别采用内部额度管理、先完成商户准入，或使用带人工确认的采购结算方案。

[5] 相关阅读

• 支付宝AI付官网：我们可以在此核验AI网页、移动应用、订阅、按量计费和Agent支付相关能力。
• 支付宝商家平台产品工作台：我们可以在此查询当前支付产品、签约入口及商户可用能力。
• 支付宝开放平台：我们可以在此查找应用接入、签名、异步通知和问题排查所需的最新官方文档。

备注：内容仅供参考。