运营中券商的支付与加密货币后台

问题

一家受监管的券商，要在已经服务客户的平台上不断增加支付方式和加密货币功能。每次改动都会碰到资金、权限，以及两个必须保持一致的系统：客户门户和后台。

难点在哪里

• 入金和退款都经过支付服务商，涉及会话、webhook，以及 Apple Pay 和 Google Pay 各自的钱包支付规则。
• 加密货币金额需要 8 位小数精度，而且要贯穿每个 API、模型和权限定义，不只是数据库。
• 后台操作要走双人复核（maker-checker）审批，权限控制细到单个字段。
• 状态通过 RabbitMQ 跨服务传递。链路上任何一处丢了一个字段，都不会报错，只会悄悄出问题。

架构

1. 01为巴林实体通过 Checkout.com 交付 Apple Pay、Google Pay 和 Benefit 三种独立的入金方式，三种都已在生产环境运行。还编写了团队的入金与退款端到端本地测试指南。
2. 02加入加密货币平台的头两个月承接了 26 个后端工单，涉及 7 个服务与共享库：后台 API、权限控制 API、两个 RabbitMQ 消费者服务、客户门户 API 和两个共享 Python 库。
3. 03为双人复核（maker-checker）的撤单流程开发了带字段级权限（Casbin）的分页、可筛选列表接口和 CSV/PDF 导出接口。
4. 04把加密货币金额的 8 位小数精度扩展到各 API、模型和权限定义。
5. 05为首次入金添加了 Braze 事件。

决策与挑战

• 每种钱包支付单独一个入金方式

  Apple Pay、Google Pay 和 Benefit 是作为各自独立的入金方式交付的，不是同一个银行卡流程的变体。每一种都有自己的会话规则，发布前都做过端到端测试。

• 把本地测试指南写出来

  怎样在自己的电脑上把一笔入金和一笔退款从头到尾跑通，之前没有文档。我写了这份指南，容易踩的坑也写了进去，下一位工程师不必从零开始。

• 先证明原因，再改代码

  交易故障先被复现，并追查到数据层面的原因。修复随后放进 symbol 解析，那是所有下单路径唯一共用的地方，而不是去给恰好出错的那个接口打补丁。

• 消息两端都要修，消费者先发布

  KYC 字段丢了两次，一次在生产者，一次在消费者。只修一端也能通过代码评审，到了生产环境却照样失败。消费者先发布，这样它不会因为还不认识新消息而拒收。

值得一讲的故事

经过验证的结果

• ✓Apple Pay、Google Pay 和 Benefit 作为入金方式已在生产环境运行。
• ✓头两个月交付 26 个后端工单，涉及 7 个服务与共享库。
• ✓带字段级权限的列表和导出接口，已用于双人复核的撤单流程。
• ✓加密货币金额的 8 位小数精度已覆盖各 API、模型和权限定义。

数字

• 3 种钱包支付方式已上线
• 头两个月 26 个工单
• 7 个服务与共享库
• 加密货币金额 8 位小数精度