In order to better support the rapid development of trading business, Hornet’s Nest payment center has changed from the initial “slash-and-burn” stage, which only supports basic payment and refund, to the “bone healing” stage of structural adjustment, and has completed the evolution of “precipitation and storage” stage, which realizes the form of comprehensive product platform.

At present, the hornet’s nest pay center integrates based orders, cashier, routing management, including pay channels, clearing check, statistics report and so on the many kinds of ability, for the hornet’s nest vacation (platform, customization), transportation (air tickets, train tickets, cars), hotel (open platform, agents) and so on nearly 20 lines of business to provide services. This paper will briefly introduce the core parts in different stages of the overall evolution of the payment center.

I. Payment center 1.0

In the initial stage, the payment center is mainly responsible for accessing the payment channels (Alipay, wechat, Lianlian, etc.) to quickly respond to the payment, refund and some basic needs of the business, and each business line realizes the cashier desk respectively, and then invoks the payment center for payment. The interaction flow chart of business system, payment center and third-party channel is as follows:

The interaction process of each system is as follows:

1. The line of business encapsulates the order information and requests it to the payment center
2. The payment center will briefly process the order information and then add the payment information request to the third-party payment channel
3. The third-party payment channel asynchronously calls back the payment result to the payment center
4. The payment center will simply process the data from the third party and then synchronously notify each business system
5. The business system performs logic processing, user notification and page jump

In the early stage of business development, the volume of business is small and the transaction scenario is relatively single. Such a design can quickly respond to business requirements and realize functions. However, as business complexity increases and more and more services are connected, this architecture becomes inadequate. Each business line needs to develop some functions repeatedly, and the payment center does not have the overall control ability, so the development and maintenance costs are increasing. The main issues include:

• High maintenance costs: Each business line needs to maintain the cash register separately and call the payment system to complete the payment, so problems such as idempotent and security should be ensured respectively
• Poor Dr Capability: All functions are concentrated in a large module. If a function fails, all functions are affected
• Unreasonable structure: A single architecture cannot meet complex service scenarios
• Chaotic system responsibilities: The cashier maintains payment methods and some business routes, lacking unified control

In order to balance the demand response of rapidly growing business with the high availability of the system and ensure the quality of online services, we made a rapid architectural adjustment and began the evolution of Payment Center 2.0.

Payment center 2.0

The 2.0 architecture deposits the public transaction, payment and finance of each business to the payment center, and mainly solves the following three main problems:

• Establish a unified system of basic order, payment and finance, abstract and encapsulate common processing logic, form a unified basic service, and reduce the cost of business access and repeated research and development;
• Build a secure, stable and scalable system to provide basic support for the rapid development of business and innovation needs, and solve the contradiction between “fast” business and “stable” payment;
• Accumulate core transaction data, and provide big data support for users, businesses and finance.

2.1 Core Competencies

Payment center 2.0 is an important period for the rapid development of the whole transaction system. In this process, not only the architecture should be upgraded, but also the service stability should be guaranteed.

At present, the payment center provides the following key capabilities for business:

• Platform payment: Users can use third-party platforms such as wechat and Alipay to complete payment
• Quick payment: Users provide bank card information for convenient payment
• Protocol payment: After authorization, users can make convenient payment without interrupting user experience
• Credit payment: users can choose to pay by installments such as Huabei
• Overseas payment: users can choose overseas payment channels to complete the purchase of overseas products
• Offline payment: Users can choose ToB channel to complete the payment of specific scenarios

According to the characteristics of Hornet’s Nest business, the core transaction scenarios currently supported include:

• Payment and refund: applicable to the purchase and refund of ordinary goods
• Split payment: applicable to scenarios with large limits or amounts
• Single payment: applicable to the scenario where insurance accounts are transferred to different accounts

2.2 Architecture Design

In the process of evolution, the gateway, which is relatively independent and serves as the foundation of the unified system, is modular. The payment gateway abstracts the standard requests such as payment, refund and query, and then gradually sorts out the payment channels on the basis of the gateway, and extracts the basic order module step by step, decouples the business function and payment function, and supports complex business scenarios. The overall architecture of the current system functions is as follows:

As shown in the figure, there are three levels of architecture:

• ** Product layer: ** Combination of the core layer to provide the ability to pay, the end users to provide cash registers, operational financial personnel to provide operational financial system
• ** Core layer: ** payment center core module, including basic order, payment route, payment channel, etc
• ** Support layer: ** Is used to support the infrastructure of the entire system, including monitoring alarms, logs, message queues, etc

2.2.1 product layer

The product layer mainly contains the cashier desk, payment management background and financial accounting and reconciliation system visible to consumers. This paper focuses on the design of the cash register.

checkstand

The cashier desk consists of H5 cashier desk and PC cashier desk:

Mobile client:

PC:

As shown in the figure above, the cashier is mainly composed of three parts: basic order information (including order number and payment amount), order details (including date information, product information and basic information), and payment method (platform payment, credit payment, etc.).

As the cashier is the only entrance to the payment center for users, user experience and security are crucial. In order to support business personalization and user consistent experience, the cashier desk is mainly realized through customization and configuration. For business students, access is also very simple. They only need to jump to the cashier page through the order number, and the subsequent process is completed by the payment center.

After placing an order, the user arrives at the cashier’s page, and the cashier shows the available payment channels through the business line of the order, the payment amount, whether the order is combined and other information. At the same time, the risk control system will monitor goods, orders, user behavior and other dimensions, shielding high-risk payment channels. When the payment channel breaks down, the display can be suspended at the cashier desk.

(1) Customization

• In order to support the unified characteristics of different modes and displays of different business lines under the cashier desk, the mode inherited from the factory class is used to realize various business data and display styles.
• The main attributes of the cash register are divided into display modules and channel routing. The modules with repeated and default functions are realized by abstract classes in the way of templates, and the subclasses can achieve self-defined implementation by default method or rewriting parent class method.
• The checkout display implementation class already implements a default checkout with most of the required components (such as countdown, header customization, order details, and so on).
• Typically, each line of business simply adds specific implementation classes to produce a clear and rich page

(2) Configuration

The configuration of the cashier desk is mainly based on the attributes of each business (business type, category, etc.) to carry out certain process configuration for subsequent operations, such as:

• The display layer of the cashier desk is processed differently based on the back-end routing, including the list of supported channels (wechat, Alipay, etc.) seen by the user, as well as the top ranking and marking, etc
• Meet different scenarios, different business under the same payment method to receive payments to different accounts
• Use different settlement methods and settlement channels according to different scenarios

2.2.2 core layer

The core module in the payment center, including basic order, payment route, payment channel, etc.

Based on order

The basic order system is the bridge connecting transaction business line, payment center and settlement system, realizing the decoupling of business and payment settlement. It mainly covers business order creation, closing, payment, refund, callback notification and other API modules. Basic data support payment functions of common payment, single payment, split payment, insurance payment and other scenarios. The interaction flow of each system is as follows:

Currently, the basic order system can support the following two special scenarios:

(1) One order vs. multiple items

A basic order can contain N items (item information includes product name, product ID, unit price, quantity, and discount, and order information includes user UID, mobile phone number, payment amount, and order discount). N items correspond to M suborders (M≦N). If the business type of all business sub-orders is the same, it is the common mode; otherwise, it is the tie-in mode; Each business order corresponds to a statement element (the payment information will be synchronized to the reconciliation system after successful payment). The order creation mode of one order vs. multiple goods basically supports all current scenarios, including the possible shopping cart mode in the future.

(2) One order vs. more payment

Ordinary order users choose alipay, wechat and other channels will generate a payment slip; When the amount exceeds 5000 yuan, you can choose to split the order amount to pay, and multiple payment bills will be generated at this time. If the order is checked, the insurance will be paid by the third party, and two payment bills will be generated. At the same time, split payment will also lead to partial payment or overpayment by users, and the monitoring will automatically refund for abnormal payment; Large orders have a conversion rate of more than 10%, and the one order VS multiple payment model better supports the hornet’s nest payment scenario.

Channel Route Management

Channel routing mainly includes two aspects: the service side needs to control the payment channel, and the payment side needs to select the payment account.

(1) Payment account management

Payment During order creation and callback processing, the payment account needs to be determined based on the service type, payment mode, and payment channel. In earlier versions, the corresponding relationship is maintained through configuration files. A service type corresponds to multiple configuration items. Multiple configuration items need to be added for each new service. In addition, as more payment channels are added, more configuration information needs to be configured for new services, which is difficult to maintain.

After optimization, the existing configuration of the corresponding relationship into the database, data table by business type, payment method, payment channel to determine a unique account, the payment account specific parameters information is still in the file configuration. When creating an order, query the payment account according to the business type, payment method and payment channel, record the account information into the payment order data table, and query the payment account directly from the order table when callback.

(2) Payment channel management

At present, third-party channels such as Alipay, Alipay International, wechat, JINGdong Pay, Applepay, Lianlianpay and UnionPay 2B are connected, and there are multiple payment products under each channel. The interfaces of third-party channels vary widely, but all offer standard functions such as ordering, refund, inquiry, payment notification, and bill download. The payment center encapsulates these payment channels by using an abstract class as the base class, using the template method to design the pattern, defining a standard process in the base class, and the concrete implementation in the channel’s respective implementation class. The client class only needs to care about the public methods of the base class, regardless of the channel.

2.2.3 support layer

The support layer includes monitoring and alarm, log management, add check, configuration management, message bus and other modules. Logs are collected and managed by ELK, system configuration is managed by the distributed configuration center developed by the company, and message bus is distributed and consumed by the RabbitMQ secondary encapsulation of the company.

As the payment system has high requirements for availability and sensitivity of payment data, the payment center has independently implemented a monitoring and alarm system. The functions and design ideas of the monitoring and alarm system will be described in detail below.

The monitoring system

To ensure real-time and effective monitoring, monitoring resources such as databases must be separated from business libraries (to avoid putting all eggs in one basket). Payment monitoring system covers API monitoring, service performance monitoring, database monitoring and so on, and can provide unified alarm, analysis and troubleshooting capabilities. From abnormal data collection to fault active discovery and stability trend analysis, it provides data support for payment system optimization.

(1) Monitoring background

The background mainly contains the management of monitoring users and the creation and management of monitoring items. Users can configure the parameters according to the corresponding monitoring items, including API request address, request mode, availability, correctness, response time and other performance data, as well as alarm mode and policy. The detailed configuration is shown as follows:

Interface monitoring can be bound to a fixed host IP address and set the timeout period. Monitoring requests can be set in GET and POST modes. Fixed request parameters can be set in POST mode. The response data module can verify whether HTTP code is abnormal, configure the response data type, compare the returned key value, and set the timeout time for DB query for DB monitoring. The alarm module currently supports SMS and email. The minimum and maximum alarm thresholds can be set. When the maximum alarm threshold is exceeded, an alarm will be triggered every other time, avoiding the problem of SMS bombing during a fault.

(2) Monitoring core

In order to achieve the fastest monitoring frequency of 10 seconds and support thousands of monitoring items running in parallel, payment monitoring adopts multi-process management. The parent process creates a specified number of child processes. Each child process completes a fixed number of monitoring tasks and exits the task. In this case, the parent process monitors the status of child processes in real time and creates new child processes to execute tasks. The parent process can also receive external signals to restart and stop the service as follows:

(3) Monitoring and alarm

The interface request and returned data will be analyzed and processed according to the monitoring configuration when the monitoring item is executed, and then alarm notification will be made according to the alarm policy through Redis counting. Example of daily monitoring SMS messages:

2.3 Practical Experience

(1) Data consistency

As mentioned above, we adopt a modular approach to decouple business functions from payment functions. In this process, every module introduced will involve system interaction issues, so the most core is the data consistency problem. To solve the problem of data consistency, transaction, real-time, delay check and compensation mechanism should be introduced to ensure the final consistency of data. The architecture is very clear, but for the whole transformation process is difficult, like changing the engine of a flying plane, so we also describe the process as a bone scraping phase.

(2) Stability

Payment services are provided by third-party payment channels, which are unstable. For example, a user pays for an order with Alipay. Due to various reasons, the payment center does not receive the notification of successful payment, and the user pays again with wechat, resulting in repeated payment.

In order to solve this problem, the payment center adopts the strategy of periodic scanning to actively detect duplicate payment orders and automatically execute the refund, without human involvement. In the refund process, the refund receipt needs to go through the application, review, call the refund interface and other processes. In the interface adjustment process, failure may occur. If a refund ticket fails to be invoked, the system initiates retries based on the retreat algorithm and gradually increases the retry interval until the number of retries exceeds the limit. An alarm is triggered when the number of failed orders exceeds the threshold or when the failed time of an order exceeds the threshold. Refund bills that cannot be processed automatically can be manually detected, or offline refund.

Third, summary & outlook

At present, Hornet’s Nest payment center has the ability to support multiple businesses, multiple scenarios and multiple payment methods, but there are still many areas to be improved and perfected in order to realize a true “a hundred flowers bloom” platform.

The upcoming Payment Center 3.0 will decoupled individual applications according to business with the idea of microservices, gradually evolving from a single system with high coupling to a distributed system composed of many subsystems with high concurrency, high availability and support for more transaction payment scenarios. After the separation of microservices, the system structure will be clearer, but the development, management and maintenance of the overall system will also bring greater challenges.

With the upgrading of Hornet’s nest’s “content + transaction” strategy, the payment center will also explore more payment methods and capabilities, and continue to empower all business lines.

Author: Payment and settlement team of Hornet’s Nest E-commerce.

(Hornet’s nest technology original content, reproduced must indicate the source to save the end of the two-dimensional code picture, thank you for your cooperation.)