Design and Implementation of a Payment Verification Tool for E‑commerce QA

Background In the e‑commerce industry, any transaction involving money—such as payments and reconciliation—can cause serious online incidents if errors occur. Testing these payment flows traditionally relied on manual verification across multiple systems, which is time‑consuming and prone to miscommunication between departments.

The article shares how ZhuangZhuang QA tackled these pain points by designing a dedicated payment verification tool.

Requirement Analysis

1. Business Status The team first mapped the current online recycling business, identifying three core payment scenarios (Recycle 1, Recycle 2, Recycle 3). Recycle 1 and Recycle 2 involve two payment types (A and B), with A further split into various surcharges and subsidies, leading to over 15 distinct business lines each with unique account configurations. Recycle 3 adds more complexity with three payment categories (sale, A‑type, B‑type) and intricate commission calculations, making account verification labor‑intensive.

2. Requirement Research Interviews with store‑side teams revealed similar verification challenges, prompting a joint investigation of online and offline payment scenarios. The resulting diagram (see image) highlighted key verification items: account details, payment amounts, and calculation formulas.

Requirement Design

The verification tool’s core functions are:

Display basic information of recycling orders and standard orders (status, order ID, business line, etc.).

Compare key data (payment type, account, amount) between expected results (calculated by the tool) and actual results (fetched from the system), showing a side‑by‑side comparison.

Provide detailed reconciliation records where each payment line can be expanded to reveal the calculation process, formulas, and field values, enabling non‑technical users to understand discrepancies quickly.

System Design

The architecture consists of three layers: a front‑end UI layer for rendering pages, a presentation layer for fetching basic information, and a business layer that implements payment reconciliation logic, aggregates order, recycling, and after‑sale data, performs price calculations, and returns comparison results.

Core Functionality

1. Payment Information Verification Users select a business line and scenario, input an order or recycling ID, and the tool calls a middle‑platform API to retrieve key order data. It then computes expected results and compares them with actual payment outcomes, marking each record as pass or fail.

The verification logic builds two maps (expected and actual) per business line, iterates over them, and compares amounts, income/expense, and accounts, finally merging the results into a combined map.

2. Generic Invocation To test both online and test environments, the tool supports generic service calls: users specify the target service IP, the front‑end sends an HTTP request to the web layer, which forwards it to the zzjava_test service; zzjava_test then invokes zzjava_scf in the chosen environment, allowing test‑environment data to be validated from the production UI.

The generic call specifies service name, interface, method, parameter types, and values, then sets the execution environment and destination IP before dispatching the request.

Efficiency Gains

1. Manual Verification Previously, testers manually calculated commissions and payment amounts, then compared them one‑by‑one with results from the transaction toolbox, a tedious process.

2. Automated Verification With the tool, entering an order or recycling ID automatically computes all payment records and comparison results, eliminating cross‑system queries and manual calculations, dramatically reducing the learning curve for colleagues unfamiliar with commission rules.

3. Project Applications After more than a month of production use, the tool has been applied to various projects, such as category expansion (automating commission checks for new product lines), calculation‑logic changes (supporting RD self‑testing), and multi‑payment‑type scenarios (handling numerous accounts and flows).

Outlook The verification tool’s applicability extends beyond the current business, potentially serving any order‑and‑payment‑related domain. Future enhancements may enrich verification content and inspire additional efficiency‑boosting methods.