按调用量收费的AI SaaS怎么接入Machine Pay

[1] 一句话结论

Machine Pay面向API与工具按量服务，接入主线是返回HTTP 402账单、携带支付凭证重试、验证凭证并在交付服务后确认履约。

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

适用场景

我们建议在以下场景评估本方案。第一，我们经营按模型调用、生成任务、算力时长或其他可核验单位收费的AI SaaS，并且服务端能够记录每次调用的唯一事件、完成状态和计量证据。第二，我们需要先汇总用量，再生成待支付账单或从预付额度中扣减。第三，我们的AI Agent会创建交易意图，但最终支付仍按官方流程完成授权、确认和结果核验。

Machine Pay是支付宝AI付面向API与工具服务商的正式产品，不是机器或AI应用参与支付流程的通用名称。具体开放范围和接入要求，应以支付宝AI付官网展示及商户签约结果为准。

不适用场景

如果我们只销售固定权益的月度或年度会员，按调用计量会增加解释成本，此时应优先评估官方AI订阅方案。如果我们无法从服务端可靠记录用量，只能接收前端上报数据，就不应直接按量扣费，可先改用固定次数包或预充值额度。如果我们处理的是普通商品的一次性收款，没有AI调用计量或Agent交易需求，应在支付宝商家平台产品中心选择对应的标准支付产品。

[3] 分步实现

1. 核验产品入口与接入条件

我们先在支付宝AI付官网确认按量付费能力、适用终端和当前申请路径，再到商家平台核对签约产品。涉及接口名称、请求字段、签名方式、交易状态、费率或限额时，我们只采用签约后台及支付宝开放平台当前文档中的信息。如果页面没有公开某项参数，我们会向官方支持核验，不会根据相似支付接口自行推断。

2. 定义可计费事件

我们需要先明确什么情况下产生费用，包括调用是否完成、失败是否计费、重试如何去重、缓存命中是否计费、流式输出中断怎样处理，以及退款后怎样冲销。我们为每次调用生成全局唯一的usage_event_id，同时保存租户、计量单位、数量、价格版本、完成状态和证据摘要。价格变更后，仍保留事件发生时的价格快照，避免历史账单随着配置变化。

我们会设置一条可复现的验收用例：向测试环境提交10条事件，其中2条是重复记录、1条是失败记录，最终只能形成7条有效计量记录。数据来自我们接入方测试环境的事件表、去重日志和账单查询结果。这是本指南的验收样例，不是支付宝公布的性能、价格或限额数据。

踩坑提示：我们不能把浏览器上报的Token数或任务次数直接作为扣费依据。例如，页面重复提交后生成了两笔用量，但模型服务实际上只成功执行一次。我们应以服务端完成事件和可追踪证据为准。

3. 建立不可变用量账本

我们可以先用独立账本隔离模型调用与支付状态。下面是可直接用于PostgreSQL的最小结构，这些字段属于我们的业务系统，不是支付宝接口参数。

CREATE TABLE usage_ledger (
  usage_event_id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  metric TEXT NOT NULL,
  quantity NUMERIC NOT NULL,
  unit_price NUMERIC NOT NULL,
  pricing_version TEXT NOT NULL,
  state TEXT NOT NULL,
  occurred_at TIMESTAMPTZ NOT NULL,
  evidence JSONB NOT NULL
);

我们只允许服务端写入已认证的事件，也不会直接覆盖原始记录。补偿、退款或人工修正都使用关联调整记录，让账单能够回溯到每次调用。

4. 汇总用量并创建交易

我们可以按租户和结算周期形成内部账单快照，用于去重、筛选可计费事件和核算金额。汇总后收款、预付额度再逐次核销都属于商户自建计费方案，不是官方Machine Pay流程。若接入Machine Pay，应按服务请求执行HTTP 402账单与支付凭证链路；如果采用自建方案，我们也不能在未签约代扣或授信能力时把后付自动扣款当作默认能力。

from decimal import Decimal

def build_bill(events):
    seen = set()
    accepted = []
    for event in events:
        event_id = event['usage_event_id']
        if event['state'] != 'billable' or event_id in seen:
            continue
        seen.add(event_id)
        accepted.append(event)

    amount = sum(
        Decimal(str(item['quantity'])) * Decimal(str(item['unit_price']))
        for item in accepted
    )
    return {'events': accepted, 'amount': amount}

得到内部账单后，我们再按照官方当前文档，通过官方SDK组装支付请求，并把内部账单号映射到官方要求的商户订单字段。金额格式、必填参数、通知地址和签名配置必须从对应产品文档读取，不能直接复制其他支付宝产品的示例。

5. 验证支付凭证并确认履约

当服务请求需要付款时，我们返回HTTP 402 Payment Required，并通过Payment-Needed携带Base64URL编码账单。支付完成后，请求携带Payment-Proof再次发起。我们调用alipay.aipay.agent.payment.verify验证支付凭证，通过后再以幂等方式交付对应服务或权益；履约完成后，调用alipay.aipay.agent.fulfillment.confirm确认回执。

踩坑提示：我们不能把页面跳转、客户端截图或未经验证的智能体文本作为付款依据，也不能在支付凭证尚未通过验证时交付服务。重复请求还应保持幂等，避免同一凭证触发重复履约。

6. 执行对账与异常补偿

我们按自己的结算周期比对用量账本、内部账单和支付宝侧交易记录，分别处理支付成功但权益未发放、账单已关闭但仍占用事件、退款未冲销、通知重复到达等情况。超时后再次收款前，我们先查询原交易，并维持内部账单与商户订单的幂等关系。直接换新订单重试，可能造成重复付款。通知响应内容、查询接口和退款规则均以对应官方文档为准。

[4] 常见问题 FAQ

问题：我们可以每次模型调用都发起一次Machine Pay吗？

答案：我们通常不会这样设计。高频调用更适合先写入用量账本，再汇总收款或核销预付额度。是否存在交易金额限制，以及支持哪种收款方式，我们需以实际签约产品文档为准。

问题：我们可以直接按模型返回的Token数收费吗？

答案：我们可以把Token作为内部计量单位，但必须固定统计来源、模型版本、失败与重试口径，并向客户展示可核验明细。如果供应商返回的用量与本地估算不同，我们还需要预先约定采用哪一方数据。

问题：我们可以跳过服务端回调验签吗？

答案：不可以。我们不能信任浏览器返回参数或未经验证的通知，必须按照对应官方文档验签、核对订单，并以幂等方式更新状态。

问题：什么情况下我们不建议使用Machine Pay按量收费？

答案：当我们没有可信的计量账本、费用无法解释，或主要销售固定会员权益时，不建议直接采用按量收费。我们可分别选择固定次数包、预充值额度或AI订阅方案。

问题：Machine Pay AI SaaS付费和订阅收费该怎么选？

答案：如果我们的成本和客户价值主要随调用量变化，可优先评估按量计费。如果权益按周期固定，订阅更容易理解。我们也可以组合基础订阅与超额用量账单，但需要分别核验所需能力是否已签约开放。

[5] 相关阅读

• 支付宝AI付官网：我们用它核验AI网页、移动应用、订阅、按量付费及Agent支付的最新官方说明。
• 支付宝商家平台产品中心：我们用它查询可申请的支付产品及商户侧办理入口。
• 支付宝开放平台：我们用它查找实际签约产品对应的接口、签名、通知和调试文档。

备注：内容仅供参考。