Mastering Payment Channels: Concepts, Selection, Integration & Management

01. What Is a Payment Channel

Like transporting goods by road, sea, rail or air, a payment channel creates an information‑exchange environment that supports the transfer and verification of transaction data, enabling the flow of funds and the completion of trades.

1.1 Payment Channel Concept

In a narrow sense, a payment channel connects the wallets of consumers, merchants and banks during a transaction. Broadly, any path that satisfies payment needs—whether using points, virtual cards, or internal virtual accounts—can be considered an internal virtual payment channel.

1.2 Payment Channel Classification

Channels can be classified by card type support, interaction mode, initiator, industry restrictions, required verification elements, and payment target (e.g., points, bank cards, tokens).

1.2.1 By Usage

Channels serve different purposes: collection (receiving payments), payout (sending payments), authentication, cross‑border, etc.

1.2.2 By Supported Entity

Channels may serve corporate (public) or personal (private) accounts.

1.2.3 By Provider

Ordinary enterprises use licensed third‑party providers (Alipay, WeChat Pay, banks) or build internal virtual‑account, coupon, or points channels. Third‑party payment institutions rely on core systems of financial institutions, while banks connect to central bank settlement systems.

1.3 Structural Relationships of Payment Channels

A payment channel sits within a hierarchy that includes payment methods, brands, products, and partners. A payment product (e.g., WeChat Pay) bundles a channel and an account to form a solution for a specific scenario.

1.3.1 Channel‑Method Relationship

One payment method may have multiple authorized channels.

1.3.2 Channel‑Partner Relationship

When a company (e.g., "Guang Enterprise") integrates WeChat Pay, the channel connects to the merchant, the third‑party provider, and the bank.

1.3.3 Channel‑Account Relationship

The channel ultimately transfers funds between payer and payee accounts.

1.3.4 Ordinary Merchant Channel Structure

Merchants often integrate multiple payment methods, resulting in several parallel channels.

1.3.5 Merchant‑Financial Institution Structure

Beyond the merchant, the flow reaches clearing‑settlement institutions and central bank systems.

02. Selecting a Payment Channel

Choosing a channel is similar to selecting a vehicle: consider attributes such as type, capacity, and fuel. Identify channel attributes (e.g., fees, limits, supported cards) and match them to business scenarios.

2.1 Business‑Scenario‑Based Selection

Different business models require different payment methods—offline retail may use POS or QR codes, while online platforms need SDKs or mini‑program integrations.

2.2 Multi‑Dimensional Evaluation

Use a checklist (fees, limits, security, compliance) to pre‑evaluate candidate channels before integration.

2.3 Integration Process

2.3.1 Team Roles

Define responsibilities for product, backend, frontend, security, and operations.

2.3.2 Preparation Steps

Clarify functional requirements (e.g., refund policy, deposit handling).

Obtain and review API documentation.

Confirm interface specifications, response codes, and encryption requirements.

Prepare a requirements document covering background, scope, and critical payment states.

Ensure security considerations such as IP whitelisting, key management, and network isolation are addressed.

03. Payment Channel Management System Design

After selecting channels, design a management module to avoid chaos as transaction volume grows.

3.1 Channel Management List

Maintain a list with unique channel name, code, associated payment method, and status. Include cost rules, configuration fields (merchant ID, callback URL), and accounting mappings.

3.2 Channel Cost Rules

Define cost rules separately and link them to channels. Support bank‑specific fees and allow bulk import of configurations.

3.3 Channel Parameter Configuration

Store sensitive parameters (merchant numbers, request URLs) with strict access controls.

04. Bank Card Debit Channel Practical Integration

4.1 Background

Implement a bank‑card debit feature to enable automatic bill payments via the PAF protocol.

4.2 API Documentation Review

4.2.1 Call Flow

Debit requires a two‑step process: protocol signing (sending an SMS for verification) and then debit using the returned agreement number.

4.2.2 Signing Phase

1) Protocol signing API – initiates signing and sends an SMS. 2) SMS verification API – validates the code and returns the agreement number.

4.2.3 Debit & Refund

Debit API expects amount in cents; include a callback URL for asynchronous result notification. Refund API also uses cents and must handle refund status, limits, and partial refunds.

4.2.4 Response Codes

Separate common response codes from business‑specific ones and prefix errors with the channel provider name for quick identification.

4.3 Functional Planning

4.3.1 User‑Side Signing

Integrate OCR to capture card numbers, match them to bank codes via a BIN module, and avoid manual entry.

4.3.2 Card BIN Management

Maintain a BIN table (6‑9 digits) to identify issuing bank and card type. Use Luhn algorithm to validate card numbers.

def check_luhn(card_num):
    num_list = list(map(int, str(card_num)))
    for i in range(len(num_list) - 2, -1, -2):
        num_list[i] <<= 1
        if num_list[i] > 9:
            num_list[i] -= 9
    return sum(num_list) % 10 == 0

4.3.3 Bank Management

Maintain internal bank codes to map various channel‑specific codes to a unified standard.

4.3.4 Signing Records

Store signing data (card, merchant, user) to support operations and customer service queries.

4.3.5 Exception Handling

Establish alerting for consecutive signing or debit failures, following principles of professionalism, orderliness, and speed.

Effective payment channel management is essential for a stable payment ecosystem and can be adapted to other third‑party services.