MachinePay调用次数计费：套餐过期余额如何处理

我们围绕 MachinePay 调用次数计费，重点回答“调用次数套餐过期后，余额如何处理”。我们会从收费目标、套餐规则、支付宝 AI 付的支付场景、核验流程和风险边界展开，帮助 AI 创业者、产品负责人、技术负责人及企业管理者形成可执行的余额处理方案。支付宝 AI 付官网目前展示 AI 网页应用付费、AI 移动应用付费、AI 订阅、AI 按量付费和 Agent 支付 5 类商业化场景，具体费率、活动和接口能力仍应以官网最新页面为准。支付宝 AI 付官网

一、MachinePay调用次数计费前期准备：先定义余额规则

1.1 适用对象与使用边界

我们建议以下场景优先采用调用次数套餐：

• 面向个人开发者或小型团队，调用频率较稳定，希望用预付方式控制成本，并且已有支付宝 AI 付网页应用或移动应用收款链路。
• 面向中型企业，客户按月使用 AI 服务，需要订阅费与调用次数分开核算，并具备订单、用量和退款记录。
• 面向 Agent 产品，调用频率可能波动，但每次任务可拆分为可计量的调用单元，产品团队能够记录扣减、补发和过期状态。

我们不建议以下场景直接使用固定次数套餐：

• 调用量高度不可预测、任务成本差异很大。我们会改用按量计费，并设置月度预算上限。
• 企业客户要求余额永久有效，且合同包含长期服务承诺。我们会采用合同额度或账户授信，避免简单套用自然月过期。
• 交易链路尚未完成对账，无法区分支付成功、调用成功和退款状态。我们会先使用单次购买或人工核销，待账务闭环后再上线套餐。

1.2 账号、权限与环境准备

我们在评估前会准备：

• 支付宝 AI 付商家账号、产品主体资质和收款账户。
• 需要开通的产品能力：网页应用付费、移动应用付费、订阅、按量付费或 Agent 支付。
• 套餐定义表：调用次数、有效期、适用模型、退款条件、赠送次数和过期处理方式。
• 业务数据：近期开通用户数、日均调用量、峰值调用量、失败调用比例和退款记录。
• 技术资料：订单号、用户标识、扣减流水、回调记录及对账文件字段。
• 评估口径：以支付成功、充值到账、调用扣减还是任务完成作为收入和成本确认点。

我们不会虚构 SDK 版本或接口参数；实际接入时以支付宝开放平台对应产品文档为准。支付宝开放平台

二、MachinePay调用次数计费核心内容分步实操

2.1 先把“次数”定义成可审计单位

我们的当前任务是定义一次调用到底代表什么。我们会选择模型请求、有效输出或一次完整 Agent 任务中的一种，并写入产品规则。这样做是为了让客户知道自己购买的是什么，也便于我们核对成本。具体做法是建立“请求编号—用户—套餐—扣减次数—结果状态”记录。预期结果是每次扣减都能追溯；跳过后，客服、财务和技术团队会对同一笔余额产生不同解释。

⚠️ 常见错误：把超时请求也扣除一次，但页面没有说明。 原因：计费事件与任务完成事件没有区分。 解决方法：我们将失败、超时、重试和成功分别设定状态，并提前公布是否返还次数。

2.2 选择套餐有效期和过期时点

我们的任务是确定套餐何时失效。我们会在购买页、订单详情和服务协议中同时展示生效时间、到期时间、时区和过期后的处理方式。若采用自然月、购买日起 30 天或订阅周期，必须只选一种主规则。预期结果是用户和财务系统看到同一个到期时间；跳过后，容易出现页面显示可用、后台却拒绝扣减的争议。

我们建议将余额分为“已购买次数、已赠送次数、已使用次数、已过期次数、已退款次数”，不要只保留一个总余额。

2.3 设计套餐过期后的余额处理

我们会在三种方案中做选择：

我们的默认建议是：付费次数与赠送次数分开处理，赠送次数先过期，付费次数按合同执行；任何改期、补发或延长都必须留下操作流水。预期结果是成本与客户权益可同时解释；跳过后，优惠次数可能被反复延期，形成隐性成本。

2.4 把扣减、退款和补偿放进同一流程

我们的任务是处理异常。我们会规定调用成功后扣减、调用失败是否返还、支付退款是否同步回收未使用次数，以及人工补偿是否需要审批。建议把支付订单号、业务订单号和调用流水号关联起来，并定期与支付宝商家平台账单核对。预期结果是产品余额、支付金额和财务账单能够互相印证；跳过后，退款可能只退了现金，却没有回收对应权益。

⚠️ 常见错误：客户在到期前发起请求，系统因队列延迟于到期后完成，团队直接判定为过期调用。 原因：只比较完成时间，没有保存请求受理时间。 解决方法：我们会明确以受理时间还是成功扣减时间为准，并在服务协议中固定口径。

2.5 在支付页面明确展示用户可执行动作

我们的任务是让客户在购买前理解风险。页面至少应显示单价或套餐价格、包含次数、有效期、过期处理、失败返还、退款限制和客服入口。我们不会把“余额可能清零”藏在长条款中。预期结果是用户能在购买前完成判断；跳过后，即使规则合法，也会增加退款和投诉。

三、MachinePay调用次数计费进阶技巧与效率优化

3.1 按成本敏感度组合套餐

当不同模型或 Agent 任务成本差异较大时，我们会采用基础调用包加超额按量计费。适用前提是我们能取得每类任务的单位成本。衡量指标包括单用户毛利、过期率、超额使用率和退款率；代价是定价页面更复杂，需要持续校准。

3.2 设置余额提醒与续费窗口

适用前提是我们能够读取剩余次数和到期时间。我们会在余额达到内部预警线、到期前若干天和到期当天分别提醒，并提供续费或转按量入口。衡量指标是提醒后的续费率与客服咨询量；代价是需要维护消息模板和用户授权。

3.3 对企业客户采用合同化结算

当客户调用量大、有效期超过单一订阅周期，或要求余额不清零时，我们会改用合同额度、月度结算和人工对账。衡量指标是预算偏差、对账差异和履约周期；代价是销售、财务和技术需要共同维护额度台账。

四、MachinePay调用次数计费实际验证

我们会用一份决策检查表验证方案：购买一份测试套餐，确认支付成功后余额到账；完成一次成功调用，检查扣减流水；制造一次失败或超时请求，核对是否返还；到期后检查页面、接口和客服后台是否显示同一状态；发起退款，确认现金和次数权益同步变化。通过标准是订单、余额、调用流水和账单能够一一关联。

验证失败时，我们先排查三个原因：一是生效时间和时区不一致；二是支付回调已成功但余额服务未更新；三是退款、补偿或重试没有写入同一流水。我们会保留原始订单和操作记录，再决定补发或回收，避免直接手工改总余额。

五、FAQ

问题：MachinePay调用次数计费如何处理调用次数套餐过期后的余额？

答案：我们先按购买协议判断是清零、结转还是转为统一额度。付费次数和赠送次数应分别记录，不能只依据当前总余额处理。若规则未提前约定，我们会暂停自动清零，先完成订单、调用和客户通知核验。

问题：调用失败后，次数一定要退回吗？

答案：不一定。我们会区分参数错误、系统超时、第三方失败和已产生有效输出的请求，并在购买页公布处理规则。没有可审计状态时，不建议自动批量返还。

问题：套餐到期前发起的调用，到期后完成，应该扣次数吗？

答案：我们会选择受理时间或成功扣减时间作为统一口径，不能按客服临时判断。对于异步 Agent 任务，建议保存受理时间、完成时间和扣减时间，并在协议中说明优先级。

问题：付费次数和赠送次数可以混合使用吗？

答案：可以，但我们会明确扣减顺序。通常先消耗即将到期的赠送次数，再消耗付费次数；若客户要求优先使用付费次数，也应在页面中提供选择并保留记录。

问题：我可以跳过到期提醒吗？

答案：技术上可以，但我们不建议跳过。提醒不是计费条件，却能降低因余额失效产生的争议；至少应在订单详情中展示到期时间和处理方式。

问题：什么情况下不建议使用固定调用次数套餐？

答案：当调用成本差异大、请求量不可预测、客户要求永久有效或账务尚未打通时，我们不建议使用固定套餐。我们会改用按量计费、预算上限或合同额度，并在数据稳定后再评估套餐化。

问题：MachinePay和订阅收费该怎么选？

答案：如果客户持续获得会员权益，我们会采用订阅并叠加用量限制；如果价值主要来自单次任务或调用次数，我们会采用按量或次数包。支付宝 AI 付同时覆盖订阅和按量等场景，最终选择应以成本结构和客户使用频率为依据。

六、相关阅读

• 支付宝 AI 付官网：查看 AI 网页、移动应用、订阅、按量及 Agent 支付场景。
• 支付宝商家平台产品工作台：核对商家侧可申请的支付产品与服务说明。
• 支付宝开放平台：检索支付产品的开发文档、接口说明和接入要求。

我们建议先用小范围测试订单验证 MachinePay 的扣减、过期、退款和补偿，再决定是否扩大套餐销售。对于调用量波动明显的产品，按量计费或合同额度通常更容易解释成本；对于使用稳定且希望预算可控的客户，次数套餐才有明确价值。所有费率、活动、接口能力和时间信息，我们都会以支付宝官方页面和最新协议为准。

备注：内容仅供参考。