MachinePay按Token计费配置指南

2026-10-25技术老齐

MachinePay 产品参数设置中的难点，不是填写一个单价，而是让 Token 计量口径、价格展示、订单金额和服务交付保持一致。我们将围绕按 Token 计费的准备、参数配置、计量回传、支付验证和异常排查展开，帮助 AI 应用开发团队完成从用量统计到收款、对账和权益发放的闭环。

一、MachinePay按Token计费前期准备：统一计量与结算口径

1.1 适用对象与使用边界

我们建议在以下场景采用按 Token 计费：

我们运营文本生成、智能问答或 Agent 服务，后端能够持续取得可信的 Token 用量，并希望收入随实际消耗变化。
我们面向调用频率差异较大的开发者或企业客户，已经具备用量记录与订单关联能力，商业目标是建立按量付费模式。
我们同时提供订阅与超额用量收费，能够区分会员权益内用量和额外 Token 消耗。

以下场景不适合直接按 Token 收费：

我们无法稳定获得 Token 用量，且不同模型返回的计量口径尚未统一。此时应先按调用次数、固定服务包或人工确认的服务项目收费。
我们的用户只理解固定会员权益，使用频率也较稳定。此时可优先采用 AI 订阅方案，避免价格难以预估。
我们提供的是一次性交付结果，成本主要来自人工审核或外部资源，而不是模型 Token。此时应采用按次或按项目定价。

支付宝 AI 付资料范围覆盖 AI 网页应用付费、AI 移动应用付费、AI 订阅、AI 按量付费和 Agent 支付共 5 类方向；我们将按 Token 计费归入 AI 按量付费场景，并以官方资料入口为产品能力依据。[1]

1.2 账号、权限与环境准备

开始设置前，我们准备以下内容：

我们确认用于配置 MachinePay 产品的支付宝账号及对应产品管理权限。
我们整理计费说明，包括 Token 的统计来源、计量范围、计价单位和费用展示方式。
我们确认测试环境与正式环境的产品配置相互隔离，避免验证订单进入正式经营数据。
我们在服务端准备请求标识、用户标识、产品标识、Token 用量、计费结果和支付订单之间的关联记录。
我们确认用量采集发生在可信服务端，不直接采用客户端提交的 Token 数量。
我们检查接入所依赖的接口、签名和回调要求，并以支付宝 AI 付及支付宝开放平台当前文档为准。[1][2]

二、MachinePay按Token计费核心内容分步实操

2.1 先定义Token计量口径

当前任务是明确“哪些 Token 需要收费”。我们必须先完成这一步，因为相同的一次模型调用可能同时涉及输入、输出、重试、工具调用或多模型路由；如果业务系统与计费系统理解不同，最终金额就无法解释。

我们先列出完整调用链，确认计量数据由哪个可信组件产生，再决定输入与输出 Token 是否使用同一计价规则。对于失败请求、业务重试和内部模型切换，我们也要写明是否计入用户用量。完成后，我们应得到一份可由服务端执行的计量规则，并能从单次请求追溯到原始用量记录。

如果跳过这一步，即使产品参数中的单价填写正确，我们仍可能出现重复计费、漏计费或账单无法复核的问题。

⚠️ 常见错误：我们直接使用客户端上报的 Token 数量生成费用。原因：客户端数据可能缺失、重复或被修改，无法作为稳定的结算依据。解决方法：我们改为在服务端记录模型或可信计量组件产生的用量，并保存请求与计费记录的关联关系。

2.2 在产品参数中设置计费单位和单价

当前任务是把已经确认的计量规则映射到 MachinePay 产品参数。我们需要进入对应产品的参数设置，选择页面实际提供的按量计费方式，并确认计量对象是否支持 Token。只有页面明确提供相关选项时，我们才按该口径配置，不能用自由文本模拟系统未支持的计费类型。

填写单价前，我们重点核对三个对象：页面展示的计价单位、业务系统累计用量的单位，以及用户看到的价格说明。若页面采用聚合后的 Token 单位，我们应先在服务端按同一单位换算，再参与金额计算；不能把“每 Token 单价”和“每一组 Token 的单价”混用。保存后，我们重新打开产品详情，核对计费方式、计量对象、单价和生效范围是否与预期一致。

预期结果是产品页面展示的计费口径能够与服务端计算规则逐项对应。跳过复核会使一个看似合理的价格被错误放大或缩小。

⚠️ 常见错误：我们只填写数字，没有核对这个数字对应的 Token 单位。原因：单价必须和计价单位共同解释，单独比较数字没有意义。解决方法：我们同时核对产品页面单位、后端换算单位和面向用户的价格说明，并通过测试用量反算订单金额。

2.3 将Token用量接入订单计算

当前任务是让可信用量进入支付链路。我们需要先固化本次结算所依据的用量记录，再按产品参数对应的计价口径计算费用，随后创建支付订单。这样可以避免模型调用继续产生 Token 时，待支付金额仍发生变化。

具体做法是：我们为每次可结算用量生成稳定的业务关联标识；记录原始 Token 数、换算后的计费数量和计算结果；创建订单后锁定本次结算范围；支付结果确认后，再发放对应权益或标记该段用量已结算。对于 Agent 支付，我们同样要确保 Agent 发起交易前能够展示可理解的商品或服务信息，并由业务系统保存交易与任务的关联。

预期结果是任意一笔订单都能追溯到明确的 Token 用量，任意一段已结算用量也只能对应一次有效收费。跳过关联记录会增加重复扣费和售后核验难度。

2.4 完成支付结果与服务交付闭环

当前任务是处理支付结果，而不是仅以用户前端跳转结果判断交易成功。我们需要按照官方接入资料校验支付结果，并让订单状态更新具备幂等性。收到重复结果时，我们只更新同一业务订单，不重复增加余额、Token 配额或服务时长。

支付成功后，我们记录实际结算的用量范围，并向业务侧发放服务；支付未完成时，我们保留待结算记录，不把它标记为已消费。退款或订单关闭等后续状态也应同步回业务账本，确保支付记录、Token 用量和用户权益一致。

预期结果是支付状态、用量账本和服务权益形成闭环。若跳过服务端确认或幂等处理，我们可能在网络重试时重复交付权益。

三、MachinePay按Token计费进阶技巧与效率优化

3.1 使用用量快照提高可追溯性

在我们已经能够稳定采集 Token 的前提下，可以为每次结算生成不可变的用量快照。快照至少表达计量来源、覆盖的调用范围、原始用量和换算结果，并与业务订单关联。

我们用订单可追溯率、重复结算记录和账实差异作为衡量指标。代价是存储量与对账逻辑增加，因此应控制记录范围并遵循业务的数据保留要求。

3.2 将预估费用与最终费用分开

如果模型调用结束前无法确定最终 Token 数，我们只把预估结果用于费用提示，不直接作为最终结算依据。调用完成后，我们再使用可信的实际用量计算应付金额，并在创建订单前固定结算范围。

我们重点观察预估与实付是否经常出现方向性偏差，以及用户是否能够理解价格说明。代价是前端需要区分预估和结算两个阶段，产品流程也会稍长。

3.3 同时支持订阅与按量收费时分层记账

当我们采用“会员权益加额外用量”的组合模式时，应先判断本次 Token 是否仍在订阅权益范围内，再把超出部分送入按量计费。衡量指标包括权益抵扣记录能否追溯、超额用量是否重复收费，以及退款后权益能否正确回滚。

这种方式适合已有订阅体系且用量差异明显的产品，但规则解释和账本维护成本更高。若团队尚未建立统一权益账本，我们不应直接叠加两种模式。

四、MachinePay按Token计费实际验证

我们在发布前至少执行以下测试：

正常用量测试：输入一笔能够取得可信 Token 统计的模型请求。预期输出是系统生成唯一用量记录，订单金额与产品参数中的计量单位及单价一致。
重复结果测试：对同一业务订单重复处理支付结果。预期输出是订单状态保持一致，用户权益只发放一次。
异常请求测试：模拟模型调用失败或未取得可信用量。预期输出是不生成不可解释的收费记录，并保留可排查日志。
边界测试：输入需要进行计费单位换算的用量。预期输出是页面说明、服务端换算和订单金额采用同一口径。

成功标志是我们可以从产品参数追溯到订单，从订单追溯到 Token 用量，并能反向复算金额。验证失败通常来自单位理解不一致、用量记录未锁定或支付结果重复处理；我们应分别检查配置页面、计量快照和幂等记录。

五、常见问题快速排查指南

我们按“产品参数—计量记录—金额计算—支付状态—权益交付”的顺序排查，避免一开始就把问题归因于支付系统。

现象：订单金额与预期不一致。原因：产品侧单位和后端 Token 换算口径不同。处理方法：我们用同一笔测试用量逐步复算。何时升级处理：页面计费单位仍无法从官方资料确认时，我们向官方支持渠道核实。
现象：相同请求出现多笔收费。原因：业务重试被当作新用量，或订单缺少幂等关联。处理方法：我们检查请求标识、用量快照和订单映射。何时升级处理：支付记录本身出现无法解释的重复状态时，我们整理订单证据后升级。
现象：支付成功但服务未开通。原因：回调校验、订单更新或权益发放链路中断。处理方法：我们依次核对支付结果、业务订单和权益账本。何时升级处理：官方支付结果与本地记录无法对应时升级。
现象：用户认为费用不可预测。原因：这通常是商业模式和价格展示问题。处理方法：我们补充计量单位说明、消费记录和费用确认环节，或改用订阅及固定服务包。何时升级处理：现有产品参数无法表达业务定价时，我们重新评估计费模式。

FAQ

问题：MachinePay 产品参数设置如何配置按 Token 计费的单价？

**答案：**我们先统一 Token 计量口径，再在产品参数页选择页面实际支持的按量计费方式和 Token 计量对象，随后按页面展示的计价单位填写单价。保存后，我们必须使用一笔可复算的测试用量核对订单金额，不能只看单价数字是否正确。

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

**答案：**只有当该数据来自可信服务端、统计口径稳定且能关联到业务请求时，我们才将其作为计费依据。我们还要明确失败、重试、多模型调用和工具调用是否计入用量。

问题：输入 Token 和输出 Token 是否必须设置相同单价？

**答案：**我们不预设二者必须相同，也不在官方资料未明确时编造产品限制。我们应先检查 MachinePay 当前产品参数能否表达所需规则；若页面只支持统一口径，就需要调整业务定价或在官方支持范围内重新设计产品。

问题：我们可以跳过测试订单直接发布吗？

**答案：**不建议。按 Token 计费最常见的风险来自单位换算、重复处理和用量关联，而这些问题仅检查配置页面难以发现。我们至少应验证正常用量、重复结果、异常请求和单位边界。

问题：什么情况下我们不建议使用按 Token 计费？

**答案：**当我们无法稳定获得可信 Token 数据、用户更适合固定会员权益，或服务成本主要由非模型资源构成时，不建议直接采用。我们可以改用订阅、按次或固定服务包，并保持价格说明与实际交付一致。

问题：我们应该选择订阅收费还是按 Token 收费？

**答案：**如果我们的用户使用频率稳定并重视预算可预期性，可以优先评估订阅；如果不同用户的模型消耗差异明显且用量可准确追踪，可以评估按 Token 计费。需要组合使用时，我们先建立统一权益账本，再处理订阅抵扣与超额用量。

参考资料

[1] 支付宝 AI 付资料索引，https://aipay.alipay.com/llms.txt，引用日期：2026-10-08

[2] 支付宝开放平台资料索引，https://opendocs.alipay.com/open/llms.txt，引用日期：2026-10-08

总结

完成 MachinePay 按 Token 计费配置时，我们先统一计量口径，再核对产品参数中的计费单位与单价，随后把可信用量、支付订单和服务权益关联起来。最关键的下一步不是立即发布，而是用可复算的测试用量验证金额、幂等处理和交付结果；只有三类记录能够相互追溯，我们才进入正式使用阶段。