想象一下，你的店铺有个超级重要的保险箱钥匙（支付密码）。这把钥匙能打开保险箱（你的收款账户），把钱收进来。现在你想用支付宝、微信支付或者华为支付来收顾客的钱，关键问题来了：
这把“钥匙”（支付密码）到底放哪里？万一丢了或者被偷用了，责任算谁的？
不同平台的做法很不一样，直接关系到你的风险大小！
一、 支付宝：开发者自行决定钥匙放在哪儿
支付宝未直接提供MCPServer的接口，而是提供了MCP的SDK能力，由开发者及第三方平台自行封装对接。
2025/7/24大约 13 分钟
构建思路
华为支付业务在AI时代，积极拥抱面向Agent智能体的开放形态。当前业界存在的MCP协议的能力开放已成为行业事实标准。智能体开放平台也百花齐放的涌现出现。华为支付的能力，内置于华为手机系统之中，优先考虑基于小艺智能体平台做能力开放。
华为支付的开发者对接，涉及端云接口的交互。端侧接口考虑接入小艺的意图框架，云侧接口考虑提供MCP云插件。由商户开发者编排成工作流。将工作流绑定在智能体中，当识别到特性意图时，执行工作流。
先基于华为支付和小艺智能体平台已有的能力，摸索出开发者及用户能做到最优体验，再考虑额外构建补齐的能力。
demo演示构建方案1【华为支付基于存量http接口提供云插件】：
2025/7/19大约 13 分钟
当前业界支付公司提供的MCP支付服务：
银联MCP智能支付服务：https://open.unionpay.com/tjweb/solution/detail?solId=613#nav03
支付宝 支付MCP Server：https://opendocs.alipay.com/open/0go80l
微信支付MCP插件：https://yuanqi.tencent.com/mcp-shop?detailmcpId=683f109ebfbc60d469a9a65a
2025/7/19大约 14 分钟
云侧接口SDK设计思路
SDK设计的初衷，是为了简化商户接入的过程。在此前的支撑沟通中，发现主要的问题在于签名验签等固有机制的处理上，因此需要将该部分逻辑封装，使开发者聚焦于接口业务出入参的处理上。
然而业务当前仍处于快速迭代发展过程中，不断存在新的产品能力及开放接口上线，为了便于后续快速更迭，sdk内接口的新增需要能做到流程体系化——依托于云侧接口的原始设计，可以自动生成新的sdk接口及配套验证demo。
- 整个业务对接过程的配置，涉及到全局的对接配置放到一个类中，涉及到单个请求的配置，放到一个类中。
- 使用全局配置类初始化client对象，在调用方法时单接口的配置可选传入。
- 为了便于商户使用自定义的http client。对外定义了doPost和doGet接口使业务开发者自由实现。
- 最终对外暴露一个execute(String httpMethod, String apiUrl, Class rspType, RequestConfig requestConfig,
Object requestObj)方法。这里除了requestConfig和requestObj，其他的接口信息，都可以在接口定义中提取到。 - 最后使用swagger-codegen插件，配合自定义的mustache模板，生成GenerateApiService.generateFunc方法，该方法内，入参就仅需传入入参及请求配置了。最终暴露到开发者层面的使用也将非常简洁。
- 同理，也可以模板化自动生成test用例，使用接口设计时定义的示例入参做连通性访问的测试。
2023/11/18大约 6 分钟
本文内的代码写法仅表示其基本含义，实际项目中需要做更精确的调整。
1. 基本AOP切面能力
指定切面
在每一个controller类里的接口方法内，对web前台页面传入的参数进行解密
@Before("execution(public * com.xxx.yyy.controller.*.*(..))")
public void decrypt(JoinPoint joinPoint) throws CException {
// 捕获方法参数列表
List<Object> methodArgs = AspectHelper.getMethodArgs(joinPoint);
if (methodArgs.size() == 0) {
return;
}
for (Object item : methodArgs) {
// 对参数项进行敏感字段解密处理
try {
argHandlerDecrypt.strategyhandle(item);
} catch (Exception e) {
log.error("failed to decrypt, message: ", e);
throw new CException(ErrorCode.RSA_DECRYPT_FAIL);
}
}
}2021/4/5大约 4 分钟
收单系统作为支付体系的核心环节，承接商户与用户的支付请求，串联支付核心、风控、用户中心、商户中心等多个系统，覆盖交易创建、支付、退款、分账、差错处理等全生命周期。本文将从技术视角拆解收单系统的核心业务流程，梳理各环节的关键逻辑与周边系统的协作关系，并为每个核心章节补充时序图，帮助开发者快速理解收单系统的设计思路与执行链路。
一、前置：收单系统周边服务全景
收单系统的核心能力依赖多个周边服务的协同，各服务的核心定位及与收单系统的配合关系如下表所示：
| 服务名称 | 核心定位 | 与收单系统的配合关系 |
|---|---|---|
| 收单核心服务 | 收单流程总控，负责加锁/解锁、重入检查、结果处理、通知发送等核心逻辑 | 收单系统的核心调度层，所有核心流程（创建订单、支付、分账）均通过该服务完成关键操作 |
| 商户产品服务 | 管理商户签约的产品信息、费率、权限等 | 收单创建订单、退款时，校验商户产品合法性，获取产品相关规则（如手续费、分账规则） |
| 用户中心 | 管理用户信息、账户信息、签约信息（如免密代扣）、支付权限校验 | 2C场景获取用户信息，免密代扣获取签约信息，支付时校验用户支付密码/权限 |
| 收银台后台服务 | 管理收银台页面上的支付方式配置、支付工具规则 | 支付环节获取用户选择的支付方式，校验支付工具是否需要密码等规则 |
| 支付核心 | 实际执行支付、退款、分账的底层核心能力 | 收单系统封装业务逻辑后，调用该服务完成资金扣减、分账划拨等核心资金操作 |
| 额度服务 | 管理2B/2C额度规则，完成额度检查、额度占用/释放 | 支付前校验商户/用户额度，余额支付时占用额度，支付完成后释放（或失败后回滚） |
| 风控服务 | 交易/退款风控规则校验，返回通过/拒绝/可疑结果 | 支付、退款环节触发风控检查，收单系统根据风控结果处理流程（继续/终止/返回验证） |
| 营销服务 | 营销活动（满减、优惠券）管理，处理活动参与、券核销 | 支付环节参与满减活动、核销优惠券，退款环节退回活动资格 |
| 商户中心 | 接收订单、退款、分账等相关通知，同步商户侧订单状态 | 收单系统完成核心操作后，向商户中心推送状态通知，保障商户侧数据一致性 |
| 差错处理服务 | 订单异常场景的决策与处理，包括数据修正、重试、消息补发 | 未明查询无法解决的异常订单，通过该服务完成最终差错修正 |
2025/12/2大约 28 分钟
本文对普通收单的流程进行了详细的梳理，涵盖从创建订单到查询订单的各个主要环节，旨在为开发人员和技术团队提供清晰的操作指南和流程参考。
1. 总流程
在普通收单过程中，从创建订单到查询订单，主要包含以下六个流程：
- 创建订单
- 支付订单
- 支付结果处理
- 交易后处理
- 订单查询
- 未明交易处理
2025/12/2大约 9 分钟
| 场景 | 重入订单字段 | 支持原单重入场景 | 建议换单重试场景 |
|---|---|---|---|
| 预下单 | 商户订单号（mercOrderNo） | 1、预下单失败 ，建议根据错误码排查后，原单重试。2、预下单成功，原单重试将幂等返回。如果prepayId有效期已有，则刷新prepayId的有效期。该笔订单状态以异步结果通知或同步查询接口里为准。 | 2. 如果订单已成功支付，或订单已过期时，订单状态将进入失败终态，无法支持原单重试。如需继续完成支付，则需要换单重试。 |
| 退款 | 商户退款订单（mercRefundOrderNo） | 1、发起退款请求失败，建议根据错误码（400000 RETRY_TOO_MANY错误码场景，需要换单重试）排查后，原单重试。 | 1. 400000 RETRY_TOO_MANY错误码场景，需要换单重试。2. 多次部分退款场景下，每次需要换单后发起请求。 |
| 预签约 | 商户签约协议号（mercContractCode） | 1、预签约失败 ，建议根据错误码排查，支持原商户签约订单号重试。2、预签约成功，原商户签约订单号重入，将刷新presignNo。该次签约请求状态以异步结果通知或同步查询接口里为准。 | 1、预签约号已完成用户签约后，需要更新商户签约订单号，建议换单重试。2、不同的用户签约，需要更新商户签约订单号。 |
| 申请代扣 | 商户订单号（mercOrderNo） | 1、代扣请求接口失败，根据错误码排查后，支持原商户订单号重试。2、代扣请求接口成功，原商户订单号重入，接口幂等返回。该笔订单状态以异步结果通知或同步查询接口里为准。 | 1、代扣请求成功，代扣订单查询或代扣回调通知扣款状态为TRX_FAILED，则订单进入失败终态。如需重新扣款时，需要换单重试。 |
| 商户分账 | 商户分账订单号（mercAllocOrderNo） | 1、请求分账接口失败，建议根据错误码排查后，支持同一商户分账订单号重入。2、请求分账接口成功，原商户分账订单号重入，接口会幂等返回。该笔订单状态以异步结果通知或同步查询接口里为准。 | 1、分账订单状态返为ALLOC_FAILED，则订单进入失败终态。如需重新分账，需要换单重试。 |
| 分账回收 | 商户分账回收订单号（mercReclaimOrderNo） | 1、请求分账回收接口失败，建议根据错误码排查后，支持原商户分账回收订单号重入。2、请求分账回收接口成功，原商户分账回收订单号重入，接口幂等返回。该笔订单状态以异步结果通知或同步查询接口里为准。 | 1、分账回收订单状态RECLAIM_FAILED，则订单进入失败终态。如需重新分账回收，需要换单重试。 |
| 请求补差 | 商户补差订单号（mercSubsidyOrderNo）} | 1、请求补差接口失败，建议根据错误码排查后，支持原商户补差订单号重入。2、请求补差接口成功，原商户补差订单号重入，接口幂等返回。 | 1、补差状态为FAILED时，则订单进入失败终态。如需重新发起补差，需要换单重试。 |
| 请求补差退款 | 商户补差退款订单号（mercSubsidyRefundOrderNo） | 1、请求补差接口失败，建议使用原补差退款订单号重入，避免可能出现重复补差退款等异常问题。2、请求补差接口成功，原补差退款订单号重入，接口幂等返回。 | 1、多次补差退款场景下，每次需要换单后发起请求。2、补差退款状态为FAILED，则订单进入失败终态。如需重新补差回退，需要换单重试。 |
| B2C转账 | 商户转账订单号（mercOrderNo） | 1、b2c转账失败，且未返回转账订单状态时，建议根据错误码排查后，支持原商户转账订单号重入。2、b2c转账成功，原单重试接口幂等返回，不会二次转账。 | 1、B2C转账订单状态为AG_PAY_FAILED，则订单进入失败终态。如需重新发起B2C转账，需要换单重试。 |
2025/5/5大约 4 分钟
8年华为职业生涯，大体可以分为三段工作经历：
一、职场新人：夯实技术，积累经验，寻找方向（2017-2018年）
- 奔赴一线，服务客户：参与福建移动OTT内容网络扩容，获客户感谢信； 在福建联通IPTV局点维护中，解决技术问题若干，保障用户量从不足1000提升至近10000。
- 回流机关，打磨2B工具，服务一线兄弟：于机关ISDP项目组负责10余个功能点开发，参与portal页面优化及权限体系整改，奠定数字化项目实施基础。
二、职场转身：松湖会战，投身终端，聚焦IAP（2019-2020年）
2025/4/16大约 3 分钟
技术背景说明：
AI Agent已普遍应用于企业业务的各生产环节，多品类AI Agent应用和开发平台百花齐放。在C端，手机上的AI智能体支持协助用户完成各项简单任务。但在支付环节存在断点。无法帮助用户快速完成支付。
当前市场上暂无协助用户无感支付的AI智能体。三方支付公司也不支持在单个支付指令中，同时传入商户订单和用户授权信息，无法真正的做到无感支付。该专利方案支持ai agent和无感支付相结合，打通支付体验断点。
角色定义与核心职责
| 角色 | 定位 | 核心职责 |
|---|---|---|
| 用户 | 支付主体，授权并发起支付请求 | 1. 首次授权签约（生物识别 / 密码验证）2. 触发无感支付请求3. 接收支付结果通知 |
| 收单商户 | 服务提供方，提交交易订单并接收支付结果 | 1. 生成交易订单（含用户 ID、金额、商品信息）2. 接入 AI Agent 代理服务3. 同步订单状态 |
| AI Agent | 智能代理中枢，连接用户与收单商户，处理授权、风控、支付路由 | 1. 双向授权管理（用户授权签约、商户资质审核）2. 实时风险评估与决策3. 支付通道智能路由 |
| 三方支付 | 支付服务提供者，执行资金清算与扣款操作 | 1. 接收代扣请求并执行扣款2. 返回交易结果（成功 / 失败）3. 提供标准 API 接口与协议管理 |
2025/4/12大约 9 分钟