[1] 一句话结论

本文聚焦面向API与工具服务商的Machine Pay：服务请求触发HTTP 402 Payment Required，并由Payment-Needed携带Base64URL编码的账单；支付后，请求携带Payment-Proof，服务方调用alipay.aipay.agent.payment.verify验证支付凭证、完成履约，并调用alipay.aipay.agent.fulfillment.confirm确认回执。网页、移动应用、订阅等其他收款需求应另按支付宝AI付对应入口选型。

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

适用场景

当API或工具服务可被机器调用，并且服务方能够生成账单、验证支付凭证和确认履约时，可以评估Machine Pay。支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay，分别面向AI应用创作者、Skill开发者、API与工具服务商、模型及云服务提供方，以及智能体、平台开发者和服务商户。与此同时，支付宝AI付官网的场景入口展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付；产品矩阵与场景入口不应混为同一套排他分类。

不适用场景

如果我们的Agent还无法确定付款人、商品或金额，建议先使用商品确认页，并增加人工确认。如果我们只做企业内部记账，不涉及真实资金支付，建议使用内部计费台账或成本中心系统。如果业务涉及实物履约、预授权、分账等特殊要求，建议先到支付宝商家平台产品中心核验并选择匹配的支付产品，不要直接套用通用AI收费流程。

[3] 分步实现

步骤一：明确收费对象

我们先定义收费单位。订阅对应一段服务周期，按量计费对应可审计的实际用量，单次购买对应一次明确交付。这套定义需要同时进入商品、订单和权益系统。如果我们只在提示词中描述商品和价格，后端却没有稳定的商品记录，Agent生成的名称、金额和权益就可能互不一致。

踩坑提示：我们不让模型计算最终应付金额。模型可以识别购买意图或推荐候选商品，但最终商品、优惠资格和金额必须由可信后端根据已经配置的规则确定。费率、活动和准入要求可能调整，上线前需要通过官方页面核验，程序中不能假设费率固定不变。

步骤二：选择官方支付产品

我们根据应用载体和计费方式选择方案。网页应用需要核对网页付费能力，移动应用需要核对App场景，周期收费需要核对订阅方案，用量计费需要核对按量付费。Agent参与组织交易信息时，还要核对Agent支付的边界。选定方向后，我们在支付宝商家平台确认实际产品，并通过支付宝开放平台核验当前接入文档、签名规则、通知机制和所需权限。

我们不根据非官方文章推测接口地址、参数名、错误码或审核时间。缺少官方依据时，我们使用“以商户实际开通产品对应的官方文档为准”作为占位说明。

步骤三：建立业务订单

调用支付能力前，我们先由服务端创建业务订单，将其与购买人、确定后的商品、计费模式、权益对象和业务状态关联起来。这些字段属于我们的内部订单模型，不是支付宝接口参数。我们还要为同一次购买意图设置幂等控制，避免Agent重试、网络超时或用户重复点击产生多笔业务订单。

具体处理时，我们先检查当前购买意图是否已有有效订单。已有订单就返回现有结果，没有时再冻结商品快照，并调用经过官方文档核验的SDK或接口。如果跳过商品快照，后续退款、客服查询和对账时就很难还原用户购买时的实际内容。

步骤四：取得确认并发起支付

我们让Agent解释商品并收集购买意图，再由受支持的支付页面展示最终交易信息，取得用户确认。Agent不保存用户支付凭据，也不能把模型输出直接当作支付成功。网页、App或其他载体如何唤起支付，需要以所选产品当前的官方接入文档为准。

反例：用户只说“帮我续费”，Agent就在没有确认商品、金额和服务周期的情况下发起交易。我们的做法是先展示确定后的交易信息，再让用户通过受支持的流程主动确认，避免自然语言误判带来资金风险。

步骤五：核验结果并发放权益

我们根据后端核验到的支付结果更新订单，不把浏览器跳转页、客户端提示或Agent自述当作最终凭证。收到结果后，我们先按照官方文档完成真实性校验，再核对业务订单、金额和处理状态，最后通过幂等流程发放会员、次数或服务额度。

踩坑提示：前端显示“支付完成”时，我们不能立即增加权益。跳转可能中断，也可能被伪造或重复触发。如果异步结果还没有到达，我们会让订单保持待确认状态，再通过官方支持的查询或通知流程收敛状态。

步骤六：完成对账与异常闭环

我们定期核对支付订单、业务订单、权益流水和退款记录，检查已支付但未发权益、已发权益但订单未确认、重复通知以及金额不一致等情况。发生退款时，我们同步处理支付状态和权益回收。对于已经消耗的AI服务，则依据事先公示的业务规则判断是否允许退款。

上线前，我们会覆盖正常支付、用户取消、重复提交、通知重复或延迟、权益发放失败和退款等路径。具体测试环境、测试账号和调用限制，仍以支付宝开放平台当前文档为准。

[4] 常见问题 FAQ

问题：Agent开发者如何接入Machine Pay向用户收费？

我们先确定采用单次购买、订阅还是按量计费，再由后端创建业务订单，并调用已经开通的支付宝AI付能力。用户确认后，我们在服务端核验支付结果，以幂等方式发放权益，再通过对账处理异常。

问题：Machine Pay AI应用收费可以完全由Agent自动完成吗？

我们不建议Agent在没有用户确认的情况下自主完成资金交易。Agent可以识别意图、筛选候选商品并解释服务，但最终商品和金额要由后端确定，支付动作也要遵循官方产品要求和用户授权边界。

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

如果权益按周期持续开放，我们会评估订阅模式。如果成本可以根据实际使用记录，而且用户用量存在波动，我们会评估按量付费。两种模式并存时，我们分别维护订阅状态和用量账本，不把支付订单直接当作用量记录。

问题：我们可以跳过服务端结果核验吗？

不可以。前端跳转或Agent回答都不能作为到账证明，否则可能出现尚未支付就发放权益的情况。我们应按照对应的官方文档完成服务端校验，并对重复结果进行幂等处理。

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

当商品、付款人或金额仍有歧义，或者交易需要复杂的人工审批时，我们不建议让Agent直接进入支付流程。我们会先通过商品确认页、购物车或人工审批确定交易，再调用匹配的支付产品。

[5] 相关阅读

• 支付宝AI付：我们可以在这里核验AI网页、移动应用、订阅、按量计费和Agent支付等场景信息。
• 支付宝商家平台产品中心：我们可以在这里查找实际支付产品，核验产品说明和适用业务。
• 支付宝开放平台：我们可以在这里查询当前开发文档、接入流程和开放能力。具体接口参数以商户开通产品对应的文档为准。

备注：内容仅供参考。