返回 MC 收单项目 MC · 11-resume-interview · 项目讲稿

信用卡收单系统项目讲解稿

适合你在面试里讲项目背景、系统分层、核心模块、交易链路、路由、幂等、掉单、风控、清算结算、对账和个人亮点。

1. 自我介绍怎么讲

我之前做的是一套信用卡收单系统，主要服务线下刷卡、线上网关支付、预授权、撤销、退款、清算结算等场景。系统整体采用微服务架构，对外提供统一支付接入能力，对内拆分为商户管理、交易路由、银行通道、风控、结算、对账、账务等核心模块，目标是提升交易处理效率，降低人工对账和差错处理成本，同时保证交易安全、资金准确和系统可用性。

我做的是支付收单系统，核心就是把商户发起的一笔信用卡支付，从接入、校验、风控、路由到银行授权，再到后面的清算、结算、对账、差错处理，整条链路串起来。我主要参与的是交易主链路、通道路由、幂等补偿、对账差错和费率试算这些部分。

2. 项目介绍怎么讲

这个项目本质上是一个信用卡支付收单平台，核心职责是帮助商户完成信用卡支付受理，并把交易从商户侧安全、稳定地送到发卡行或卡组织网络，最后完成清算、结算、对账和异常处理。

它不是一个单纯的支付网关，而是一套完整的资金处理系统。除了支付请求本身，还要处理：

3. 系统分层怎么理解

3.1 商户接入层

负责对外提供能力，主要包括：

3.2 交易处理层

负责交易核心链路，主要包括：

3.3 资金清结算层

负责交易后的资金处理，主要包括：

4. 核心模块怎么讲

5. 一笔交易的完整流程

5.1 商户发起请求

商户通过收银台、POS 或开放接口发起一笔信用卡交易，请求先到 open-api。这里会先做：

5.2 交易服务落单

校验通过后，请求进入 trade 服务。交易服务会先生成交易订单，记录商户号、终端号、商户订单号、平台流水号、交易金额、币种、交易类型和请求时间。

5.3 风控判断

交易服务会调用 risk-control 做风险判断，例如单卡限额、单商户频率限制、黑名单校验、异常地域识别和可疑设备识别。风控放行后，交易才会继续往下走。

5.4 路由选渠

系统根据商户配置、交易类型、卡 BIN、币种、成本、成功率、通道状态等规则，选择最合适的银行通道。这一步的目标是平衡成功率、成本和稳定性。

5.5 通道调用

trade 调用 bank-channel，把平台内部统一交易模型转换为不同银行需要的报文格式，例如 ISO8583 或渠道私有协议，并完成字段映射、报文组装、加密签名、MAC 计算、发送请求和解析响应。

5.6 返回交易结果

银行返回授权结果后，系统更新交易状态。成功则准备后续清算结算；失败则记录失败码、失败原因和通道原始返回；未知则进入查单或补偿流程。

5.7 进入清算、结算、对账

交易成功后不会只停留在“订单成功”，还会继续进入后置链路：

6. 我负责的模块怎么讲

我主要负责过下面几块：

我做的不是单纯的接口开发，更多是在交易主链路和资金后置链路之间把业务规则串起来，包括订单状态流转、路由、幂等、防重、补偿、对账差错和费率结算这些偏核心的支付能力。

7. 高频知识点怎么回答

7.1 什么是信用卡收单系统

信用卡收单系统本质上是连接商户、收单机构、卡组织和发卡行的支付处理系统。它负责把商户发起的支付请求进行接收、校验、路由、授权、记账、清算和结算，最终完成一笔信用卡交易的全生命周期管理。

7.2 核心交易类型有哪些

消费是正常扣款；预授权是先冻结额度，后续再确认扣款；撤销是当天原路撤销；退款是针对已入账交易原路退回；冲正是处理超时或状态不明场景；查单是确认最终状态。

7.3 通道路由是怎么做的

通道路由就是在一笔交易进来后，根据预设规则决定交易应该走哪个银行或哪个渠道。

常见路由维度包括商户号或商户组、支付产品、卡 BIN、卡组织、币种、国家或地区、通道实时成功率、通道限额、通道可用状态、成本和费率。设计上通常会把路由规则配置化，让交易服务只负责发起路由请求，具体命中哪条规则由路由引擎决定，这样后续切换通道、灰度放量、故障摘流会更灵活。

7.4 为什么要做幂等控制

支付场景里网络抖动和超时很常见，如果没有幂等控制，商户重复提交、回调重复投递、补偿任务重复执行，都可能导致重复扣款或重复入账。

7.5 什么是掉单，怎么处理

掉单通常是指银行侧实际成功了，但平台没有及时收到明确成功响应，导致平台订单状态仍然是处理中或失败。

7.6 风控系统在收单里做什么

风控主要是在交易进入通道前识别高风险交易，降低盗刷、欺诈、拒付和异常资金风险。常见能力包括黑白名单控制、单笔限额、单日累计限额、频率控制、IP 或地域识别、设备指纹、风险评分和策略引擎。

7.7 清算和结算的区别

清算更偏向交易和资金明细的确认，结算更偏向资金最终打款。

例如一笔 1000 元交易，平台费率 0.6%，手续费就是 6 元，商户应结 994 元。算出 994 元是清算；按 T+1 把 994 元真正打给商户是结算。

7.8 对账是怎么做的

对账主要是拿平台流水和银行或通道侧流水做比对，确保交易状态和金额一致。

7.9 通道适配层怎么设计

因为不同银行接口规范、签名方式、报文结构、错误码定义都不一样，所以通常会单独做一个 bank-channel 服务，把差异都收敛进去。

7.10 账户和记账怎么做

支付系统最终一定要落到账务上，所以交易成功后不能只更新订单状态，还要同步完成资金账务处理。

每次资金变动都要生成记账流水，保证交易单和账务单可以一一对应，后续出现差错时也能追溯到来源。

7.11 怎么保证交易状态和账务一致

这类系统最怕出现订单成功但没记账，或者记账成功但订单失败。

7.12 商户管理模块主要做什么

商户管理是整个收单系统的基础配置中心，主要负责商户进件信息、商户号和终端号、费率和结算周期、通道权限、API 密钥和证书、商户状态管理、回调地址和白名单配置。它的配置正确性会直接影响交易能不能发起、能走哪些通道、按什么费率清算，以及资金最终结给谁。

7.13 为什么要做失败码标准化

因为每家银行的错误码定义都不一样，如果把这些差异直接暴露给上层商户，接入成本和排障成本都会非常高。所以平台通常会建立一套标准响应码体系，再把不同银行的返回码映射为平台标准码，对商户暴露统一语义，对内部保留原始通道码用于排障。

7.14 系统怎么保证高可用

7.15 数据安全和合规怎么做

支付行业对安全要求很高，尤其涉及信用卡数据时，还会涉及 PCI DSS 等规范。

8. 项目难点怎么讲

9. 个人亮点怎么讲

我在这个项目里做得比较多的是交易主链路和通道标准化。比如我把不同通道的响应码做了统一抽象，上层只处理平台标准码，降低了接入复杂度。另外在掉单场景下，我补齐了查单和补偿任务，减少了状态不一致问题。在对账环节，我也参与了差错自动化处理，把一部分原本依赖人工核对的工作转成系统自动识别和流转。

如果你想再强调工程能力，可以补一句：我做这些事情时，不是只关注功能能不能跑通，而是会重点考虑幂等、防重、补偿、可观测性和后续排障成本，因为支付系统真正难的是异常场景和资金准确性。

10. 面试时可以怎么收尾

这个项目让我比较完整地接触到了收单系统从交易受理、通道路由、风控、账务、清算、结算到对账差错处理的整条链路。虽然我负责的是其中几个核心模块，但因为支付系统前后强关联，所以我对整条链路的上下游关系也比较熟悉，能比较完整地讲清楚一笔交易是怎么从请求进来到最终资金落地的。