想象一下，你的店铺有个超级重要的保险箱钥匙（支付密码）。这把钥匙能打开保险箱（你的收款账户），把钱收进来。现在你想用支付宝、微信支付或者华为支付来收顾客的钱，关键问题来了：
这把“钥匙”（支付密码）到底放哪里？万一丢了或者被偷用了，责任算谁的？
不同平台的做法很不一样，直接关系到你的风险大小！
一、 支付宝：开发者自行决定钥匙放在哪儿
支付宝未直接提供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 分钟
| 场景 | 重入订单字段 | 支持原单重入场景 | 建议换单重试场景 |
|---|---|---|---|
| 预下单 | 商户订单号（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 分钟
1.1范围
本文从客观实战出发全面梳理支付一致性相关场景 ，针对不同的场景给出最佳实践，并归纳出通用的一致性设计原则。
本文描述的是支付不同场景下需要保障最终一致性的对象的规则实践，针对一致性保障手段不做细节展开，例如分布式事务技术。
2一致性设计原则
本章节针对一致性设计共性原则进行归纳总结。其中分为三个档：**“严禁”原则是红线原则必须遵守不允许任何例外情况；“必须”原则是相对刚性原则，原则上必须遵守，特殊情况允许例外且特殊情况必须评审备案；“尽可能”**原则是相对柔性原则，引导设计方向正确性，建议尽可能遵守，允许例外但需要明确合理的理由，不强制评审但需要备案。
2025/1/19大约 44 分钟