想象一下，你的店铺有个超级重要的保险箱钥匙（支付密码）。这把钥匙能打开保险箱（你的收款账户），把钱收进来。现在你想用支付宝、微信支付或者华为支付来收顾客的钱，关键问题来了：
这把“钥匙”（支付密码）到底放哪里？万一丢了或者被偷用了，责任算谁的？
不同平台的做法很不一样，直接关系到你的风险大小！
一、 支付宝：开发者自行决定钥匙放在哪儿
支付宝未直接提供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 分钟
| 场景 | 重入订单字段 | 支持原单重入场景 | 建议换单重试场景 |
|---|---|---|---|
| 预下单 | 商户订单号（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 分钟
技术背景说明：
目前各类钥匙数字化，通过手机设备装载各类钥匙的场景越来越便捷，消费者依赖手机管理各类钥匙。也就衍生出各类数字钥匙授权激活的述求。
以车钥匙为例，车主在线下场景，需要授权给4S店或其他人，目前都只能通过账号输入确认的方式进行。用户操作较为繁琐。通过手机碰一碰的方式，不需要提前输入被授权方的账号及身份信息，更加快捷方便。基于设备维度授权，也更加安全。
技术方案时序图
2025/4/12大约 4 分钟
1.1范围
本文从客观实战出发全面梳理支付一致性相关场景 ，针对不同的场景给出最佳实践，并归纳出通用的一致性设计原则。
本文描述的是支付不同场景下需要保障最终一致性的对象的规则实践，针对一致性保障手段不做细节展开，例如分布式事务技术。
2一致性设计原则
本章节针对一致性设计共性原则进行归纳总结。其中分为三个档：**“严禁”原则是红线原则必须遵守不允许任何例外情况；“必须”原则是相对刚性原则，原则上必须遵守，特殊情况允许例外且特殊情况必须评审备案；“尽可能”**原则是相对柔性原则，引导设计方向正确性，建议尽可能遵守，允许例外但需要明确合理的理由，不强制评审但需要备案。
2025/1/19大约 44 分钟