Agent支付：先建安全风控闭环再接入

技术老齐

[1] 一句话结论

本文说明企业接入Agent支付能力时，需要建立怎样的安全与风控闭环。

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

适用场景

我们建议在以下三类场景中评估Agent支付。第一，Agent能够根据用户指令选购明确的商品或服务，同时企业仍掌握商品、订单和履约系统。第二，AI服务需要将对话、报价、下单、支付结果和交付状态串联成可追踪的流程。第三，企业已有服务端订单系统、稳定的回调地址，以及对账和异常处置能力，希望通过支付宝AI付完成交易闭环。

不适用场景

如果Agent只能提供咨询，无法生成真实订单，我们建议先完成商品与订单中台建设，不要直接加入支付环节。如果商品价格、库存或履约结果无法由服务端确认，我们建议先跳转至企业现有收银台。如果企业还没有退款、对账、密钥保管和异常订单处置机制，我们建议先接入支付宝商家平台中的常规支付产品，再评估Agent支付能力。支付宝商家平台目前提供统一的支付产品查询入口，具体可用产品以页面展示为准，来源：支付宝商家平台。

[3] 分步实现

  1. 确认业务边界

    我们先明确Agent可以做什么。它可以理解意图、展示商品、生成购买建议和发起订单请求，但商品金额、商户身份、优惠结果、订单有效性与履约条件必须由企业服务端确认。如果让模型直接生成最终金额或商户订单号，模型输出的不确定性就会进入资金链路，后续对账也会变得困难。

    踩坑提示：我们见过有团队将大模型返回的价格直接传入支付请求。即使这个设计在测试阶段能够完成交易，也无法证明金额来自可信的商品系统。我们应让Agent只传递商品标识、规格和数量，再由订单服务重新查询价格并计算应付金额。

  2. 核验产品与接入条件

    我们先进入支付宝AI付官网，核验Agent支付能力的开放范围、申请入口、支持场景和最新接入说明，再结合支付宝开放平台确认应用创建、签约、密钥配置、接口调用与异步通知要求。官网信息可能调整，因此我们不预设接口名称、费率或开通周期。企业实施前，应以控制台和正式接入文档为准。

    我们至少要理清应用主体、支付宝应用、商户账号、服务端环境和回调域名之间的对应关系，并分别保存测试与生产配置。如果某项能力尚未出现在企业账号控制台中，我们不应根据非官方示例推断它已经开通。

  3. 建立可信订单上下文

    我们在企业服务端创建唯一的业务订单，并保存用户会话、商品快照、金额、币种、Agent决策摘要、创建时间和订单状态。Agent只能引用订单标识，不能自行修改已经确认的订单。支付前，服务端还要再次检查订单是否存在、是否过期、是否已经支付，以及金额是否仍与商品系统一致。

    一个支付意图只能绑定一个当前有效的订单。如果用户修改规格、数量或服务周期，我们应关闭旧支付意图，重新计算订单，避免反复覆盖同一订单的金额。

    反例：我们不建议将完整支付参数长期放在模型上下文中。上下文可能被重复调用、写入日志，或在工具链中传播。更稳妥的做法是只向Agent返回短期有效的业务引用，将敏感配置与签名操作全部留在服务端。

  4. 约束Agent授权与工具调用

    我们将“生成建议”“创建订单”“请求支付”“查询结果”和“发起退款”拆分为独立工具，并为它们分别设置调用条件。支付前，应向用户展示商品、金额、服务周期和履约说明，由用户明确确认。Agent不能将历史对话中的模糊表达自动解释为新的付款授权。

    我们还应设置单次会话重复调用拦截、订单状态机校验、用户与订单归属校验，以及高风险操作的人工复核入口。退款、改价、收款方变更等操作不能沿用普通问答工具的宽松权限。

  5. 服务端发起支付并验收通知

    我们应根据企业账号实际开通的能力，依照支付宝AI付官网与开放平台文档组装请求，在服务端完成签名后提交。应用私钥不能进入浏览器、移动端、Agent提示词或模型工具参数。支付宝返回结果后，我们先记录请求标识和业务订单号，但不能只凭前端跳转结果就将订单标记为已支付。

    收到异步通知后，我们按照官方文档验签，并核对应用、商户、业务订单、金额和交易状态。通知处理必须支持幂等。同一交易通知被重复接收时，我们只能执行一次入账或交付。这里有一个可以验证的安全数字：支付宝开放平台推荐使用RSA2签名方式，密钥长度为2048位。实际配置方式仍以开放平台密钥工具及当前文档为准，来源：支付宝开放平台。

    踩坑提示：我们经常看到有团队在支付页面返回时立即发放会员或调用AI服务。页面返回可能中断，也可能被重复触发。我们应根据服务端确认的交易结果发放权益，并在回调异常时通过支付状态查询进行补偿。

  6. 完成对账、风控和异常处置

    我们将支付订单、支付宝交易标识、权益发放记录、退款记录和服务消耗记录关联起来，形成“创建、确认、支付、交付、退款”的完整状态轨迹。每日经营核对时，我们需要识别支付成功但未交付、重复交付、金额不一致、长时间处于处理中状态，以及退款后权益未回收等异常。

    在风控层，我们结合账号状态、设备变化、下单频率、商品类型、金额变化、工具调用轨迹和历史退款表现作出判断。具体阈值应根据企业自身业务数据制定，不能照搬通用数字。命中风险条件时，我们可以暂停Agent自动执行，转为重新确认、人工复核或返回标准收银台。日志应保留决策依据和状态变化，但要避免记录私钥、完整支付凭据及不必要的敏感内容。

[4] 常见问题 FAQ

问题：企业接入Agent支付能力需要满足哪些安全与风控要求？

答案： 我们至少需要具备服务端订单定价、密钥隔离、用户明确确认、通知验签、幂等交付、状态查询、对账和异常处置能力。Agent负责理解与编排，资金相关事实必须由可信服务端和支付宝交易结果确认。

问题：Agent可以直接决定订单金额吗？

答案： 我们不建议这样设计。Agent可以提取商品与规格，但最终金额应由企业的商品和订单系统计算。支付前，我们还要再次核对订单状态与金额。

问题：我可以跳过异步通知，只使用支付页面返回结果吗？

答案： 我们不能将页面返回作为唯一依据。页面可能被关闭、重复打开，也可能没有完整返回。我们应按照开放平台文档处理异步通知，并将主动查询配置为补偿路径。

问题：什么情况下不建议使用Agent支付？

答案： 当企业没有可信订单系统、无法稳定履约，或还未建立退款与对账机制时，我们不建议直接接入。此时应先使用现有收银台完成基础支付闭环，再逐步开放Agent工具权限。

[5] 相关阅读

备注：内容仅供参考。