2、支付基础：支付系统基本概念、支付流程、支付渠道、清算与结算

在开始构建全额支付Agent智能体之前，我们必须先建立对支付领域的系统性认知。支付系统是金融基础设施中最复杂、最严谨的环节之一，它涉及多方参与者、多类账户体系、多种资金流转路径以及严格的法律合规要求。Agent智能体若要代理用户完成支付操作，就必须理解支付指令从发起到资金最终落账的完整链路，否则极易在异常处理、对账、风控等环节出现严重偏差。本章将围绕支付系统的核心概念、标准流程、渠道分类以及清算结算机制展开，为后续Agent的意图识别、参数组装、异常兜底与状态机设计奠定坚实的业务基础。

上图展示了支付系统从用户发起指令到资金最终结算完成的整体链路。Agent智能体在其中的角色是“支付指令的发起者”与“支付结果的感知者”，它并不直接参与清算网络的底层通信，但必须理解每一步的状态含义与时间窗口。例如，当Agent调用支付接口后，返回的“受理成功”仅代表支付机构已接收请求，并不代表资金已从用户账户扣除。这种异步特性要求Agent在设计对话流程和状态机时，必须预留“等待回调”或“主动查单”的机制，而不能简单地将接口响应视为最终结果。

2.1 支付系统基本概念与参与者

支付系统是一个由多方参与者共同构成的复杂网络，每一方在资金流转中承担不同角色，拥有不同的账户体系和记账规则。Agent开发人员必须清晰区分这些角色，因为不同角色对应的接口协议、字段语义、异常处理方式截然不同。

2.1.1 核心参与者及其职责

参与者	角色定义	核心职责	Agent对接视角
用户（付款方）	资金的最终来源，拥有银行账户或支付账户	授权支付、确认交易、管理支付凭证	Agent需获取用户的支付授权（如免密协议、）
商户（收款方）	提供商品或服务，拥有收款账户	创建订单、发起收款、处理退款	Agent需理解商户订单号与支付单号的映射关系
支付机构（收单方/支付渠道）	具备支付业务许可证的机构，如支付宝、微信支付、银联商务	提供API接口、资金托管、交易风控、清结算服务	Agent直接调用的接口提供方，需处理其签名、加密、回调规则
清算机构	负责支付指令的汇总、轧差与净额计算，如银联、网联	连接支付机构与央行，完成跨机构资金清算	Agent一般不直接对接，但需理解清算失败导致的“单边账”
央行（最终结算）	国家金融基础设施，管理备付金账户	完成商业银行间的资金最终划拨	Agent需知晓结算时间窗口（T+0/T+1）对退款时效的影响

在实际业务中，支付机构往往同时扮演“收单方”和“渠道提供方”双重角色。例如，当用户通过微信支付向商户付款时，微信支付既是收单机构，也是渠道本身。而当商户通过第三方聚合支付平台（如PingPong、Airwallex）接入时，聚合平台是收单方，其背后可能对接了微信、支付宝、银联等多个渠道。Agent在对接时，必须明确自己面对的是“直连模式”还是“间联模式”，因为两者的接口规范、对账逻辑和异常处理策略存在显著差异。

2.2 标准支付流程与状态机

支付流程虽然因渠道和场景不同而有所差异，但核心骨架是统一的。Agent必须掌握这个标准流程，才能准确理解用户查询的上下文，并在异常情况下做出正确决策。

2.2.1 支付流程的六个关键阶段

1. 订单创建：商户系统生成订单，包含订单号、金额、商品描述、过期时间等要素。此阶段不涉及资金操作。
2. 支付请求：用户或Agent向支付机构发起支付请求，携带订单信息、支付方式、用户身份凭证等。支付机构返回一个支付流水号。
3. 用户确认/授权：对于需要用户交互的场景（如扫码支付、跳转网银），用户需完成身份验证和支付确认。对于免密支付或协议支付，此步骤由事先签署的协议替代。
4. 支付受理：支付机构校验请求合法性，冻结或扣除用户资金，并返回“受理成功”或“受理失败”的同步响应。
5. 异步回调：支付机构完成内部处理后，通过异步通知（Webhook）将最终支付结果推送给商户系统。回调可能延迟数秒到数分钟。
6. 对账与结算：日终或定时，支付机构与商户进行交易对账，确认无误后按结算周期将资金划转至商户银行账户。

Agent在对接支付接口时，最容易犯的错误是将“同步响应”当作“最终结果”。例如，调用支付宝的alipay.trade.precreate接口后，返回的code=10000仅代表请求成功，但此时交易状态为WAIT_BUYER_PAY，用户尚未完成付款。Agent必须通过主动查询（alipay.trade.query）或被动接收异步通知来获取最终状态。

2.2.2 支付状态机与Agent状态映射

支付状态	含义	Agent状态机映射	可执行操作
CREATED	订单已创建，未发起支付	待支付	发起支付、取消订单
PENDING	支付请求已受理，等待用户确认	支付中	等待回调、主动查单、关闭交易
SUCCESS	支付成功，资金已清算	已支付	通知业务系统、触发后续流程
FAILED	支付失败（余额不足、风控拦截等）	支付失败	提示用户、引导更换支付方式
CLOSED	交易已关闭（超时未支付或主动关闭）	已关闭	重新发起支付（需新订单）
REFUNDING	退款处理中	退款中	查询退款进度
REFUNDED	退款完成	已退款	核对退款金额与时间

Agent的状态机设计必须与支付状态严格对齐，且要处理“状态回退”的边界情况。例如，当Agent收到SUCCESS回调后，如果后续对账发现该笔交易被撤销（如风控发现盗刷），支付状态会变为REVERSED。Agent需要具备处理这种“终态变更”的能力，及时通知用户并触发业务补偿流程。

2.3 支付渠道分类与选择策略

支付渠道是Agent执行支付动作的“最后一公里”。不同渠道在费率、限额、到账时效、覆盖范围、用户体验上差异巨大。Agent需要具备渠道选择能力，根据用户场景和业务需求动态路由到最合适的渠道。

2.3.1 主流支付渠道对比

渠道类型	典型代表	费率范围	单笔限额	到账时效	适用场景
银行卡快捷支付	银联在线、银行直连	0.38%-0.6%	单笔5万-100万	T+0/T+1	大额交易、对公转账
第三方支付（账户余额）	支付宝、微信支付	0.6%-1.2%	单笔2万-5万	实时到账	小额高频、C端消费
扫码支付（主扫/被扫）	微信/支付宝扫码	0.38%-0.6%	单笔5000-5万	实时到账	线下门店、面对面交易
网银支付	各大银行网银	0.1%-0.3%	单笔100万+	T+0	企业网银、大额B2B
数字人民币	数字人民币APP	0%（试点期）	单笔5万	实时	政策导向、新型场景

2.3.2 Agent渠道选择决策树

Agent在选择渠道时，应遵循以下优先级判断逻辑：

• 第一步：合规性过滤。排除当前用户身份、交易场景不允许的渠道（如跨境交易不能使用境内个人收款码）。
• 第二步：金额匹配。根据订单金额判断是否超出渠道单笔限额，若超出则拆单或选择更高限额渠道。
• 第三步：时效性匹配。用户是否要求实时到账？若要求T+0，则排除T+1结算的渠道。
• 第四步：成本优化。在满足前三个条件的渠道中，选择综合费率最低的渠道。
• 第五步：成功率预估。结合历史数据（如该渠道近1小时成功率、银行维护公告）动态调整选择。

2.4 清算与结算机制

清算与结算是支付系统中资金流转的“后台引擎”，虽然用户无感知，但Agent在处理退款、对账、差错账时，必须理解这两个概念的区别。

2.4.1 清算与结算的定义与区别

• 清算（Clearing）：指支付机构之间、支付机构与清算机构之间交换支付指令、计算应收应付净额的过程。清算是“算账”，不涉及实际资金划拨。
• 结算（Settlement）：指根据清算结果，通过央行或商业银行完成资金在账户间的实际转移。结算是“划钱”，资金真正发生位移。

举例说明：用户A通过支付宝向商户B付款100元，同时用户C通过支付宝向商户D付款80元。在清算环节，支付宝将这两笔交易汇总，计算出支付宝应向商户B支付100元、向商户D支付80元，同时从用户A和用户C的备付金账户中扣除相应金额。在结算环节，支付宝通过央行备付金账户，将180元分别划转至商户B和商户D的银行账户。

2.4.2 结算周期与Agent退款策略

结算模式	资金到账时间	退款处理方式	Agent注意事项
T+0（实时结算）	交易当日到账	可直接原路退回	退款时效快，但需关注支付机构是否收取实时结算手续费
T+1（次日结算）	交易次日到账	若资金未结算，可撤销交易；若已结算，需走退款流程	Agent需判断当前交易是否已结算，以决定调用“撤销”还是“退款”接口
T+N（周期结算）	按周/月结算	只能走退款流程	退款金额可能从后续结算款中抵扣，Agent需向用户说明到账时间

2.5 案例拆解：Agent处理一笔“支付超时未回调”的交易

下面通过一个完整案例，展示Agent如何综合运用上述支付知识处理实际异常场景。

背景与约束：某电商平台接入微信支付和支付宝双渠道，Agent负责处理用户支付咨询与异常交易。平台要求Agent在用户发起支付后30分钟内，若未收到支付结果回调，必须主动介入处理。

初始现象：用户通过Agent下单支付一笔金额为1,280元的订单，选择了微信支付。Agent调用微信支付统一下单接口，成功返回prepay_id，并将支付状态置为PENDING。然而，25分钟后，Agent仍未收到微信支付的支付结果回调通知。

关键数据：

• 订单号：ORD20250607001
• 微信支付单号：WX202506070012345
• 下单时间：2025-06-07 10:00:00
• 当前时间：2025-06-07 10:25:00
• 最后查询状态：NOTPAY（未支付）

分析判断过程：

1. Agent首先检查本地状态机，确认订单处于PENDING状态，且未收到任何回调。
2. Agent调用微信支付订单查询接口（pay/orderquery），返回trade_state=NOTPAY，说明用户尚未完成支付。
3. Agent检查订单过期时间，发现该订单设置了30分钟有效期，距离过期还有5分钟。
4. Agent判断：用户可能已经放弃支付，或者支付过程中遇到问题（如余额不足、密码错误）。

实际操作步骤：

# Agent执行逻辑伪代码
1. 调用微信支付查询接口
   response = wechat_pay.query_order(out_trade_no="ORD20250607001")
2. 判断trade_state:
   - 若为SUCCESS: 更新本地状态为已支付，通知业务系统发货
   - 若为NOTPAY: 进入超时处理流程
   - 若为CLOSED: 更新状态为已关闭，提示用户重新下单
3. 超时处理流程:
   a. 调用微信支付关闭订单接口 (pay/closeorder)
   b. 更新本地状态为CLOSED
   c. 通过对话界面主动推送消息给用户:
      "您的订单ORD20250607001已超时未支付，系统已自动关闭。
       如仍需购买，请重新下单。如有疑问，请回复'人工'。"
   d. 记录本次超时事件到Agent日志，用于后续分析支付转化率

结果对比：Agent在超时前主动关闭了订单，避免了订单过期后产生“僵尸订单”。用户收到通知后，重新下单并选择了支付宝支付，最终支付成功。若Agent未主动介入，该订单将在5分钟后自动关闭，但用户不会收到任何通知，可能导致用户误以为支付成功而等待发货，引发客诉。

风险与代价：Agent主动关闭订单存在一个风险：如果用户实际上已经完成了支付，但微信支付回调延迟，Agent关闭订单会导致“已支付但订单关闭”的单边账。为规避此风险，Agent在关闭订单前必须再次调用查询接口确认trade_state仍为NOTPAY，且关闭订单接口返回成功后才能更新本地状态。

复盘经验：支付回调的延迟通常不超过5分钟，但极端情况下可能延迟到30分钟以上。Agent的超时阈值应设置为“订单有效期-5分钟”作为安全边界。同时，Agent应具备“回调补单”机制：即使本地状态已置为CLOSED，若后续收到该订单的SUCCESS回调，Agent仍应能识别并触发逆向流程（如自动退款）。