5.4 Technical Architecture of Payment
Architecture is the future, and payment institutions can have a bright future only if they are built on a well-designed technical architecture system. If there are architectural problems in the technical system of payment, then there is no way to achieve high availability, high security, high efficiency, and horizontal scalability.
Summarizing the technical architecture design experience hosted and participated in payment institutions at home and abroad for many years, it is found that the layered architecture design method based on the reference architecture is an effective payment technology architecture design method. This section will introduce how to use the thinking method of layered architecture design to build the technical architecture of payment.
5.4.1 Reference Architecture
The so-called reference architecture is one or a set of documents, which provide reference and suggestion architecture for integrating products and services to form solutions. The reference architecture allows different teams and architects to focus on the functional abstraction and architecture design of their respective layers through the layering.
If you take a closer look, you can find that the Internet technology industry has always adopted this hierarchical architecture design idea. For example, the familiar Internet protocol TCP/IP was developed on the basis of the hierarchical model of ISO OSI. Large-scale integrated circuit design is actually designed layer by layer, and then integrated to provide computing or storage capabilities. The reference architecture embodies the industry's common best practices, and the development of architecture design on the basis of best practices can absorb mature experience and proven models to the greatest extent.
Today's Internet has spread all over the world, but in the 1980s, the open interconnection between different computer networks was still a Warring States era. In order to promote the open interconnection of computer networks worldwide, the International Telecommunication Union and the International Organization for Standardization announced the ISO/IEC 7498-1 standard [1 ] in 1984. This ISO OSI standard laid the foundation for the subsequent development of the Internet.
The OSI seven-layer model is a framework design method. The main purpose of establishing the seven-layer model is to solve the compatibility problems encountered when interconnecting heterogeneous networks. Its main function is to help different types of hosts realize data transmission. Its greatest advantage is that it clearly separates the three concepts of service, interface and protocol, and enables reliable communication between different systems and networks through seven hierarchical structural models. From high-level distributed applications to the physical realization of data transmission across communication media, it is divided into seven layers of definitions, which depend on each layer from top to bottom [2 ] :
Seventh layer application layer:
An interface designed to realize mutual communication between different application software, such as HTTP, HTTPS, FTP, SSH, Telnet, SMTP, POP3, etc.
The sixth layer presentation layer:
Perform activities such as encryption, decryption, and analysis on the received data. The presentation layer deals with the representation of data encoding flowing through the node, so as to ensure that the information sent by the application layer of one system can be read by the application layer of another system. In short, it is to convert the data in different formats in the computer system into a common standard representation of the network.
The fifth layer session layer:
The data transmission path is established through the transport layer, that is, the port. The main function of the session layer is to manage and coordinate communication or sessions between various processes on different hosts, and is responsible for establishing, managing and terminating sessions between applications.
The fourth transport layer:
Provide end-to-end reliable and transparent data transmission services for upper-layer protocols, including dealing with issues such as error control and flow control.
Layer 3 network layer:
Solve the problem of how to send data packets through each node.
The second link layer:
Data link establishment, maintenance, removal, specifying topology and providing hardware addressing.
The first physical layer:
Provide a physical channel for transmitting data and transmit data.
This open network interconnection protocol actually defines a reference architecture, so that all computers trying to connect to the network have a reference standard framework. Because of the layering of the reference architecture, each layer can focus on solving a part of the problem, which actually reduces the complexity of the entire system. The clear interface definition between layers also effectively avoids unnecessary interference between each other. The architectural design of payment technology can also be designed with a similar reference architecture, and based on this, a more detailed hierarchical design can be made.
5.4.2 Payment Reference Architecture
Like the ISO OSI Open Interconnection Reference Architecture discussed above, the payment system reference architecture also decomposes complex payment applications into five levels: payment front-end applications, access gateways, business applications, general services, and infrastructure. Each level focuses on a specific direction, thinks and designs for related function sets, and finally forms a unified payment technology architecture system through call integration between levels.
The main advantage of this is that each level can focus on the core functions of this level, and hand over some complex operations to other levels to think about the design separately. In addition, the same functions can be summarized into general services, which not only ensures the standardization and behavioral consistency of the entire system services, but also improves the overall governance of the payment technology architecture. The payment reference architecture is shown in the figure below:
The functions and components of each level of the payment technology system reference architecture shown in the above figure are described as follows:
Front-end application layer:
iOS and Android Apps and Web Apps. This part is mainly the development of various network applications and mobile apps, including the cash register developed for merchants to facilitate the completion of payment business, various electronic wallets developed for consumers to facilitate payment, and merchants to facilitate receipt of orders on Android or POS App developed on iOS, etc.
Access gateway layer:
API gateway, financial system and bank gateway, merchant access gateway, etc. For payment institutions, the most important access gateway is the merchant's application access gateway, which is the connection between the merchant and the payment institution in order to complete the payment. To receive the payment success or failure result notification returned by the payment institution. Gateway access to banks or other financial institutions is another important component. This part is mainly responsible for docking with banks or other financial institutions, ensuring that payment institutions can translate received payment requests into payment instructions, and then forward them to banks or other financial institutions, including the execution of payment instructions returned by banks or other financial institutions result.
Core business layer:
Customers , business management, rates, payment requests, fee calculations, accounts, accounting, settlement, reconciliation, payment, etc. This part is the core part of the entire payment system. It mainly includes payment institutions receiving payment requests from merchants, translating payment requests into payment instructions that can be used by banks or financial institutions, obtaining payment results from banks or other financial institutions, and returning the payment processing results to merchants. Of course, it also includes the calculation and billing part after the payment request is completed, as well as the reconciliation between the payment institution and the bank or other financial institutions, as well as the settlement and payment activities based on this
Generic service layer:
Common basic services such as log, data, notification, authentication, authentication, GUID and risk control. The general service layer, as the name implies, is an application or service that includes the general functions of the payment system. These functions or services are the basis of other applications and are widely used in other applications. For example, Log Service is a service responsible for processing various log information in all applications. First, combine and output various application log information according to the specified format; secondly, perform various processing on the log information including collection, statistics and analysis. Thirdly, provide flow control and monitoring information to the front end according to the results of statistical analysis.
Infrastructure layer:
Basic services such as network, computing, storage, security, domain name and time. This part mainly provides computing, storage and network capabilities for the above layers of applications and services, and also includes network time services, domain name resolution services, database services, data backup services, and disaster and recovery services. The infrastructure layer is responsible for providing production environment, integration environment, release environment, performance test environment, function test environment and demonstration environment for the upper layer services, ensuring that various application environments set up for different purposes can meet various needs.
After dividing the various levels of the payment technology architecture according to the reference architecture, different architects can be arranged to focus on their respective responsible levels and complete the architecture design work at this level. Based on the design results of each level, through collective discussion, determine the design goals, principles, interfaces and function sets of each level. Further high-level design and detailed design are then performed until all layers are finally fully realized. Services between tiers and tiers should be governed by internal service level agreements.
5.4.3 Layered architecture design case
According to the previous reference architecture, the architect responsible for the general service layer provides the general basic services contained in the general service layer, as shown in the figure below for the general service layer. The five services abstracted in the figure are:
CDS: Common Data Service (Common Data Service), which isolates data at the physical layer from data at the logical layer.
CKS: Common Key Service (Common Key Service), responsible for managing various security keys.
CNS: Common Notification Service (Common Notification Service), sending emails, SMS and other notifications.
CUS: Common GUID Service (Common GUID Service), responsible for issuing globally unique IDs.
CAS: Common Applications Logging Service (Common Applications Logging Service) is responsible for processing log information.
Architects can go further and make a more specific design for each generic service. Here, taking the general log service CAS as an example, the architecture design scheme of CAS is given. CAS is a log processing service used by all applications, so it is versatile enough to exist in the general service layer. The main functions of CAS are described below:
Standardized log information structure
Receive application logs in a pre-defined format to ensure that all application logs follow the log output standard. Avoid different applications generating log information in various formats, which will cause difficulties in subsequent log processing.
The producer sends log information into the message queue
Define the producer, put the formatted data into the message queue, and realize the asynchronous processing of the log. Avoid the problem of local I/O or network congestion caused by massive output of application logs.
Consumers process logs in message queues
Take out logs from the message queue, and perform in-depth processing according to the processing rules to increase the value of log data. For example, an SQL statement issued by an application performs database-related operations. From the logs generated linearly in chronological order, you can see the submission time, return time, returned data, and status of the execution result of the SQL statement execution. Consumers can compare and calculate the time when the SQL statement is raised and the time when the data is returned, so as to obtain the execution time of the SQL statement. At the same time, it can be analyzed based on the execution of the same SQL statement in history, so as to obtain the execution time of the SQL statement in this calling process, and what level it is based on the 90th percentile calculation. It allows developers to more intuitively understand the execution status and results of the called services.
Event processing for each log message
Screen the various information output in the log. For example, the log information at the Information level can be counted and then stored; the log information at the Critical level needs to be analyzed and judged in detail; the log information at the Exception level needs to be further analyzed. Analyze or issue an alarm.
Dynamic near real-time statistics
Log information is stream-processed based on keywords and tags such as application IDs. Use tools like Stream to do real-time statistical analysis. It can provide traffic reference for the front-end circuit breaker, and also provide data for factual statistics of payment-critical businesses.
Therefore, CAS is a very valuable general service. Well constructed, it can not only standardize the format of all log information, but also greatly improve the analysis level of application logs and the management and control of various application and system events in logs. Early warning and processing before merchants to avoid future troubles. Therefore, the architect responsible for this level needs to be able to think carefully, abstract, summarize and analyze valuable design key points. The following figure shows the architectural design of the general log system CAS.
On the basis of the CAS architecture design, the R&D engineers can further improve and refine the CAS design, and then obtain the detailed design scheme of the CAS, as shown in the figure below. Then hand over the design to specific R&D personnel to complete the detailed design and code implementation of the entire CAS. Summarizing years of experience in technical architecture design and implementation, the R&D technicians of many payment institutions lack an overall understanding and detailed analysis of the business they handle. This book will discuss the architectural design of the payment core business layer in a similar way to CAS in "Chapter 6 Application Design Before Payment".
5.5 The overall structure of payment
The figure below shows the overall architecture of payment. Different payment institutions may vary due to the different businesses they focus on, but in general they should be similar. Basically, it can be divided into the five levels mentioned above. In terms of design, two parts, the access part on the left and the operation management platform on the right, are added. This section will give a slightly detailed introduction based on the architectural design of this payment system.
First of all, the front-end part includes various forms of service access such as Web, App, POS and telephone IVR access. According to the specific needs of business development, these applications can be connected to the main payment system through standardized APIs and SDKs.
Secondly, on the left side of this architecture, bank access, institution access, partner access, PSP access and regulator access are added. This part can be realized by establishing standardized access services. If the access service is well designed, it can not only improve the efficiency of access, but also standardize the process of payment request processing.
Thirdly, an operation management platform is added to the right, which is mainly used by the business operators within the payment institution to manage various businesses. Such as signing, application, review, approval, activation, rate, reconciliation, settlement, payment and other specific operations and review uses, as well as the merchant background provided to merchants to query the results of payment requests and settlement reports.
Finally, there are core application functions such as payment request processing, accounts, accounting, billing, settlement, and payment in the central part, as well as log, authentication, authentication, notification, ID, certificate, key, and data processing services in the lowest layer.
The other parts are basically the same as the levels described in the reference architecture proposed above, so I won't repeat them here.
5.5.1 Subsystems divided by stakeholders
From the above analysis and summary of payment functions, we can see that in the payment ecosystem, different stakeholders need to have different function combinations to correspond. In the actual payment industry practice, we often organize and summarize these functions into 11 subsystems according to the objects served and the businesses to be managed by the objects. The sum of these subsystems constitutes the overall payment system. The 11 subsystems are:
(1) Merchant
Merchant acquiring subsystem (for clerk acquiring): Paying, App or POS.
Merchant background subsystem (for store owner management): after payment, the merchant uses BOSS.
(2) Consumers
E-wallet subsystem (for payment by the payer): payment, e-wallet App.
(3) Regulatory agencies
Payment reporting subsystem (for regulators): post-payment, anti-money laundering and countering terrorist financing.
(4) Payment institution
Payment Processing Subsystem (Core): Payment in progress.
Subsystem for network access (for business management): before payment.
Bank access subsystem (for technical support): before payment.
Merchant access subsystem (for technical support): before payment.
Operation background subsystem (for reconciliation and settlement): after payment.
Risk management subsystem (for risk control management): payment is in progress.
Data management subsystem (for business management): after payment.
5.5.2 Subsystems divided by payment process
The subsystems divided according to the three stages of pre-payment, payment and post-payment are as follows:
(1) Before payment
Subsystem for network access and provisioning (for business management)
Bank access subsystem (for technical support)
Merchant access subsystem (for technical support)
(2) Paying
Payment Processing Subsystem (Core)
Merchant Acquiring Subsystem (for clerk acquiring orders)
E-wallet subsystem (for payer payment)
Risk management subsystem (for risk control management)
(3) After payment
Merchant background subsystem (for store owner management)
Operation background subsystem (for account reconciliation and settlement)
Payment reporting subsystem (for regulators)
Data management subsystem (for business management)
The various subsystems of the payment technology system are summarized as follows according to the stakeholders and their positions in the payment processing process:
before payment |
Payments |
after payment |
|
Merchant |
Merchant Acquiring Subsystem |
Merchant background subsystem |
|
consumer |
Electronic Wallet Subsystem |
||
payment institution |
Network access opening subsystem |
Payment Processing Subsystem |
Operation background subsystem |
Regulatory Authority |
Payment Reporting Subsystem |
||
Table 5.2 Subsystem division of payment system |
|||
5.6 Chapter Summary
This chapter first describes the payment ecosystem, defines the various stakeholders involved in payment activities in the ecosystem, and analyzes the different roles and demands of each stakeholder in payment activities. On this basis, with each stakeholder as the main body, the classification defines the set of functions corresponding to each subject. Then, it expounds and discusses the four technical requirements of high availability, high security, high efficiency and scalability that the payment technical system must have. Then, a reference architecture design methodology to guide and define the architecture design of payment technologies is recommended and discussed. And combined with specific practices, it introduces in depth how to use the thinking method of the reference architecture to define the payment architecture. Taking the general log service in the general service layer as an example, the thinking method of building the payment technology architecture is introduced. Finally, the overall architecture of the payment technology is defined, and the 11 subsystems that the payment technology architecture should be equipped with are summarized.
This article is excerpted from "Understanding Payment in a Book" published by Machinery Industry Press, and is released with the authorization of the publisher
"A book to understand payment"
Let you be the first group of people who fully understand payment! A landmark book in the field of payment, summarizing the 30-year experience of payment leaders in China, the United States, and Japan, etc., highly recommended by the executive vice president of China UnionPay, with a 360° interpretation of payment.
Discount book purchase link (35% off) Click to view the original text
You can join the reader group of technical trivia, please reply in the background: reader group
Past recommendations:
technical trivia
Based on distributed design, architecture, and system thinking, it also discusses bits and pieces related to R&D, not limited to code, quality system, and R&D management.