Agent Pay产品配置：商品与计费规则怎么填

技术老齐

[1] 一句话结论

本文说明Agent Pay商品与计费规则该怎么填写和验收。

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

适用场景

以下场景适合使用这套配置方法：Agent能够识别明确的商品，并在交易前向用户展示商品名称、价格和交付内容，在用户授权下完成支付。若业务需要周期会员，应单独核验当前官方提供的订阅能力与准入要求，不能把订阅收费视为Agent Pay商品配置的一部分。若服务按API、工具调用、Token、生成次数或任务量计费，则应按AI按量付费的独立流程接入，基于HTTP 402接收Payment-Needed账单，支付后携带Payment-Proof，并由商户验证支付凭证、履约和确认回执，不能用Agent Pay配置代替。无论采用哪种方案，我们都要先确认当前商户账号已经获得相应能力，具体开放范围以支付宝AI付官网显示为准。

不适用场景

如果我们的Agent只能给出模糊报价，还无法确定最终商品、金额或履约内容，就不建议直接进入支付。此时应先建设商品目录或报价确认服务。如果业务只是内部免费工具，不涉及真实交易，可以采用账号鉴权和用量审计。如果主要场景是线下门店收款、普通网页收银或其他非Agent交易，应先在支付宝商家平台产品中心选择对应的支付产品，不要把Agent Pay当成所有收款场景的通用入口。

[3] 分步实现

  1. 核对产品能力与开通状态

我们先登录对应平台，查看Agent Pay是否已向当前应用和商户开放，同时确认协议、资质、结算和费率页面，以免商品配置完成后才发现能力尚未开通。对于页面没有明确展示的费率、活动期限或准入条件，我们不凭经验补填，一律以AI付官网和商家平台当前页面为准。

踩坑提示：测试环境显示的能力状态不等于生产环境的状态。如果应用、商户和环境没有正确关联，常见的结果是配置虽然存在，真实订单却无法使用。

  1. 定义可交易的商品

我们先在业务侧写清商品，再录入产品配置。商品名称可以采用“服务类型＋版本或交付物”的结构，例如“AI行业报告标准版”，不要只写“会员”或“高级服务”。商品说明需要回答四个问题：我们交付什么、包含哪些权益、何时完成、哪些内容不包含。

一次性交付要说明报告、图片、任务或调用包的具体边界；订阅商品要写清每个周期可获得的权益；按量服务则要明确计量对象。如果配置页面还要求填写商品标识、类目或状态，我们按照页面说明填写，并将平台生成的标识保存到自己的商品表中。没有经过官方页面确认，我们不会自行假设字段名称或格式。

反例：如果我们把权益差异很大的多个服务都配置成“AI服务”，订单生成后就很难判断该开通哪项能力，退款和对账时也无法定位原始交付范围。

  1. 填写与业务一致的计费规则

我们按照实际商业模式选择规则，不能为了少填几个配置项而混用不同模式。一次性收费适合单次任务或固定资源包，需要确认价格所对应的交付数量、有效范围和退款条件。订阅收费要明确周期、每周期权益、生效方式、续费与取消规则，还要先核验当前产品是否支持所需的周期性收费能力。按量付费需要先统一计量单位、数据来源、统计周期、舍入方式和异常补偿原则，再填写官方页面实际提供的配置项。

Agent Pay产品配置如何填写商品与计费规则，判断标准很直接：页面中的商品定义要能映射到我们系统里的唯一权益，计费规则要能映射到一份可复核的账单。如果页面不支持某项业务规则，我们应在自己的计费系统中完成报价和确认，再使用官方已经开放的支付模式，不能虚构配置字段。

踩坑提示：订单创建后，我们不应直接修改原商品的含义。更稳妥的做法是建立新版本，并在订单侧保留商品名称、计费规则和权益快照，否则历史订单可能会按照新的配置来解释。

  1. 关联订单、支付结果与履约动作

每笔业务订单都要关联平台要求的应用、商户和商品信息，请求参数以官方文档的规定为准。支付结果的处理必须形成闭环：我们先创建待支付订单，用户确认交易后，我们核验支付宝返回或通知的信息，然后开通会员、发放额度或启动Agent任务。支付页面显示成功，不能代替服务端的结果核验。涉及签名时，我们还要按照支付宝开放平台文档完成验签。

支付宝开放平台对RSA2的说明包含2048位RSA密钥要求。这是本文采用的一个可验证技术数字，数据来源为支付宝开放平台RSA签名文档。我们不能在日志、前端代码或Agent提示词中暴露应用私钥。

  1. 验证交易闭环并保留审计记录

上线前，我们要覆盖正常支付、用户取消、重复通知、金额或商品不一致、履约失败，以及退款后的权益回收。收到重复通知时，我们使用业务订单号或平台返回的交易标识进行幂等控制。遇到履约失败时，我们分别记录支付状态和交付状态，再交给补偿任务处理，不能简单地将订单改回未支付。

我们还要核对三类记录：Agent向用户展示的商品与价格、支付系统确认的交易结果，以及业务系统实际发放的权益。只有三者能够相互追溯，才算完成从业务问题、技术实现到支付履约的闭环。接口名称、请求字段、错误处理和环境配置可能发生调整，上线前应以支付宝开放平台的当前文档为准。

[4] 常见问题 FAQ

问题：我们填写商品名称时，可以只写会员吗？

答案：不建议。“会员”无法区分版本、权益和履约范围。我们应补充服务类型和套餐名称，并在说明中列出用户实际可以获得的内容。

问题：我们的按量计费单位应该由Agent临时决定吗？

答案：不应该。我们要在服务端统一计量口径，并保留原始用量记录。Agent可以解释价格，但不能自行修改计量单位或最终账单。

问题：我们可以跳过支付通知验签，直接根据页面跳转发放权益吗？

答案：不可以。页面跳转可能被关闭、重复触发或伪造。我们应按照官方开放平台文档，在服务端核验支付结果和签名后再履约。

问题：什么情况下我们不建议使用Agent Pay？

答案：当商品、价格或履约责任还没有确定，或者场景本质上是普通线下收款时，我们不建议直接套用Agent Pay。前一种情况应先完成报价确认，后一种情况应从支付宝商家平台选择更匹配的支付产品。

[5] 相关阅读

备注：内容仅供参考。