支付收单相关

发表于 分类于
本文字数： 1.6k 阅读时长 ≈ 6 分钟

收单场景

一、收单系统核心架构设计

    1. 分层架构
      层级 核心功能 技术实现
      接入层 - 请求鉴权（商户身份验证、签名校验）
      - 协议转换（HTTP/API/SFTP）
      - 流量控制（限流、熔断）      		 Nginx/OpenResty、Spring Cloud Gateway、JWT/OAuth2.0、Sentinel熔断
      业务层 - 订单生成与状态管理
      - 支付路由（成本、成功率、渠道限额）
      - 手续费计算
      - 异步通知      		 Spring Boot、状态机（如Cola StateMachine）、规则引擎（Drools）、分布式锁（Redisson）
      渠道层 - 多支付渠道适配（银行、支付宝、微信等）
      - 渠道协议封装（签名、加密、回调）
      - 请求重试与熔断      		 模板方法模式、工厂模式、OkHttp/Feign、Resilience4j熔断器
      风控层 - 实时反欺诈（IP/设备指纹/行为分析）
      - 交易限额控制
      - 黑名单/白名单管理      		 Flink实时计算、规则引擎、Redis布隆过滤器、设备指纹库（数美/同盾）
      数据层 - 交易流水存储
      - 渠道配置管理
      - 对账与结算数据存储      		 MySQL（分库分表）、Redis（缓存热点数据）、Elasticsearch（日志）、Hive/ClickHouse（分析）
      对账与结算层 - 自动化对账（交易系统、渠道、银行）
      - 资金划付（T+1结算）
      - 财务报表生成      		 分布式任务调度（XXL-JOB）、Apache Camel（文件解析）、RPA（自动打款）
    1. 核心流程
    2. 用户支付流程： 
      1
      用户发起支付 → 接入层鉴权 → 业务层生成订单 → 风控拦截 → 路由选择渠道 → 调用渠道接口 → 返回结果 → 更新订单 → 异步通知商户
    3. 对账与结算流程： 
      1
      定时拉取渠道对账单 → 比对交易系统流水 → 标记差异 → 自动修复（补单/冲正） → 生成结算文件 → 发起银行打款
    1. 关键技术组件
    • 分布式事务：通过Seata/TCC模式保障交易与会计入账的一致性。
    • 消息队列：Kafka处理异步通知、重试任务，削峰填谷。
    • 分库分表：按商户ID哈希分片，解决交易流水海量存储问题。
    • 规则引擎：动态配置路由策略和风控规则（如低手续费渠道优先）。

二、常见问题及解决方案

    1. 高并发场景下的性能瓶颈
    • 问题：大促期间TPS激增，数据库或渠道接口响应延迟。
    • 解决方案：
      • 读写分离：交易写MySQL主库，查询走从库或Elasticsearch。
      • 缓存优化：Redis缓存热点订单数据（如30分钟内订单），减少数据库压力。
      • 异步化处理：支付成功后，通过Kafka异步触发通知和会计入账。
      • 分库分表：按商户ID分片，单表数据量控制在千万级以内。
    1. 渠道接口超时或故障
    • 问题：银行接口不稳定，导致交易失败率升高。
    • 解决方案：
      • 熔断降级：Hystrix/Resilience4j监控失败率，超阈值后自动切换备用渠道。
      • 并行请求：同时调用多个渠道，取最先成功的响应（需权衡成本与用户体验）。
      • 重试机制：指数退避重试策略（1s, 5s, 15s），最多重试3次。
      • 异常隔离：故障渠道标记为不可用，定时任务探测恢复状态。
    1. 资金不一致（长短款）
    • 问题：交易系统与渠道对账单金额不符，导致资金缺口。
    • 解决方案：
      • 幂等设计：订单ID + 渠道流水号唯一索引，拦截重复处理。 
        1
        CREATE UNIQUE INDEX idx_uniq_tx ON payment(order_id, channel_tx_no);
      • 自动化对账：定时任务比对交易流水与渠道对账单，差异记录报警。
      • 过渡户管理：在途资金暂存清算过渡户，日终清零并核对余额。
    1. 支付成功率低
    • 问题：用户支付失败率高，可能因风控误判或路由策略失效。
    • 解决方案：
      • 实时监控：仪表盘展示各渠道成功率，自动剔除低效渠道。
      • 灰度放量：新渠道上线时，按5%流量逐步测试。
      • 用户反馈：失败页提供重试入口，并收集失败原因（如截图报错信息）。
    1. 安全与合规风险
    • 问题：交易欺诈、数据泄露、洗钱行为。
    • 解决方案：
      • 实时风控：规则引擎拦截高风险交易（如同一IP频繁支付）。 
        1
        2
        3
        4
        // 示例：风控规则（同一用户5分钟内超过3笔交易）
        if (userTxCount.last5min() > 3) {
            throw new RiskRejectedException("交易频率过高");
        }
      • 数据加密：敏感信息（卡号、CVV）使用AES加密，密钥管理通过HSM（硬件安全模块）。
      • 审计日志：全链路日志留存，满足PCI-DSS和GDPR合规要求。
    1. 对账差异处理
    • 单边账处理：
      • 自动补单：渠道有记录但系统无，自动生成负向订单冲抵。
      • 人工审核：大额差异（如>1000元）生成工单，财务人员复核后处理。
    • 时间差问题：
      • 挂账处理：在途资金计入过渡户，次日对账后自动清分。

三、系统优化策略

    1. 高可用设计
    • 多活架构：支付系统跨机房部署，数据库主从同步 + VIP切换。
    • 故障演练：定期模拟渠道故障、网络分区，验证容灾能力。
    1. 监控与告警
    • 核心指标：
      • 支付成功率、平均响应时间、渠道可用率。
      • 对账差异率、资金余额偏差、风控拦截率。
    • 工具链：Prometheus + Grafana监控大盘，ELK日志分析，Sentinel实时熔断。
    1. 自动化运维
    • 配置中心：Nacos/Apollo动态调整路由权重、手续费率。
    • CI/CD：Jenkins + Kubernetes实现灰度发布和回滚。

四、总结

收单系统的核心目标是 高并发、高可用、资金零差错，需通过分层架构解耦业务逻辑，结合熔断降级、异步化、自动化对账等机制保障稳定性。关键点包括：

  1. 渠道容灾：多路备份与智能路由，确保支付成功率。
  2. 数据一致性：幂等设计 + 对账系统兜底，杜绝资金风险。
  3. 安全合规：实时风控 + 全链路加密，防范欺诈与数据泄露。
  4. 扩展能力：分布式架构 + 弹性扩缩容，支撑业务快速增长。