想象一下，你的店铺有个超级重要的保险箱钥匙（支付密码）。这把钥匙能打开保险箱（你的收款账户），把钱收进来。现在你想用支付宝、微信支付或者华为支付来收顾客的钱，关键问题来了：

这把“钥匙”（支付密码）到底放哪里？万一丢了或者被偷用了，责任算谁的？

不同平台的做法很不一样，直接关系到你的风险大小！

一、 支付宝：开发者自行决定钥匙放在哪儿

支付宝未直接提供MCPServer的接口，而是提供了MCP的SDK能力，由开发者及第三方平台自行封装对接。

构建思路

华为支付业务在AI时代，积极拥抱面向Agent智能体的开放形态。当前业界存在的MCP协议的能力开放已成为行业事实标准。智能体开放平台也百花齐放的涌现出现。华为支付的能力，内置于华为手机系统之中，优先考虑基于小艺智能体平台做能力开放。

华为支付的开发者对接，涉及端云接口的交互。端侧接口考虑接入小艺的意图框架，云侧接口考虑提供MCP云插件。由商户开发者编排成工作流。将工作流绑定在智能体中，当识别到特性意图时，执行工作流。

先基于华为支付和小艺智能体平台已有的能力，摸索出开发者及用户能做到最优体验，再考虑额外构建补齐的能力。

demo演示构建方案1【华为支付基于存量http接口提供云插件】：

当前业界支付公司提供的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

AI 智能体（Agent）的普及正在重构支付场景，瑞幸咖啡作为 AI 点单场景的标杆案例，其与支付宝、华为等平台的对接实践，折射出当前 AI 支付生态的核心逻辑与竞争格局。本文将从瑞幸 AI 点单的实现路径切入，对比支付宝、微信、华为支付在 AI 支付领域的能力布局，并探讨华为支付基于鸿蒙生态的落地策略。

一、瑞幸 AI 点单的核心实现逻辑

1.1 自建业务 Agent：瑞幸的核心自主化策略

瑞幸 AI 点单 Agent 由品牌自主研发，核心特征如下：

• 多端统一：可适配 App、小程序、元服务等多载体，无需重复开发；
• 主体独立：授权提示、服务协议等核心交互环节均以瑞幸为主体；
• 弱依赖宿主：智能体运行不依赖宿主 App，但支付方式需遵循宿主生态规则（如支付宝小程序需用支付宝支付）。

收单系统作为支付体系的核心环节，承接商户与用户的支付请求，串联支付核心、风控、用户中心、商户中心等多个系统，覆盖交易创建、支付、退款、分账、差错处理等全生命周期。本文将从技术视角拆解收单系统的核心业务流程，梳理各环节的关键逻辑与周边系统的协作关系，并为每个核心章节补充时序图，帮助开发者快速理解收单系统的设计思路与执行链路。

一、前置：收单系统周边服务全景

收单系统的核心能力依赖多个周边服务的协同，各服务的核心定位及与收单系统的配合关系如下表所示：

服务名称	核心定位	与收单系统的配合关系
收单核心服务	收单流程总控，负责加锁/解锁、重入检查、结果处理、通知发送等核心逻辑	收单系统的核心调度层，所有核心流程（创建订单、支付、分账）均通过该服务完成关键操作
商户产品服务	管理商户签约的产品信息、费率、权限等	收单创建订单、退款时，校验商户产品合法性，获取产品相关规则（如手续费、分账规则）
用户中心	管理用户信息、账户信息、签约信息（如免密代扣）、支付权限校验	2C场景获取用户信息，免密代扣获取签约信息，支付时校验用户支付密码/权限
收银台后台服务	管理收银台页面上的支付方式配置、支付工具规则	支付环节获取用户选择的支付方式，校验支付工具是否需要密码等规则
支付核心	实际执行支付、退款、分账的底层核心能力	收单系统封装业务逻辑后，调用该服务完成资金扣减、分账划拨等核心资金操作
额度服务	管理2B/2C额度规则，完成额度检查、额度占用/释放	支付前校验商户/用户额度，余额支付时占用额度，支付完成后释放（或失败后回滚）
风控服务	交易/退款风控规则校验，返回通过/拒绝/可疑结果	支付、退款环节触发风控检查，收单系统根据风控结果处理流程（继续/终止/返回验证）
营销服务	营销活动（满减、优惠券）管理，处理活动参与、券核销	支付环节参与满减活动、核销优惠券，退款环节退回活动资格
商户中心	接收订单、退款、分账等相关通知，同步商户侧订单状态	收单系统完成核心操作后，向商户中心推送状态通知，保障商户侧数据一致性
差错处理服务	订单异常场景的决策与处理，包括数据修正、重试、消息补发	未明查询无法解决的异常订单，通过该服务完成最终差错修正

本文对普通收单的流程进行了详细的梳理，涵盖从创建订单到查询订单的各个主要环节，旨在为开发人员和技术团队提供清晰的操作指南和流程参考。

1. 总流程

在普通收单过程中，从创建订单到查询订单，主要包含以下六个流程：

1. 创建订单
2. 支付订单
3. 支付结果处理
4. 交易后处理
5. 订单查询
6. 未明交易处理

1.1范围

本文从客观实战出发全面梳理支付一致性相关场景 ，针对不同的场景给出最佳实践，并归纳出通用的一致性设计原则。

本文描述的是支付不同场景下需要保障最终一致性的对象的规则实践，针对一致性保障手段不做细节展开，例如分布式事务技术。

2一致性设计原则

本章节针对一致性设计共性原则进行归纳总结。其中分为三个档：**“严禁”原则是红线原则必须遵守不允许任何例外情况；“必须”原则是相对刚性原则，原则上必须遵守，特殊情况允许例外且特殊情况必须评审备案；“尽可能”**原则是相对柔性原则，引导设计方向正确性，建议尽可能遵守，允许例外但需要明确合理的理由，不强制评审但需要备案。