统一支付系统架构设计

1. 核心模块设计

统一支付订单模块是系统架构的核心，其功能涵盖订单的创建、状态的调整以及支付方式的推荐等核心环节。每一份订单都应包含一个唯一的标识码、交易的具体金额、商品的详细信息、客户的个人信息以及订单的当前状态等必要信息。

支付渠道适配器肩负着将微信、支付宝、苹果支付等众多支付平台接口规范进行转换的关键任务。它需确保支付请求格式得以标准化，对响应内容进行有效解析，并对错误代码进行映射。同时，适配器还需采纳插件式的设计思想，以便于新支付渠道能够迅速接入并完成集成。

确保支付结果准确无误的关键在于回调机制，它具备以下功能：对签名进行验证、对订单的最新状态进行更新、触发与业务相关的通知等。在整个回调处理流程中，务必保证其具备幂等特性，从而防止重复执行。

客户端请求支付
       ↓
服务端创建订单，调用渠道下单接口
       ↓
返回客户端调起支付 SDK 参数
       ↓
客户端拉起微信/支付宝/苹果支付
       ↓
支付完成后 → 渠道回调服务端
       ↓
服务端验签、确认支付成功、修改订单状态
       ↓
发货 / 通知业务模块

2. 业务保障模块

POST /api/pay/create
{
  "product_id": "coin_100",
  "amount": 100,
  "channel": "wechat"
}

发货流程必须与支付系统分开处理，并通过消息队列技术执行异步作业。发货前，必须对支付状况进行二次确认，确保支付状态确认为“已支付但尚未发货”，然后方可启动发货流程。此外，还需详细记录发货凭证和物流跟踪信息。

POST /api/pay/apple/verify
{
  "receipt_data": "base64...",
  "order_id": "202506110001"
}

补单机制作为一种容错措施，通过周期性的任务来识别异常订单，比如那些虽已支付确认却未启动回调的订单。这一策略需包括：对初次尝试的订单立即进行重试、后续重试时采用指数退避策略、以及最后需要人工干预等不同级别的应对措施。

POST /api/pay/callback/wechat
POST /api/pay/callback/alipay

退款环节必须确保能够完成全额或部分退款的执行，并且要保证退款交易记录的完整保留。此外，还需与多种支付方式对接退款接口，以保证退款状态的实时同步。尤其需要强调的是，对于通过苹果支付产生的退款，必须利用App Store Connect平台来进行必要的处理。

GET /api/pay/status?order_id=xxx

3. 风控与对账

POST /api/pay/refund
{
  "order_id": "202506110001",
  "reason": "user_cancel",
  "amount": 100
}

风控系统需实现以下几项关键目标：首先，需对交易额度实施有效管理；其次，对交易次数设定合理上限；再者，需对异常交易行为进行准确识别，如短时间内频繁进行大额支付等。在此背景下，建议采用规则引擎技术，以便实现风控策略的灵活调整与配置。

每天，对账系统都会自动抓取各个渠道的账单，并与账单内的订单进行详细对照。在此操作环节中，需要处理包括调整盈亏状况、确认手续费金额、核对退款金额等多个不同环节。最终，必须制作出一份详细展示差异的报表，以便财务部门能够据此进行处理。

GET /api/pay/refund/status?refund_id=xxx

4. 支付流程实现

CREATE TABLE payment_order (
  order_id      VARCHAR(32) PRIMARY KEY,
  user_id       BIGINT NOT NULL,
  channel       VARCHAR(20),
  amount        INT,
  status        VARCHAR(20),
  product_id    VARCHAR(32),
  channel_txn   VARCHAR(64),
  created_at    DATETIME,
  updated_at    DATETIME
);

在构建订单接口过程中，务必对商品的具体信息和用户的身份信息进行严格的审查，然后根据这些信息来构建一个预支付订单。接下来，系统会生成一个数据集，这个数据集中包含了支付所需的所有参数，比如微信的预支付标识prepay_id。

使用苹果支付时，必须严格注意以下事项：认真操作21007沙箱环境下的代码编写，确保对具备自动续期订阅功能的验证流程进行妥善处理，同时不断更新收据验证的地址信息。在此操作中，我们建议采用JWT技术对收据内的信息进行解码。

type PayService interface {
    CreateOrder(params OrderRequest) (PayResponse, error)
    HandleCallback(data []byte) (CallbackResult, error)
    QueryOrder(orderID string) (OrderStatus, error)
}

渠道接口需具备以下功能：包括验证签名、查找订单信息、更新交易状况以及传递业务数据等整个流程的处理。特别针对微信和支付宝的回调，必须对签名的真实性和订单金额进行细致的审查。

5. 安全设计要点

请依照各平台设定的规则实施数字签名：在使用微信支付时，必须执行HMAC-SHA256加密算法，而支付宝则必须运用RSA2算法。在进行服务间的数据传输过程中，我们实施了双向HTTPS加密以及请求签名机制。

/pay
├── controller
│   └── pay_controller.go          // 下单、回调入口
├── service
│   ├── pay_service.go             // 调度统一接口
│   ├── wechat_pay.go              // 微信实现
│   ├── alipay.go                  // 支付宝实现
│   └── apple_pay.go               // 苹果支付实现
├── model
│   └── payment_order.go           // 订单模型定义
├── repository
│   └── payment_repo.go            // 订单读写
└── util
    └── signature.go               // 签名生成/验证

确保数据不被篡改的措施包括：首先，交易金额信息必须由服务端提供；其次，支付环节中的各项参数必须经过数字签名验证；再者，对于回调通知的签名亦需进行严格的核实。在此操作流程中，客户端的职责仅限于充当支付参数传递的桥梁。

      [客户端请求支付]
               │
               
   ┌── Step 1：创建支付订单 ───────────────┐
   │                                     │
   │         服务端生成统一订单（支付单） │
   │         并调用各渠道下单接口        │
   └────── 返回支付凭证/跳转链接 ──────┘
               │
               

   ┌── Step 2：客户端发起支付 ─────────────┐
   │   调起微信/支付宝/苹果支付 SDK       │
   └──────────────────────────────────────┘
               │
               
   ┌── Step 3：支付渠道异步回调 ───────────┐
   │   微信/支付宝服务器 → 通知服务端      │
   │   Apple → 客户端拿到 receipt，        │
   │          传给服务端验证              │
   └──────────────────────────────────────┘
               │
               
   ┌── Step 4：服务端确认支付状态 ────────┐
   │  - 更新订单状态                      │
   │  - 通知业务模块发货 / 送金币         │
   └──────────────────────────────────────┘

实现幂等性需借助特定请求标识符与数据库事务的匹配，如此一来，订单重复生成的问题得以有效预防。为此，在订单表中，(order_id,channel)这一组合已被设定为联合唯一索引。

6. 数据库设计

{
  "amount": 100,
  "pay_channel": "wechat", // or alipay / apple
  "product_id": "coin_100"
}

核心表包括：

订单详情中包含订单编号、支付金额、支付状态和支付途径等关键信息。

{
  "pay_params": { ... }, // SDK 调起参数
  "order_id": "202506110001"
}

支付流水记录中包含了以下几项关键信息：交易唯一标识（trans_id）、订单编号（order_id）以及交易途径流水序号（channel_trade_no）。

退款信息记录表格，包含退款标识符、订单标识符以及退款金额。

该对账差异记录表格中，涵盖了以下几项内容：核对的具体日期、相应的订单识别码以及所出现的差异种类。

7. 扩展优化建议

异步化处理：将支付结果通知、发货等耗时操作放入消息队列

缓存优化：对频繁查询的订单状态进行缓存

分布式事务：采用最终一致性方案处理支付与发货

监控报警：建立支付成功率、耗时等关键指标监控

8. 实施建议

采用分层架构：接口层→业务逻辑层→渠道适配层

[待支付] ──→ [支付中] ──→ [已支付]
   │                          │
   │                          └──→ [发货成功]
   │
   └──→ [已取消] / [超时关闭]

定义清晰的模块边界和接口规范

建立完善的日志和监控体系