简介：这份PDF聚焦支付系统中承上启下的收银核心，面向支付系统初学者、架构设计人员及希望提升实战能力的研发者，系统讲解收银台如何渲染可用支付方式、完成可支付检查并与支付引擎协同。内容围绕支付咨询、支付受理、收银核心系统架构、领域模型和常见支付方式展开，结合大量手绘风格图示拆解订单校验、资产与渠道咨询、额度检查、风控、渠道路由及结果轮询等关键环节，强调可直接应用于日常研发设计。资源包为1个PDF文件，大小约5.2MB，便于按章节查阅和对照学习；目前已有102人学习。适合作为支付系统入门、架构思路梳理及培训机构教学参考，也能帮助资深研发从收银核心视角理解支付链路的协作边界与设计取舍。
1. 收银台不是收银机：为什么支付系统的门面要独立成一个子系统
翻《图解支付系统设计与实现》这类支付系统架构设计资料时，多数人下意识先找支付引擎——钱是它扣的，出问题自然也该它来处理。但真正决定一笔交易在用户侧“看起来成没成”的，恰恰是被当成前端页面、经常被塞进业务系统里的收银台。收银核心在支付系统里做的是两件决定性的事：把散落在会员、卡中心、营销、渠道、风控里的信息合并成“这次你能用什么付”；把用户的选择重新校验一遍再交给引擎。它承上启下，接口朝上接业务订单，朝下只输出“用什么扣、扣多少、走哪条通道”。这一层翻译错了，结果就是可用支付方式少一半，或者扣款成功订单却已关闭。
2. 支付咨询：可用支付方式到底是怎么被“算”出来的
用户打开收银台，看到的是一排图标：某银行储蓄卡、账户余额、某个第三方钱包、一张满减券。这是计算结果，不是配置结果。同一笔订单换个用户、换个时间、换个金额，结果完全不同。搞懂这一层，才能理解为什么“收银台少了某个支付方式”这类问题从来不是简单加个开关能解决的。
2.1 咨询阶段要回答的三个问题
支付咨询在渲染之前要给出三个答案：这笔订单现在还能不能付、用户手里有哪些支付工具可用、这些工具按什么顺序呈现给用户。第一个问题是布尔判断，第二、三个问题都是集合计算。
“能不能付”属于基础检查，包括订单状态（是否已支付、是否已关闭、是否超时）、商户签约关系是否还在有效期内、用户身份是否完成实名。这层检查失败的典型表现是收银台直接展示一个空列表加一句“订单已失效”，而不是渲染出一堆按钮然后每个都点不动。
“有哪些可用工具”是资产与渠道的交集。这里有个容易忽略的点：资产侧给出的是“用户拥有什么”，渠道侧给出的是“这笔交易允许走什么”，两者取交才是可用集合。用户绑了一张卡，但这张卡所属的通道当前在维护窗口内，那这张卡就不该出现。反过来，通道支持某家银行，但用户没绑过这家银行的卡，也不该出现。
第三个问题“按什么顺序”决定了转化率。同一批可用支付方式，把余额放第一位和把信用卡放第一位，用户的选择分布会差出几十个百分点。
2.2 四类咨询的依赖关系与编排顺序
咨询不是四个独立查询拼在一起，它们之间存在隐含的依赖：额度咨询需要知道用户选的是哪张卡、哪条通道，而资产咨询和渠道咨询的结果要先做交集才能确定候选集。
常见的实现顺序是：基础检查 → 资产咨询（绑卡列表、余额、可用券）→ 渠道咨询（币种、金额区间、渠道开关、商户开通的产品编码）→ 额度咨询（对每个候选组合算可用余额上限）→ 组装 → 排序。
额度这一层尤其容易写错。一笔交易的可用额度其实是多个限额取最小值：用户单笔限额、卡本身的单笔限额、通道的单笔限额、商户维度的单日累计剩余、用户维度的单日累计剩余。把它们做成“逐个判断、任一不通过就剔除”是最简单也最不容易出错的方式，代价是组合数一多性能就撑不住，所以实际实现里通常先按维度做粗筛，再对剩下的小集合做精确计算。
2.3 支付方式组装：把渠道能力翻译成用户能懂的一项
组装这一步是收银核心真正体现价值的地方。渠道侧返回的是能力描述，比如“支持快捷支付、单笔上限 5 万、支持某几张卡”，用户看不懂也记不住。组装要把它翻译成一行可点击的条目。
一条组装好的支付方式通常包含：展示名称（银行名 + 卡种 + 尾号）、支付方式类型（快捷、网银、余额、代扣、VA、OTC、钱包）、绑定的支付工具标识、命中的营销标签、可用额度提示、以及一个供后续受理阶段回查的路由信息。
这里有取舍：同一张卡可能同时支持快捷和网银。是把它们拆成两条让用户选，还是按优先级只留一条？拆开会让列表变长、选择困难，只留一条则可能在快捷通道故障时失去备选。常见做法是默认合并、只展示优先级更高的一条，同时保留降级信息，在受理阶段发现首选通道不可用时自动切换，用户无感知。
2.4 排序不是按喜好：可用性、营销、成本三方加权
排序策略是收银台里最像“产品需求”的一段代码，但它的底层是一个打分函数。一个可用的思路是给每个候选算一个分数再降序排：
// 支付方式排序：三类权重加权，权重由运营配置中心下发 public void sort(List<PaymentMethod> methods, UserProfile user, MerchantStrategy strategy) { for (PaymentMethod m : methods) { double score = 0d; // 可用性权重：余额充足、卡状态正常、通道健康度高，直接决定用户点下去能不能成 score += strategy.w1() * availabilityScore(m); // 营销权重：满减、立减、返现的力度，力度越大越靠前 score += strategy.w2() * promoScore(m); // 用户偏好：历史使用频次、最近一次使用的支付方式 score += strategy.w3() * preferenceScore(m, user); // 成本项为负：通道费率高的往后排，避免营销费用和通道成本双高 score -= strategy.w4() * costScore(m); m.setScore(score); } methods.sort(Comparator.comparingDouble(PaymentMethod::getScore).reversed()); }w1到w4是运营可调的权重，生产环境里通常按商户维度配置，大商户和小商户的策略可以完全不同。availabilityScore不是布尔值而是连续值，比如余额足够但只剩一点点、卡临近有效期，这些都应该降低分数而不是直接剔除。costScore取负号是因为它代表成本，费率高意味着平台赚得少，但也不能一味压低，否则用户最常用的卡永远排在最后，体验会崩。
权重调参这事有血泪经验：把营销权重调太高，用户点进去发现券有门槛用不了，投诉量立刻上来。所以营销标签必须和实际可用性绑定，不能用“可能可用”的券去吸引点击。
2.5 并行调用与降级：一个资产域超时不能让整个收银台白屏
咨询阶段要调用四五个外部域，串行执行的话首屏时间就是各域耗时之和。真实环境里营销服务偶发 800ms 是常态，串起来很容易把首屏拖到 3 秒以上。常见实现是并行分发加独立线程池隔离：
// 并行咨询：每个域独立线程池 + 独立超时，单域失败只影响该域结果 CompletableFuture<AssetResult> assetF = CompletableFuture.supplyAsync(() -> assetService.query(ctx), assetPool) .orTimeout(200, TimeUnit.MILLISECONDS) .exceptionally(e -> AssetResult.degraded()); CompletableFuture<ChannelResult> channelF = CompletableFuture.supplyAsync(() -> channelService.query(ctx), channelPool) .orTimeout(150, TimeUnit.MILLISECONDS) .exceptionally(e -> ChannelResult.empty()); // 汇总时按域判断：资产降级则只展示不依赖资产的支付方式（如网银、VA） ConsultResult merged = merger.merge(assetF.join(), channelF.join(), quotaF.join());orTimeout的单位是毫秒，200ms 这类值不是拍脑袋定的，而是从线上 P99 倒推：如果资产服务 P99 是 180ms，超时设 200ms 只损失 1% 的请求；设 500ms 就等于让 1% 的慢请求拖垮整体。exceptionally里返回的不是空对象而是“降级对象”，它携带一个标记，让组装阶段知道这一块数据缺失，从而剔除依赖它的支付方式，而不是把所有支付方式都判为不可用。
降级要有底线：资产域降级时，余额支付和绑卡支付必须一起下线，不能展示出来让用户点了再失败。渠道域降级时，反而可以保守一点只保留余额这类不依赖外部通道的方式。哪些能降、哪些不能降，是个需要逐域确认的问题，不能统一处理。
3. 支付受理：为什么“确认支付”之后要把咨询重新跑一遍
用户在收银台停留 30 秒很正常，接个电话回来再点确认也不稀奇。这 30 秒里，余额可能被另一笔订单扣走，券可能过期，订单可能超时关闭，运营可能刚把某个渠道关停。如果受理阶段直接信任咨询结果去扣款，就会出现“展示时说能用、扣款时说不行”的经典翻车。重跑校验不是为了代码对称好看，是因为检查和实际使用之间存在时间差，而这个时间差在支付场景里代价极高。
3.1 检查与使用之间的时间差
这类问题在并发编程里有专门的名字，核心矛盾是：你在 T0 时刻检查了条件成立，在 T1 时刻才使用这个条件，中间状态可能已经变了。收银台把这个问题放大到了分钟级，而且变化来源极多——用户自己（另一台设备下单）、系统（订单超时任务）、运营（渠道开关）、外部（银行通道故障）。
所以受理阶段的校验比咨询阶段更严格，也更“短平快”：不做排序、不做组装、不查营销，只对用户选定的那一个支付方式做精确校验。校验项包括订单状态、支付工具状态（卡是否被解绑、余额是否足够）、额度是否仍然满足、渠道开关是否仍然打开。任何一项不通过，都必须在提交引擎之前拦下来，并返回明确的原因码让前端展示。
3.2 幂等键与支付单：明确防重复提交的第一道校验
用户手抖连点两次、网络超时后客户端自动重试、页面刷新后重新提交，这三种情况都会产生重复请求。防住它的核心不是前端置灰按钮，而是幂等键的设计。
幂等键必须选业务上唯一且稳定的字段，最常用的是“商户号 + 商户订单号”。不能选前端生成的请求 ID，因为刷新页面就会重新生成；也不能选时间戳。业务键确定后，靠数据库唯一索引作为并发安全保证：
// 受理入口：先落收银单，靠唯一索引挡并发，再走后续流程 @Transactional public AcceptResult accept(AcceptCommand cmd) { CashierOrder order; try { // 唯一索引 uk_merchant_order (merchant_id, merchant_order_no) order = cashierOrderRepo.insertIfAbsent( cmd.getMerchantId(), cmd.getMerchantOrderNo(), cmd.getAmount(), cmd.getCurrency()); } catch (DuplicateKeyException e) { // 并发重复请求：直接读回已存在的单，走幂等返回 order = cashierOrderRepo.get(cmd.getMerchantId(), cmd.getMerchantOrderNo()); return AcceptResult.idempotent(order); } // 首次请求：状态置 PAYING 后再提交引擎，避免提交成功但本地无记录 order.markPaying(); return submitToEngine(order, cmd); }关键在于顺序：先插入本地收银单，再提交引擎。反过来做的话，引擎受理成功但本地插入失败，这笔钱就成了没有归属的孤儿。insertIfAbsent内部的唯一索引冲突是原子操作，比“先 select 再 insert”可靠得多，后者在并发下必然漏。
3.3 风控挑战：不是拒绝，而是把决策权回交用户
风控的返回结果不是简单的通过与拒绝，中间还有一层“挑战”。当风险评分落在灰区时，硬拒会误伤正常用户，直接放过又会放大损失，所以系统返回一个挑战令牌，要求用户完成一次额外验证——短信验证码、支付密码、设备指纹二次确认之类。
这个流程在架构上的意义是：受理阶段的状态不是二元的，而是三元的（通过、挑战、拒绝）。挑战态意味着收银单进入一个中间状态，等待用户回填验证结果后带着令牌再来一次。第二次请求必须用同一个幂等键，否则会生成两张单。
挑战令牌要有有效期，通常几分钟，过期即失效；且必须和收银单绑定，不能跨单复用。这几条约束在实现时经常被简化，最后演变成令牌被重放或者跨用户使用。
3.4 渠道路由：同一张卡为什么能选择不同通道
用户选的是一张卡，系统要选的是一条通道。同一家银行的卡，背后可能有直连通道、聚合通道、不同地区的接入点，它们的费率、限额、成功率、可用时段都不一样。渠道路由的输入是卡 BIN、金额、币种、商户费率配置，输出是一条具体通道。
路由策略通常是“健康度优先、成本次之”。健康度来自实时的成功率统计，某条通道连续失败率超标就自动降权，请求打到备选通道。这个降权动作必须是自动的，靠人工发现再去关开关，中间的时间窗口足够产生一批失败交易。
只有外部渠道的卡类支付才需要路由，余额支付、内部账户扣减不经过这一步。这也是受理流程里唯一一个“咨询阶段完全没做过”的环节，因为它依赖用户最终选定的支付工具，咨询阶段无法预知。
3.5 轮询收单平台而不是支付引擎：结果归属问题
扣款请求发给支付引擎之后，引擎返回的只是“已受理”，不是终态。终态要从收单平台取，这个设计经常被误解成多绕了一圈。原因在于两者的职责不同：支付引擎负责执行扣款动作，收单平台负责持有这笔业务订单的状态。
举个具体场景：用户从渠道页返回时，支付引擎那边显示扣款成功，但收银单因为超时任务已经被关闭。这时候收单平台会发起资金退回，订单的真实结果是“未支付成功”。如果前端按引擎结果展示“支付成功”，用户会以为买到了，实际订单已关闭，客诉和退款会一起涌进来。
所以对用户而言唯一有意义的状态是收单订单的状态。引擎是执行方，收单是归属方，状态权威跟着归属走。这条规则在写代码时的体现是：轮询接口的返回结构里必须包含收单状态，引擎状态只能作为辅助排查字段，不能直接映射成前端文案。
4. 领域模型与系统架构：收银核心如何把资产、渠道、额度拼成一次决策
支付咨询和支付受理这两条流程，落到代码里就是一组领域对象和一张依赖关系图。模型划错了，流程会写成一堆 if-else；依赖排错了，一次渠道故障能引发连锁反应。
4.1 聚合根与值对象：收银单、支付方式项、支付工具的边界划分
收银核心的聚合根是收银单，它代表“一次支付意图”，生命周期从用户进入收银台开始，到终态结束。状态流转大致是：初始化 → 支付中 → 成功 / 失败 / 关闭。这个状态机必须是单向的，成功不可逆，关闭后不可重开，任何“回退”需求都应该用新单解决。
支付方式项是值对象，不是实体。它描述“某一项可用的支付能力”，随咨询结果整体替换，不需要独立生命周期，也不需要单独建表持久化（缓存即可）。把它做成实体是常见的设计错误，会导致每次咨询都往库里写一批行，然后又要写清理任务。
支付工具是另一个概念，指卡、余额账户、券这类真实资产，归属在卡中心和账户体系里，收银核心只持有引用。这个边界很重要：收银核心不应该成为资产的权威存储，否则就成了第二本账。
限额规则值得单独建模。它的维度是多重的：用户、卡、通道、商户，每个维度又有单笔、日累计、月累计三个周期。用一张规则表加一个计算器比在每个业务分支里写判断要好得多，规则可以配置，计算逻辑只有一份。
4.2 外部依赖的分层：谁在前，谁在后
收银核心本身不产生数据，它的能力全部来自编排。梳理依赖时按“是否阻塞主流程”分层比较清晰：
| 依赖域 | 提供的能力 | 阻塞级别 | 降级影响 |
|---|---|---|---|
| 会员 | 用户身份、实名状态 | 强阻塞 | 无法支付，直接失败 |
| 商户服务 | 签约产品、费率、开关 | 强阻塞 | 无法确定可用产品 |
| 卡中心 | 绑卡列表、卡 BIN、卡状态 | 中阻塞 | 卡类支付下线，余额可用 |
| 风控 | 风险决策、挑战下发 | 强阻塞 | 无法继续，安全优先 |
| 渠道路由 | 通道选择、健康度 | 中阻塞 | 卡类支付降级到默认通道 |
| 渠道网关 | 与外部渠道通信 | 弱阻塞 | 该渠道支付不可用 |
| 支付引擎 | 真实扣款 | 强阻塞 | 无法完成支付 |
| 收单平台 | 订单状态权威 | 强阻塞 | 结果不可判定，需补偿 |
强弱阻塞的区别在于：强阻塞依赖失败时整个请求必须失败，不能降级；中弱阻塞失败时可以剔除部分支付方式继续。风控被列为强阻塞是刻意的——宁可这一笔付不了，也不能绕过决策。
4.3 三种收银台形态：控制权在哪里
标准收银台由支付平台托管，商户系统跳转过来，页面渲染、支付方式列表、结果页都在支付方域内。它的优势是支付方可以随时调整策略，劣势是商户对体验没有控制权。
前置收银台以组件或 SDK 的形式嵌进商户自己的页面，支付方提供组件和接口，商户决定容器和交互。这种形态下收银核心要处理跨域、鉴权、以及“组件版本和接口版本不一致”的兼容问题，是最容易踩坑的一种。
扫码付走的是另一条链路。正扫是商户生成二维码，码里携带商户订单信息，用户扫码后被唤起到收银台页面，走的还是完整的咨询加受理流程。反扫则是用户出示付款码，商户扫完直接发起扣款请求。反扫这条链路上没有咨询阶段——付款码本身就隐含了支付工具（通常是余额或默认卡），且要求短时免密，所以风控判断和限额校验必须在受理侧一次性做完，没有任何提前量。
4.4 正扫与反扫在收银核心里的位置差异
把两种扫码放在一起看，会发现它们对收银核心的调用方式完全不同。正扫是“用户主动进入收银台”，收银核心有充分的展示空间和计算时间；反扫是“商户主动发起扣款”，收银核心退化成一条受理通道，只做校验和转发，连支付方式列表都不需要生成。
这个差异直接影响了接口设计：正扫需要咨询接口，反扫只需要受理接口，且反扫的受理必须是同步返回结果或者极短轮询，因为收银员在等。把两者塞进同一个接口是常见的偷懒做法，结果是反扫要等咨询阶段的全部下游返回，收银台前排队。
5. 收银核心避坑手册：五类线上排查最常见的症状
这一节的每一条都来自真实故障的抽象，症状、原因、解决方式按顺序写。看的时候可以先对号入座，再看机制。
5.1 咨询说能用，点支付说不支持
现象：用户看到某个银行卡支付方式，点击确认后返回“该支付方式暂不可用”，重试仍然失败，但过几分钟又好了。
原因：咨询结果被缓存了。缓存可能存在于三个位置：服务端本地缓存、网关层缓存、客户端页面停留。任何一处 TTL 过长，都会让已经失效的支付方式继续展示。受理阶段做了强校验，所以点下去必然失败——这不是 bug，是两层校验不一致导致的用户体验断层。
解决分三层：服务端咨询结果缓存 TTL 压到 60 秒以内，且按用户维度而不是全局维度缓存；渠道开关变更时通过事件主动失效相关用户的缓存；受理阶段发现不一致时不要返回通用失败码，而是返回一个带“请重新选择支付方式”的专用码，前端拿到后自动刷新列表，而不是让用户手动重试。
5.2 用户连点两次，同一订单扣了两笔
现象：同一笔商户订单产生两条支付记录，用户被扣两次款，需要人工退款。
原因：幂等键选错。用前端生成的请求 ID 做幂等，用户刷新页面后 ID 变了，两次请求都被认为是新请求；或者实现上用了“先查后插”，两个并发请求同时查到不存在，然后都插入成功。
解决：幂等键固定为商户号加商户订单号，落库时依赖数据库唯一索引而不是应用层判断。唯一索引冲突时不要抛异常给用户，而是读回已有记录做幂等返回。同时把“插入收银单”和“提交引擎”的顺序固定下来，先插后提，避免引擎成功但本地无记录。
5.3 引擎成功但收银台显示失败，用户被扣款却收到失败提示
现象：渠道侧扣款成功，用户页面显示“支付失败”，几分钟后收到退款短信，客诉集中在“为什么扣了又说失败”。
原因：轮询逻辑把“超时”当成了“失败”。轮询若干次没拿到终态后，代码直接判失败并把收银单置为关闭；随后引擎的成功回调到达，但单子已经关闭，只能走退款。另一种情况是轮询查的是引擎状态而不是收单状态，两个状态源不一致。
解决：轮询超时只置为“处理中”，绝不直接判失败。关闭订单前必须做双向确认：向引擎查一次、向渠道查一次，两边都不是成功态才能关。状态机保持单向，成功态不可逆。对于已经关闭但渠道又成功的单，走自动退款并对账系统打标，让问题可见而不是静默吞掉。
5.4 VA 与 OTC 类支付的状态不收敛
现象：用户在线下 ATM 或柜台转了钱，订单一直停在“待支付”，直到超时关闭。
原因：这类支付方式依赖渠道的异步通知，通知丢包、延迟、或者渠道根本没实现通知，都会导致状态不收敛。更隐蔽的问题是关单时间和渠道凭证有效期的关系——如果本地 30 分钟关单，渠道凭证有效期 60 分钟，用户在第 45 分钟付款，系统已经关单，钱进来了但订单没了。
解决：异步通知加主动查询双通道，通知没来就靠定时查询兜底。关单时间必须晚于渠道凭证有效期，留出足够缓冲。这类支付方式还要接入对账，用渠道的对账文件补状态，这是最后一道保险。
5.5 首屏加载慢到用户放弃
现象：收银台首屏加载三秒以上，移动端弱网下更糟，转化率明显下滑。
原因：咨询阶段的下游调用是串行的，资产、营销、渠道、额度依次请求；或者某一个下游超时设置过长，把整体拖住；再或者是并行做了但没有线程池隔离，一个慢调用占满了公共线程池，导致其他请求排队。
解决：并行化加独立线程池，每个域单独配置超时；超时值从线上 P99 倒推而不是拍脑袋；对非核心域（营销、推荐）设置更短的超时和明确的降级结果。降级后的列表可能少一个优惠标签，但用户能付款，这个取舍在上线前就该确认。
6. 设计取舍：收银核心为什么故意“不算钱”
收银核心与支付引擎的分工，本质上是把“决策”和“执行”拆开。收银核心负责判断这笔交易能不能付、用什么付、走哪条路；支付引擎负责真正把钱扣走。把扣款逻辑也做进收银核心，短期看少一次调用，长期看会变成灾难：每个渠道的扣款协议、重试策略、对账逻辑都不一样，这些差异如果散落在收银核心里，收银核心会迅速膨胀成一个无法维护的巨型服务。收敛到支付引擎之后，渠道差异只在一个地方处理，收银核心可以专注于自己的核心问题——可用性计算。
| 维度 | 收银核心 | 支付引擎 |
|---|---|---|
| 核心职责 | 可用支付方式计算、受理校验 | 真实扣款、渠道交互 |
| 状态归属 | 收银单（支付意图） | 支付单（执行流水） |
| 幂等键 | 商户号 + 商户订单号 | 支付单号 |
| 失败处理 | 返回原因码，引导重选 | 重试、切换通道、退款 |
| 扩展点 | 支付方式类型、排序策略 | 渠道适配器 |
另一个取舍是咨询与受理的重复计算。两次校验必然带来性能开销，但换来的是数据一致性。折中方式是用短 TTL 缓存加受理强校验，把“大概率还可用”和“确定可用”分开处理。这个折中不是免费的——它要求两端的原因码严格对齐，否则用户会看到前后矛盾的提示。
还有一条容易被忽视的取舍：最终结果以收单平台为准，意味着收银核心必须接受“引擎成功但业务失败”这种反直觉的状态，并且把它正确地展示给用户。这背后是状态归属的原则——谁持有订单，谁定义结果。引擎只是执行者，它没有资格宣布交易成功。
我踩过一次坑：早期版本里把引擎回调直接当成支付成功往业务侧推，结果订单超时关闭的那批交易全部推错，退款和补单混在一起对了整整两天。从那以后我每次设计支付状态流转，都强制走一遍“状态是谁产生的、谁有权修改、修改后谁需要知道”这三个问题，答不上来就不写代码。这份《图解支付系统设计与实现》里把收银核心和支付引擎的协同画成了一张图，对着图把这几个问题过一遍，比看十页文字都快。希望帮到你。
本文还有配套的精品资源，点击获取
