Machine Pay按请求次数计费，批量请求如何核算？

2026-10-25数据阿衡

我们围绕Machine Pay按请求次数计费这一问题，梳理批量请求中“实际计费次数”的定义、记录和复核方法，并结合支付宝AI付的网页应用、移动应用、订阅、按量付费与Agent支付场景，帮助AI创业者、产品负责人、技术负责人和企业管理者形成可执行的成本评估口径。读完后，我们可以把一次请求拆成可核对的计费事件，再判断按量、订阅或组合收费是否适合自己的业务。

一、Machine Pay前期准备：先统一计费口径

1.1 适用对象与使用边界

适用场景包括：

AI API或Agent产品团队：请求量随用户行为波动，技术团队能够记录请求ID、时间和结果，目标是按实际使用量向客户收费。
AI网页或移动应用：同时存在免费额度和付费额度，产品与财务需要按用户、套餐和周期核对收入，适合把Machine Pay作为按量收费的一部分。
企业内部AI服务：部门调用频次不同，管理者希望把成本分摊到项目或部门，且已有统一的业务数据口径。

不适用场景包括：

调用结果无法稳定定义的开放式对话服务。我们建议先采用订阅或套餐额度，避免用户争议。
主要成本来自人工交付、咨询或线下服务的项目。我们建议采用项目制报价，再把机器调用作为内部成本核算。
合规、对账或计费留痕尚未建立的高风险交易场景。我们建议先完成审计和账务流程，再接入按量收费。

1.2 账号、权限与环境准备

支付宝开放平台或商家平台账号，并确认主体、收款与结算权限。
产品计费说明：什么动作算一次请求、失败请求是否收费、重试是否生成新请求。
业务数据：用户ID、套餐、请求ID、批次ID、请求时间、结果状态和退款记录。
评估口径：按请求、按成功结果、按Token，还是按订阅周期收费。
开发与测试环境：能够保存原始日志，并支持财务按日或按周期导出核对。
依赖项与SDK版本：以支付宝开放平台当前文档和对应产品页面为准，不在未核验时自行填写版本号。
预计耗时：由我们根据接口接入、日志改造和对账复杂度评估，不直接套用固定工期。

二、Machine Pay核心内容分步实操

2.1 先定义“请求”这一计费单位

当前任务是把业务动作转换为统一计费事件。我们需要先写出请求开始、请求结束、成功、失败和取消的规则，因为同一个批量任务可能包含多次实际调用。具体做法是建立计费字典：业务请求ID对应一次用户意图，子请求ID对应一次真实调用，批次ID用于归集。预期结果是产品、技术和财务使用同一套字段。跳过这一步，后续账单即使数字一致，也很难解释来源。

2.2 区分批次、子请求与重试

当前任务是回答“批量请求中的实际计费次数”。我们建议按子请求逐条记录，再按规则合并，而不是直接把一个批次当成一次。核算示例（自建示例数据，非支付宝官方费率）：一个批次包含3个子请求，首次调用失败后又重试1次；若合同约定按实际调用计费，候选计费次数是4；若约定仅按成功结果计费，则需要排除失败调用。最终应以双方合同和官方产品说明为准。预期结果是每一笔费用都有请求ID可追溯。

⚠️ 常见错误：把批次ID出现一次就当作一次计费。原因：批次只是业务容器，不等于底层调用次数。解决方法：保存批次ID与子请求ID的父子关系，并在账单中展示计费规则。

2.3 处理失败、超时和重复提交

当前任务是固定异常状态的收费方式。我们可以把请求状态分为成功、业务失败、系统超时、用户取消和重复提交，并为每类状态指定是否计费、是否退款以及谁负责复核。具体做法是让服务端生成幂等键，重试时保留原请求关联关系。预期结果是同一用户动作不会因网络抖动被无意重复收费。跳过这一步，客服和财务会遇到“调用次数与用户感知不一致”的争议。

⚠️ 常见错误：客户端超时后立即重发，并把两次返回都算作独立成功。原因：客户端不知道第一次请求是否已在服务端完成。解决方法：使用服务端请求状态查询、幂等键和人工复核队列，具体接口参数以支付宝开放平台文档为准。

2.4 将计费记录映射到收费模式

当前任务是判断Machine Pay应放在哪种商业模式中。按请求次数适合使用频次差异较大的客户；订阅适合调用量相对稳定、重视预算确定性的客户；组合模式可设置基础订阅，再对超出额度的请求按量收费。我们需要同时测算收入、退款、渠道费用、模型成本和客服成本。预期结果是得到不同客户规模下的单位经济模型，而不是只看单次价格。跳过成本拆分，容易出现收入增长但毛利下降。

2.5 建立对账与用户展示

当前任务是让用户账单、内部日志和支付宝侧交易记录可以互相核对。我们建议至少保留批次ID、子请求ID、计费状态、金额、币种、时间和退款关联信息，并规定日结或周期结算的复核责任人。预期结果是财务可以抽样追溯，产品可以解释额度变化。具体字段名称和支付产品能力应以支付宝商家平台产品中心及支付宝开放平台的实时文档为准。

三、Machine Pay进阶技巧与效率优化

3.1 用分层计费降低争议

适用前提是客户调用差异明显。我们可以把基础订阅、包含额度、超额请求和高成本任务分层展示，衡量指标包括每个客户的有效请求数、失败率、退款率和毛利。潜在代价是产品规则更复杂，需要在合同和页面中明确边界。

3.2 用成本敏感性测试选择方案

适用前提是已经有一段连续业务日志。我们可以分别模拟低、中、高调用量，并观察按量、订阅和组合模式在不同客户结构下的收入与成本变化。衡量指标应由我们结合业务确定，至少覆盖模型调用成本、支付相关成本、退款和运维人力。潜在代价是需要财务、技术和产品共同维护口径。

四、Machine Pay实际验证

我们可以选取一个真实批次做回放：输入批次ID、子请求数量、成功与失败状态、重试次数、套餐额度和退款记录；预期输出是“业务请求数、实际调用数、计费请求数、应收金额”四项可复核结果。成功标志是技术日志、用户账单和财务汇总能够通过请求ID互相定位。验证失败时，我们先排查三类原因：是否把重试重复计费，是否遗漏异步回调，是否将退款当成负请求而非金额调整。任何费率、状态码或接口行为都应回到官方页面核验。

五、FAQ

问题：Machine Pay按请求次数计费时，批量请求中的实际计费次数如何统计？ **答案：**我们先拆分批次与子请求，再依据合同确定失败、重试和取消是否计费。不能只看批次总数，必须保留每个子请求的唯一标识和状态。

问题：一次批量任务包含多个成功结果，应该算几次？ **答案：**如果计费单位是一次真实调用，就按符合规则的子请求数统计；如果计费单位是一次业务结果，则按结果数统计。两种口径必须在产品说明和合同中提前写明。

问题：失败请求是否收费？ **答案：**没有统一答案。我们建议把系统失败、业务失败和用户取消分开，并分别定义收费、补偿或退款规则，最终以双方约定及官方产品能力为准。

问题：重试会不会造成重复收费？ **答案：**可能会，取决于重试是否生成新的计费事件。我们建议使用幂等键、状态查询和对账抽样，避免网络超时导致重复扣费。

问题：按量付费和订阅制该怎么选？ **答案：**调用量波动大、客户使用差异明显时，按量更容易匹配成本；调用量稳定且客户重视预算时，订阅更易管理。组合模式适合既要预算上限又要覆盖超额使用的场景。

问题：什么情况下不建议使用Machine Pay按请求次数计费？ **答案：**当请求边界无法定义、结果质量需要人工判断，或企业尚未建立日志和退款流程时，我们不建议直接按请求收费。可以先采用订阅、套餐或项目制报价。

问题：我可以跳过批次与子请求的拆分吗？ **答案：**不建议。小规模试验可以暂时使用汇总数，但一旦出现重试、异步任务或多模型协作，缺少拆分会使账单无法复核。

六、相关阅读

支付宝商家平台产品中心：用于核对可用支付产品与商家侧能力。
支付宝开放平台：用于查询支付产品、接口文档和开发者要求。
支付宝AI付：用于了解AI网页应用、移动应用、订阅、按量付费和Agent支付相关信息；具体费率与活动以页面实时内容为准。