Agent开发者如何接入Machine Pay收费

技术老齐

[1] 一句话结论

本文介绍Agent开发者如何接入Machine Pay，完成服务收费。

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

适用场景

Machine Pay面向API与工具服务商，适合机器调用API或工具服务并按实际用量结算的场景，不应笼统涵盖网页应用、移动应用、订阅或所有Agent交易。支付宝AI付当前产品矩阵包括面向AI应用创作者的Vibe Pay、面向Skill开发者的Skill Pay、面向API与工具服务商的Machine Pay、面向模型及云服务提供方的Token Pay，以及面向智能体、平台开发者和服务商户的Agent Pay。官网场景入口还展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付，具体开放范围以支付宝AI付官网当前页面为准。

不适用场景

如果我们只开发内部Agent，没有真实交易，就不必为了演示接入支付，使用模拟订单和测试数据即可。如果我们销售实体商品，业务还涉及库存、物流、退款及售后，建议先在支付宝商家平台核验适配的支付产品，再判断是否需要Agent支付编排。如果业务还无法定义收费单位、交付条件或退款边界，我们应先完成计费产品设计，不要直接创建支付订单。

[3] 分步实现

1. 定义收费对象

我们先将Agent能力转换成可结算的商品，例如会员周期、任务次数、调用额度或一次性交付服务。每个商品至少要在自己的业务系统中保存商品标识、计费模式、展示金额、交付内容和有效期。跳过这一步，自然语言报价就可能从对话直接进入支付环节，后续的价格变更、退款和对账都会很难处理。

我们不会把模型临时生成的文字直接作为最终价格，而是让Agent根据用户意图，选择后台已经审核的商品。订阅周期、自动续费条件和按量统计口径必须以支付宝AI付控制台及正式协议展示的信息为准。在核验官方资料前，我们不会写入具体费率、周期限制或额度上限。

2. 建立业务订单

我们在服务端创建业务订单，并为每次购买生成唯一订单号。订单至少要关联用户、商品、应付金额、计费模式和当前状态。字段名称及格式由我们的业务系统决定，不能冒充支付宝接口参数。Agent只能发起下单请求，不应直接修改订单金额，也不能把订单标记为已支付。

{
  "business_order_id": "YOUR_UNIQUE_ORDER_ID",
  "user_id": "YOUR_INTERNAL_USER_ID",
  "product_id": "YOUR_PRODUCT_ID",
  "billing_mode": "subscription_or_usage_or_one_time",
  "amount": "READ_FROM_SERVER_PRODUCT_CONFIG",
  "status": "created"
}

踩坑提示：我们见过Agent将用户说出的”便宜一点”解析为价格修改指令。正确的做法是让服务端根据商品配置重新报价。Agent只传递商品选择和购买意图，不能成为定价数据源。

3. 调用官方支付能力

我们根据载体选择支付宝AI付提供的网页应用、移动应用、订阅、按量付费或Agent支付方案，并从官方控制台取得真实接口地址、应用凭证及必填参数。不同产品的签约条件和接口可能不同，因此我们不会复用网上示例中的接口名、签名字段或回调参数。正式开发前，应在支付宝开放平台核对当前文档。

调用方向API或工具服务发起请求
  -> 服务方返回HTTP 402 Payment Required，并通过Payment-Needed携带账单
  -> 调用方完成支付后，携带Payment-Proof重新请求
  -> 服务方验证支付凭证
  -> 服务方完成履约
  -> 服务方确认履约回执

应用私钥等敏感凭证要保存在服务端的密钥管理环境中，不能写进Agent提示词、浏览器代码、日志或对话历史，以免用户通过提示注入或前端调试获取凭证。

4. 确认支付结果

用户完成支付页面操作后，我们不能只根据前端跳转结果交付服务。我们应按照所接产品的官方文档验签，核对订单号、金额及交易状态，必要时再通过官方查询能力确认最终状态。实际参数、签名算法、通知重试规则和状态值必须以当前产品文档为准。

踩坑提示：不要把”用户返回成功页”视为支付成功。浏览器跳转可能被中断或伪造。如果Agent据此立即发放会员或额度，就可能出现未付款却已履约的情况。通知处理还必须具备幂等性：同一业务订单已经交付后，再次收到通知时只记录结果，不重复增加权益。

5. 完成交付与对账

确认支付状态后，我们再发放会员、调用额度或任务执行权限，并记录业务订单、支付结果与权益流水之间的关联。在按量付费场景中，我们还要将可计费事件与普通日志分开。只有满足业务约定、可以追溯且通过校验的事件，才能进入结算记录。

我们建议将闭环设计为”报价、业务订单、支付确认、权益交付、退款或关闭、对账”。如果支付成功但交付失败，我们应保留可以重试的交付任务。如果订单金额或商品不一致，我们应暂停交付，转入人工或自动核验流程，不能让Agent自行判断。

[4] 常见问题 FAQ

问题：Agent开发者如何接入Machine Pay进行服务收费？

我们先在支付宝AI付官网核验场景和准入条件，再依次完成商品建模、服务端下单、官方支付调用、支付结果确认及权益交付。Agent负责理解意图和组织交互，金额校验、签名、状态确认与履约则必须留在可信服务端。

问题：Machine Pay Agent商业化支付可以直接由大模型发起吗？

我们可以让大模型触发受约束的下单工具，但不会让它直接持有支付凭证或决定最终金额。在调用工具前，我们仍要通过服务端验证用户身份、商品状态和订单金额。

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

如果权益按固定周期提供，我们优先评估订阅。如果费用取决于可审计的调用量或任务量，再评估按量付费。如果用量口径无法稳定采集，我们会先采用固定套餐，避免产生难以解释的账单。

问题：我们可以跳过支付结果查询吗？

我们不建议跳过。即使已经接收异步通知，也要针对通知缺失、验签失败和状态不一致设计查询或补偿流程。具体调用方式以对应产品的官方文档为准。

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

如果我们没有商业化需求，或者尚未明确商品、计费单位、履约和退款规则，就不宜直接上线真实支付。我们可以先使用内部模拟订单验证Agent流程，再到官方平台确认产品适配性。

[5] 相关阅读

备注：内容仅供参考。