跨境支付涉及多个法域和清算轨道。2PC / 3PC 的协调者单点故障代价过高， 因此架构优先保证最终一致性、账务准确、资金安全。
自上而下调用。点击某一层可展开该层设计要点。
这一层只负责接入与契约。支付路由、合规判定、记账都不得泄漏到网关或 App 侧。
FX 作为路由输入变量；每个轨道有独立超时、重试、熔断与舱壁隔离。
合规是架构约束，不是事后检查。每条监管依据对应的技术决策必须可追溯。
Bi-temporal 账本同时记录事件发生时间与系统知晓时间，避免乱序到达导致历史余额错误。
密钥不出域、日志不可篡改、事件可回放。上层的幂等、对账与合规追溯都依赖这一层的确定性。
与国内支付的核心差异：清算轨道异构性，以及 FX 作为路由输入变量。
每通道独立：超时 / 重试 / 熔断 / 舱壁隔离。
MT / MX 转换 · 异步确认
ISO 20022 · 即时结算
API / 文件 · 混合确认
链上确认 · 最终性判定
滚动窗口 5–10 分钟内，错误率 > 5% 或 p99 > 30s → 打开熔断。
冷却后半开探测：小比例流量重测，再决定关闭或再次打开。
路由评估时对所有可行通道评分，存储排名列表。主通道失败后直接尝试次通道，无需重新评估。
跨轨道切换前提：确认原通道未执行，防止重复支付。
通道切换属于流程编排，用 Saga；账户冻结 / 扣款属于资金操作，用 TCC。
面试中可展示的锚点知识：同一编排层必须吞下完全不同的确认语义。
| 维度 | SWIFT | SEPA | 本地清算（SPEI / PIX） | 稳定币 |
|---|---|---|---|---|
| 报文格式 | MT / MX | ISO 20022 XML | CLABE / 专有 | 链上交易 |
| 确认机制 | 异步 MT103 | 即时 | 即时 / 秒级 | 链上确认 |
| 结算时间 | 小时 ~ 天 | 秒级 | 秒级 | 分钟级 |
| 失败模式 | 超时 / 返回 | 即时拒绝 | 即时拒绝 | 链上重组 |
| 幂等挑战 | 高（异步） | 低 | 低 | 中（确认延迟） |
合规不是单体审批流程，而是独立检查管道的串联。
OFAC SDN / EU 综合名单 / UN 制裁名单。每笔交易都查，不仅入职时。
特定走廊超过阈值触发增强尽职调查。
印度 / 巴西 / 南非 / 菲律宾要求入境交易目的码。在到达清算轨道前验证。
按付款人 / 收款人 / 走廊聚合交易监控，检测拆分交易（structuring）模式。
交易监测 + 可疑交易报告生成。
单体合规把所有检查耦合在一个流程中，任一检查超时或需人工介入会导致整条支付链路阻塞。 管道化后，各检查独立执行、独立超时；needs-review 的交易被异步分流，不影响其他交易处理。
设计原则：合规是架构约束，不是事后检查。架构要求：每条监管依据对应技术决策必须可追溯。
设计原则：每一笔资金动向必须回溯到授权依据。
(source_system, source_event_id) 唯一约束乱序到达场景：周末流动性、延迟 pacs.002。只记墙钟时间会产生错误的历史余额。
T+0 流式对账：事件 / Webhook 到达时即时匹配。
T+1 文件对账：SFTP 文件哈希校验，批量核验。
差异检测 → DLQ + 运营 UI → 根因分类。
根因：汇率波动 / 手续费叠加 / 退款链路断裂 / 中间行扣减 / FX 舍入。差异分类体系比修复能力更重要。
Omixbus 账户下虚拟分隔，例如 Ben 50 USD / Alice 100 USD。
余额下降 100 USD 时，仍可精确追溯归属，而不是只看到一个混同余额。
面试高频追问点：重试、并发、TTL，以及乱序到达下的历史余额。
返回原始结果，不重复执行业务效果
返回 409 冲突，防止参数篡改重放
错误实现：查 key → 处理 → 写 key。两个并发重试都读到「未找到」。
正确实现：插入 key 与业务操作在同一数据库事务中。并发未见的 key 由唯一约束 / 锁处理——一个获胜，其他等待或冲突。
key 的 TTL 必须超出客户端最大重试窗口，并留有裕量。
否则 TTL 过期后重试会找不到记录，从而重复执行。
实时结算会产生乱序到达：代理行延迟退单、周末流动性划拨、延迟的 pacs.002 确认。 仅记录墙钟时间的账本会在这些事件到达时产生错误的历史余额。
Bi-temporal 同时存储「事件实际发生时间」和「系统知晓时间」，确保任意时间点的余额查询正确，无论事件到达顺序。
TCC = Try-Confirm-Cancel。不锁住资源直到全部完成，而是先预留，再按结果确认或释放。
预留资源，执行业务检查。
冻结付款人 100 元，订单锁定为「处理中」。
确认执行，资源正式生效。
扣减冻结的 100 元，订单变为「已支付」。
释放预留资源，回滚。
解冻 100 元，订单恢复为「待支付」。
关键点：Try 不真正扣款，只冻结。Confirm 才扣款。Cancel 是释放冻结。
冻结 100 元：可用 −100，冻结 +100
订单状态 → 处理中
标记交易为待确认
所有 Try 成功？
扣减冻结的 100 元，订单 → 已支付
解冻 100 元，订单 → 待支付
Confirm 和 Cancel 必须幂等。网络重试可能导致同一 Confirm 被调用多次，系统必须保证只执行一次效果。
Try 未执行，但 Cancel 被调用。例如 Try 超时未到达，协调者触发 Cancel。系统要识别「没有对应的 Try」，直接返回成功，而不是报错。
Cancel 比 Try 先到达。网络延迟导致 Try 在 Cancel 之后才到。系统要识别「这笔交易已被取消」，拒绝执行 Try。
所有 Try / Confirm / Cancel 操作必须记日志，用于故障恢复和对账。这是审计可追溯性的一部分。
支付系统里：TCC 管资金，Saga 管流程。
| 维度 | TCC | Saga |
|---|---|---|
| 资源锁定 | Try 阶段冻结资源 | 不冻结，直接执行 |
| 补偿方式 | Cancel 释放冻结 | 补偿操作抵消已执行效果 |
| 隔离性 | 较好（资源已预留） | 较差（中间状态可见） |
| 适用场景 | 资金冻结、库存预留 | 长流程、跨服务编排 |
| 支付场景 | 账户扣款、退款 | 支付编排、通道切换 |
我的判断是：核心资金操作采用 TCC，流程编排采用 Saga。TCC 的 Try 冻结资金，Confirm 扣款，Cancel 解冻——保证资金不会被重复使用。Saga 用于非资金流程，比如通道切换和路由重试。两者结合，既保证资金安全，又保持系统灵活性。
但无论用哪种模式，对账都是最终兜底。分布式事务解决的是实时一致性问题，对账解决的是最终一致性问题。两者缺一不可。
白板绘制建议 5 分钟完成。每画一层，用一句话锚定核心判断。
标注每层核心职责。
画通道适配器异构性。
强调 pass / fail / needs-review 三态。
复式账本 + 对账三角。
幂等、bi-temporal、TCC、熔断阈值。
编排层的关键不是路由算法，是通道异构性抽象。
合规层的设计原则是管道化而非单体。
账本的核心是仅追加和 bi-temporal。
核心资金操作采用 TCC，流程编排采用 Saga。
展示对 BIS Project Agorá 的认知：令牌化央行储备和商业银行存款可以实现安全原子结算， 但原型仍处于测试阶段，且不改变央行储备和商业银行存款的法律性质。
生产环境中，复式账本 + 对账兜底仍是确定性的选择。
完整话术与十大面试题见侧栏「面试十题」，或直接打开 Q1 核心架构。 CTO 怎么配合 CEO 和其他岗位，见 职能与跨岗配合。
按技术战略、安全合规、可靠性、组织领导力展开。每题先给判断，再给机制，最后用锚点知识接追问。
先亮核心判断，再落到状态机、账本和对账，避免一上来堆技术选型。
我设计跨境支付平台的起点不是技术选型，而是一个核心判断——支付系统必须保证交易最终一致性、账务准确性和资金安全，而不是追求强一致性分布式事务。跨境场景下，涉及多个法域、多个清算轨道和多个时区，2PC / 3PC 会因为协调者单点故障导致事务阻塞，代价太高。
所以我采用分层架构：接入层做协议适配和签名验签；核心层包含交易指令处理器、账务记账服务、风控决策引擎；支撑层覆盖对账文件解析、TCC 补偿任务、定时调度和监控告警。各层通过标准化 API 交互，避免业务逻辑对底层通道产生直接依赖。
最核心的两个组件：第一是有限状态机，显式定义订单生命周期的合法状态迁移路径——待支付 → 支付中 → 成功 / 失败 / 关闭 → 待退款 → 退款成功。状态变更通过乐观锁 version 字段保障原子性和幂等性，每次更新校验当前状态和版本号，影响行数为 0 则触发重试。第二是复式记账模型，账务系统与交易主链路解耦，保证借贷平衡，这是资金可审计的基础。
跨境支付传统模式下通过代理行 Nostro / Vostro 账户逐级划拨，全球约 27 万亿美元沉淀在预存账户中形成「沉淀流动性」。如果被追问架构演进方向，可以谈模块化「枢纽-辐射」架构，将 API 协调、ISO 20022 报文和自动化合规集成，可显著降低费用和结算时间。
我不会泛泛谈「数字化、智能化」。对我而言，跨境支付技术路线图的硬约束来自 G20 路线图：到 2027 年底，75% 的跨境批发支付在发起后 1 小时内到账，平均成本不超过交易金额的 1%。
这些目标直接决定技术优先级。比如「1 小时内到账」要求我把清算轨道选择从静态路由升级为动态路由引擎，根据通道实时健康度、成本和时效自动选择最优路径。「成本不超过 1%」则要求我压缩代理行链条，推动本地清算网络直连和 ISO 20022 报文标准化以减少人工干预。
值得注意的是，FSB 最新评估表明，全球目标按期达成的可能性较低。这意味着 CTO 的职责不仅是跟随行业趋势，更要在所在企业的走廊市场中找到可量化的、能提前达标的场景，用这些场景证明技术投资回报。
FSB 于 2026 年 3 月启动了路线图新一阶段实施，强调统一化、互操作性和合规自动化是优先事项。Swift 新零售支付框架首批超 25 家签约银行已承诺最迟 2026 年 6 月开始使用。
对账是跨境支付系统的兜底机制。我的设计原则是：不依赖任何单一时点的状态假设，而是建立全链路三方对账——内部账、银行账和通道账在同一框架下核验。
具体做法是构建统一对账中心：从业务端获取账单源数据，解析转换后调用对账规则引擎匹配跨境支付端不同的数据准入条件，执行资金对账、单据对账和流水对账三类任务。对账不平的数据自动进入异常处理系统，触发人工复核流程。
技术上，我倾向于异步对账 + 定时全量核验的混合模式。日间做增量对账快速发现异常，日终做全量对账确保零遗漏。对账差异的根因分析能力比修复能力更重要——差异往往来自汇率波动、手续费叠加、退款链路断裂等系统性原因。CTO 需要建立差异分类体系，把每一类差异的解决路径标准化，而不是每次靠人工排查。
ISO 20022 的 MX 报文比 MT 报文数据更丰富，内置验证和更严格的结构化要求能提升数据处理可靠性，但标准化允许一定解释空间，可能影响对账匹配。这是迁移期对账工作的关键风险点。
合规是需求输入，不是上线前检查项；可审计的核心是资金动向能回溯到授权依据。
我的原则是：合规不是上线前的检查项，而是需求定义阶段的输入条件。在 PRD 和架构决策文档中，每条监管依据对应的技术决策必须可追溯。
以美国 MSB 为例，它的核心不是「牌照」，而是让银行和通道方能够理解你的合规身份。没有 MSB 注册和配套 AML / KYC 体系，银行和通道方甚至不会进入实质讨论。从技术角度，MSB 意味着必须实现：客户识别系统、反洗钱交易监测、制裁筛查（OFAC 等）、可疑交易报告生成。这些不是合规部的文档工作，而是需要嵌入到支付链路的代码级约束——在创建支付订单时就要触发 KYC 校验，在释放商户余额前完成 AML / KYT 筛查。
欧盟 PSD3 / PSR 正在重塑整个支付合规框架，将 PSD2 的 121 条条款重新分配到 PSD3 和 PSR 中，显著扩展了开放银行制度、强化了 SCA 规则和欺诈责任分配。这意味着技术架构需要从一开始就支持模块化的合规策略引擎，而不是把合规逻辑硬编码到业务流程中。当监管变化时，只需要更新策略配置，不需要重新部署核心链路。
新加坡 MAS 于 2026 年 9 月发布 PS Act 修订咨询，对流通规模超过 500 万新元的稳定币发行人要求 MPI 牌照，储备资产须为低风险高流动性资产且市值始终 ≥ 流通面值的 100%，最低基础资本 100 万新元，持有人可在 5 个工作日内按面值赎回。如果目标企业涉及东南亚市场，这是必须展示的监管认知。
可审计性的核心不是「有日志」，而是每一笔资金动向能否回溯到授权依据。这需要三个层次的能力：
第一，不可篡改的审计轨迹。所有状态变更必须记录操作者、时间戳、变更前后值、决策依据（规则版本 / 模型版本）。日志存储采用 WORM（一次写入多次读取）策略，杜绝事后篡改可能。
第二，数据血缘与决策可追溯。一笔支付从发起经过路由、风控、清算、结算，每个环节的决策输入和输出都必须可追溯。规则引擎和风控模型的版本必须与每笔交易的决策记录绑定。
第三，密钥生命周期管控。PCI DSS 4.0 要求在硬件安全模块（HSM）中管理密钥，主密钥由 HSM 生成并保护，数据密钥由主密钥加密后本地缓存且有 TTL 限制，必须禁用明文密钥导出。同时令牌化必须原子完成，无中间态缓存，令牌不可逆且无 PAN 派生能力。
从架构上，我会把审计能力设计为横切关注点，而不是事后追加的模块。每个微服务在发布事件时必须同时发布审计事件，审计事件写入独立的审计存储，与业务存储物理隔离。这样即使业务库受损，审计链路仍然完整。
先保证资金安全与可追溯，再谈恢复速度。故障成本是错付、漏付、重复付，不是宕机本身。
我的第一原则是：先保证资金安全与可追溯，再谈恢复速度。支付系统故障的成本不是宕机，而是错付、漏付、重复付或无法对账。
具体设计上，核心是幂等键 + 状态机 + 异步补偿三层机制。支付指令在创建时生成全局唯一幂等键，所有重试请求通过幂等键去重——网络会重试，没有幂等就会多扣钱。通道故障时，系统不会盲目重试，而是将订单置为「支付中」状态，由定时任务通过主动查询确认最终状态，采用「事件驱动 + 定时兜底」的混合模式触发状态核对。
对于需要跨服务协调的场景，TCC 模式比 2PC 更适配支付场景：预提交阶段冻结用户账户金额、锁定订单状态；正式提交阶段确认所有参与者成功后完成扣款。协调者超时未收到确认时，触发补偿逻辑而非阻塞等待。
通道层面，我会维护多通道动态路由，监控各通道的健康度指标（成功率、延迟、错误码分布），故障时自动切换备用通道。但切换的前提是确认原通道上的在途交易状态，避免同一笔支付在两个通道上重复执行。
展开讲解见架构页 TCC 与分布式一致性：资金操作用 TCC，通道切换用 Saga，对账做最终兜底。
这是支付系统设计中的一个经典陷阱。很多人的第一反应是本地缓存 + 异步同步，但这在跨境支付场景下可能带来严重的合规风险。
我的判断是：离线支付在跨境场景下必须极度审慎，因为每一笔资金动向能否回溯到授权依据是不可妥协的。如果离线期间商户被加入制裁名单，这笔交易在同步时已经完成了商户侧的交付，但资金结算无法执行——商户和平台都面临合规风险。
所以我的设计是：离线支付只允许在极小额、低风险场景下启用的有限功能，且必须满足三个条件。第一，离线交易金额上限严格受控，超限自动拒绝；第二，离线交易在本地持久化时立即记录时间戳和设备指纹，同步时按照原始时间戳而非同步时间做合规校验——如果交易发生时商户不在制裁名单上，该笔交易可以结算；第三，同步流程中增加制裁名单回溯比对，对比离线期间制裁名单的增量变化。
一票否决只用在监管红线、资金安全和审计不可追溯。其余用数据和替代方案对话。
情境：【描述公司想快速上线某功能或进入某市场的商业诉求】
判断：我识别出核心风险不是产品问题，而是资金安全或监管红线。具体是 【描述具体风险点，如制裁筛查缺失、资金隔离不合规、数据本地化未满足】。
沟通方式：我没有直接说「不行」，而是用监管可解释性的框架向 CEO 和董事会解释：如果我们这样做，银行合作方在审计时无法接受，可能导致通道被切断，代价远大于短期收益。同时提供了替代方案——【描述如何在合规框架内部分满足商业诉求】。
结果：【描述最终决策和长期影响】
我对这题的体会是：CTO 的一票否决权只应该用在监管红线、资金安全和审计不可追溯三个领域。其他技术选型分歧应该通过数据实验来解决，而不是靠权威压制。
职能怎么切、怎么跟 CEO 和产品 / 合规 / 风控 / 财务配合，见 CTO 职能与跨岗配合。
在支付领域，技术债务的处理优先级不是按「重构价值」排序，而是按资金安全风险排序。
我的做法是把技术债务分为三类。第一类是资金安全相关：如缺乏幂等保护、对账不完整、审计日志缺失——这类必须在当前迭代解决，没有商量余地。第二类是合规相关：如 ISO 20022 迁移未完成、数据本地化未满足——这类按监管截止日期倒排。Swift 已明确自 2026 年 11 月起所有跨境支付必须使用结构化地址，自由文本地址将被直接拒绝。第三类是效率和可维护性相关：如服务拆分不合理、代码质量——这类通过持续的工程文化改进来消化。
创新投入的原则是：先保证核心链路的确定性和可审计性，再谈新技术探索。稳定币和 DLT 在清算效率上有明确价值，BIS 的 Project Agorá 已经证明了令牌化央行储备和商业银行存款可以在多币种结算中安全使用。但在核心支付链路中引入新技术前，必须完成合规评估和监管沟通。
ISO 20022 迁移不是一个技术选型问题，而是一个有硬截止日期的战略项目。Swift 已明确：自 2026 年 11 月起，所有通过 SWIFT 处理的跨境支付必须使用结构化或混合地址，非结构化自由文本地址将被直接拒绝。
对 CTO 而言，这个项目最大的挑战不是技术实现，而是数据质量。很多机构的地址数据从设计之初就没有按结构化格式存储，现在需要经过读取、解析、验证和重构的完整流程。我的策略是分三步：第一步，在支付通道层做 MT / MX 双格式支持，确保共存期内不中断；第二步，建立地址数据的清洗和转换管道，对所有存量客户和交易对手数据做批处理；第三步，在业务入口层增加结构化地址校验，阻止新的非结构化数据进入。
从架构上，ISO 20022 的 MX 报文数据更丰富、结构化程度更高，可以提升直通处理率，但也意味着报文体积更大，可能影响系统性能。所以在 CBPR+ 共存期（到 2027 年 11 月），需要同时对 MT 和 MX 做性能压测和容量规划。
先切开边界：电商「自建支付」是商户侧资金链路，不是持牌收单。我没有 MSO/MSB 侧收单、收款或 VCC 的全链路负责人经历——这点我会主动说。我全权负责的是【支付中台/结算】：交易状态机、通道对接、【卖家出金】、对账。
建设顺序仍是先合法、再资金、后规模，但范围停在商户侧：P0 幂等和状态机；P1 多通道与对账；若做过出金再讲待结算/可提现。红线是无牌不碰客户资金沉淀。持牌侧的清算、结汇、发卡是 UseePay 的网络，我用架构判断对接，不把对接写成自建。
对方会按交易、资金、账务、合规、风控追问。我只展开亲手签过的细节；没做过的结汇、BIN、卡组织清算，直接说边界。管理上讲真实带【N】人，不把编制说成收单+收款+测试三队。
展开步骤见 建设方案。数字用【】，面试前换成真实经历，不要把对方的 50 亿交易额写成自己的。
UseePay 公开口径仅作比较基准：覆盖 200+ 国家地区、收单成功率 98.5%、可用性 99.999%、对接快至 3 天。CTO 要把成功率、可用性、结汇确定性做成 SLO，且资金准确性优先于可用性。
准备 2–3 个真实案例，按「商业诉求 → 风险 → 技术判断 → 向非技术高管解释 → 结果」打磨。展示判断力的故事比展示成功的故事更有说服力。
| 领域 | 关键日期 / 数字 | 一句话锚点 |
|---|---|---|
| G20 路线图 | 2027 年底 | 75% 批发支付 1 小时内到账，成本 ≤ 1% |
| ISO 20022 | 2026 年 11 月 | 结构化地址强制执行，自由文本拒收 |
| PSD3 / PSR | 2026 年正式通过，2027 年底适用 | 121 条 PSD2 条款重新分配，SCA 规则扩展 |
| 新加坡 MAS | 2026 年 9 月咨询，截止 10 月 16 日 | 稳定币发行人 MPI 牌照，500 万新元门槛 |
| 美国 MSB | 运营后 180 天内注册，每 2 年续期 | FinCEN 注册，BSA / AML 合规 |
| PCI DSS 4.0 | 已生效 | HSM 根信任，令牌化原子完成 |
| 幂等设计 | — | 幂等键去重，状态机驱动，对账兜底 |
| 审计可追溯 | — | 每笔资金回溯到授权依据 |
术语是锚点，不是装饰。每个词出现时，用一句话说清它解决什么问题。
外部请求的第一道防线：认证、限流、幂等、脱敏。
所有外部请求进入系统的统一入口。支付场景中承担认证、限流、幂等键强制校验、日志脱敏。重要性：防止非法请求和重复支付的第一道防线。
授权框架，允许第三方应用在不获取用户密码的情况下访问资源。支付场景中常用于商户接入授权。
客户端和服务端互相验证证书，而非只验证服务端。用于确保通信双方身份可信，防止中间人攻击。
客户端为每笔支付请求生成的唯一标识。服务端用它判断请求是否已处理过。网络会重试，没有幂等保护就会重复扣款。这是支付系统最核心的防护机制之一。
银行卡号。PCI DSS 要求 PAN 在存储和日志中必须脱敏或令牌化，不能明文出现。
服务端主动向商户系统推送事件通知，例如「支付成功」「退款完成」。比轮询更实时，但需要处理重试和乱序。
一笔支付从发起到结算的中枢：路由、状态、补偿、隔离。
协调一笔支付从发起到最终结算的全过程，包括路由选择、状态管理、重试补偿、通道适配。可以理解为支付系统的「中枢神经」。
根据成本、时效、通道健康度、汇率等变量，决定走哪条清算通道。跨境场景同一笔支付可能有多条可行路径，由引擎动态选择最优路径。
用有限个状态和合法迁移路径描述订单生命周期，例如待支付 → 支付中 → 成功 / 失败 → 待退款 → 退款成功。任何非法状态跳转都会被拒绝，防止资金状态混乱。看状态机怎么跑
更新时检查版本号是否变化；若已变化说明被其他请求修改，当前操作重试。用于防止同一笔订单被并发修改。
不冻结资源，直接执行；失败时用补偿操作抵消已完成步骤。适合长流程编排，例如通道切换和路由重试。资金冻结 / 扣款不要用 Saga，改用 TCC。
补偿型分布式事务：Try 冻结资源，Confirm 真正扣款，Cancel 解冻。支付里更适合资金操作，因为需要隔离性。难点是幂等、空回滚和悬挂。看架构页展开
通道错误率超过阈值时自动切断流量，避免故障扩散。冷却后以小比例流量试探恢复。防止单通道故障拖垮整个平台。
借鉴船舶设计：每个通道或服务使用独立资源池，一个通道故障不会耗尽全部资源而影响其他通道。
主通道执行前，预先对所有可行通道评分并存储排名。主通道失败时直接尝试次通道，无需重新评估，减少切换延迟。
不同货币之间的兑换。跨境支付中，FX 汇率是路由决策的重要输入——不同通道的汇率和换汇成本可能不同。UseePay 把它做成独立产品「货币汇兑」，见 公司介绍术语。
与法币挂钩的加密货币，常用于跨境结算试验。BIS 的 Project Agorá 正在测试令牌化央行储备和商业银行存款的原子结算，但生产环境仍以传统清算轨道为主。
区块链等分布式账本的统称。用于探索实时结算和原子交换，但监管接受度和最终性认定仍是障碍。
SWIFT 只传报文，不划拨资金；资金走代理行账户。
全球银行间金融电信协会，提供跨境报文传输网络。注意：SWIFT 只传报文，不实际划拨资金。资金通过代理行账户完成。
欧盟范围内的欧元支付清算体系，支持即时结算。
各国自有清算系统，如墨西哥 SPEI、巴西 PIX、美国 ACH / FedNow。通常比跨境代理行链条更快、更便宜。
SWIFT 的两种报文格式。MT 是传统格式（如 MT103 用于客户汇款），MX 是基于 ISO 20022 的 XML 格式。MX 数据更丰富、结构化程度更高，但报文体积更大。
国际标准化组织制定的金融报文标准。Swift 已明确自 2026 年 11 月起，跨境支付必须使用结构化地址，自由文本地址将被拒绝。这是当前支付行业最重要的合规截止日期之一。
ISO 20022 报文类型。pacs.008 是客户信用转账报文，pacs.002 是支付状态报告。实时结算中 pacs.002 可能延迟到达，账本需要处理乱序事件。
墨西哥的银行账户标准编号，类似 IBAN。本地清算适配器需要支持 CLABE 校验。
没有直接业务关系的两家银行，通过第三方银行完成资金划拨，这个第三方就是代理行。链条越长，成本越高、时效越慢。
Nostro 是「我们的账户在你那里」，Vostro 是「你的账户在我们这里」。代理行之间通过这类账户划拨资金。全球约 27 万亿美元沉淀在预存账户中，形成「沉淀流动性」。
每笔交易都要筛查，不只入职时查一次。
核实客户身份，包括身份验证、地址验证、背景调查等。支付企业必须在新客户入职时完成 KYC。
对企业客户核实公司注册信息、实际受益人、经营范围等。与 KYC 对应，但针对企业客户。
防止通过支付系统清洗非法资金。技术上包括交易监测、可疑交易报告、客户风险评级等。
与 AML 密切相关，重点识别和阻断流向恐怖组织的资金。
对照 OFAC SDN、EU 综合名单、UN 制裁名单等，检查交易对手是否在被制裁对象中。每笔交易都要查，不仅入职时查。
美国财政部外国资产控制办公室，负责执行美国经济制裁。其 SDN 名单是全球支付企业必须筛查的名单。
对交易本身做风险评估，而非仅评估客户。包括交易金额、频率、对手方、目的码等维度。
标识一笔跨境支付用途的代码。印度、巴西、南非、菲律宾等要求入境交易必须携带目的码，在到达清算轨道前验证。
按付款人、收款人或走廊聚合交易，检测异常高频或拆分交易（structuring）。拆分是将大额资金拆成多笔小额以规避申报阈值。
发现可疑交易时向监管机构提交的报告。技术系统需要支持自动生成和提交。
合规检查三态之一。不是直接拒绝，而是将交易分流到人工队列进一步审查，不阻塞其他交易处理。
两个国家或地区之间的支付通道，例如「美国 → 墨西哥」。不同走廊的监管要求、清算轨道、FX 成本差异很大。
资金不会凭空产生或消失；修正靠补偿分录，不改原记录。
每笔交易同时记录借方和贷方，保证借贷平衡。用于确保资金不会凭空产生或消失。和 PSP 结算、分账怎么分层
账本记录不可修改或删除，修正通过新增补偿分录完成。这是审计可追溯性的基础。
修正已记录交易时不改原记录，而是新增一笔反向分录抵消。例如误记 100 元，新增 -100 元分录修正。
同时记录事件实际发生时间（valid time）和系统知晓时间（transaction time）。实时结算中事件可能乱序到达，只记墙钟时间会产生错误的历史余额。
余额不是存在可变字段里，而是从不可变日志计算得出。这样任意时间点的余额都可追溯和验证。
内部账、银行账、通道账三方核验。任何一方不一致都进入差异处理流程。对账是跨境支付的兜底机制。
事件或 Webhook 到达时即时匹配，实时发现差异。
次日通过 SFTP 文件批量核验，做全量兜底。
安全文件传输协议。银行和通道方通常通过 SFTP 交换对账文件。
处理失败的消息进入的队列。对账差异进入 DLQ 后，由运营团队在 UI 中处理。
在同一个实体账户下，用虚拟子账户区分不同客户资金归属。例如 Ben 50 USD / Alice 100 USD。余额下降 100 USD 时仍可精确追溯归属。
客户资金与公司自有资金分开存放，防止公司破产时客户资金被挪用。这是支付牌照的核心要求之一。
密钥、审计、可观测性与数据主权托住上层确定性。
专用硬件设备，用于生成、存储和管理加密密钥。PCI DSS 4.0 要求密钥必须在 HSM 中管理，主密钥由 HSM 生成并保护。
云上的密钥管理服务，通常与 HSM 配合。数据密钥由主密钥加密后本地缓存，且有 TTL 限制。
一次写入多次读取。数据写入后不可修改或删除。审计日志采用 WORM 存储，杜绝事后篡改。
支付卡行业数据安全标准，由 Visa、Mastercard、American Express、Discover、JCB 等卡组织共同制定。服务商最高等级是 Level 1。UseePay 持有 PCI-DSS Level 1。4.0 要求令牌化必须原子完成，无中间态缓存。面试把对方认证当对标，不要写成自己的证书。
用随机令牌替代 PAN，映射关系存在安全环境中。即使令牌泄露，也无法还原卡号。
开源可观测性框架，统一采集日志、指标、链路追踪。用于监控交易全链路。
某些国家要求数据必须存储在本国境内，例如欧盟 GDPR、印度、俄罗斯等。架构上需要支持按法域隔离数据存储。
SLO 是内部服务等级目标，SLA 是对客户的承诺。支付系统中资金准确性和可追溯性优先于可用性。看 SLO 六个维度
RTO 是故障后多久恢复，RPO 是允许丢失多少数据。支付系统中 RPO 通常要求接近零，因为资金数据不可丢失。
不信任任何内部或外部网络，每次访问都需验证。用于防止横向移动攻击。
客户自己管理加密密钥，云服务商只负责存储和使用。用于满足数据主权和合规要求。
牌照不是贴纸，是银行和通道愿意跟你谈的前提。
美国 FinCEN 监管的货币服务企业牌照。境外支付企业在美国运营需要注册 MSB，并建立 BSA / AML 合规体系。
香港海关颁发的金钱服务经营者牌照。UseePay 持有 MSO，是在香港合法开展汇款、换汇等金钱服务的前提，银行和通道会先看牌照再谈合作。
美国财政部金融犯罪执法网络，负责 MSB 注册和 AML 监管。
美国反洗钱核心法律，要求金融机构建立 AML 程序、保存记录、提交报告。
欧盟支付服务指令。PSD2 是现行版本，PSD3 和 PSR 将取而代之，把 PSD2 的 121 条条款重新分配，扩展开放银行、强化 SCA 和欺诈责任分配。
欧盟 PSD2 要求的认证机制，通常需要两个或以上独立要素（知识、持有、生物特征）。
卡组织的持卡人认证。支付时可能跳转到发卡行验证。能降盗刷和拒付，但会打断转化。商户侧要接好回跳失败关单；通道侧按风险灵活触发，而不是全量上 3DS。看 3DS 回跳图
新加坡金融管理局。2026 年 9 月发布 PS Act 修订咨询，对流通规模超过 500 万新元的稳定币发行人要求 MPI 牌照。
新加坡支付服务法下的牌照类别，适用于交易量超过阈值的支付企业。
英国金融行为监管局，负责支付牌照和合规监管。
到 2027 年底，75% 的跨境批发支付在发起后 1 小时内到账，全球平均支付成本不超过 1%。FSB 最新评估表明按期达成可能性较低。
负责监测全球金融体系风险的国际机构，主导 G20 跨境支付路线图的实施评估。
BIS 项目，验证令牌化央行储备和商业银行存款可在多币种结算中安全使用。原型仍在测试，且不改变央行储备和商业银行存款的法律性质。
对接东方支付这类持牌通道时，面试要能用这些词讲清交易怎么闭环、账怎么对上。
持牌支付服务商，如东方支付、UseePay。商户侧支付中台对接的是 PSP，不是自建收单。一句话说清：收单主体是 PSP，我负责订单闭环和对账。
电商内部把创单、验签、异步通知、查单补单、退款、对账收口的一层。避免每个业务系统直接绑死某一家 PSP。最终支付状态以通道为准；中台保证不重复扣、不漏单、能对上账。看业务流程图
向 PSP 提交商户资料、MCC、结算账户，审核通过后获得商户号和密钥。进件在通道侧审核，商户侧负责备齐资料和网站合规。配置中心怎么存 MID / 密钥
PSP 分配的商户号。沙箱和生产各一套，请求和对账都按 MID 隔离，切错环境会把真实资金打到测试单上。
商户行业类目代码。决定费率、能否开通卡组织和是否触发额外风控。禁售类目进件会被拒。BBC 类目对不上怎么补
用密钥或证书确认请求/通知确实来自对方且未被篡改。通知验签失败一律不改账，否则伪造回调就能把订单改成已支付。
用户支付后浏览器跳回商户页面。只能改善体验，不能当最终态——用户可能关页，回跳会丢。
PSP 后台向商户 notify URL 推送支付结果。以后台通知为准。必须处理重试、乱序、重复，并用商户订单号幂等。与 Webhook 是同一类机制。
商户侧生成的唯一单号，创单时传给 PSP。幂等、查单、对账的主键。同一单号重复创单必须返回原结果，不能再扣一次。
PSP 生成的交易流水号。对账时与商户订单号成对出现：我方有单号、通道有流水，对不上就是长款或短款。
主动向 PSP 查询订单最终态。用户关页或通知丢失时，不能一直停在「支付中」，要用查单把状态收敛成成功或失败。
通道已扣款，商户订单仍是未支付或支付中。靠查单和定时任务补齐。不补就会短款：客人付了钱却发不了货，或账对不上。
PSP 提供的测试环境。上线前至少覆盖创单、通知、退款、对账四条用例。密钥和生产隔离，禁止用生产密钥打沙箱。
退款退回原支付卡或钱包。跨境场景下到账天数因通道而异。退款中也是正式状态，退款通知必须幂等。
只退订单的一部分金额。账上要同时记剩余可退余额，避免超额退或重复退。
支付成功不等于钱能拿走。PSP 按结算周期入账后才可提现。出金前必须确认通道已成功，否则会垫资或重复出金。
对账差异。长款：通道有成功单、我方没有（通知丢了）。短款：我方记了成功、通道没有（不能发货）。手续费内扣也会造成金额不一致。
PSP 从结算金额里直接扣费，入账额小于订单额。对账必须按「订单额 / 手续费 / 净额」三列匹配，只对订单额会对不平。
卡支付两步：授权先冻额度，捕获才真正请款。商户侧若只做「支付成功」，要知道通道可能是 auth+capture；未捕获会在有效期后自动解冻。
清算是机构间算谁欠谁；结算是钱真正划走。持牌 PSP 做这两步。商户侧对的是结算后的对账单，不是卡组清算文件。
持卡人向发卡行申请撤销交易。通道会把拒付通知给商户，可能扣回已结算资金。要冻结发货、留存物流凭证应诉。成功率再高，拒付率高一样会被通道清退。
虚拟信用卡，常用于投放广告或采购。发卡涉及 BIN、授权主机、卡生命周期。只用过别人的 VCC 去付广告，不等于做过发卡全链路。
银行卡号前 6 或 8 位，标识发卡机构。VCC/发卡必须有 BIN sponsor。商户侧风控有时用 BIN 判断卡种和发卡国家。
虚拟收款账户。买家打款到专属账号，PSP 按账号匹配商户。属于收款产品，不是收银台创单。没接过 VA 就不要讲开户获客。
3DS 中发卡行的认证服务器。用户跳转验证发生在 ACS。商户只接到 PSP 的跳转/回跳，不直接对接 ACS。
来自《UseePay 公司介绍 2026》。面试要用这些词对齐对方产品，数字只作对标，不要写成自己的业绩。
持牌机构帮商户向买家收款：卡、钱包、本地支付一次接入。UseePay 面向海外 C 端 / 小 B 端实时支付。这是授权到清算的持牌能力。商户侧接收银台不等于自建收单。
把海外销售款收回并结汇入境，也可用收款账户付物流、广告、采购。和收单不同：收单是买家在收银台付款，收付款是企业账户进账和出款。JD 里的「收款研发」多指这一段。
UseePay 三大产品之一：7×24 在线换汇，覆盖 G10 和离岸人民币。和编排层的 FX 输入是同一件事的产品化——费率、时效、在岸/离岸都要进路由，否则对账永远在解释点差。
把外汇卖成人民币并入境。UseePay 宣传结汇封顶费率和「结汇人民币回国」。没牌照不能碰客户结汇；没做过就说资金在通道侧，自己负责状态和对账。
一次接入、多支付方式：国际卡、本土钱包、便利店、微信、支付宝。商户对接的是网关契约，不是每家卡组织和钱包。UseePay 收单产品的对外形态。
品牌自建官网卖货，不是亚马逊店铺。UseePay 收单主战场，对接 Shopify、Shopline、Shoplazza 等建站平台。转化率对跳转、3DS 极敏感。
买家不离开商户页面完成卡支付，常用托管字段或 iframe。UseePay 作为 Shopify 官方合作伙伴上线无跳转。能提转化，但 PCI 范围和 3DS 回跳要想清楚。
Visa、Mastercard、American Express、Discover、JCB、Diners Club 等制定卡规则、清算和 3DS 的网络。UseePay 介绍里的 PCI、运通认证网关、Diners/Discover 会员，都是在卡组织网络里拿到席位。
UseePay 自研风控：通用规则集 + 行业定制规则集，灵活触发 3DS。面试对齐「规则可解释 + 行业集 + 3DS 精准触发」，不要空谈 AI 风控。没管过名单和拒付，就不要说自己做了 UseeShield。
创单后真正扣款成功的比例，常近似授权成功率。UseePay 公开口径 98.5%。CTO 要把成功率做成路由目标，并用 3DS 少伤转化。简历只写自己的数。
各国本地方式：欧洲、南美、东南亚、韩国本地支付等。不是再签一家国际卡通道，而是编排层加轨。覆盖国家数字主要靠 LPM，不只靠 Visa。
当地习惯用的钱包，不是国际卡。UseePay 还接了微信、支付宝。钱包回调字段和卡支付不同，状态机不能写成只有授权/捕获。
买家拿付款码去便利店付现金，常见于日本等市场。创单后会有较长待支付窗口，超时关单和补单规则与即时卡支付不同。
设备钱包，卡号以令牌进通道，有利于转化和 PCI 减负。UseePay 是官方合作伙伴。接钱包要处理 token 而不是 PAN，也要处理设备侧失败。
卡组织联合的一键支付，买家用邮箱/手机唤起已存卡，减少手输卡号。UseePay 已集成。和 Apple Pay 不同：这是卡组织的跨设备网络，不是手机钱包。
先买后付。UseePay 整合 Klarna、Afterpay、Affirm。账期、拒付和退款与卡支付不同，对账不能按单笔即时成功来做。
美元、欧元、日元、英镑、瑞士法郎等一组高流动性货币。UseePay 货币汇兑支持 G10 + 离岸人民币。面试说换汇覆盖，先问清是 G10 还是也含在岸人民币。
CNY 是在岸，CNH 是离岸。UseePay 宣传人民币双汇率可选。价格、监管和能否入境不同。没做过结汇不要讲自己选过在岸/离岸。
换汇时相对中间价少拿到的钱，通常是点差。宣传「实时汇率 0 汇损」是产品口径；账上仍要记下汇率和手续费，否则对账对不平。
银行开给客户的专属账号，用于收款识别。UseePay 与香港本土银行做虚拟银行账户服务。比一般 VA 更靠近银行侧开户，没做过就不要讲开户获客。
在目标国开的收款户，买家可以像付本地账单一样打款。UseePay 上线美、欧、尼日利亚、越南、韩国等地。属于收付款产品，不是收银台创单。
C 端是个人买家，小 B 端是小商户。UseePay 收单服务这两类在线实时支付。和外贸大 B 的收付款、结汇不是同一条产品线。
在线旅游代理，如机票酒店。UseePay 服务航空旅游、酒店出行，并签约同程艺龙等。航旅预授权、部分退、改签对状态机要求更高。
商户付给通道的扣率。UseePay 独立站宣传 1.5% 起。费率随 MCC、卡种、国家变化。路由若不算费率，成本账会对不上。
卡组织或运通对网关的资质认可。UseePay 成为美国运通认证支付网关。这是通道侧席位，不是商户接了 PSP 就算认证网关。
Shopify、Shopline、Shoplazza 等。支付要做成官方或应用市场插件，对接快至 3 天靠契约，不是人肉对接。
自己持有或通过 BIN sponsor 直接连卡组织清算，而不是只做 Stripe/Worldpay 的上层聚合。Adyen、Worldpay 是这条路。聚合上手快，直连才有费率和数据深度。
费率拆成卡组织交换费 + 卡组费 + 收单加价。大商户对标 Adyen / Worldpay 时常用。宣传「1.5% 起」是打包价，账上仍要拆开，否则对账和定价都会糊。
Stripe Connect 一类：平台代子商户收款、分账、出款。电商/市场最吃这套。没有清结算中台就做不了，会变成手工打款。
Stripe Radar、Adyen RevenueProtect：规则 + 模型嵌在授权路径上，用成功率/拒付率闭环。UseeShield 应对齐这个位置，而不是事后看报表。
不需要背所有缩写。高频必须自然使用的核心术语约 15 个；对接 PSP、谈 UseePay 时再加下面这组。
幂等键、状态机、复式记账、对账、熔断、KYC / AML、制裁筛查、ISO 20022、SWIFT、代理行、HSM、PCI DSS Level 1、MSB、MSO、PSD2 / PSD3、Saga / TCC。
Bi-temporal、虚拟隔离账户、预评分备用路由、舱壁隔离、WORM、BYOK、Project Agorá、VCC、BIN、BNPL、在岸 / 离岸人民币、直连收单、Connect。
PSP、进件、验签、异步通知、商户订单号、查单、掉单补单、待结算 / 可提现、长款 / 短款、3DS、拒付。每个词跟上「它解决什么问题」：例如「掉单」紧接着说「通道扣了款、我方还是支付中，不查单就会漏发货或对不上账」。
全球收单、全球收付款、货币汇兑、结汇、聚合支付网关、独立站、无跳转、卡组织、UseeShield、支付成功率。先对齐三大产品，再问自己管到哪一层。50 亿、98.5%、99.999%、1.5% 起是对方公开口径，只作比较基准。
术语是锚点，不是装饰。每个术语出现时，用一句话说明「它解决什么问题」，而不是只抛出缩写。
例如说「幂等键」，紧接着说「网络会重试，没有幂等就会多扣钱」。这样面试官既能确认知识深度，也能确认表达能力。
电商自建支付是商户侧资金链路，不是持牌机构。简历要主动切开，再用同一套五层架构接到 UseePay 的收单、收付款、汇兑。
我没有持牌收单、收款或 VCC 的全链路负责人经历。我全权负责的是跨境电商【支付中台】：交易状态、通道对接、【卖家出金】和对账。按交易、资金、账务、合规、风控讲我管到哪一层。不会把 PSP 对接说成自建收单。
切不开，就会被当成「只会接 Stripe」。
| 维度 | 跨境电商自有支付 | UseePay |
|---|---|---|
| 法律身份 | 商户 / 平台，资金走持牌方或银行 | 香港 MSO、美国 MSB、PCI-DSS Level 1 |
| 产品形态 | 收银台、分账、退款、对账 | 全球收单 + 全球收付款 + 货币汇兑 |
| 客户 | 自己的买家和卖家 | 出海独立站、外贸、OTA、数字娱乐 |
| 成败 | 转化、到账、对得上账 | 成功率、可用性、费率、结汇、可审计 |
| CTO 命题 | 嵌进交易主链路且不出资金事故 | 合规写成架构约束，通道异构性做成编排层 |
每一步都能映射到 UseePay 现有产品或认证。
状态机、幂等、对账、风控策略自建；收单、结汇、换汇走持牌通道。无牌不碰客户资金沉淀。
KYC/KYB、每笔制裁筛查、三态管道。对应 MSO / MSB / PCI L1：牌照是银行愿意谈的前提。
网关强制幂等键、PAN 脱敏、Webhook 乱序重试。对齐独立站 + Shopify 无跳转，对接快至 3 天靠的是契约而不是人肉。
路由看成本、时效、健康度、FX。熔断舱壁，failover 前确认在途。本土化扩通道是编排问题，不是再签一家。
资金冻结/扣款用 TCC，通道切换用 Saga。对账日间增量 + 日终全量，三方核验兜底。
复式、仅追加、补偿分录、乐观锁状态机。虚拟隔离账户分清卖家资金。
规则 + 行业集 + 3DS 精准触发，对齐 UseeShield。不要空谈 AI 风控。
待结算 → 可提现 → 结汇；FX 进路由。简历只写自己的成功率、可用性、未匹配率，不写对方的 50 亿。
白板仍画五层，不要另造一套名词。入职后的 3–5 年 / 组织扩编见 10 到 100。
| 阶段 | 必交付 | 明确不做 |
|---|---|---|
| P0 0–3 月 | 幂等、状态机、PCI 范围、制裁筛查、最小收银台 | 不自建资金池、不上稳定币核心账本 |
| P1 3–8 月 | 2 条以上通道、三方对账、退款/拒付、TCC | 不把合规写死在单个服务 |
| P2 8–14 月 | 本地支付、FX 入路由、结汇可追溯 | 未确认在途不跨轨重试 |
| P3 14–18 月 | 动态路由、熔断舱壁、行业风控、插件 | 可用性不凌驾账务正确 |
项目标题 + 综述 + 3～4 条成果。未做过的不要写。
跨境电商支付中台（【公司】 / 【职位】 / 【年份】）。面向【独立站/平台卖家】，全权负责商户侧：下单支付、通道对接、【卖家结算】、对账。资金清算走【PSP/持牌合作方】，平台不沉淀客户资金。不要写「跨境收单系统」，除非真管过授权到清算。
负责支付域架构与交付。核心判断：交易最终一致性、账务准确、资金安全优先于分布式强一致。将支付拆为接入、编排、合规、账本，避免交易服务直接依赖某一卡组织或本地钱包。
懂独立站转化，也懂通道、对账和合规嵌入。CTO 否决权只用在监管红线、资金安全和审计不可追溯。先保证核心链路确定性，再谈稳定币 / DLT。
各准备 90 秒。对方口径只作基准，不写成自己的业绩。实现泳道图见 三产品流程。
把成功率做成路由目标，3DS 少伤转化。比较基准：98.5% 成功率、独立站 1.5% 起、Shopify 无跳转。
卖家痛的是货卖了钱回不来。讲待结算 / 可提现，以及付给物流广告采购。
FX 必须进路由，否则对账永远在解释点差。对齐 7×24、G10 + 离岸人民币、在岸/离岸可选。
成本在银行关系和持续合规，不在写代码。UseePay 已有 MSO / MSB / PCI L1，CTO 要把牌照要求写成架构约束。UseeShield 用规则 + 行业集 + 可解释 + 3DS 精准触发对齐。
公司介绍三条产品线的实现手稿。纪律：挂同一套账本、清结算、风控；终态以通道或银行为准。按产品各建结算 = 复印作坊。认知可以讲，履历只写亲手签过的段。
海外买家当场付钱走收单；货款打进本地专属账号走收付款。两条钱都进共用内核（账务、清结算、风控、对账），再汇兑或变成待结算 / 可提现 / 结汇 / 出金。
海外买家在独立站付款 → 聚合网关
海外货款打入本地户 / VA → 入账匹配
G10 / 离岸人民币，7×24 账户内兑换
待结算 → 可提现 → 结汇入境或付给物流广告采购
| 产品 | 客户在干什么 | UseePay 卖的能力 | 不是什么 |
|---|---|---|---|
| 全球收单 | 独立站 / 小 B 让 C 端当场付钱 | 聚合网关：卡、本土钱包、便利店、微信、支付宝 | 不是电商自己的收银台中台 |
| 全球收付款 | 外贸把货卖出去的钱收回来，再付物流广告采购 | 本地收款户 + 入账匹配 + 结汇 + 出金 | 不是创单收银台 |
| 货币汇兑 | 手里的美元换成欧元或离岸人民币 | 7×24、G10、CNY / CNH 可选 | 不是「0 汇损所以账上没点差」 |
收银台钱进。卡、钱包、便利店、微信支付宝。
一本账、清结算、UseeShield、对账。三条产品都挂这里。
本地户入账、待结算、结汇、出金付费。
G10 与离岸人民币，7×24 在账户内兑换。
聚合支付网关：海外 C 端 / 小 B 在线实时付。可能走直连，也可能转接 Stripe / Worldpay。成功率做成路由目标，3DS 少伤转化。
泳道表：谁在哪一步做什么。
收单研发主责 ②–⑤；账务清结算主责 ⑥；风控主责 ③。测试门禁：创单、通知、退款、对账。
海外销售款收回并结汇入境；收款账户可付物流、广告、采购。这是账户和出金，不是收银台。JD 里的收款研发多指这一段。
未匹配挂账，不能当可提现。泳道表如下。
收款研发主责 ①②⑤；合规嵌入 ①③④；账务清结算主责 ③⑥。没有这本账户账，结汇和出金只能人肉。
7×24 兑换 G10 与离岸人民币；在岸/离岸可选。宣传 0 汇损是产品口径，账上仍要点差和手续费，否则对账对不平。FX 必须进路由。资金冻结用 TCC，不要 Saga 直接扣。
可并入收款域或独立 FX 域，账必须写共享账本。泳道表如下。
汇兑可并入收款域或独立 FX 域，但必须写同一账本。资金冻结用 TCC，不要用 Saga 直接扣。
30 人先点将，不要按「收单产品 / 收款产品 / 汇兑产品」各招一队开发去复制结算。
| 域 | 在三张图里管哪一段 | 扩编时加人理由 |
|---|---|---|
| 收单 | 创单路由、无跳转、3DS 回跳、通道适配器 | 新 LPM / 新插件，而不是新账本 |
| 收款 | 开户、入账匹配、出金、本地户 | 新国家收款户，复用 KYB 和账务 |
| 账务清结算 | 三张图的结算、待结算、点差、对账 | 0.5→1 的第一优先；三人产品共用 |
| 风控 | 收单 3DS；收款进出金名单；汇兑大额 | 规则平台，不按产品各写一套引擎 |
| 质量 / 平台 | 每条产品的创单/通知/退款或出入金/兑换用例 | 资金门禁独立，防止业务团队自测上线 |
未补的【】不要出现在投递版本。
同题展开见 Q11。白板仍用五层模型，不要为简历另造名词。
对方要的是收单 / 收款 / VCC 任一模块的真实全链路负责人。没有做过，就不要写成做过。
30 人研发部分成收单、收款、测试。面试会按交易、资金、账务、合规、风控五件事追问。编造全链路会被问穿；把电商收银台升级成「跨境收单系统」同样会穿帮。
简历策略：用精确动词写你真正全权负责的那一段（通常是商户侧支付中台），主动标明边界，用架构判断补齐对持牌侧的认知——认知可以讲，履历不能借。
| 对方要听的全链路 | 必须能讲到的细节 | 电商履历里常见的真实对应 | 不能写成 |
|---|---|---|---|
| 收单 | 授权 / 捕获 / 清算 / 结算、3DS、拒付、商户入网、费率 | 对接 PSP、收银台、支付成功率、Webhook | 自建收单、卡组织清算、持有 MID 网络 |
| 收款 | 本地收款户、VA、到账、结汇、付给物流广告、资金隔离 | 卖家分账、待结算 / 可提现、提现对账 | MSO/MSB 收款网络、银行开户获客 |
| VCC | BIN、发卡授权、卡生命周期、3DS ACS、账务记账 | 采购支付用了别人的虚拟卡产品 | 自建发卡、卡组会员、BIN sponsor |
订单状态机、幂等键、通道适配、成功失败关闭退款。这是你最可能真正全权负责的一段。
只写你管过的：待清算、可结算、卖家提现。没碰过结汇/换汇就写「资金在持牌通道，我负责状态与对账」。
订单 vs PSP 对账单、手续费、退款差异。这是商户三方对账，不要说成持牌清算账本，除非真做了复式账本。
卖家 KYC、盗刷规则、3DS 开关，写「平台合规」；不要写 MSB/OFAC 全量筛查，除非你真的接过名单并阻断出金。
对方编制是收单研发 + 收款研发 + 测试。你写真实的：带【N】人，如何拆业务团队与测试、如何排期、如何否决。没管过 30 人就写跨职能协同规模，不要写成「管理收单/收款/测试三队」。怎么配合 CEO 和其他岗，见 CTO 职能。
诚实开场（推荐背这段，而不是上一段过满的 60 秒）：
我没有持牌机构收单、收款或 VCC 发卡的全链路负责人经历。我全权负责的是跨境电商【支付中台 / 结算】：交易状态、通道对接、【卖家出金】和对账。下面按交易、资金、账务、合规、风控讲我管到哪一层。对 UseePay 这种持牌网络，我的判断是商户侧这些能力必须和收单/收款解耦——这也是我为什么来应聘，而不是假装已经管过你们这 30 人编制。
支付公司的 CTO 不是最高级工程师，而是把交易、资金、账务、合规、风控收成可交付系统的人。和 Q8 拒绝 CEO 一起准备。
CEO 决定去哪赚钱。CTO 决定怎样赚得合法、账对得上、明天还在。
对 UseePay 这种持牌网络，业务职责可以压成这五件。
覆盖国家、成功率、结汇时效、对接天数，变成 SLO 和架构：成功率进路由，可用性低于账务正确，牌照要求写进创单前检查。
不重复扣、不漏单、能对上账。通道最终态为准。故障成本是错付 / 漏付，不是宕机。对照 中台流程图。
收单、收付款、汇兑是三条产品线，底层仍是接入 / 编排 / 合规 / 账本。扩 LPM、BNPL、无跳转是加轨，不是再养一套系统。
KYC / KYB、制裁筛查、PCI 范围、3DS、资金隔离是创单和出金的门禁。银行和卡组织看的是：每笔钱能否回溯到授权依据。
对方约 30 人：收单研发、收款研发、测试。CTO 切边界、排优先级、定契约、决定何时否决。没管过 30 人就讲真实带【N】人，不要说成已经管过这三队。
不要说「技术上不行」。改成风险、替代、代价三句话。否决权省着用。
| CEO 要的 | CTO 交的 |
|---|---|
| 新走廊、新行业、更快进件 | 能不能做、多久、PCI / MCC / 牌照卡在哪 |
| 更高成功率、更低费率 | 路由、3DS 策略、通道健康度，用数据而不是口号 |
| 「先上线再补合规」 | 只在三件事上否决：监管红线、资金安全、审计不可追溯 |
| 对外讲 98.5%、3 天对接 | 对内变成可监控指标；不要把公司介绍数字说成自己的业绩 |
银行审计 / 通道清退 / 错付漏付，代价是什么。
合规框里能满足几成：灰度、限额、后置 3DS、只开放部分 MCC。
不做的收入、做的工期、牌照与银行关系。其余用拒付率、未匹配率、在途确认时间说话。
CTO 提供可追溯系统和明确接口，判断权留在专业岗。
| 岗位 | 他们负责 | CTO 配合 |
|---|---|---|
| 产品 | 商户旅程：无跳转、收款户、OTA 预授权 | 定义状态机和「最终态以谁为准」。新产品先问：收单、收付款，还是汇兑 |
| 合规 / 法务 / 牌照 | 规则和审计口径，MSO / MSB 能不能做某国 | 规则嵌进管道：fail 阻断、review 人工、pass 放行，版本跟交易绑定 |
| 风控 | 拒付、盗刷、行业集，对齐 UseeShield | 实时订单事实 + 规则发布。风控不直接改账。成功率路由是工程的 |
| 财务 / 清算运营 | 对账单、长短款 | 订单号对通道号，手续费按净额，差异分类。运营有 UI 处理 DLQ，不靠人肉查库 |
| 销售 / 客成 / 进件 | 对外承诺费率、对接天数、结汇回国 | 变成沙箱用例、MCC 限制、密钥环境隔离。进件审核在持牌侧 |
| 收单 / 收款研发 / 测试 | 收银台与 3DS；VA 与结汇；创单通知退款对账用例 | 同一套账本和对账中心。资金相关没有「先上线再补测」 |
| 银行 / 通道 / 卡组织 | 谈席位、清算文件、认证网关 | CTO 不一定亲自谈，但要问清：在途怎么查、对账文件何时到、失败码是否稳定 |
面试约 40 秒：
我没有持牌收单全链路的负责人经历。我全权负责的是商户侧支付中台：创单、验签、通知、查单、退款、对账。放到 UseePay，CTO 的业务职能我理解为五件事：把覆盖和成功率写成 SLO、把收单 / 收款 / 汇兑收成一套编排、把牌照写成创单前约束、用对账兜住资金、带小队按产品线交付而不是按通道堆人。和 CEO 的配合是：他定走廊和客群，我给可做边界和替代方案；否决权只用在监管红线、资金安全和审计不可追溯。作坊到 10–100 的系统与组织怎么推，见 下一节。
对接 PSP 不是自建收单。没管过 30 人不要说成已经带过收单 / 收款 / 测试三队。
改成资金事故概率和银行断通道。也不要把风控、合规、财务的判断权全揽过来。
组织升级、加二级之前先问清人与协作，见 入职摸底。
以前是业务导向的小作坊：能人扛需求、通道能接上、钱大体能走。现在要走 10 到 100：梳理并重构现有系统，规划未来 3–5 年科技战略，把内部缺失的中台、清结算、账务、风控从 0.5 做到 1，同时把组织从约 30 人升到 60–80，并配齐能带队的二级。行业可以不顶格，但收单、收款业务逻辑必须懂；人要从开发实干里走上来，架构和二级管理都要能落地。
| 维度 | 作坊（过去） | 10 到 100（现在要的） |
|---|---|---|
| 驱动 | 销售和通道机会驱动，需求直达开发 | 业务视角定科技战略：先问清结算/账能不能扛，再答应走廊 |
| 系统 | 点状对接、人肉对账、风控事后补 | 中台 + 清结算 + 账务 + 风控 0.5→1，一套事实、可审计 |
| 组织 | 30 人围着业务转，CTO/骨干是单点 | 二级带域：收单、收款、中台、风控、测试/平台；60–80 人可复制 |
| 失败模式 | 人顶得住就还行 | 人顶不住：错账、拒付、通道被切、扩人只是复制作坊 |
内部痛点已经点名。不要先画微服务全景，按资金风险排序落地。
没有一本可追溯的账，清结算和风控都是空中楼阁。目标：一笔交易一本分录，商户、通道、内部账对得上。0.5 往往是报表和 Excel；1 是复式、仅追加、状态机驱动。
收单请款、收款入账、汇兑交割、手续费内扣、待结算/可提现，收口成一套流水而不是三条产品三套结算。0.5 是通道文件人工导入；1 是日间增量 + 日终全量 + 差异分类。
从人工抽查变成创单/出金门禁。对齐 UseeShield：规则 + 行业集 + 3DS 精准触发，决策版本跟交易绑定。0.5 是事后拦；1 是可解释、可灰度、能降拒付而不伤光成功率。
进件、商户、费率、密钥、工单、对账 UI。作坊里这些在群里和表格里。中台是让 60 人不用再问「这个单到底谁改过」。
先账本事实，再清结算自动化，风控嵌主链路，最后才是体验型中台。三条产品（收单 / 收付款 / 汇兑）必须共用账本和对账，否则 30 人变 80 人只是三套作坊并排。没做过持牌清结算，就说：架构我定边界和验收，领域负责人我招，前 90 天一起把 0.5 的家底盘清。
先加二级和中台，再加人。先翻倍业务开发，等于把作坊复印一份。
| 阶段 | 编制怎么切 | CTO 自己干什么 |
|---|---|---|
| 现在 ~30 | 收单、收款、测试已经在 JD 里。补的是「中台/账务/风控」责任人，哪怕先从现有骨干里点将 | 盘系统、定域、每周看长短款和拒付，而不是写需求代码 |
| 到 ~60 | 二级 5–7 人：收单、收款（含汇兑或独立 FX）、账务清结算、风控、质量/平台。每域 8–12 人 | 管二级：目标、编制、接口契约、晋升。代码审查停在架构和资金路径 |
| 到 ~80 | 加行业或走廊小队（独立站 / 外贸 / OTA），但小队只消费中台，不自建账本。测试独立，资金用例门禁 | 管密度和复制：新走廊是配置和规则，不是新仓库 |
每个二级能独立讲清：域的状态机、谁有权改账、本周未匹配、招什么样的下一个人。CTO 管跨域接口和否决，不审批每个接口字段。
1）账务/清结算负责人 2）风控工程 3）能带 8 人的收单/收款经理 4）测试负责人（资金四条用例）5）才是批量补开发。从开发走上来的 CTO 要能面试账务题，不能只面框架。
入职 30 天：系统与人盘点、一张痛点图。90 天：账务和对账最小 1.0、二级名单。12 个月：中台不再依赖能人。扩编和 CEO 谈的是「域的容量」，不是「再要 10 个开发」。当面要问清的人与协作，见 入职摸底。
这是岗位说明书的主战场。科技战略用业务语言：成功率、到账、结汇、拒付、对接天数、审计过关。
| 年 | 业务要看见什么 | 系统 / 组织 |
|---|---|---|
| 第 1 年 | 错账下降、对账日清、进件和出金可解释；新走廊不再「先接了再说」 | 家底盘清；账务 + 清结算 0.5→0.8；风控进创单/出金；点出 3–5 名二级 |
| 第 2–3 年 | 收单、收款、汇兑共用一套资金事实；独立站无跳转、本地支付是加轨不是新系统 | 中台 1.0；三方对账自动化；UseeShield 类规则平台；编制走向 50–60 |
| 第 3–5 年 | 新行业（OTA、数字娱乐）主要是 MCC、规则集、结算周期配置；牌照要求是架构约束 | 60–80 人按域运转；SLO（成功率、未匹配率、结汇时效）上会；PCI 范围不随人膨胀 |
用同一套接入、编排、合规、账本，支撑三条产品线扩张；科技投入优先打在「账对得上、风控拦得住、二级带得动」，而不是新概念。稳定币 / DLT 放在核心账本之后，不放在第 1 年。
不必排甘特图。面试讲原则和选项，表明想过牌照、走廊和人才密度，而不是许诺上市技术故事。
香港 MSO、美国 MSB、以后更多法域。账本和合规管道按主体隔离，而不是每拿一张牌照 fork 一套系统。
独立站、外贸、航旅、数字娱乐共用内核。差异在 MCC、3DS、账期、分账，不在各写各的结算。
收单负责人和收款负责人能单独对 CEO、银行、大客户讲自己的域。CTO 从「全能救火」变成「标准、人才、跨域裁决」。
本地清算、更多钱包、审慎的代币化结算，都挂在同一账本和对账上。5–10 年的技术领先，表现为加轨成本下降，而不是换一套信仰。
这些比技术选型更容易把 10 到 100 做失败。
| 关注点 | 作坊症状 | 规模期做法 |
|---|---|---|
| 能人单点 | 关键对账、切通道只有一两个人会 | runbook、值班、二级备份；晋升看带人不是看救火次数 |
| 需求直达开发 | 销售承诺次日上线 | 进件/MCC/牌照/在途确认过门禁；CTO 用容量和风险回话 |
| 三套账 | 业务、通道、财务各说各的数 | 一本账 + 差异分类；未匹配率进经营会 |
| 风控事后化 | 出了拒付再补规则 | 创单前规则；行业集；3DS 可解释触发 |
| 测试只测功能 | 页面通了就上 | 创单、通知、退款、对账四条资金用例；没有「先上线再补测」 |
| 按项目加人 | 每个新通道一个小团队 | 按域加人；通道是适配器。编制和 CEO 按域容量谈 |
| 二级无授权 | 改字段也要 CTO 点头 | 域内自治，跨域契约和资金路径才升级。否则 80 人也还是作坊 |
| 文化仍是业务优先 | 合规和账务永远排最后 | 业务优先可以保留，但资金正确和可审计是硬约束，写进 SLO |
面试约 50 秒（回答「你来了怎么推」）：
我理解这个岗位是 10 到 100，不是再找一个能写业务需求的人。业务已经稳定，缺的是内部系统从 0.5 到 1，以及 30 人到 60、80 的二级管理。我没有持牌清结算全链路的负责人经历，收单收款的业务闭环我懂：状态、通知、查单、对账、待结算。入职后 90 天盘清账务和清结算家底，先立一本账和差异分类，同时点将二级，招的第一批人是账务/清结算和风控工程，而不是把开发翻倍。3–5 年把收单、收款、汇兑收成一套中台；5–10 年按牌照和行业加轨，不 fork 系统。扩编只跟域的容量走，避免复印作坊。对标 Stripe / Adyen 要对的是「一套平台」而不是成交额，见 国际对标。
从开发做上来、能下地；懂收单收款逻辑；能讲架构重构和 3–5 年；组织升级有阶段，不是口号。
不要说已经管过 60–80 人或持牌清结算 1.0，除非是真的。规划可以完整，履历只讲【N】人和亲手签过的账。
组织升级、加二级之前用来当面问的清单。网页上已有的是 JD / 介绍 / 我方工作假设，点链接看；内部事实必须问完再定方案。二级 = CTO 下面按域带队的人，不是二线支持，释义见 10 到 100。拍板人是 CEO；当面称谓以对方介绍为准。编制、绩效、去留都问 CEO。
先分清四类，再决定是换人、改协作、还是加二级。人：现任技术总监能力、意愿、威信。协作：销售直达、产品缺位、部门墙、时效承诺无人守。结构：没有域、没有账务编制、三套结算并排。其他：工具没有、牌照约束、一把手节奏频繁改。把假设当事实会误伤现任；把我方 3–5 年规划说成 CEO 已经拍板会显得越权。
| 你要弄清的 | 网页上已有（工作假设，不是内部事实） | 仍须当面问 |
|---|---|---|
| 技术总监是人 / 协作 / 结构？ | 能人单点、缺二级、需求常直达开发 → 10 到 100、现状脑图 | 现任是谁、汇报线、去留、延期是不是总卡在他身上 |
| CEO怎么看组织升级 | 岗位已知：她就是 CEO。观点无公开材料。配合法见 CTO 职能 | 她对二级、现任总监、编制拍板、先摸底再扩编的态度 |
| 研发绩效与业务支持评价 | 规模期应对齐成功率、未匹配、资金四条用例 → 八件事、提效脑图 | 人事现在考什么；业务 / 财务分别怎么评价研发 |
| 产品团队与重复建设 | 对外三条产品应共用账本，不要按产品复制结算 → 三产品流程、扩编切法 | 产品几人、需求池是否一个、谁有权砍冗余 |
| 研发内部沟通协作 | 作坊症状：能人扛需求、测试只测页面 → 作坊到规模 | 站会、文档、跨组接口谁拍板；最近一次协作翻车 |
| 战略 + 业务推进的困难 | 中台 / 清结算 / 账务 / 风控仍是 0.5 → 0.5→1 | 他们自己认为卡在人、牌照、通道、还是优先级 |
| 团队结构与跨部门阻力 | JD：约 30 人 = 收单研发 + 收款研发 + 测试 → 诚实写法 | 实有人数、有无账务/风控编制、时效工作为何完不成 |
| CEO 怎么管研发 | 我方配合法：风险 / 替代 / 代价；否决三件事 → CTO 职能、Q8 | 她看周报还是看结果；有没有硬性节奏或禁令 |
| 高层结构与协作 | CEO 定走廊，CTO 定合法可记账 → 一句话分工 | 她下面还有哪些 C 级、谁管牌照/财务/销售、周会怎么开 |
| 几年战略与将引入的角色 | 我方 3–5 / 5–10 年规划 → 分年、国际对标、分年脑图 | CEO / 董事会自己的年份目标；非研发角色（产品、合规、财务运营） |
| CTO 现阶段有没有明确要求 | 岗位买三样：科技战略、0.5→1、30→60–80 配二级 → 五件职能 | 90 天 KPI 有没有；没有则授权摸底后再出方案 |
先问清汇报线和拍板权，再谈加二级。否则新来的 CTO 会和现任总监抢审批。编制、绩效、去留，最终都是问 CEO，不要再找一个「另外的 CEO」。
不先分清这三类，组织升级会变成换人秀，或空加一层经理。时效完不成、跨部门有阻力，根因经常不在总监本人。
工作假设是骨干单点、改字段也要往上找、没有能带域的二级。见 二级怎么立、二级无授权。这是我方推断，不是对他个人的鉴定。
听什么：人 —— 团队不服、不愿放权、只会救火。协作 —— 需求绕过他、部门墙、承诺由销售先开。结构 —— 收单/收款/测试三摊没有账务域，他再强也管不过来。问法：「我想先分清是人、协作还是编制结构，再决定二级怎么加，避免一上来就换人。」
她就是拍板人。要听的是她对 10 到 100、现任总监和编制的真实态度，不是再确认她是谁。
岗位已知：对方 CEO 是拍板人。怎么配合见 CTO 职能。不要把 我方 10 到 100 说成已经同意的方案。
听什么：她是否支持「先摸底再扩编」；是否把 CTO 当成写需求的人；编制是否她说了算。口径只可能和董事会或销售不一致，不存在「另一个 CEO」对不上。
CTO 的否决权和二级授权，取决于上面几个人怎么开会。结构不清，90 天方案会没有接收人。
我方模型：CEO 定去哪赚钱，CTO 定合法、账对、明天还在。跨岗接口见 和其他岗位怎么配合。这是应聘方怎么配合，不是他们现在的 C 级名单。
听什么：有没有独立合规/财务；销售是否强于系统约束；技术是否只在会后才被通知「已经答应客户」。这些决定你能不能真的否决红线。
作坊变规模，产品要收成矩阵，研发要按域而不是按项目。先问清现在有没有产品团队。
JD 只暴露了三摊：收单、收款、测试。时效完不成、部门协调有阻力，要问是编制缺口还是接口没人。
约 30 人 = 收单研发 + 收款研发 + 测试。缺的是中台 / 账务 / 风控责任人。目标切法：到 60 人 5–7 个二级，每域 8–12 人。见 30 人编制、30→60→80、按域扩编。
听什么：若收款研发其实在做结汇+出金+账，那是结构超载不是人懒。若每个新通道一个小团队，对上 按项目加人。问法：「我想按实有编制画一张图，再决定二级加在哪，而不是按 JD 三个词扩编。」
内部若已经是「能人拉群搞定」，加二级只会多一层转发。要听具体机制，不要听「我们沟通还行」。
作坊常见：需求直达开发、测试只点页面、关键对账只有一两个人会。规模期要 runbook、值班、域内自治。见 作坊到规模、中台流程图 里的状态和通知纪律。
听什么：有没有唯一状态机；通知和查单是不是能人手工；复盘是否只问「谁的错」。这些决定 90 天是先立契约还是先换工具。
作坊到规模一定要把对外三条产品收成一套内核。没有产品团队，重复建设会由销售和研发共同完成；有产品但按三条线各养交付，冗余照样停不下来。
对外产品：全球收单、全球收付款、货币汇兑，应挂同一账本 / 清结算 / 风控。见 三产品实现流、不是什么、支付中台流程。公司介绍里的产品矩阵 ≠ 内部已有产品部。
听什么：若没有产品，CTO 90 天要兼「砍需求」；若有产品但不进资金门禁，矩阵只是宣传。降低重复建设的抓手是 按域加人、通道当适配器，不是再招一队产品经理去写新结算。
对方口头的「研发跟不上」可能是优先级、牌照、通道健康度或能人单点。要对上他们的原话，不能只复述我方 0.5 判断。
我方判断内部缺中台、清结算、账务、风控 1.0，业务已过「能接单」。见 招聘动机、现状、对标缺口。
听什么：若他们坚持先进件体验、账可以后补，和我方「先一本账」冲突，要在 CTO 授权 里谈清楚，否则入职即打架。
没有考核和拍板规则，二级立不起来。没有 90 天授权，摸底会变成暗访。
考「按期上线数」会强化作坊；规模期至少要对齐资金正确和可审计。人事、业务、财务三套评价不一致时，CTO 会被三边拉扯。
建议上台的数：成功率、未匹配率、结汇时效、资金四条用例门禁。见 提效指标、SLO 上会。这是我方主张，不是现行 KPI。
听什么：业务说慢、财务说账乱、人事说态度——三句话对不上，就是协作问题不是单点的人。改考核是组织升级的一部分，要进 90 天方案，不能只加头衔。
结果导向可以，但要问清「结果」是成交承诺还是账对得上。硬性要求（必须参加的会、必须报的数、不许说不）会决定你能不能做 Q8 那种否决。
我方怎么配合：不说技术不行，改口风险 / 替代 / 代价；否决只用在监管红线、资金安全、审计不可追溯。见 和 CEO 怎么配合、Q8 拒绝 CEO、风险承载。
听什么：若「结果」= 客户要的日期，规模化会被销售日历驱动。要把结果改写成成功率、未匹配、资金事故，需要她当场点头，见 授权。
二级和组织图要跟着公司战略长，不能只按研发自己的域来。非研发角色（产品、合规、清算运营、银行关系）缺了，研发二级会被迫兼职。
我方规划：第 1 年账和对账、点二级；2–3 年三产品共用资金事实；3–5 年新行业变配置；5–10 年多牌照当代码隔离。招人顺序偏研发：账务清结算 → 风控工程 → 能带 8 人的经理 → 测试负责人。见 3–5 年 / 5–10 年、分年脑图、对标。这是应聘方案，须用对方战略校验。
听什么：若只招开发不招账务/合规/产品，10 到 100 会停在口头。把非研发角色写进你的组织方案，避免变成「研发内部升级、公司还是作坊」。
有明确 90 天 KPI 就按 KPI 排；没有，就明确「摸底完成后再定下一步，确认时间按工作情况定」。这句话要在入职前得到 CEO 同意。
岗位要买的三样：业务语言的 3–5 年科技战略；中台清结算账务风控 0.5→1；30→60–80 并配齐二级。入职 30 天盘系统和人，90 天一本账 + 二级名单。见 五件职能、推动节奏。履历边界见 诚实写法。
建议开口：「现阶段如果还没有对 CTO 的细 KPI，我建议 90 天先分清是人、协作还是结构，再提交组织与系统的下一步方案，确认时间按摸底进度定。在此之前不按作坊假设直接加人。」对应 50 秒稿。
原清单没覆盖、但会决定二级能不能落地的几问。
二级里最关键的一个位子是账务 / 清结算负责人。不知道谁改账，就不知道点将点谁。见 先账本、Q3 对账、资金核心层。
30 人阶段二级先从内部点，不先对外招一圈经理。见 招人顺序、扩编切法。
没有权限的摸底只能听故事，方案会飘。要在入职或 offer 阶段说清。
把「明确要求」从感觉改成可验收。见 30 / 90 / 12 个月。
面试 / 入职对齐约 40 秒：
组织升级和加二级之前，我先分清是人、协作还是结构，而不是一上来换技术总监或把开发翻倍。网页上我按 JD 做了工作假设：约 30 人是收单、收款、测试，缺账务和二级授权，三条产品应该共用账本——这需要您用内部事实纠正。如果现阶段对 CTO 还没有细 KPI，我建议 90 天完成摸底（系统、账、人、产品需求入口），再提交下一步方案，确认时间按摸底进度定。今天想先对齐：现任总监怎么切、您对编制和二级的态度、研发现在考什么、产品有没有人能砍重复建设。
白板用这几张图。对标一套资金平台怎么长出来，不对标成交额。详细条文仍见 10 到 100 与仓库规划稿。
先让账对得上、风控拦得住、二级带得动。收单 / 收付款 / 汇兑是同一内核的三张皮。组织近邻 Adyen，产品近邻 Airwallex，收单轨现阶段可继续借 Stripe / Worldpay。
第 1 年不模仿 Stripe 发功能。稳定币 / DLT 不放在账本 1.0 之前。
盘系统地图、转接 vs 直连、点将二级、资金四条用例门禁。
账务+清结算 0.5→0.8，日清，风控进门禁。
中台 1.0，三产品共用资金事实，编制 50–60。
新行业变配置，SLO 上会，60–80 按域运转。
多牌照当代码隔离，二级能对外，直连是选项。
数字来自对方 2025–2026 公开口径或监管披露，只作能力对标。UseePay 介绍里的 50 亿、98.5% 同样是对方口径。不要把巨头成交额或自己没做过的直连收单写成履历。
Stripe、Adyen、Worldpay 是全球收单基础设施；Airwallex、Payoneer 更像「账户 + 收款 + 换汇 + 出款」。UseePay 三条产品（全球收单、全球收付款、货币汇兑）形状更接近后者，收单侧 2023 年又与 Stripe、Worldpay 全面合作——说明今天仍有一部分是聚合/转接，不是处处直连卡组织。对标要对「一套钱的平台怎么长出来」，不是对「今年做 1.9 万亿美元」。
UseePay 公司介绍点名合作的，以及同一赛道必须能讲清的。
可编程金融基础设施。2025 年商户处理量 1.9 万亿美元（+34%），约合全球 GDP 的 1.6%；服务超 500 万商家。2026 年 2 月员工股权要约估值 1590 亿美元。产品不只收单：Billing、Tax、Radar 风控、Connect 平台分账、Issuing、Treasury、稳定币编排（收购 Bridge）。核心资产是 API、授权优化和开发者体验。UseePay 独立站「3 天对接、无跳转」是在学它的接入，不是学它的体量。
传统全球收单商，服务 100+ 国家的大中小商户：授权、清算、欺诈、多币种、资金到账。2024 年 FIS 把 55% 卖给 GTCR，企业价值约 185 亿美元；2024 年处理约 550 亿笔、2.5 万亿美元。Global Payments 以 242.5 亿美元收购，2026 年 1 月 9 日交割。强项是直连收单和线下+线上，弱项是历史包袱、多套系统。UseePay 与它合作，等于借它的卡组席位；自己的 10 到 100 是把「借来的轨」收成自己的账本，而不是再写一套 Worldpay。
阿姆斯特丹上市，坚持单一全球平台。FY2025 处理量 1.3943 万亿欧元，净收入 23.642 亿欧元，EBITDA 利润率 53%，年末 4771 人。线上+门店统一，直连收单，风控 RevenueProtect，发卡和商业账户在做 money-in / 管理 / money-out。面试金句：同一套平台撑过万亿处理量、不到五千人——规模来自平台，不来自按通道加人。这是 30 人到 80 人最该偷师的组织逻辑。
伦敦起家的企业级卡收单，偏数字原生大商户和授权率优化，EMEA/APAC 直连相对深。2025 年 9 月行业报道估值回落到约 120 亿美元（2022 年高点约 400 亿）。对 UseePay：学它的成功率/智能受理，不要学「只做超大商户」的销售模型。
收单 + 收款账户 + FX + 出款。这些才是 3–5 年产品对标，不是去追 Stripe 成交额。
墨尔本起家。收款、多币种账户、换汇、企业卡、支出管理、本地支付方式。自称 85+ 牌照、160+ 本地网络、出款 200+ 国家。2026 年 6 月 H 轮 3.2 亿美元、估值 110 亿美元。产品三件套与 UseePay「收单 + 收付款 + 汇兑」几乎同构，只是它把账户和牌照铺得更开。这是最该逐项比能力的对手，也是最不该在面试里说「我们已经一样」的对象。
Payoneer 偏平台卖家收款与付款；乒乓、万里汇偏跨境卖家收款结汇。对应 UseePay 的全球收付款，不是收银台。对标点：本地收款户、结汇入境、付给广告物流、账户体验。没有账务中台，这些都是人肉。
PayPal 是钱包+收单网络；Braintree 是其开发者网关；Antom（蚂蚁国际）做全球收单与本地方式。独立站同时会碰到 Stripe 和这些。UseePay 已接微信、支付宝、Apple Pay、Google Pay、Click to Pay，是在补「方式」，还不是在补「网络」。
Block（Square）偏北美 SMB 与线上线下；Nuvei 偏游戏与高风险垂直；dLocal、EBANX 偏新兴市场本地支付。对应 UseePay 的本土化支付加轨：编排层问题，不是再签一家国际卡。
10 到 100 要补的中台、清结算、账务、风控，本质就是巨头已经产品化了的内部系统。
| UseePay 现在的痛 | 巨头对应的能力 | 10 到 100 要落地的 |
|---|---|---|
| 内部系统缺失、作坊接单 | Stripe / Adyen 单一平台，产品更新可以堆在同一套 API 上 | 先一本账、一套状态机，禁止按通道或按销售项目 fork |
| 清结算 0.5 | Worldpay / Adyen 直连清算；Airwallex 账户内待结算/可付 | 收单请款、收款入账、汇兑交割、手续费进同一流水；日间+日终对账 |
| 账务 0.5 | 巨头都有商户账本、资金隔离、可审计分录 | 复式、仅追加；Connect 式分账以前必须先有这本账 |
| 风控 0.5 | Stripe Radar、Adyen RevenueProtect 嵌在授权路径 | UseeShield 从事后报表变成创单/出金门禁，用拒付率和成功率闭环 |
| 30 人 → 60/80、缺二级 | Adyen ~4800 人处理万亿级，按平台而不按通道扩 | 按域设二级（收单、收款、账务、风控、质量），加人只加域容量 |
| 业务导向、先答应走廊 | 巨头用牌照和直连决定能不能接，用 IC++ 和数据定价 | 科技战略从业务来：先问账和风控能不能扛，再答应新行业 |
分清「3–5 年必须像」和「5–10 年可以追」。成交额、五千人研发、80 张牌照都不在必须像的清单里。
| 工作 | 3–5 年（10 到 100） | 5–10 年（可选领先） |
|---|---|---|
| 账本与清结算 | 三产品共用一本账；长短款进经营会 | 多牌照主体隔离仍共用内核；虚拟账户和分账产品化 |
| 接入体验 | Shopify 级插件、沙箱四条用例、密钥和环境隔离；对接天数可重复 | 自助进件、文档即契约，接近 Stripe 的「开发者分钟级」 |
| 成功率与费率 | 路由看健康度/3DS/成本；宣传 98.5%、1.5% 起变成可监控 SLO | 直连关键市场，IC++ 可报价；减少对 Stripe/Worldpay 转接的依赖 |
| 风控 | 规则+行业集+可解释 3DS；决策版本跟交易绑定 | 授权优化模型进主路径，但仍要可审计，不能黑盒改账 |
| 收款与 FX | 本地收款户、待结算/可提现、G10+CNH 进同一账户视图 | 更多法域账户、企业卡/有节制的 VCC，走同一资金内核 |
| 组织 | 5–7 个二级；测试独立守资金用例；禁止按项目招人 | 二级能对外讲自己的域；CTO 只做标准、人才、跨域裁决 |
| 牌照与直连 | 把已有 MSO / MSB / PCI L1 写成创单前约束；盘清哪些量走合作收单 | 关键走廊直连或 BIN sponsor；新牌照当代码隔离，不 fork |
第 1 年不模仿 Stripe 发 350 个功能，只模仿 Adyen：单一平台纪律。盘清转接 vs 直连的量、一本账、对账日清、点出二级。第 2–3 年把 UseeShield、清结算、账户做成内部产品，让收单/收款/汇兑都是这个产品的皮肤。第 3–5 年用配置接 OTA、数字娱乐，成功率与未匹配率上会。5–10 年再谈更多直连、发卡、稳定币编排——前提是内核已经不像作坊。
面试约 40 秒（被问「你怎么看 Stripe / Worldpay」）：
UseePay 2023 年和 Stripe、Worldpay 合作，说明收单轨可以借；Airwallex 才是产品形状上的近邻。巨头的共性不是万亿处理量，是钱进、账记、风控、钱出在同一套平台上。我们现在缺的中台、清结算、账务、风控 0.5 到 1，就是在补这一层。我对标的是 Adyen 那种「平台加人」而不是「通道加人」，以及 Stripe 的接入体验和 Radar 在授权路径上的位置。3–5 年先把 30 人的作坊收成可复制的 60–80 人平台；直连和更多牌照是 5–10 年的选项，不是入职第一年的 KPI。对方的 1.9 万亿和我们介绍里的 50 亿，我都只当比较基准，不写成自己的成绩。
合作与竞争可以同时存在；转接是现阶段合理策略；对标能力模型和二级组织。公开数字注明来源年份。
「我们要做成中国的 Stripe」却讲不出账本。不要贬低 Worldpay 是过时系统却提不出清结算 1.0。不要把合作通道说成自有直连。
创单、验签、异步通知、查单补单、退款、对账。最终支付状态以通道为准；中台保证不重复扣、不漏单、能对上账。
支付中台：创单、验签、异步通知、查单补单、退款、对账。最终支付状态以通道为准，我保证不重复扣、不漏单、能对上账。
商户订单号、加签、幂等。同一单号只落一笔。
出去加签，进来验签。失败一律不改账。
以后台通知为准。重试、乱序、重复都要幂等。
通知丢失就主动查。终态跟通道走。
原路退、部分退记可退余额。通知同样幂等。
订单号对通道号。长款补、短款停发货。
同步回跳只改善体验，不能把订单写成成功。权威状态来自通道通知或查单。
验签失败 → 不改账（防伪造回调）。验签成功 → 幂等更新。重复通知直接返回成功。
定时查单。通道成功则补单，失败则关单。这是「不漏单」的兜底，不是可选优化。
长款：通道有、我方无 → 补单。短款：我方有、通道无 → 不能发货。手续费内扣要按净额对。
靠商户订单号幂等：创单、通知、退款都用同一主键。网络重试不会再扣一次。
异步通知为主，查单补单兜底。用户关页也不能让「通道已扣、我方未支付」过夜。
商户订单号 vs 通道交易号，加上手续费净额。对账是闭环的最后一公里。
收单主体是东方支付。你讲的是支付中台如何把通道接稳、把账对上。没做过的条目直接删。对照 业务流程图。
跨境电商支付中台对接持牌通道东方支付。我负责商户订单到通道的交易闭环和对账，不负责东方支付侧的清算、牌照和发卡。
下单、签名、同步回跳、异步通知、查单补单、退款、幂等。这是对接 PSP 最能讲全链路的一段。
支付成功后的待结算 / 可提现；结算周期和币种以东方支付账单为准。没做结汇就说资金在通道侧。
商户订单号 vs 通道交易号，日终对账文件，手续费和退款差异。不要说成持牌清算账本。
我在【公司】全权负责对接东方支付。他们是持牌通道，我是商户侧中台：创单、验签、通知、查单、退款、对账。支付状态以他们的最终通知和查单为准，我保证订单不重复扣、不漏单、能对上账。进件、双钥、3DS、状态机展开见 原理图解。
把对接东方支付时最容易被追问的七件事讲透。履历只写亲手签过的段；没做过复式账本就说对账中心。公开口径 98.5% / 99.999% 只作比较基准。
沙箱和生产各有一套 MID 和密钥。BBC 还可能按类目拆多个 MID。创单时按「环境 + 商户 + 币种」取出通道参数。密钥只存 keyRef（指向 KMS / 密钥库的编号），明文不出配置表、不进 Git。
MID：通道认你是谁，沙箱/生产隔离。keyRef：加签验签的钥匙在密钥库哪一格。notify URL：权威结果打到哪，必须公网可达。币种：最小单位和小数位，禁止 float。
配置变更走审核，不热改生产 MID。创单路径只读、适配器只拿当前 env。notify URL 按环境分开，切生产时改的是配置行，不是改代码。
配置中心是通道契约的单一事实源。密钥引用在 L5，创单读取在 L2 适配器，对外契约在 L1。对照 东方支付对接。
沙箱证明闭环能跑；双钥证明轮换时验签不会空窗。两者都是「不停服」的前提。
沙箱和生产是两套 MID + 密钥 + notify。四条用例全绿，才把创单指针从 sandbox 拨到 prod。密钥轮换不是「删 A 写 B」，而是验签集合先变大、加签再切、最后才下线旧钥——所以服务不用重启。
同一商户订单号重复创单返回原结果，不再扣一次。
验签失败不改账；重复 / 乱序 notify 幂等。回跳不当终态。
原路退、部分退记可退余额；退款通知同样验签 + 幂等。
用沙箱对账文件对上成功单和手续费净额。长款补、短款停。
换 MID、keyRef、notify 的公网 URL。金额从测试额变成真实额。补单任务和对账任务必须在第一天就开。只测了「跳转成功页」就切生产，掉单会过夜。
当前密钥。notify 只带 A 的签名。
密钥环变大。PSP 若已开始用 B 签回调，我方也能过。服务不重启。
新请求用 B。在途 notify 可能还是 A，所以旧钥必须留着。
窗口期内旧 notify 已耗尽，再删 A。窗口通常按通道文档，常用【24h～7d】。
加签只用一把「当前钥」；验签遍历密钥环。不停服 = 先扩验签集合，再切加签，最后收缩。
瞬间替换唯一密钥：当天 notify 验签全失败，订单卡在支付中，BBC 出不了库，对账全是短款。
MCC 是通道给你的行业代码，不是商品类目表。BBC 保税仓 / 海外仓货一杂，最容易进件时填「综合零售」，实际在卖美妆、保健、成人或品牌授权货。
进件阶段：收单开不了，BBC 主链路停。交易阶段：3DS 全量打断、成功率下降。结算阶段：冻户等于收款域停摆，待结算无法出金。合规阶段：禁售货已出库，可能被通道清退。不要把这些说成「持牌被罚」，那是 PSP 的事；你讲的是商户侧停收单、停出库、停结算。
1. 立刻：下架或拦截错 MCC 的 SKU，短款/冻户期间停发货。
2. 进件：按真实类目拆 MID，网站、客服、物流单据和 MCC 一致。
3. 风控：高风险类目延迟出库，不要全站关 3DS。
4. 账务：已销售未结算的单单独挂账，等通道解冻再给供应商。
5. 组织：类目变更要过配置审核，不能运营直接上新品。
3–5 年目标是「新行业变成 MCC / 规则 / 账期配置」，而不是每个类目 fork 一套结算。商户侧你已经吃过「一个 MID 装所有货」的亏，所以到持牌网络会坚持：行业差异进 L3 规则和进件配置，账本仍是一本。
3-D Secure：发卡行确认「是不是持卡人本人」。用户会被带到发卡行认证页（ACS），再跳回商户。降盗刷和拒付，但打断转化。
浏览器回到 return URL，只说明人回来了，不说明钱扣了。权威仍是 PSP 的异步通知或查单。订单在整个 3DS 期间保持支付中。对照 中台流程图。
欧盟 PSD2 强客户认证；高额 / 新卡 / 异地；Visa 等卡组强制；通道风控命中。BBC 跨境卡支付最常见。本地钱包通常不是 3DS，状态机不要写成只有「跳转验证」。
回跳失败、用户关掉 ACS：关单或保持支付中等查单。不要把回跳参数当成功。3DS 全量会上转化；应对齐 UseeShield 那种「规则触发」，不是一刀切。
商户接到的是 PSP 给的跳转/回跳，不直接对接 ACS。不要说自己做了 3DS ACS 或卡组会员。没接过就删，只保留认知。
四个词经常被混成「我们做了清算」。先切开场景，再钉到五层。没做过复式就说对账中心，不要说清算账本。
| 是什么 | 用在哪 | 系统约束 | 五层落点 | |
|---|---|---|---|---|
| 复式账本 | 每笔资金同时记借和贷，借贷必须平衡；仅追加，改错走补偿分录 | 支付成功、退款、手续费、分账、出金；审计要回溯授权依据 | 交易服务不直接改余额；入账必须带幂等锚点 (source, event_id)；非法状态不能出分录 | L4 资金核心L5 审计日志 |
| PSP 结算 | 持牌通道按账期把已成功交易的净额划到商户结算户（常 T+N，内扣手续费） | 东方支付把 C 端扣款变成可打给平台的钱。支付成功 ≠ 钱已到账 | 待结算不能早于通道结算单；对账按净额；商户侧不编清算文件 | L2 适配器拿对账单L4 三方对账 |
| 分账 / 提现 | 一笔 C 端支付拆成平台佣金 + 多个供应商货款；待结算 → 可提现 → 出金 | BBC 多供应商；售后部分退要扣可结算或追缴 | 出金前通道必须已成功；未结算不许提现；退款与已提现冲突要垫资策略，不能只改订单状态 | L2 状态编排L3 出金前风控L4 分录 |
| MCC | 商户行业类目代码，通道用来定价、开卡组、加风控 | 进件、费率、3DS 强度、能否卖某类货 | 创单使用的 MID 必须与当前售卖类目匹配；类目变更走进件，不热改 | L1 进件配置L3 行业规则 |
全球收单对应创单到 PSP 结算；全球收付款对应待结算 / 提现；货币汇兑是结算币种变化时的对账分类。三条必须挂同一本账，否则 80 人是三套作坊。见 三产品流程、五层模型。
有限状态机：只有有限个状态，状态之间只有白名单迁移。支付里它防止「钱的故事」被并发和乱序写花。
状态：待支付、支付中、成功、失败、关闭、退款中、已退。事件：创单、notify、查单、关单、退款申请、退款 notify。守卫：当前状态 + 版本号 version 对得上，才允许迁移；影响行数为 0 则重试，不覆盖。
权威事件是通道 notify 或查单。同步回跳、3DS 回跳都不是事件终态。
notify 和查单可能同时到达。更新语句带 WHERE status='支付中' AND version=?，成功则 version+1。谁先到谁赢，后来的发现行数为 0：若已是目标终态则幂等返回；若终态冲突则进人工，不覆盖。这就是乐观锁。资金操作需要隔离时用 TCC，通道编排失败用 Saga 补偿，不要在长链路上用 2PC。见 TCC。
SLO 是内部目标；SLA 才写进对客合同。支付里资金准确优先于可用性。UseePay 公开的 98.5% 成功率、99.999% 可用性只作比较基准，简历写自己的【】。
先问「账对不对」，再问「能不能付成」，再问「钱何时能给供应商」，最后才是「系统在不在」和「接口快不快」。可追溯不是百分比，是硬约束：每笔资金动向都能回到授权依据。
重复扣 = 0；T+1 未匹配率【】；长款补、短款停发货。这是账本和对账的 SLO，不是 uptime。
创单后真正成功的比例。做成路由目标，而不是商务关系。3DS 少伤转化。比较基准 98.5%，只报自己的数。
通道 T+N 内可提现覆盖率。BBC 供应商催款看这个。支付成功但不可提现，不算收款做成。
核心创单 / 查单 / 退款接口存活。账务正确冲突时，宁可拒创单，不要瞎重试多扣。比较基准 99.999%，不抄到简历。
创单同步耗时、notify 到改状态的延迟、补单收敛时间。回跳快不等于支付快。
验签失败不改账；分录带 source_event_id；WORM 日志。做不到就不是支付系统，而是业务库。