电商业务 - 支付

支付业务是电商系统中技术复杂度最高、稳定性要求最严的模块之一。支付的成功与否，不仅影响用户购物体验，更直接关系到平台的资金安全和收入稳定性。支付系统需要与订单系统、账户体系、风控系统、对账中心等多个模块紧密协作，同时还要对接多个外部支付渠道，技术挑战极大。

支付

在电商业务中，支付模块的稳定性和用户体验至关重要。一个设计良好的支付系统能够有效提升转化率，降低用户流失，而一个有缺陷的支付系统则可能导致资金损失和用户投诉。

支付体系整体架构

支付系统的核心在于稳定性、安全性和扩展性。一个完整的支付体系包含以下核心组件：

核心业务流程分析

支付流程设计

支付流程从用户提交订单开始，到最终支付成功结束，涉及多个状态转换和系统交互：

关键节点说明

支付订单生成：基于业务订单创建支付订单，记录支付金额、支付方式等信息

支付渠道调用：根据用户选择的支付方式，调用对应的支付渠道接口

同步结果处理：立即返回支付结果给用户端

异步通知确认：支付渠道通过回调通知最终支付结果，确保数据一致性

产品架构图

所谓产品架构图，简单的理解，就是站在产品角度，提供什么样的服务能力。下面是一个典型的支付系统的产品架构图。这个图画得比较简单，但是已经涵养一个支付系统最核心的产品能力。

实际实现时差异会很大，尤其是上面的产品或应用层，有很多机构为特殊的行业提供一些特殊的能力，比如携程的支付就会有航空方面的B2B业务。但基础的能力基本也就这些。

上面部分是会员或商户感知的产品能力，包括门户、收银台，收单产品，资金产品等。下面部分是支付系统最核心的服务，用于支撑对外的产品能力。如果多跳几家公司，就会发现基础的部分大家都差不太多。

极简支付系统架构图

这个图很精简，但是基本已经够用，应付本对本交易这种简单的业务是完全没有问题的。

一些复杂的支付系统可能还有外汇、额度中心、产品中心、卡中心等，甚至一个子系统可能会拆分为多个应用独立部署，比如收单结算就可以拆成收单和结算两个独立的应用。

完整支付系统架构图及各子系统简介

跳过几个支付公司，这些基础的概念在几家公司都差不太多，区别是底层技术实现。比如RPC框架，数据库，业务流程，部署架构等。

这是一比较完整的系统架构图，属于逻辑划分。在单体应用中，就是一些模块，在分布式应用中，就是一些子域、子应用或子系统。

核心系统依赖图

开放网关

主要对接商户，比如下单、支付等接口入口。通常要求有比较高的安全性。部分公司可能会把移动端网关、PC门户网关、商户通知等能力集成在开放网关，也可能会单独拆出部署。

收单结算

负责把商户的单收下来，并给商户发起结算。承担的收单产品包括有：线上收单，线下收单，担保交易、即时到账等，每个公司的商业策略不同，开出的收单产品会有差异。

有些公司把结算划到出款中心，对接银企直连的渠道。

资金产品

承担无买卖标的的纯资金转移能力。典型的有：充值、转账、提现、代发。和支付的区分在于支付是有买卖标的，而资金产品没有。也就是在系统中没有买卖记录发生，但在线下可能有。

资金产品一般需要独立的牌照。

收银核心

渲染可用支付方式。包括查询账户是否有余额，查询营销是否有营销券，查询渠道网关是否有可用的外部渠道，最后组合成可用支付方式，供前端渲染。

收银核心就像一个大内总管，收到请求后，找商户平台核实身份，找合约平台核实权限，找会员平台核实用户身份，找收单看一下这笔单是否可以继续支付，找账务中心获取余额信息，营销看看有没有可用的券，找渠道网关看看没有可用的渠道，找额度中心看看是否超限额了，找风控问一下当前支付是否安全，找会员平台校验支付密码 ... ...

支付引擎

负责真正的扣款或转账。有些公司叫支付核心。

如果是余额就调账务扣减余额，如果是红包就调营销做核销，如果是外部银行通道就调渠道网关。

渠道网关

负责去外部渠道扣款。通常还会提供渠道路由、渠道咨询等能力，做得细的公司可能会把渠道核心和报文/文件网关单独拆出来。其中渠道核心就提供渠道路由、渠道咨询、渠道开关等服务，报文/文件网关负责报文转换、签名验签等。

会员平台

管理会员的生命周期，比如注册、注销、登录等。同时还提供核身服务（比如登录密码，支付密码，短信验证码等）、实名认证服务等。

商户平台

管理商户的入驻签约、KYB、交易管理等。

产品中心

管理对外提供的产品能力，比如快捷支付，代扣等。一般大的支付系统才会独立成一个子系统。

账务中心

负责账户开立，记账等。

会计中心

会计科目管理、分录管理、日切管理等。

监管报表有时候也放在这里，有些公司也会独立出去。

很多集团公司往往有一套独立的专业财务系统，这个时候往往需要会计中心做完日切后，要把记账信息合并到集团公司的财务系统中去，简称并账。

对账中心

负责明细对账和资金对账。

营销平台

提供满减、红包等营销工具。

风控平台

针对账户和交易，提供实时、离线风控，控制交易的风险。反洗钱、反欺诈是基本要求。

通常各公司对风控规则看成是机密，研发也可能看不到运营配置的规则。经常看到有网友问：“有xx公司的人在吗？我有xxx场景下的支付总是提示风控不过，是否知道是什么原因，怎么才能通过？”，完全是浪费口舌，谁会对外公布自己的风控规则，让人去钻空子呢？

运营平台

订单管理、渠道管理、产品管理等综合运营工具。

数据平台

主要用于数据汇总和分析。当前各支付公司基本都是分布式部署N多个应用，数据都在散落在各子系统中，需要汇总到数据平台用于经营分析。

卡中心

负责管理用户的绑卡信息。需要经过PCI认证。

额度中心

累计用户、商户的额度，通常有日、月、年，单卡等各种分类。

外汇平台

负责外汇报价和兑换。

流动性与调拨中心

一些跨境支付公司，在多个国家多个银行有头寸，各头寸之间经常需要做流动性管理，提高资金利用率。

毕竟在国外不需要把备付金强制存到央行还不给利息。当资金量大的时候，这笔收益可不少。

差错中心

负责差错处理。比如渠道退款失败（银行账号销户，过了银行的退款有效期等），需要通过其它的方式退给用户。

拒付中心

处理用户的拒付和举证。在跨境支付场景下，信用卡用户联系发卡行说卡被盗刷或商品没有收到，或商品有问题等，拒绝支付给商户。国内基本没有看到拒付场景。

拓展知识

技术风险与资损防控

一般来说，技术风险主要包含稳定性和资损两个方面。其中稳定性风险就是大家经常说的几个9，比如99.999%可用，就是5个9。资损风险就是平台或用户的资金损失。

虽然资损也是技术风险的一种，但是因为对于专业的持牌支付公司来，资损是一种非常严重的事故，容易引发客诉、网络事件、甚至监管介入，所以又较一般的风险更为严重，常常把资损防控单独拿出来说。

技术风险体系过于庞大，这里只谈几点通用知识。

识别风险来自哪里

我们通常先需要知道风险来自哪里，才知道如何去防控。而风险往往来自变化。举几个例子，抛砖引玉：

流量变化：大促场景下，流量会暴增。
代码变化：引入了新的代码。
业务变化：修改了业务流程，或引入了新的业务。
外部变化：外部新的攻击手段。

应对风险

根据变化去应对风险。比如大促引入了流量变化，那就做压测、扩容、限流、降级非核心业务等应对。比如原来只有支付，这些有了用户提现，针对用户提现，内部多个子域可能状态/金额不一致，和银行渠道的状态/金额也可能不一致，那就加入各种对账手段，以及对应的应急预案。

内部系统实时与离线对账

对账是资损防控中最效的手段之一。一般的支付平台会有内部系统之间的两两核对，这种核对主要是信息流层面的核对，主要核对状态、金额的一致性。

说明：

可以拆成离线核对和实时核对。
离线核对一般就是把生产数据库的数据定时清洗到离线库（一般还可以分为天表和小时表）。
实时核对一般就是监听数据库的binlog，当数据有变动时，延时几秒后请求双方系统的查询接口，查到数据后进行核对。

技术方案实现

数据库设计

支付系统涉及多张核心表，包括支付订单表、支付流水表、退款表等：

支付订单表（payment_order）


sql

CREATE TABLE `payment_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `payment_order_no` varchar(32) NOT NULL COMMENT '支付订单号',
  `business_order_no` varchar(32) NOT NULL COMMENT '业务订单号',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `amount` bigint(20) NOT NULL COMMENT '支付金额（分）',
  `pay_amount` bigint(20) NOT NULL COMMENT '实付金额（分）',
  `discount_amount` bigint(20) DEFAULT '0' COMMENT '优惠金额（分）',
  `payment_channel` varchar(16) NOT NULL COMMENT '支付渠道：ALIPAY、WECHAT、UNIONPAY',
  `payment_method` varchar(16) NOT NULL COMMENT '支付方式：APP、H5、PC、JSAPI',
  `payment_status` varchar(16) NOT NULL COMMENT '支付状态',
  `expire_time` datetime NOT NULL COMMENT '支付过期时间',
  `pay_time` datetime DEFAULT NULL COMMENT '支付时间',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_payment_order_no` (`payment_order_no`),
  KEY `idx_business_order_no` (`business_order_no`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='支付订单表';

支付流水表（payment_flow）


sql

CREATE TABLE `payment_flow` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `payment_order_no` varchar(32) NOT NULL COMMENT '支付订单号',
  `flow_no` varchar(32) NOT NULL COMMENT '支付流水号',
  `channel_flow_no` varchar(64) DEFAULT NULL COMMENT '渠道流水号',
  `request_params` text COMMENT '请求参数',
  `response_result` text COMMENT '响应结果',
  `flow_status` varchar(16) NOT NULL COMMENT '流水状态：SUCCESS、FAILED',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_flow_no` (`flow_no`),
  KEY `idx_payment_order_no` (`payment_order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='支付流水表';

分库分表

当数据量大的时间，分库分表是再所难免的。

一个经典的面试题是：如果分了100张表，按商户来分表，还是按商户订单号来分表？如果按商户分表怎么解决各表流水数据量平衡问题？如果是按商户订单号来分表，商户想按时间段查询怎么办？

解法有很多种。一种典型的解法，就是线上数据库按商户订单号分表，同时有一个离线库冗余一份按商户号分表的数据，甚至直接使用离线数据平台的能力，把商户的按时间段查询需求从在线库剥离出来。

支付状态机设计

状态机，也称为有限状态机（FSM, Finite State Machine），是一种行为模型，由一组定义良好的状态、状态之间的转换规则和一个初始状态组成。它根据当前的状态和输入的事件，从一个状态转移到另一个状态。

支付状态机管理支付订单的完整生命周期，确保状态流转的正确性：


java

public enum PaymentStatus {
    // 待支付
    PENDING,
    // 支付中
    PROCESSING,
    // 支付成功
    SUCCESS,
    // 支付失败
    FAILED,
    // 支付关闭
    CLOSED,
    // 退款中
    REFUNDING,
    // 部分退款
    PARTIAL_REFUND,
    // 全额退款
    FULL_REFUND
}

状态流转规则：

PENDING → PROCESSING：用户发起支付请求
PROCESSING → SUCCESS：支付成功
PROCESSING → FAILED：支付失败
PENDING → CLOSED：订单超时关闭
SUCCESS → REFUNDING：发起退款
REFUNDING → PARTIAL_REFUND/FULL_REFUND：退款完成

常见代码实现误区

经常看到工作几年的同事实现状态机时，仍然使用if else或switch case来写。这是不对的，会让实现变得复杂，且容易出现问题。

甚至直接在订单的领域模型里面使用String来定义，而不是把状态模式封装单独的类。

还有就是直接调用领域模型更新状态，而不是通过事件来驱动。

支付网关设计

支付网关作为统一入口，负责路由决策、参数组装和协议转换：


java

@Service
public class PaymentGatewayService {
    
    @Autowired
    private Map<String, PaymentChannel> paymentChannelMap;
    
    /**
     * 统一支付接口
     */
    public PaymentResponse pay(PaymentRequest request) {
        // 1. 参数校验
        validatePaymentRequest(request);
        
        // 2. 风控检查
        riskControlCheck(request);
        
        // 3. 选择支付渠道
        PaymentChannel channel = selectPaymentChannel(request);
        
        // 4. 生成支付订单
        PaymentOrder paymentOrder = createPaymentOrder(request);
        
        // 5. 调用支付渠道
        PaymentResponse response = channel.pay(buildChannelRequest(paymentOrder));
        
        // 6. 记录支付流水
        savePaymentFlow(paymentOrder, response);
        
        return buildPaymentResponse(response);
    }
    
    /**
     * 支付渠道路由
     */
    private PaymentChannel selectPaymentChannel(PaymentRequest request) {
        String channelKey = request.getPaymentChannel() + "_" + request.getPaymentMethod();
        PaymentChannel channel = paymentChannelMap.get(channelKey);
        if (channel == null) {
            throw new PaymentException("不支持的支付方式");
        }
        return channel;
    }
}

支付渠道适配

通过策略模式实现多支付渠道的适配，便于扩展和维护：


java

public interface PaymentChannel {
    
    /**
     * 支付
     */
    PaymentResponse pay(PaymentChannelRequest request);
    
    /**
     * 退款
     */
    RefundResponse refund(RefundRequest request);
    
    /**
     * 查询支付结果
     */
    QueryResponse query(QueryRequest request);
    
    /**
     * 处理异步通知
     */
    NotifyResponse handleNotify(NotifyRequest request);
}

@Service("ALIPAY_APP")
public class AlipayAppChannel implements PaymentChannel {
    
    @Override
    public PaymentResponse pay(PaymentChannelRequest request) {
        // 构造支付宝APP支付参数
        AlipayTradeAppPayRequest alipayRequest = new AlipayTradeAppPayRequest();
        // 设置业务参数
        // 调用支付宝SDK
        // 返回支付参数
        return buildPaymentResponse(alipayResponse);
    }
    
    @Override
    public NotifyResponse handleNotify(NotifyRequest request) {
        // 验证签名
        if (!verifySignature(request)) {
            return NotifyResponse.fail("签名验证失败");
        }
        
        // 处理支付结果
        processPaymentResult(request);
        
        return NotifyResponse.success();
    }
}

支付幂等性保障

幂等是针对重复请求的，支付系统一般会面临以下几个重复请求的场景：

用户多次点击支付按钮：在网络较差或系统过载情况下，用户由于不确定交易是否完成而重复点击。
自动重试机制：系统在超时或失败时重试请求，可能导致同一支付多次尝试。
网络数据包重复：数据包在网络传输过程中，复制出了多份，导致支付平台收到多次一模一样的请求。
异常恢复：在系统升级或崩溃后，未决事务需要根据已有记录恢复和完成。内部系统重发操作。

幂等解决方案

所谓业务幂等，就是由各域自己把唯一性的交易ID作为数据库唯一索引，这样可以保证不会重复处理。

在数据库前面可以加一层缓存来提高性能，但是缓存只用于查询，查到数据认为就返回幂等成功，但是但不到，需要尝试插入数据库，插入成功后再刷新数据到缓存。

为什么要使用数据库的唯一索引做为兜底?

是因为缓存是可能失效的。

在面临时经常有同学只回答到“使用redis分布式锁来实现幂等”，这是不对的。因为缓存有可能失效，分布式锁只是用于防并发操作的一种手段，无法根本性解决幂等问题，幂等一定是依赖数据库的唯一索引解决。

支付接口必须保证幂等性，防止重复支付：


java

@Service
public class PaymentIdempotentService {
    
    @Autowired
    private RedisTemplate redisTemplate;
    
    /**
     * 支付幂等性校验
     */
    public boolean checkIdempotent(String paymentOrderNo, String idempotentKey) {
        String redisKey = "payment:idempotent:" + paymentOrderNo;
        
        // 使用Lua脚本保证原子性
        String luaScript = 
            "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "    return 1 " +
            "else " +
            "    redis.call('set', KEYS[1], ARGV[1], 'EX', 3600) " +
            "    return 0 " +
            "end";
        
        Long result = redisTemplate.execute(
            new DefaultRedisScript<>(luaScript, Long.class),
            Collections.singletonList(redisKey),
            idempotentKey
        );
        
        return result == 1;
    }
}

大部分简单的支付系统只要有业务幂等基本也够用了。

金额处理规范

对于研发经验不足的团队而言，经常会犯以下几种错误：

没有定义统一的Money类，各系统间使用BigDecimal、double、long等数据类型进行金额处理及存储。
定义了统一的Money类，但是写代码时不严格遵守，仍然有些代码使用BigDecimal、double、long等数据类型进行金额处理。
手动对金额进行加、减、乘、除运算，单位（元与分）换算。

带来的后果，通常就是资金损失，再细化一下，最常见的情况有下面3种：

手动做单位换算导致金额被放大或缩小100倍。

比如大家规定传的是元，但是其中有位同学忘记了，以为传的是分，外部渠道要求传元，就手动乘以100。或者反过来。

还有一种情况，部分币种比如日元最小单元就是元，假如系统约定传的是分，外部渠道要求传元，就可能在网关处理时手动乘以100。
1分钱归属问题。比如结算给商家，或计算手续费时，碰到除不尽时，使用四舍五入，还是向零舍入，还是银行家舍入？这取决于财务策略。
精度丢失。在大金额时，double有可能会有精度丢失问题。

最佳实践：

制定适用于公司业务的Money类来统一处理金额。
在入口网关接收到请求后，就转换为Money类。
所有内部应用的金额处理，强制全部使用Money类运算、传输，禁止自己手动加减乘除、单位换算（比如元到分）。
数据库使用 DECIMAL 类型保存，保存单位为元。
在出口网关外发时，再根据外部接口文档要求，转换成使用指定的单位。有些是元，有些是分（最小货币单位）

业务ID生成规则

数据库一般都会设计一个自增ID作为主键，同时还会设计一个能唯一标识一笔业务的ID，这就是所谓的业务ID（也称业务键）。比如收单域的收单单号。

也有人采用所谓雪花算法，但其实不适用于支付场景。

下面以32位的支付系统业务ID生成为例说明。实际应用时可灵活调整。

第1-8位：日期。通过单号一眼能看出是哪天的交易。
第9位：数据版本。用于单据号的升级。
第10位：系统版本。用于内部系统版本升级，尤其是不兼容升级的时候，老业务使用老的系统处理，新业务使用新系统处理。
第11-13位：系统标识码。支付系统内部每个域分配一段，由各域自行再分配给内部系统。比如010是收单核心，012是结算核心。
第14-15位：业务标识位。由各域内部定，比如00-15代表支付类业务，01支付，02预授权，03请款等。
第16-17位：机房位。用于全球化部署。
第18-19位：用户分库位。支持百库。
第20-21位：用户分表位。支持百表。
第22位：预发生产标识位。比如0代表预发环境，1代表生产环境。
第23-24位：预留。各域根据实际情况扩展使用。
第24-32位：序列号空间。一亿规模，循环使用。一个机房一天一亿笔是很大的规模了。如果不够用，可以扩展到第24位，到十亿规模。

日志规范

只要在公司写过代码，就一定打印过日志，但经常发现一些工作多年的工程师打印的日志也是乱七八糟的。我曾经在一家头部互联网公司接手过一个上线一年多的业务，相关日志一开始就没有设计好，导致很多监控无法实现，出了线上问题也不知道，最后只能安排工程师返工改造相关的日志。

我们要明白日志是用来做什么的。只是先弄明白做事的目的，我们才能更好把事情做对。在我看来，日志有两个核心的作用：

监控，诊断系统或业务是否存在问题；
排查问题。

对于监控而言，我们需要知道几个核心的数据：业务/接口的请求量、成功量、成功率、耗时，系统返回码、业务返回码，异常信息等。对于排查问题而言，我们需要有出入参、中间处理数据的上下文、报错的上下文等。

接下来，基于上面的分析，我们就清楚我们应该有几种日志：

接口摘要日志。监控接口的请求量、成功量、耗时、返回码等。使用固定格式，需要打印：时间、接口名称、结果（成功/失败)、返回码、耗时等基本信息就足够。
业务摘要日志。监控业务的请求量、成功量、核心业务信息、返回码等。使用固定格式，需要打印：时间、业务类型、上一步状态、当前状态、返回码、核心业务信息（不同业务有不同的核心业务信息，比如流入，就有支付金额/退款金额，卡品牌，卡BIN等)。
详细日志。用于排查问题，不用于监控。格式不固定。主要包括时间、接口、入参、出参、中间处理数据输入、异常的堆栈信息等。
系统异常日志。同时用于监控。格式固定。需要打印：时间、错误码、错误信息、堆栈信息等。

异步通知处理

支付渠道的异步通知是确认支付结果的最终依据：


java

@Service
public class PaymentNotifyService {
    
    /**
     * 处理支付通知
     */
    @Transactional(rollbackFor = Exception.class)
    public void processNotify(PaymentNotifyDTO notifyDTO) {
        // 1. 验证通知合法性
        if (!verifyNotify(notifyDTO)) {
            throw new PaymentException("通知验证失败");
        }
        
        // 2. 查询支付订单
        PaymentOrder paymentOrder = paymentOrderDAO.selectByOrderNo(notifyDTO.getPaymentOrderNo());
        if (paymentOrder == null) {
            throw new PaymentException("支付订单不存在");
        }
        
        // 3. 检查订单状态，避免重复处理
        if (paymentOrder.getPaymentStatus() == PaymentStatus.SUCCESS) {
            return;
        }
        
        // 4. 更新支付订单状态
        updatePaymentOrderStatus(paymentOrder, notifyDTO);
        
        // 5. 更新业务订单状态
        updateBusinessOrderStatus(paymentOrder.getBusinessOrderNo());
        
        // 6. 记录通知日志
        saveNotifyLog(notifyDTO);
    }
}

分布式事务解决方案

支付系统涉及多个服务的数据一致性，需要采用合适的分布式事务方案：

基于本地消息表的最终一致性：


java

@Service
public class PaymentTransactionService {
    
    /**
     * 支付成功后的业务处理
     */
    @Transactional(rollbackFor = Exception.class)
    public void handlePaymentSuccess(String paymentOrderNo) {
        // 1. 更新支付订单状态
        updatePaymentOrder(paymentOrderNo, PaymentStatus.SUCCESS);
        
        // 2. 插入本地消息表
        EventMessage message = buildOrderPaidMessage(paymentOrderNo);
        eventMessageDAO.insert(message);
        
        // 3. 更新积分、库存等其他业务状态
        updateRelatedBusiness(paymentOrderNo);
    }
    
    /**
     * 消息补偿任务
     */
    @Scheduled(fixedDelay = 30000)
    public void compensateMessages() {
        List<EventMessage> pendingMessages = eventMessageDAO.selectPendingMessages();
        for (EventMessage message : pendingMessages) {
            try {
                // 重新投递消息
                eventPublisher.publishEvent(message);
                // 更新消息状态为已发送
                eventMessageDAO.updateStatus(message.getId(), MessageStatus.SENT);
            } catch (Exception e) {
                log.error("消息补偿失败: {}", message.getId(), e);
            }
        }
    }
}

为什么有些企业不用分布式事务？

分布式事务是个好东西，但是复杂度也高，还经常出现所谓的事务悬挂问题，且虽然各家都号称简单易用，对业务代码侵入少，但事实并非如此。

所以我个人更倾向于避免使用分布式事务解决方案，而是采用最终一致性来解决。对大部分中小公司来说，最终一致性已经够用。

支付对账系统

每日对账是保障资金安全的重要手段：


java

@Service
public class ReconciliationService {
    
    /**
     * 执行对账
     */
    public void executeReconciliation(Date checkDate) {
        // 1. 下载渠道对账单
        List<ChannelBill> channelBills = downloadChannelBills(checkDate);
        
        // 2. 查询系统支付记录
        List<PaymentOrder> systemOrders = getSystemPaymentOrders(checkDate);
        
        // 3. 对账匹配
        ReconciliationResult result = matchBills(channelBills, systemOrders);
        
        // 4. 处理差异订单
        handleDifferences(result.getDifferences());
        
        // 5. 生成对账报告
        generateReport(result);
    }
    
    /**
     * 账单匹配
     */
    private ReconciliationResult matchBills(List<ChannelBill> channelBills, 
                                          List<PaymentOrder> systemOrders) {
        ReconciliationResult result = new ReconciliationResult();
        
        // 以渠道账单为准进行匹配
        for (ChannelBill channelBill : channelBills) {
            PaymentOrder systemOrder = findSystemOrder(systemOrders, channelBill);
            if (systemOrder == null) {
                // 渠道有系统无 - 长款
                result.addDifference(ReconciliationDiff.extra(channelBill));
            } else if (!amountEquals(channelBill, systemOrder)) {
                // 金额不一致
                result.addDifference(ReconciliationDiff.amountMismatch(channelBill, systemOrder));
            } else {
                // 匹配成功
                result.addMatch(channelBill, systemOrder);
            }
        }
        
        // 检查系统有渠道无 - 短款
        for (PaymentOrder systemOrder : systemOrders) {
            if (!isMatched(systemOrder)) {
                result.addDifference(ReconciliationDiff.missing(systemOrder));
            }
        }
        
        return result;
    }
}

支付渠道降级策略

服务高可用设计，当某个支付渠道出现故障时，自动切换到备用渠道：


java

@Service
public class PaymentCircuitBreaker {
    
    private Map<String, CircuitBreakerStats> statsMap = new ConcurrentHashMap<>();
    
    /**
     * 获取可用的支付渠道
     */
    public List<String> getAvailableChannels(PaymentRequest request) {
        return statsMap.entrySet().stream()
            .filter(entry -> isChannelAvailable(entry.getKey(), entry.getValue()))
            .map(Map.Entry::getKey)
            .sorted(Comparator.comparing(this::getChannelPriority))
            .collect(Collectors.toList());
    }
    
    /**
     * 判断渠道是否可用
     */
    private boolean isChannelAvailable(String channel, CircuitBreakerStats stats) {
        // 基于失败率、超时率等指标判断
        return stats.getFailureRate() < 0.5  // 失败率低于50%
            && stats.getTimeoutRate() < 0.3  // 超时率低于30%
            && !stats.isCircuitOpen();       // 断路器未打开
    }
    
    /**
     * 记录调用结果
     */
    public void recordCallResult(String channel, boolean success, long cost) {
        CircuitBreakerStats stats = statsMap.computeIfAbsent(
            channel, k -> new CircuitBreakerStats()
        );
        stats.recordCall(success, cost);
    }
}

数据一致性保障

通过多种机制保障支付数据的一致性：


java

@Component
public class PaymentConsistencyChecker {
    
    /**
     * 定时检查支付状态不一致的订单
     */
    @Scheduled(cron = "0 */5 * * * ?")
    public void checkInconsistentOrders() {
        // 查询支付中状态超过一定时间的订单
        List<PaymentOrder> processingOrders = 
            paymentOrderDAO.selectLongTimeProcessingOrders();
        
        for (PaymentOrder order : processingOrders) {
            try {
                // 主动查询支付渠道确认状态
                QueryResponse response = paymentChannel.query(
                    new QueryRequest(order.getPaymentOrderNo())
                );
                
                if (response.isSuccess()) {
                    // 更新为成功状态
                    updatePaymentSuccess(order, response);
                } else if (response.isFailed()) {
                    // 更新为失败状态
                    updatePaymentFailed(order, response);
                }
                // 仍然处理中则忽略
            } catch (Exception e) {
                log.error("支付状态检查失败: {}", order.getPaymentOrderNo(), e);
            }
        }
    }
}

监控与告警

支付系统需要完善的监控体系来保障稳定性：

关键监控指标：

支付成功率：各渠道支付成功比率
支付耗时：支付各环节耗时分布
失败原因分布：各类失败原因的统计
渠道可用性：各支付渠道的健康状态
资金一致性：系统与渠道资金差异告警


java

@Component
public class PaymentMetrics {
    
    private final MeterRegistry meterRegistry;
    
    public void recordPaymentResult(String channel, boolean success, long cost) {
        // 记录支付结果
        Counter.builder("payment.result")
            .tag("channel", channel)
            .tag("success", String.valueOf(success))
            .register(meterRegistry)
            .increment();
        
        // 记录支付耗时
        Timer.builder("payment.cost")
            .tag("channel", channel)
            .register(meterRegistry)
            .record(cost, TimeUnit.MILLISECONDS);
    }
}

支付安全

支付安全核心关注点

支付安全是一个很大的范畴，但我们一般只需要重点关注以下几个核心点就够：

1. 敏感信息安全存储。

对个人和商户/渠道的敏感信息进行安全存储。

个人敏感信息包括身份证信息、支付卡明文数据和密码等，而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等。

2. 交易信息安全传输。

确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性。

3. 交易信息的防篡改与防抵赖。 确保交易信息的完整性和真实性，防止交易信息被篡改或者被抵赖。一笔典型的交易，通常涉及到用户、商户、支付机构、银行四方，确保各方发出的信息没有被篡改也无法被抵赖。

4. 欺诈交易防范。 识别并防止欺诈交易，包括套现、洗钱等违规操作，以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责。

5. 服务可用性。 防范DDoS攻击，确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段，及时发现并应对可能的DDoS攻击，保障支付服务的正常进行。

极简支付安全

支付安全是一个综合性的系统工程，除了技术手段外，还需要建立健全的安全制度和合规制度，而后两者通常被大部分人所忽略。

下图是一个极简版的支付安全大图，包含了支付安全需要考虑的核心要点。

制度是基础。

哪种场景下需要加密存储，加密需要使用什么算法，密钥长度最少需要多少位，哪些场景下需要做签名验签，这些都是制度就明确了的。制度通常分为行业制度和内部安全制度。行业制度通常是国家层面制定的法律法规，比如《网络安全法》、《支付业务管理办法》等。内部安全制度通常是公司根据自身的业务和能力建立的制度，小公司可能就没有。

技术手段主要围绕四个目标：

1）敏感数据安全存储。

2）交易安全传输。

3）交易的完整性和真实性。

4）交易的合法性（无欺诈）。

对应的技术手段有：

敏感信息安全存储：采用加密技术对个人和商户/渠道的敏感信息进行加密存储，限制敏感信息的访问权限，防止未授权的访问和泄露。
交易信息安全传输：使用安全套接字层（SSL）或传输层安全性协议（TLS）等加密技术，确保数据在传输过程中的机密性和完整性。
交易的完整性和真实性：采用数字签名技术和身份认证技术确保交易信息的完整性和真实性，对交易信息进行记录和审计，建立可追溯的交易日志，以应对可能出现的交易篡改或抵赖情况。
防范欺诈交易：通过支付风控系统，及时识别和阻止可疑交易行为。
服务可用性：部署流量清洗设备和入侵检测系统，及时发现并阻止恶意流量，确保支付系统的稳定运行和服务可用性，抵御DDoS攻击。

总结

支付系统作为电商平台的核心组件，其设计需要重点关注以下几个方面：

高可用性：通过多渠道冗余、断路器降级、异步化处理等手段保障系统可用性
数据一致性：采用分布式事务、最终一致性、对账补偿等机制确保资金安全
安全性：加强身份验证、参数签名、风险控制等安全措施
扩展性：通过模块化设计、策略模式等支持新支付渠道的快速接入
可观测性：建立完善的监控、日志、告警体系，快速发现和定位问题

一个健壮的支付系统不仅需要技术上的严谨设计，还需要业务流程上的周密考虑。只有在技术和业务的共同保障下，才能为用户提供安全、便捷、稳定的支付体验，为平台创造更大的商业价值。

目录

支付