This paper first introduces the overall design of the payment platform from a macro perspective, hoping that readers can have an overall understanding of the payment platform after reading this paper. The following three aspects will be discussed:
- Payment business Architecture
- Payment process analysis
- Core logic sorting
I. Payment business architecture
Let’s take a look at the overall architecture design of JD Pay:
The design of JINGdong Pay is normal and there is no difference. This picture comes from the public information on the Internet, and we have no way to know the internal implementation and the access in the picture. However, most system design is to learn from others to share the content of the software should be their own architecture.
This column is to do engineering perspective to introduce the payment system, it is certainly impossible to describe such a large and complete system, I believe that for most of the programmers, system design to write code is just easy to do. Writing a good program depends largely on the developer’s own ability, as long as the design is not a big deviation, is basically a matter of workload. So a relatively simple “all the five organs” system makes more sense to us. A picture is worth a thousand words, and it is important to note that this is a description of what the column will take the reader to implement. The part that will not be mentioned in future articles does not appear in the figure. Such as settlement, reconciliation, statements, transaction bills and so on. It’s not that they’re not part of the payment system, but they’re very important.
If readers need to have a further in-depth understanding of the payment system, we suggest that you can read the payment knowledge platform produced by Ping++ and phoenix old bear series related articles.
Ii. Analysis of payment process
Let’s take a look at the sequence diagram of wechat scan code payment, from the wechat Pay merchant background.
Business process description:
(1) The merchant background system generates orders according to the commodities purchased by users. (2) After confirming the payment, users call wechat Pay [Unified Order API] to generate pre-payment transactions; (3) After receiving the request, the wechat payment system generates the pre-payment transaction order and returns the CODE_URL of the TWO-DIMENSIONAL code link of the transaction session. (4) The merchant background system generates the QR code according to the returned Code_URL. (5) The user opens the wechat "Scan" to scan the QR code, and the wechat client sends the scan content to the wechat payment system. (6) The wechat payment system receives the client's request, verifies the validity of the link and initiates user payment, requiring user authorization. (7) The user enters the password on the wechat client, and after confirming the payment, the wechat client submits authorization. (8) Wechat Payment system completes payment transactions according to user authorization. (9) The wechat payment system returns the transaction result to the wechat client after completing the payment transaction, and prompts the user with the transaction result through SMS or wechat message. The wechat client displays the payment transaction result page. (10) Wechat Payment system notifies merchant background system of payment results by sending asynchronous messages. The merchant background system shall reply to the receipt and inform the wechat background system not to send the payment notice of the order any more. (11) If no payment notice is received, the merchant background system calls [Order Query API]. (12) The merchant confirms that the order has been paid and delivers the goods to the user.
OK, I believe that readers have a certain understanding of the process of user-wechat payment interaction. The merchant background system in the figure above refers to the system we are developing now (for the convenience of description, the payment system is referred to below). In the sequence diagram above, we focus on step 10 [notifying merchants of payment results asynchronously] and Step 11 [calling query order API]. As you might have guessed, the payment process is synchronous for the user and asynchronous for the server. To better understand this design, let’s take a look
What happens when a user scans a QR code:
In fact, it is very simple. The payment system requests the wechat interface through HTTP, and wechat returns a two-dimensional code string with a format similar to Weixin ://wxpay/ bizpayURL? Pr = A7XXXXXV. It is essentially a short link, which will contain information such as McH_id and APPID after being converted into the original link. Wechat will naturally know which merchant created the payment order. We use the QR code generation tool to turn this string into an image. User opens WeChat sweep yards, WeChat client agreement (in fact is also a browser) parsing qr code to WeChat request payment system, a series of verification of WeChat return OK, WeChat client pay controls required to enter your password, the user input correct password again to control WeChat server launch confirm payment request. Finally, when the wechat Pay server receives the confirmation payment request, you can simply create a transfer request based on the information of the payment order, which is then transformed into an asynchronous settlement process within wechat. A message is displayed indicating that the payment is successful and the process ends.
We can naturally think that when the wechat control prompts the payment success, it only means that the wechat internal created an asynchronous settlement process. In other words, the final payment results need to be notified by wechat, or we take the initiative to inquire. To expand to other payment modes, for example, APP payment developers need to integrate wechat SDK and generally implement onResp function. After the payment is completed, the wechat APP will return to the merchant APP and call back the onResp function. Many students directly believe that the payment is successful, but in fact, this is not rigorous. Let’s have a look at the wechat APP development manual:
By referring to wechat SDK Sample, the onResp function is implemented in the class. After payment is completed, wechat APP will return to merchant APP and call back onResp function. Developers need to receive notification in this function and return error code. Note: it must not be returned by the client as the result of the user’s payment, but by the payment notification received by the server or the result returned by the query API.
However, generally speaking, the payment success returned by wechat controls is in the vast majority of cases consistent with the result of the final notification, only a very small number of cases inconsistent, to tell the truth, I have not encountered inconsistent situations. However, I still recommend strictly following wechat Pay requirements for two reasons:
- If the service volume is too small, the inconsistency may not occur in a short period of time. If the interface is upgraded, a large number of inconsistencies may occur. When the time comes, wechat will force the rectification to be in place.
- After the onResp function is called back, the payment result can be actively queried, which can quickly ensure the consistency of the payment state between the business system and the payment system. Avoid temporary status inconsistency caused by wechat notification delay. Otherwise, the user will see the phenomenon on the APP, indicating that the payment is successful, but the bill is still not paid. Of course, the implementation here may be that APP calls the business system query interface – the business system calls the payment system – the payment system requests wechat to query the payment result. The synchronous request is returned all the way back to the final business system and the business bill is updated, greatly reducing the possibility of repeated payments by the user.
Iii. Core logic sorting
Looking at the above payment flow chart, we may not be very clear about the payment system call chain we want to design, because it does not reflect the relationship between the downstream system and the payment system. To illustrate this problem, I have simply drawn a graph, again using scan code payment as an example.
The above scenario assumes that the user needs to purchase a membership service.
- The business system internally creates a recharge stream and requests payment through HTTP
- After receiving the request, the payment system conducts a series of internal processing, and finally routes to a payment channel requesting wechat to obtain the QR code string
- The downstream business system receives the string and presents it to the user
OK, the analysis of the whole process is finished. It can be seen that the recharge record of the downstream business system and the payment order status of the payment system are waiting for payment. Let’s analyze the situation after users scan the code to pay.
As mentioned above, users only need to wait a moment after scanning the code to pay successfully to find that the membership purchase is successful. In this figure, the fault-tolerant processing of the payment system is ignored, such as the asynchronous step notification of the three-party channel due to network reasons and the periodic verification process of the payment system.
Both of these images look very simple because we’ve omitted a lot of internal processing logic. In fact, identity authentication, signature, encryption and decryption, flow control, fusing, compensation, account reconciliation, error handling and some standardized things designed in the payment system need a lot of space to introduce, so I will simply skip here.
Through the above analysis, we hope readers can have an overall understanding of the payment platform, and we will discuss these issues from the perspective of engineering design in the future.