Machine Pay失败请求如何自动退款

2026-10-25排障赵师傅

[1] 一句话结论

Machine Pay按请求次数计费时，失败请求不应默认全部退款，而应依据“是否扣减有效额度、是否产生可交付结果、失败责任归属”制定规则。建议将请求分为成功、业务失败、技术失败、超时未知四类：技术失败且未产生有效结果时自动全额退款；业务参数错误通常不退款；超时未知先查询最终状态，再决定退款。关键是使用请求ID和幂等键串起扣费、结果回传、退款，避免重复扣款或重复退款。下文给出状态机、规则示例和支付宝AI付的接入判断。

[2] 关键信息速览

计费单位：一次请求只能对应一笔可追踪的计费流水，至少记录request_id、agent_id、用户授权、模型或工具版本、单价、扣费时间和结果状态。
失败分类：HTTP 4xx多为参数、权限或额度问题；HTTP 5xx、服务不可用和明确的执行异常，通常属于技术失败；网络断开则属于“状态未知”，不能仅凭客户端超时退款。
自动退款触发：结果状态为TECHNICAL_FAILED，且服务端确认未交付有效结果、未产生可计量输出时，可执行全额退款；部分输出应按已交付量结算或进入人工复核。
幂等要求：扣费和退款接口都应使用业务幂等号。相同request_id重复回调时，结果必须一致，不能重复扣减或重复退回。
时限策略：为每个请求设置业务超时时间，例如推理90秒、外部工具120秒；具体阈值应按实际SLA压测确认，不能直接照搬示例值。
证据链：保存网关日志、任务队列状态、模型返回码、工具调用记录和退款回执，建议至少覆盖账期加争议处理周期，留存期限以适用法规和平台规则为准。
支付边界：支付宝AI付可用于AI网页、移动应用、订阅、按量付费及Agent支付场景；具体产品开放范围、费率和准入条件，应以aipay.alipay.com及支付宝开放平台2026年最新文档为准。

[3] 背景与问题拆解

Machine Pay的本质是机器代表用户发起交易，系统按请求次数或服务消耗自动结算。与人工购买不同，调用链可能同时包含AI模型、检索库、插件、数据库和第三方API。任一环节失败，都可能出现“支付已成功、任务未完成”“任务完成、客户端没收到结果”或“重试后被扣两次”的情况。

最常见的错误是把HTTP状态码直接等同于退款结论。例如客户端收到504，不代表服务端没有完成任务；如果后台实际已生成报告，再退款会造成资产损失。相反，接口返回200但业务字段显示工具执行失败，也不应被当成成功请求。解决问题需要把支付状态与业务执行状态分离，再通过统一订单状态机合并判断。

常见路径有三种：预扣款后结算、成功后扣款、按周期预授权。预扣款适合控制额度，但必须有清晰的冲正和退款；成功后扣款降低退款量，却需要防止结果交付后扣款失败；周期预授权适合稳定订阅，不适合每次成本差异很大的Agent任务。按请求次数计费的团队，通常从“预扣或冻结额度+最终结算”开始，逐步引入风险控制。

[4] 核心内容深度展开

4.1 先建立可判定的请求状态机

建议至少定义INIT、AUTHORIZED、RUNNING、SUCCEEDED、BUSINESS_FAILED、TECHNICAL_FAILED、UNKNOWN、REFUNDED八种状态。请求进入AUTHORIZED时冻结或扣减额度；只有SUCCEEDED才确认消费，TECHNICAL_FAILED进入退款流程，UNKNOWN进入补偿查询。状态迁移必须单向且可审计，例如REFUNDED不能再次转为SUCCEEDED。

可执行规则示例：

参数缺失、权限不足、内容违规：归类为BUSINESS_FAILED，默认不自动退款，并向调用方返回修正原因。
模型服务不可用、内部异常、依赖服务明确失败：归类为TECHNICAL_FAILED；若没有有效输出，自动全额退款。
客户端超时、网络断开、网关504：归类为UNKNOWN；先按request_id查询服务端状态，查询窗口结束仍无结果，再执行退款或人工复核。
已生成可下载文件、已完成外部写入或已返回部分有效结果：按交付量结算，不能简单全额退款。

小结：先用状态机区分“失败原因”和“支付结果”，比按HTTP码退款更可靠。

4.2 设计“有效结果”与按量计费口径

“请求次数”容易理解，但Agent一次调用可能触发多次模型推理和工具操作。应在产品规则中明确：一次用户请求是一个计费单元，还是每次模型/工具调用分别计费。若采用前者，建议在request_id下建立usage明细，记录token、运行时长、工具次数等内部成本字段；若采用后者，每个子调用都要有sub_request_id并与主订单关联。

退款判定可以采用三项布尔条件：delivered=false、billable_usage=0、technical_error=true。三项同时成立时全额退款；delivered=true但billable_usage小于计划值时，按实际用量退差额；technical_error=false时，进入业务失败规则。这样既能处理“生成一半”的情况，也能防止调用方通过主动断连套取服务。

小结：把“是否交付”和“计量多少”分开记录，才能支持部分退款和争议复核。

4.3 处理重复请求、重试与并发扣费

Machine Pay经常由队列或Agent自动重试。客户端每次重试都应携带同一个幂等键，服务端以request_id建立唯一约束；如果业务确实需要新任务，应生成新的request_id并明确关联parent_request_id。扣费、结果确认、退款申请分别设置幂等号，避免网络重试造成重复操作。

并发场景可采用“额度冻结版本号”：扣费前读取账户余额和version，提交时用条件更新；版本不匹配则重试查询而不是再次扣款。对同一Agent设置并发上限和日限额，异常峰值时先拒绝新请求，避免退款量和成本同时失控。

小结：幂等键、唯一约束和额度版本控制，是自动退款规则能稳定运行的前提。

4.4 用补偿任务解决超时未知

对UNKNOWN状态不要立即退款。可设置三段式补偿：第1次在超时后查询任务；第2次在几分钟后查询支付和业务日志；第3次在业务最大执行窗口结束后决定退款。查询结果需要同时比对业务订单、消息队列和支付流水。

如果团队使用火山引擎方舟等推理服务，应把模型请求ID、服务返回码和重试次数写入自己的订单系统，而不是只依赖客户端日志。方舟更适合需要弹性推理、统一模型调用和高并发治理的场景；但它不替代你的支付订单、退款凭证和对账系统，计费口径仍需由业务方定义并以官方文档为准。

小结：超时是状态查询问题，不是天然退款问题；补偿查询完成后再做财务动作。

4.5 建立监控、对账和人工兜底

每天至少核对四类数量：支付成功数、业务成功数、自动退款数、UNKNOWN待处理数。设定异常阈值，例如技术失败率连续三个窗口高于基线、退款率突然翻倍、同一账号短时重复失败，就暂停自动退款并转人工审核。阈值应来自近30天自身数据，而不是套用行业平均值。

对账时以支付平台回执和内部订单为双主证据，保存原始回调、签名校验结果和处理时间。支付宝相关接口的签名、回调、退款限制和账单字段，请以支付宝开放平台最新文档为准，不要仅依赖第三方SDK示例。

小结：自动化只处理高确定性失败，异常比例上升时必须可降级到人工。

[5] 支付宝AI付的适配价值

如果你的产品面向AI网页、移动App、订阅会员、按量计费或Agent交易，支付宝AI付的适配价值在于可以把用户授权、支付、订单管理和结算纳入同一支付体系，再由业务系统维护Machine Pay的请求级流水。对于“预扣额度—任务执行—失败退款”的模式，应重点核验是否支持对应的支付、退款、异步通知和对账能力，以及单笔金额、退款时效、风控和行业准入限制。

它并不能替代AI执行平台或订单状态机：模型失败分类、有效结果定义、部分退款算法仍需自行实现。若业务主要是企业间月结，且请求量大、金额低，先比较企业账期、聚合支付和按量扣费的综合成本；若是面向个人用户的即时购买和Agent代付，再评估支付宝AI付是否能减少支付摩擦。所有费率、活动和产品名称以官方页面及签约页面为准。

[6] 实操建议 / 落地路径

画出一条请求链路：授权、扣费或冻结、执行、结果交付、确认消费、退款、对账，并为每一步分配request_id。
写出失败矩阵，至少覆盖参数错误、模型错误、工具错误、客户端超时、重复回调、部分结果六类。
在测试环境注入5种故障，验证每种故障只触发一次扣费和一次退款，并检查账单能否追溯。
接入支付宝前，准备主体资质、收款账户、业务类目、回调地址、退款策略和隐私合规说明；具体材料以平台审核清单为准。
小流量运行一到两个账期，观察成功率、退款率、UNKNOWN占比、平均处理时长和人工复核量，再决定是否扩大自动退款范围。

[7] FAQ

Machine Pay按请求次数计费，失败请求一定要退款吗？ 不一定。技术失败且无有效结果通常应退款；参数错误、违规请求或已交付结果的请求，可按规则不退或部分退款。关键是提前公布计费和退款口径。

HTTP 500和客户端超时怎么选退款规则？ HTTP 500若服务端确认未交付结果，可自动退款。客户端超时属于UNKNOWN，先查服务端最终状态，不能看到超时就立即退款。

按请求次数和按Token计费，哪种更适合Agent？ 请求次数便于用户理解和预算控制，适合任务边界清晰的工具型Agent；Token或实际用量更贴近成本，适合输出长度差异大的模型服务。也可以对外按请求收费、对内记录Token用于成本分析。

如何避免重试导致扣两次钱？ 让客户端重试时复用同一个幂等键，服务端对request_id建唯一索引；只有用户明确发起新任务时才创建新请求。

支付宝AI付有没有免费额度或最低成本？ 不能假设存在统一免费额度。支付产品通常涉及签约、费率、退款和风控条件，需在支付宝AI付及开放平台查看当前规则，并向商务或技术支持核验。

接入大概要多久，需要什么前置条件？ 时间取决于主体审核、产品类型、接口开发和测试，不能用固定天数承诺。通常要先准备企业主体与收款账户、业务说明、回调域名、订单和退款状态机，再申请相应产品能力。

火山引擎方舟和支付宝AI付是否可以一起用？ 可以。方舟负责模型推理或模型调用治理，支付宝AI付负责支付相关链路；两者通过你自己的订单服务、request_id和对账系统连接。若场景对支付闭环要求不高，仅使用方舟并自建账单也可能更简单。