老规矩，先带大家通俗简单理解一下，然后再深入详解

大型电商平台的支付功能流程大致如下：

1. 用户选商品下单：用户在电商平台选好商品，填好收货地址等信息后，点击 “支付” 按钮，这就相当于告诉平台自己要付钱买东西了。
2. 平台处理支付请求：平台收到支付请求后，先看看订单有没有问题，比如商品是否有货、价格对不对等。然后生成一个唯一的支付流水号，就像你去银行办事给你的那个单号一样，用来标识这笔支付。同时，在订单表中把支付状态设为 “未支付”。
3. 用户选支付方式：平台会展示各种支付方式让用户选，比如支付宝、微信支付等。用户选好后，平台就把相关支付信息发给对应的支付平台。
4. 支付平台处理：支付平台收到请求后，会让用户输入密码或者进行指纹、面部识别等验证方式。验证通过后，就从用户的账户里扣钱。扣钱成功后，支付平台会给电商平台返回一个支付成功的消息，这个消息里就包含了之前生成的支付流水号。
5. 电商平台确认支付结果：电商平台收到支付成功的消息后，会根据支付流水号去查订单表，看看这笔支付对应的是哪个订单。然后再检查一下订单的支付状态，如果是 “未支付”，就把订单状态改成 “已支付”，同时扣减商品库存，给商家增加相应的收入余额等。如果订单状态已经是 “已支付” 了，那就说明是重复回调，直接忽略就行。
6. 通知用户：最后，电商平台会给用户显示支付成功的页面，或者给用户发一条支付成功的短信、推送等，告诉用户钱已经付好了，商家会尽快发货。

详解

大型电商平台的支付功能流程，核心是 **“安全、稳定、防重复、可追溯”**，会涉及用户端、电商业务系统、支付网关、第三方支付平台（微信 / 支付宝等）、银行 / 清算机构等多个角色，整体可拆分为「支付发起」「支付处理」「回调通知」「订单收尾」4 个核心阶段，具体流程如下：

一、阶段 1：用户发起支付（前端→电商业务系统）

这是用户触发支付的起点，核心是确认 “要付什么钱”，并生成唯一支付凭证。

1. 用户操作：用户在电商 APP / 网页的 “订单确认页” 点击「去支付」，选择支付方式（微信 / 支付宝 / 银行卡等）。
2. 订单信息校验：
   • 电商业务系统（如订单服务）先校验订单状态：必须是「待支付」（避免重复发起已支付 / 已取消订单）。
   • 校验订单金额、商品库存（防止支付时库存已不足）、用户信息（如是否登录、账号是否正常）。
3. 生成支付单：
   • 校验通过后，生成唯一支付单号（如PAY20240520123456789），与订单号绑定（一个订单可能对应多个支付单，如分多次支付）。
   • 支付单信息存入数据库（含订单号、支付金额、支付方式、支付状态INIT（初始化）、创建时间）。
4. 请求支付参数：电商业务系统调用「支付网关」，传递支付单号、金额、支付方式、回调地址（支付平台处理完后通知的地址）等信息，获取 “支付跳转参数”。

二、阶段 2：支付处理（电商→支付网关→第三方支付→用户）

这一阶段是 “用户给钱” 的核心，需要对接第三方支付平台，引导用户完成支付操作。

1. 支付网关转发请求：
   • 支付网关是电商与第三方支付的 “中间层”，统一封装不同支付平台的接口（避免业务系统直接对接多个平台）。
   • 网关根据 “支付方式”，将请求转发到对应第三方平台（如微信支付的「统一下单接口」、支付宝的「电脑网站支付接口」）。
2. 第三方支付平台处理：
   • 第三方平台（如微信支付）校验请求合法性（签名是否正确、商户是否已备案），生成 “支付凭证”：
     • 若是 APP 支付：返回prepay_id（供前端调起支付弹窗）；
     • 若是 H5 / 网页支付：返回支付跳转 URL（引导用户跳转到第三方支付页面）；
     • 若是扫码支付：返回支付二维码图片链接。
3. 用户完成支付：
   • 前端拿到支付凭证后，调起支付界面（如微信支付弹窗、支付宝 H5 页面），用户输入密码 / 指纹 / 验证码完成支付。
4. 支付结果同步返回：
   • 用户支付完成后，第三方平台会通过前端同步返回 “支付结果”（如 “支付成功” 提示），但此结果仅用于前端展示，不能作为业务处理依据（可能被篡改或丢失）。

三、阶段 3：支付回调通知（第三方支付→电商支付网关→业务系统）

这是 “确认用户已付钱” 的关键，第三方支付会通过 “异步回调” 将最终支付结果通知电商系统，核心是防重复、保可靠。

1. 第三方发起回调：
   • 支付平台（如支付宝）确认用户支付成功后，会向电商系统预先提供的 “回调地址” 发送 POST 请求，携带支付流水号（第三方平台生成，如微信的transaction_id）、支付单号（电商生成的）、支付金额、支付状态等信息。
   • 为保证安全，回调请求会带 “签名”，电商系统需校验签名（防止伪造回调）。
2. 支付网关接收与校验：
   • 支付网关先校验回调的签名合法性（用第三方平台提供的密钥验证），过滤非法请求。
   • 校验 “支付金额一致性”：回调中的金额必须与电商支付单的金额一致（防止篡改金额）。
3. 分布式锁防重复处理：
   • 网关以 “支付流水号” 为 key，加分布式锁（如 Redis 锁），确保同一笔支付的回调只有一个线程处理（避免第三方因网络重试导致重复回调）。
4. 业务系统处理回调：
   • 网关将校验通过的回调信息转发给电商业务系统（如支付服务），业务系统执行核心操作：
     1. 查支付单：根据支付单号，确认支付单状态为「INIT」（未处理）；
     2. 更新状态：将支付单状态改为「PAID」（已支付），记录第三方支付流水号、支付完成时间；
     3. 执行业务逻辑：扣减商品库存（如从「锁定库存」改为「已售」）、增加用户余额（若用余额支付）、生成订单物流单（若需发货）；
     4. 记录幂等日志：将支付流水号、处理结果（成功 / 失败）存入 “幂等日志表”，后续重复回调直接返回成功（避免重复处理）。
5. 回调响应确认：
   • 业务系统处理完成后，必须返回第三方平台规定的成功标识（如支付宝要求返回success字符串）。若未返回或返回错误，第三方平台会每隔一段时间重试回调（重试策略通常是 “指数退避”，如 10s、30s、1min 后重试）。

四、阶段 4：订单收尾（业务系统→用户）

支付完成后，需要同步订单状态、通知用户，并处理异常情况（如支付成功但业务处理失败）。

1. 更新订单状态：业务系统将订单状态从「待支付」改为「已支付」，并推送消息给用户（如 APP 推送、短信、站内信：“您的订单 XXX 已支付成功”）。
2. 异常处理（关键兜底）：
   • 若回调处理失败（如扣库存时数据库宕机）：业务系统会有 “定时任务”（如每 5 分钟），查询状态为「INIT」且创建时间超过 30 分钟的支付单，调用第三方支付平台的 “查询接口”（如微信的「查询订单接口」），主动获取最新支付状态，补全业务逻辑（即 “主动查单”，防止回调丢失导致的状态不一致）。
   • 若支付失败（如用户取消支付、余额不足）：定时任务查询到支付状态为「FAILED」，将订单状态改为「支付失败」，释放锁定的库存。
3. 对账（每日必做）：
   • 每天凌晨，电商系统会与第三方支付平台进行 “对账”：下载第三方的 “日账单”（含所有支付流水），与本地支付单、订单数据比对，确保金额、笔数一致，发现差异（如漏单、金额不对）则触发人工排查。

核心设计要点（保障安全与稳定）

1. 唯一性校验：支付单号（电商侧）、第三方支付流水号（平台侧）必须唯一，避免重复支付。
2. 幂等性：无论回调多少次，同一笔支付的业务逻辑（扣库存、加余额）只执行一次（靠分布式锁 + 幂等日志实现）。
3. 签名验证：所有与第三方支付的交互（发起支付、回调、查单）都要做签名校验，防止数据被篡改。
4. 异步 + 定时查单：不依赖前端同步结果，以第三方回调和主动查单为准，避免 “支付成功但业务没处理” 的问题。
5. 支付网关隔离：业务系统不直接对接第三方支付，通过网关统一管理，降低耦合，方便后续接入新支付方式（如银联、Apple Pay）。

通过这套流程，大型电商平台能确保支付过程 “不丢单、不重复、可追溯”，同时兼顾用户体验与系统稳定性。

支付流程核心模块技术设计文档

一、文档目的

明确大型电商平台支付系统的核心模块设计，确保支付流程安全、稳定、可追溯、防重复，支撑高并发场景下的订单支付需求。

二、核心模块划分

支付系统按 “职责隔离” 原则划分为 5 大核心模块，流程串联如下：

用户端 → 订单服务 → 支付服务 → 支付网关 → 第三方支付平台  
          ↓           ↓           ↓             ↓  
        订单库      支付单库     网关日志      回调通知  

三、核心模块详细设计

1. 订单服务（支付发起前置）

作用：确认订单合法性，触发支付流程。

• 核心逻辑：
  1. 用户点击 “去支付” 时，校验订单状态（必须为「待支付」）、库存锁定状态、金额正确性。
  2. 生成唯一「订单号」（如 ORD20241011XXXX），并调用支付服务创建支付单。
• 数据存储：订单表（t_order）关键字段：

  字段名	说明
  order_id	订单唯一标识
  user_id	用户 ID
  total_amount	订单总金额（分）
  status	订单状态（待支付 / 已支付 / 已取消）
  lock_stock	锁定库存数量

2. 支付服务（核心业务处理）

作用：管理支付单生命周期，处理支付结果。

• 核心功能：

  1. 创建支付单：
     • 接收订单服务请求，生成唯一「支付单号」（如 PAY20241011XXXX），与订单号绑定。
     • 支付单状态初始化为「初始化（INIT）」，存入支付单库。
  2. 处理支付回调：
     • 接收支付网关转发的第三方支付结果，通过「分布式锁 + 状态机」防重复处理：
       • 以「第三方支付流水号」为锁键（如 lock:pay:wx123456），确保同一支付仅处理一次。
       • 校验支付单当前状态：若为「INIT」，则更新为「已支付（PAID）」，同步更新订单状态为「已支付」，扣减库存。
       • 若已为「PAID」，直接返回成功（幂等处理）。
  3. 主动查单：
     • 定时任务（每 5 分钟）查询「INIT」状态且超过 30 分钟的支付单，调用第三方支付平台 “查单接口” 补全状态（防止回调丢失）。

• 数据存储：支付单表（t_payment）关键字段：

  字段名	说明
  payment_id	支付单号（唯一）
  order_id	关联订单号
  amount	支付金额（分）
  pay_type	支付方式（微信 / 支付宝）
  status	支付状态（INIT/PAID/FAILED）
  third_party_trade_no	第三方支付流水号

3. 支付网关（第三方对接层）

作用：统一封装第三方支付接口，隔离业务与第三方差异。

• 核心功能：
  1. 请求转发：
     • 接收支付服务的 “创建支付” 请求，根据支付方式（微信 / 支付宝）调用对应第三方接口（如微信「统一下单」、支付宝「预下单」）。
     • 统一签名生成（用第三方提供的密钥，确保请求合法性）。
  2. 回调接收与校验：
     • 暴露统一回调地址（如 https://api.xxx.com/pay/callback），接收第三方支付结果。
     • 校验回调签名（防止伪造请求）、金额一致性（回调金额需与支付单金额一致）。
  3. 日志记录：
     • 记录所有与第三方的交互日志（请求参数、响应结果、时间戳），用于问题排查与对账。

4. 第三方支付平台（外部依赖）

作用：用户完成实际支付操作的载体（如微信支付、支付宝）。

• 核心交互：
  1. 接收支付网关的 “创建支付” 请求，返回支付凭证（如微信 prepay_id、支付宝支付链接）。
  2. 用户在第三方平台完成支付（输入密码 / 指纹）后，异步回调电商支付网关，传递支付结果（含流水号、金额、状态）。

5. 幂等与安全保障（跨模块共性设计）

• 幂等性：
  • 支付单号 + 第三方流水号唯一：确保同一笔支付不会被重复处理。
  • 幂等日志表（t_idempotent_log）：记录已处理的支付流水，重复回调直接返回成功。
• 安全性：
  • 签名校验：所有接口交互必须验证签名（防止数据篡改）。
  • 分布式锁：Redis 实现，防止并发处理同一支付单（锁超时设为 5 秒，避免死锁）。
  • 敏感数据加密：用户支付信息（如银行卡号）传输与存储需加密（AES 算法）。

四、核心流程时序图

用户 → 订单服务：请求支付  
订单服务 → 支付服务：创建支付单（生成payment_id）  
支付服务 → 支付网关：申请支付参数（含payment_id、金额、支付方式）  
支付网关 → 第三方支付：调用统一下单接口  
第三方支付 → 支付网关：返回支付凭证（如prepay_id）  
支付网关 → 支付服务 → 用户：返回支付链接/二维码  
用户 → 第三方支付：完成支付（输入密码）  
第三方支付 → 支付网关：异步回调支付结果（含third_party_trade_no）  
支付网关 → 支付服务：转发回调（加分布式锁）  
支付服务：更新支付单状态→更新订单→扣库存→记录幂等日志  
支付服务 → 支付网关 → 第三方支付：返回“success”确认  
支付服务 → 用户：推送支付成功通知  

五、异常处理

1. 回调丢失：通过定时任务主动查单，补全支付状态。
2. 支付超时：超过 24 小时未支付，自动取消订单，释放库存。
3. 金额不一致：回调金额与支付单金额不符时，拒绝处理并报警（人工介入）。

六、扩展说明

• 支持多支付方式：通过支付网关的 “适配器模式”，新增支付方式（如银联）只需开发对应适配器，无需修改业务逻辑。
• 高并发支持：支付服务与网关部署多实例，通过 Redis 分布式锁与数据库行锁（UPDATE ... WHERE）控制并发冲突。

此设计可满足日均百万级支付订单的处理需求，兼顾安全性与可扩展性。