Designing a Scalable Payment Channel Management System: Architecture, Routing, and Error Handling

1. Payment Channel Management Scenarios

Payment channel management refers to the administration of payment channels such as banks and third‑party payment institutions. A single‑channel scenario (e.g., only Alipay) uses a fixed request flow, while a multi‑channel scenario requires flexible routing, channel selection, and easy addition of new channels.

2. Payment Process Analysis

2.1 Order Completion (Supplementary Order)

If a channel’s callback fails but the user’s card is charged, a supplemental task must query the channel for the order status. This logic applies uniformly to payment, refund, and withdrawal queries.

2.2 Refund Process

Refunds are divided into pre‑delivery and post‑delivery refunds, differing in who bears the refund amount. Original‑route refunds follow the original payment channel, but exceptions (e.g., expired original‑route window or account cancellation) require alternative handling.

2.3 Withdrawal Process

Withdrawal logic mirrors payment flow, with additional consideration for scenarios where all withdrawal channels are unavailable.

3. Overall Architecture Design

The system architecture consists of modules for channel information management, routing, result‑code mapping, and unified error handling, as illustrated in the diagram.

4. Payment Channel Information Management

Key functions include defining supported payment methods, maintaining channel status (online/offline, maintenance windows), configuring channel‑bank mappings, and storing basic channel attributes such as institution name, business type, and channel code.

5. Payment Channel Routing

5.1 Routing Elements

Channel‑to‑payment‑method mapping

Channel limits (single transaction and daily limits)

Channel status (availability)

Channel weight for scoring

Whitelist (card numbers, buyer or seller IDs)

Product code for business differentiation

Payment environment (e.g., WeChat Mini‑Program, H5, SDK)

Channel fee rate

Maintenance time windows

5.2 Routing Logic

The core logic selects the optimal usable channel by filtering based on request parameters, then scoring each candidate using configured rules (e.g., fee rate, weight). The highest‑scoring channel is chosen, with whitelist matches taking precedence.

5.3 Refund Channel Routing

Refund routing simply reuses the original payment channel identified from the order.

5.4 Routing Management UI

Administrators can modify routing conditions, channel weights, and whitelist entries through a management console.

6. Unified Result Code Mapping and Management

Channel response codes are mapped to user‑friendly messages and order status values. Since raw error messages may be confusing, a translation layer provides clear explanations for end users.

7. Refund Over‑due Handling

Two over‑due cases are considered: (1) refunds that exceed a channel‑specific timeout, and (2) refunds that cannot be processed via the original route. Both cases require detection and manual resolution, typically by contacting the buyer or re‑sending the refund request if the channel permits.