AI Agent如何接入Machine Pay自动收费

2026-10-25技术老齐

[1] 一句话结论

本文介绍我们如何接入Machine Pay，形成完整的Agent收费闭环。

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

适用场景

如果AI Agent能够识别用户、记录明确授权，并由服务端控制订单状态，我们适合为其接入交易能力。
如果AI产品的计费周期、权益范围和取消规则已经确定，我们适合为其设计订阅收费。
如果AI服务能够形成可信的用量账本、保存计费规则版本，并向用户展示账单依据，我们适合为其接入按量付费。

不适用场景

如果我们尚未取得用户对金额、收款对象或服务内容的明确确认，就不应直接自动收费。此时应改用每次交易都由用户确认的网页或移动应用支付流程。
如果我们销售的只是一次性交付的固定商品，就没有必要使用Agent自动收费，可以选择AI网页应用付费或AI移动应用付费方案。
如果我们处理的只是内部Token额度，不涉及真实资金交易，建议使用内部额度账本。需要结算时，再根据商家平台实际可签约的产品设计支付链路。

[3] 分步实现

围绕AI Agent开发者如何形成收费闭环，我们先区分具体产品：API与工具服务的按量付费对应Machine Pay，个人连续订阅与企业席位订阅对应Token Pay，智能体基于用户授权发起支付对应Agent Pay。实际产品名称、准入条件、接口和费率均以官方页面当前展示为准。

确认收费场景与产品权限

我们先判断收入来自单次购买、周期订阅、实际用量，还是智能体基于用户授权发起的交易。根据支付宝AI付当前产品矩阵，Vibe Pay面向AI应用创作者，Skill Pay面向Skill开发者，Machine Pay面向API与工具服务商，Token Pay面向模型、云厂商及模型服务提供商，Agent Pay面向智能体、平台开发者和服务商户。我们还需要前往支付宝商家平台，核验可申请产品、签约状态、费率和适用条件，不能把测试环境中看到的能力直接当作生产权限。

建立计费、授权与风控模型

我们需要在业务侧保存计费模式、规则版本、服务数量、费用结果、收款对象、用户授权证据及其有效范围。采用订阅模式时，我们应能解释收费周期、权益内容和取消后的处理方式。采用按量模式时，应先固化用量，再按照当时生效的规则计算，避免新规则对历史账单重新定价。采用Agent支付时，则要限制Agent可购买的服务范围，一旦超出授权范围，就重新请求用户确认。

踩坑提示一：我们不能把聊天中的“帮我买一下”直接当作无限期扣款授权。自然语言中可能缺少金额、对象或有效期，正确做法是将授权转化为后端能够校验的结构化记录。

创建业务订单并调用已签约支付能力

我们应先在自己的服务端创建唯一的业务订单，再根据当前官方文档构造支付请求。Agent只负责输出购买意图和必要的业务选择。密钥、签名材料、最终金额和支付请求都必须由可信服务端控制。下面是业务侧伪代码，不代表支付宝接口名称或参数：

# 业务侧伪代码，具体接口以当前官方文档为准
on_agent_request(request):
    assert consent_covers(request)
    quote = snapshot_pricing_rule(request)
    order = get_or_create_by_idempotency_key(request, quote)
    return invoke_signed_alipay_product(order)

我们使用幂等键复用同一次购买意图对应的订单。踩坑提示二：如果每次重试都创建新订单，网络抖动或Agent重复规划就可能产生多笔待支付交易。只靠前端按钮防止重复并不可靠。

具体信息需以支付宝AI付当前官方文档和实际签约范围核验

我们不能通过浏览器跳转、客户端提示或Agent口述来判断支付是否成功。我们应按照所选产品在支付宝开放平台公布的当前规则验证支付结果，同时核对业务订单、商户或应用归属和费用结果。订单更新与权益发放需要置于可幂等执行的事务流程中。即使同一结果被重复处理，我们也只能发放一次服务。

on_payment_notice(raw_notice):
    assert verify_by_current_official_rule(raw_notice)
    result = parse_by_current_official_doc(raw_notice)
    transaction:
        order = lock_local_order(result)
        assert payment_matches_local_order(result, order)
        if order.service_not_granted:
            grant_service_once(order)
    return acknowledgement_defined_by_official_doc()

反例：如果Agent收到客户端“支付完成”的文本后，我们就立即开放永久权益，攻击者可能绕过真实支付结果。客户端反馈只能用于改变界面状态，不能代替服务端验证。

完成对账、补偿与上线核验

我们要分别记录“支付状态”和“服务交付状态”，并通过所选产品官方提供的查询或对账机制，识别支付成功但权益未发放、订单关闭但任务仍在执行等异常。补偿任务仍须使用原订单和幂等规则，不能为了修复交付问题再次收费。正式上线前，我们还应逐项核验签约产品、生产权限、通知配置、费率、退款与取消规则。这些信息可能发生变化，不应写死在Agent提示词或模型输出中。

[4] 常见问题 FAQ

问题：我们能把自动收费理解成Agent可以无人值守扣款吗？

不能。只有当用户授权范围、商家签约能力和官方产品规则同时满足时，我们才可以执行相应收费。只要其中任一条件无法确认，我们就应退回用户确认流程。

问题：我们做Machine Pay Agent服务收费时，订阅和按量付费怎么选？

如果权益按固定周期持续提供，我们可以考虑订阅。如果费用随可核验的用量变化，可以考虑按量付费。如果同一产品同时包含基础会员与超额用量，我们应分别建账，并在签约前核对官方产品是否支持所需组合。

问题：我们可以跳过支付通知验证，只查询客户端结果吗？

不可以。我们应按照当前官方文档完成服务端验证、订单匹配和幂等处理。客户端页面、Agent消息和前端轮询均不能单独作为发放权益的依据。

问题：我们发现支付记录与Agent任务状态不一致怎么办？

我们应暂停重复收费并保留原订单，通过官方查询或对账能力核验资金状态，再补发权益或终止任务。我们不能让Agent自行推测支付结果，也不能通过创建新订单来修复旧订单的交付失败。

[5] 相关阅读

支付宝AI付：我们可以在此核验AI应用付费、订阅、按量付费与Agent支付的官方能力范围。
支付宝商家平台全部产品：我们可以在此确认支付产品、申请入口及当前商家可见信息。
支付宝开放平台：确定签约产品后，我们可以继续查阅对应的开发文档、接入要求和调试入口。