聚合支付数据库设计：订单、商户、通道表结构怎么建？附字段清单

商户主体表（merchant）

商户账户表（merchant_account）

拆成两张表最大的好处是灵活性。一个商户主体，可能同时签约了微信、支付宝两条线，费率不一样、结算账户不一样，你用一个账户表就存不下，用 account_type 字段硬塞，又变成了一张大杂烩表。

另外提醒一句：密钥和身份证、银行卡这些敏感字段，必须加密存储，不能明文落库。数据库一旦泄露，明文密钥等于把商户的钱直接交给别人。加密用 AES，密钥放配置文件或专门的密钥管理服务里，别和数据库放一起。

通道表：聚合支付最核心、也最容易被低估的一张表

什么是聚合支付？本质就是一套系统对接了多家支付通道，给商户提供一个统一接口。所以通道表是聚合支付系统的命脉——通道管理不好，聚合就是一句空话。

通道表要解决三个问题：第一，每条通道的对接参数怎么存；第二，通道现在能不能用（状态）；第三，同一笔支付走哪条通道（路由）。

字段清单（通道表 channel）

这里最关键的一列是 config。通道的对接参数（appid、商户号、密钥、网关地址）每家都不一样，你不可能为每一家通道都建一张表，那样表会爆炸。用 TEXT 存 JSON，把变的部分都塞进 config，表结构保持稳定，加新通道只加一行数据、不改表结构。

然后是 weight、error_count、daily_limit 这三个字段，它们共同构成了通道的健康度和路由。一条通道连续失败几次，error_count 累加，达到阈值就自动降权甚至停用；每天交易额到 daily_limit 了，路由就跳过它。这套机制不做，一条通道挂了，你的所有单子都堵在它上面，用户付不出去，你却浑然不知。

通道和支付方式之间，是典型的多对多关系：一条通道可能同时支持支付宝和微信，一种支付方式又可能有多条通道可选。这个关系可以单独建一张 channel_pay_type 关联表，也可以像我上面那样用 pay_types 字段逗号分隔。数据量小的时候用逗号分隔够用，数据量大、要频繁按支付方式查通道，就拆关联表。

两张大多数人漏掉的表：流水表和对账表

订单、商户、通道三张表是基础，但只有这三张表，你的支付系统是"能跑但不敢对账"的状态。真正让系统可靠的，是下面这两张。

资金流水表（fund_flow）

账户余额的每一次变动，都必须有一条流水记录。这个原则叫"账实相符"——余额表上的数字，永远等于流水表的汇总，任何一笔对不上，就能定位到具体哪条流水有问题。

核心字段：

注意 balance_after 这个字段。很多人只记变动金额，不记变动后的余额。但你要对账、要审计，光有变动金额不够，还必须知道每一笔流水发生之后，余额变成了多少。这个字段让流水表可以按时间顺序"重放"出任意时刻的余额，是财务对账和争议处理的关键证据。

对账表（reconciliation）

对账表的用途是：把平台的订单记录，和通道方的账单文件（通常是通道提供的对账单）做比对，找出不一致的单子。

核心字段：

对账的核心逻辑就一句话：平台有通道没有、通道有平台没有、两边都有但金额对不上，这三种情况都要记下来。每天跑一次对账任务，把差异单写进这张表，人工或自动处理。没有这张表，你的账就是"看起来对，但没人知道到底对不对"。

三个能直接抄的建表语句

下面给你三张核心表的完整建表 SQL，用的 MySQL 8.0 语法，字段名和上面清单一一对应。你可以直接拿去改。

-- 支付订单表
CREATE TABLE pay_order (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL COMMENT '支付订单号',
  out_trade_no VARCHAR(64) NOT NULL COMMENT '商户订单号',
  merchant_id BIGINT NOT NULL COMMENT '商户ID',
  channel_id BIGINT NOT NULL DEFAULT 0 COMMENT '通道ID',
  pay_type VARCHAR(16) NOT NULL COMMENT '支付方式',
  amount BIGINT NOT NULL COMMENT '金额(分)',
  fee BIGINT NOT NULL DEFAULT 0 COMMENT '手续费(分)',
  real_amount BIGINT NOT NULL DEFAULT 0 COMMENT '到账金额(分)',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '状态',
  notify_url VARCHAR(255) NOT NULL DEFAULT '' COMMENT '异步通知地址',
  return_url VARCHAR(255) NOT NULL DEFAULT '' COMMENT '同步跳转地址',
  client_ip VARCHAR(45) NOT NULL DEFAULT '' COMMENT '下单IP',
  expire_time DATETIME NOT NULL COMMENT '过期时间',
  paid_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_order_no (order_no),
  KEY idx_merchant_out (merchant_id, out_trade_no),
  KEY idx_status_expire (status, expire_time),
  KEY idx_create_time (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='支付订单表';

-- 商户账户表（主体表略，账户表更关键）
CREATE TABLE merchant_account (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  merchant_id BIGINT NOT NULL COMMENT '商户主体ID',
  api_key VARCHAR(64) NOT NULL COMMENT '接口密钥(加密)',
  secret_key VARCHAR(64) NOT NULL COMMENT '签名密钥(加密)',
  rate DECIMAL(6,4) NOT NULL DEFAULT 0.0038 COMMENT '商户费率',
  balance BIGINT NOT NULL DEFAULT 0 COMMENT '余额(分)',
  frozen_amount BIGINT NOT NULL DEFAULT 0 COMMENT '冻结金额(分)',
  settle_type TINYINT NOT NULL DEFAULT 1 COMMENT '结算方式',
  settle_account VARCHAR(255) NOT NULL DEFAULT '' COMMENT '结算账户(加密)',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '账户状态',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  KEY idx_merchant (merchant_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商户账户表';

-- 通道表
CREATE TABLE channel (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  channel_no VARCHAR(32) NOT NULL COMMENT '通道编号',
  name VARCHAR(64) NOT NULL DEFAULT '' COMMENT '通道名称',
  provider VARCHAR(32) NOT NULL DEFAULT '' COMMENT '提供方',
  pay_types VARCHAR(128) NOT NULL DEFAULT '' COMMENT '支持的支付方式',
  config TEXT COMMENT '通道配置(JSON)',
  rate DECIMAL(6,4) NOT NULL DEFAULT 0.0038 COMMENT '成本费率',
  weight INT NOT NULL DEFAULT 100 COMMENT '路由权重',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '状态',
  daily_limit BIGINT NOT NULL DEFAULT 0 COMMENT '单日限额(分)',
  daily_amount BIGINT NOT NULL DEFAULT 0 COMMENT '今日已交易(分)',
  last_error_time DATETIME DEFAULT NULL COMMENT '最近失败时间',
  error_count INT NOT NULL DEFAULT 0 COMMENT '连续失败次数',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  UNIQUE KEY uk_channel_no (channel_no),
  KEY idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='支付通道表';

最后说几个容易忽略的细节

表结构设计完，还有几个细节，做的时候不注意，上线后会慢慢变成坑。

第一，金额全部用 BIGINT 存分，展示时除以 100。这是支付系统的铁律。有人图省事用 DECIMAL(10,2)，小数运算在 Java、PHP 里一样有精度问题，除非你全程用 BigDecimal 或字符串运算，否则迟早出那 0.03 元的账。用整数分，从根上杜绝这个问题。

第二，索引要跟着查询走，别乱建。支付订单表最常见的查询是"按商户号 + 商户订单号查单"和"按状态 + 过期时间扫超时单"，所以上面的 SQL 里我建了 idx_merchant_out 和 idx_status_expire 两个联合索引。索引不是越多越好，建错了反而拖慢写入。

第三，订单表数据量大了一定要分表。支付订单是高频写入的表，单表几千万行之后，查询和写入都会明显变慢。常见的做法是按月分表，或者按商户 ID 取模分库分表。这个可以晚点做，但表结构一开始就要预留好，别让 order_no 和业务逻辑强耦合，否则将来拆表时哭都来不及。

第四，敏感字段加密、密钥和数据库分离、余额变动必走流水。这三条是支付系统的底线，任何一条做不到，系统都不算合格。支付系统的数据库，第一原则从来不是"能用"，而是"出事能查、能追、能赔"。

把这套表结构搭起来，你再去对账、做退款、切通道，会发现之前那些"怎么都对不上""状态乱跳""通道挂了不知道"的问题，大半都是表结构没设计好埋下的。表结构是地基，地基打歪了，上面盖什么都晃。