Design and Evolution of ZhiZhi Checkout Payment Routing System

1 Introduction

In e‑commerce transaction scenarios, the payment stage is a critical node in the entire user shopping flow. When users reach the payment step, they have shown strong purchase intent, and the traffic value at this stage far exceeds earlier stages. The payment experience directly affects the final conversion, so the checkout must ensure a smooth, secure, and reliable payment process. As business scale expands and payment scenarios become more complex, building an efficient, stable, and intelligent payment routing system becomes a major challenge.

This article deeply analyzes the design and implementation of the ZhiZhi checkout payment routing system from multiple dimensions such as system architecture, rule engine, and exception handling, sharing practical experience and technical insights gained during its evolution. Readers will learn how the system evolved from simple rule configuration to a modular routing architecture, how the rule engine supports flexible business configurations for intelligent channel scheduling, and how comprehensive monitoring and automation ensure service stability.

The ZhiZhi checkout payment routing system’s evolution from simple rule configuration to a modular routing model.

How the rule engine enables flexible business configuration and intelligent payment channel dispatch.

How the system guarantees payment service stability through thorough monitoring and automation.

Whether you are a payment practitioner or a technology enthusiast interested in system architecture, this article aims to provide inspiration and thoughtful insights.

2 Background Knowledge

2.1 Terminology

Term

Explanation

Terminal Environment

User's terminal, e.g., ZhiZhi Android app, ZhiZhi WeChat mini‑program, PC backend, etc.

Version Number

Version of the terminal, such as 8.9.7, 10.12.30, etc.

Display Channel

(Also called payment method) WeChat, Alipay, Huabei installment, JD, combined payment, split‑payment, etc.

Payment Institution

Institution serving the payer side (user‑facing), e.g., WeChat, Alipay, JD.

Acquirer Institution

Institution serving the payee side (settlement side), e.g., WeChat, Alipay, YiBao, JD.

Guidance Routing

Routing system that decides which payment methods appear on the checkout, including list, order, default, marketing copy, etc.

Channel Routing

Process that selects the highest‑priority payment channel based on configured channel routing strategy to achieve business goals.

Product Form

JSAPI, mini‑program, APP, QR code, H5 payments, etc.; special case: APP‑to‑mini‑program (belongs to mini‑program).

Direct Connect

Directly register merchant number on WeChat, Alipay, etc., and backend interacts directly with them.

Indirect Connect

Register merchant number via another licensed payment institution; backend interacts with that institution while users still use WeChat, Alipay, etc.

2.2 Logical Explanation

The above terminology is crucial. This section emphasizes several key concepts.

1: Why are terminal and version needed?

Different terminal versions support different payment methods and products. For example, a payment method may require an SDK that is only integrated from version x.x.x onward; lower versions cannot display that method.

2: Do display channel and payment institution conflict?

No. Some display channels are abstract without a concrete mapping (e.g., split‑payment, combined payment). In other cases, multiple display channels map to the same payment institution, such as Huabei and Alipay both belonging to Alipay.

3: Why design the concept of payment channel beyond merchant number?

Payment channel provides a finer‑grained control dimension for a merchant number. If a merchant registers both WeChat (B1) and Alipay (B2) under the same merchant ID, we need separate control over availability, split ratio, weight, etc., which is achieved through the payment channel dimension.

3 Historical Evolution of the Payment Routing System

To truly understand a system, we must trace its development history. Every decision and design is a product of specific conditions; they may not be optimal but reflect the trade‑offs at the time. Understanding this process helps us grasp the current state and provides valuable references for future optimization.

Stage 1: Basic Configuration Mode

The basic configuration mode is the simplest implementation that meets the routing system’s goals. It uses straightforward configuration rules and a few core conditions to complete channel selection, similar to a simple navigation system that provides a clear route given a destination.

In this mode, the system mainly matches business scenarios and company entities to the appropriate acquiring merchant number. For example, when a user selects WeChat Pay, the system returns the preset merchant configuration based on the current business scenario (e.g., device replacement) and company entity.

This mode is especially suitable for relatively fixed business rules and stable payment demand. Its advantages are:

Simple and intuitive configuration, easy to maintain.

High execution efficiency and fast response.

Clear code structure, easy to understand.

Although the system has evolved to more complex stages, the basic configuration mode still holds a place in scenarios that require simplicity and high performance, much like bicycles remain indispensable in modern transportation.

This demonstrates an important design principle: not every scenario requires the most complex solution; sometimes a simple, direct approach is optimal.

Stage 2: Rule Engine Mode

The rule engine mode introduces business matching rules and a rule engine. The system defines business scenarios based on dimensions such as buyer, seller, and business line, and treats each merchant’s payment product as an independent payment method, defining available methods for different terminals and versions.

System processing flow diagram:

This mode suits scenarios with many business lines, diverse payment methods, and relatively stable business rules. However, its limitations become apparent as the business grows:

High configuration maintenance cost: adding a merchant or business scenario requires extensive configuration changes.

Merchant usage restriction: the same payment method cannot use multiple merchants under the same scenario, limiting flexibility.

Dimension expansion difficulty: extending business scenario dimensions is not convenient, making rapid response to new requirements hard.

Stage 3: Module Construction Mode

The modular construction mode introduces the Aviator expression engine, making dimension expansion more convenient. The system decouples the original terminal environment and version structure, so business scenarios are no longer tightly bound to specific environments and payment products.

At the same time, copywriting and ordering configurations are decoupled, allowing activity copy to be configured and reused without binding each payment method to a fixed copy. The system also enriches support for multiple merchants under the same scenario and adds automatic offline mechanisms for abnormal channels, significantly improving service stability.

This mode endows the payment routing system with stronger flexibility and scalability.

4 Decoding the Routing System

4.1 Overall Architecture

The payment system is a core infrastructure of the ZhiZhi platform. It must support internal operation staff’s routing management needs and handle payment requests from all platform users. The system must adapt to diverse environments (various app versions, mini‑programs, etc.) and different user roles (buyer, seller, merchant, recycling individual, etc.).

Architecturally, the payment system directly receives C‑side traffic and collaborates closely with various business departments. Core capabilities and underlying services are provided by the company’s architecture team.

Overall architecture diagram:

Logic diagram for obtaining available payment methods:

4.2 Routing Module Composition

Thought process: In the rule‑engine mode there are obvious pain points.

1: Business scenario, terminal environment, and version are tightly bound. This leads to a situation where, after a version upgrade, the same APP may need N sets of payment configurations for different SDK combinations.

2: Business scenario and payment configuration are tightly bound. The original configuration directly determines which payment channel, icon, title, and copy appear for a scenario under a specific terminal and version, causing repetitive configuration when adding new channels.

Based on these pain points, we redesigned the structure to split the routing system into modules, removing deep coupling, enabling easy expansion, reuse, and simplified management.

The internal routing system can be divided into the following modules:

1. Business Scenario Management – defines scenarios based on business line and acquiring account; later can support more dimensions.

2. Merchant Management – maintains merchant information, including merchant ID, acquiring institution, downgrade support, login account, supported payment methods and products, fee information, and reconciliation data.

3. Payment Channel Management – based on merchants, configures key information and channel parameters. One merchant can correspond to multiple payment channels. Exception offline and split ratio are configured per channel.

4. Routing Strategy Management – includes two types: split (ratio configuration among channels of the same method) and unavailable (restrict a channel).

5. Basic Factor Management – configures the upper limit of payment methods supported by each environment.

6. Available Payment Methods – limits the payment methods usable by a business scenario, jointly constrained with basic factors.

Overall module overview:

4.3 Expression Engine

Business scenario is the core concept of the routing system; available methods, split ratios, copy, and ordering rules are all configured based on it. Therefore, defining business scenarios is crucial.

Although we could enumerate all possible dimensions, we need a design that can easily accommodate new dimensions (e.g., city‑based routing). To achieve this, we model business scenarios as script‑language expressions. This expression language is used not only in the scenario module but throughout the entire routing system.

Example: Business requirement – business line equals 1001 or 1002, terminal environment equals "Zhaoliangji Android", version between 3.1.2 and 6.3.8, and amount less than 60,000; then allowed payment methods are WeChat, Alipay, JD.

Hard‑coded implementation:

if
("业务线树".contains("1001")||"业务线树".contains("1002")){
if
("终端环境".equals("找靓机安卓")){
if
("版本判断"("版本","3.1.2","6.3.8")){
            // version check is a custom function
if
("金额"<60000){
return
"微信、支付宝、京东";
            }
        }
    }
}

When rules become more complex, hard‑coding leads to a disaster‑level maintenance burden.

Expression‑engine implementation:

// load custom functions
AviatorEvaluator.addFunction(new BusinessFunction());
AviatorEvaluator.addFunction(new VersionFunction());
// current request variables
Map
env = new HashMap<>();
env.put("fl_business_line", [1001, 10011000]);
env.put("f_t", "找靓机安卓");
env.put("f_v", "5.7.2");
env.put("f_m", "4000.00");
// expression
String expression = "func_business(fl_business_line,seq.set('1001','1002'))&&include(seq.set('找靓机安卓'),f_t)&&func_version(f_v,'3.1.2','6.3.8')&&f_m<60000";
boolean match = AviatorEvaluator.getInstance().execute(expression, env, true);
if(match){
    return "微信、支付宝、京东";
}

When a new dimension such as city is needed, we can simply add a variable and extend the expression without changing the core engine:

// add new dimension value
env.put("f_c", "北京");
// extend expression
expression += "&&include(seq.set('北京'),f_c)";

This approach enables the system to flexibly adapt to future changes and expansion requirements.

During technology selection we compared Aviator, Groovy, Drools, etc. We finally chose Aviator because of its lightweight nature, minimal dependencies, high performance, and sufficient operator support for our scenarios. The payment system is not tightly bound to Aviator; an extensible input‑output interface is reserved, allowing future replacement with Groovy, Drools, Easy‑Rule, or a custom Java implementation, thus avoiding lock‑in.

Comparison of core dependencies, learning cost, maintenance cost, rule management, and performance (10⁵ executions):

Comparison Item

Aviator

Groovy

Drools

Core Dependency Size

<1 MB

~5 MB

>10 MB

Learning Cost

Low

Medium

High

Maintenance Cost

Low

Medium

High

Rule Management

Simple

Medium

Powerful

10⁵ Execution Time

~200 ms

~1000 ms

~3000 ms

4.4 Exception Detection and Automatic Offline

Although channel exceptions are low‑probability events, the probability grows geometrically as more channels are integrated. When the system detects a channel anomaly, technical measures can ensure user experience does not degrade significantly.

Two examples:

Single acquiring institution: If JD payment relies on a single JD acquiring institution and it fails, JD can be hidden, grayed out, or display a risk warning, guiding users to other methods.

Multiple acquiring institutions: If Alipay payment has both Alipay and YiBao acquiring institutions and YiBao fails, the system can automatically route to Alipay, making the failure invisible to users.

Exception detection and automatic offline architecture:

Logic flow for automatic offline:

Through exception checking and automatic offline, the system maintains service stability and user experience during channel failures.

4.5 Automatic Recovery

Automatic recovery logic is simpler than offline, but it must consider a scenario where, to avoid a brief recovery followed by another failure, the system should gradually restore the channel if other channels are available.

Recovery flow diagram:

5 Summary and Outlook

5.1 System Evolution Summary

As business grows, the ZhiZhi checkout payment routing system has continuously evolved. The basic configuration mode laid the foundation with simple rule‑based routing. The rule‑engine mode added stronger scenario adaptability, meeting diverse business needs. The modular construction mode brought unprecedented flexibility and extensibility.

The introduction of multi‑channel adaptation optimizes payment channel costs, while automatic offline/online capabilities reduce the impact of third‑party channel fluctuations, significantly enhancing system stability and reliability.

5.2 Future Outlook

Experience Optimization Dynamic adjustment of channel weights based on success rate and response time to ensure user experience; support personalized checkout customization; improve internal R&D team usage experience.

AI Assistance Explore AI applications within the routing system.

5.3 Closing Remarks

Things have origins and ends; knowing the order brings one closer to the path.

Thus the core parts of the checkout routing system have been introduced. The data and examples in this article are for learning and communication only and may omit real‑world details, but the overall structure and logic are complete.

About the author Zhang Yiming – ZhiZhi Payment Backend R&D

To learn more about ZhiZhi's business practices, feel free to follow the official public account below.