TYPESDK Hand Tour Aggregation SDK Service-side design ideas and Architecture III: Process optimization of order preservation and notification

Through the analysis and design of the first two texts, we have been able to build an aggregation SDK service side that can support multi-game multi-channel, but this is just a simplified model in idealized state. If the logic of the access channel is built according to the idealized simplification process, then for the payment request, we can simplify the steps as follows:

1. The game client creates the order.
2. The game client (via the TYPESDK client) invokes the corresponding interface in the channel Lib library, initiating the payment.
3. The user completes the payment in the pop-up payment window.
4. The TYPESDK server waits for a callback from the channel server and notifies the game server when the callback is received.
5. The game service side performs the shipment action.

But obviously this simplification process is not enough for the actual line, such as the first step to create the order, in practice it should not be done by the game client. order creation and status management should be controlled by the game server, which, of course, needs to be supported when the game is developed. Let's consider a common process problem that needs to be typesdk the service side and the game server to work together.

The default scenario, most channel technical framework design is the default one game only one server callback address, and does not consider a game exists in multiple areas of service, multiple callback address situation. Of course, there is no need to consider TYPESDK this multi-game shared unified callback address requirements scenario. So we need to design the SDK server, so that the system can identify the channel sent back to which the callback order belongs to which game, and accordingly send shipping notifications to the corresponding servers.

But as we know, when we receive callback requests from different channels, the information we can obtain is not fixed and there is no unified judgment. Most of the callback information in the channel, in addition to the order itself related information, such as the payment of the amount of the product name, up to provide some information, such as user information and security check related. The most common scenario for a field that can be used is that there is only one field called extended information.

This extended information field has different names in different channel documents, such as "Extended fields", "Pass-through Fields", "Custom Information", "Keep information", etc., or the like. This field is transferred from the game client to the channel server and saved as part of the order when the order is placed, and the channel does not do any processing on it, and sends it back to the game server as it is when the payment is completed. In general, we use this field to transfer the order number generated within the game. We need this field to play more role, such as the game information of the delivery order, the district service information and so on. However, the first time the network transmission, it is not appropriate to transmit too long information, and secondly, many channels also artificially limit the length of this field. More exaggerated, only left to the developer 12-bit length limit, in such a short field to force a variety of information, not appropriate.

TYPESDK server as a developer's own set of unified access backstage, of course, can also be used to save the information we need. So we can store an order information in the TYPESDK server, the primary key of this information is the internal order number created by the game servers, and the content includes some more detailed information of the order such as creation time, order amount, and the area service information of order callback. In this way, when receiving the callback information of a specific order from the channel, it is easy to obtain the callback address of the corresponding district suit according to the internal order number of the order.

Game zone Service callback address can be configured to save on the TYPESDK server, and then according to the area of the order to save the information query. However, the simpler scenario is that when the order is saved, the game server directly stores the complete URL as a field at the time the order is saved, and transmits it to the TYPESDK service side as the order information.

Based on the above practices, the improved payment-recharge process is as described:

Process description

1. When a user clicks on a purchase button for a product, the game client accesses the game server

L need to access the game server and create an internal order number every time you click on a purchase, not create a complete payment.

1. The game server creates an internal order, generates an internal order number, and invokes the top-up information submission interface on the TYPESDK server.
2. TYPESDK the service side to save the order information. Returns the submission processing result
3. Game server returns the generated internal order number to the game client
4. Game client calls TYPESDK client payment interface with internal order number
5. TYPESDK client calls the API Popup payment window of the Channel Client SDK

• Payment completed by user in payment window

1. Channel SDK client submits order to channel server
2. Channel Server return recharge request received message to Channel SDK client

L at this time the recharge has not been to the account, recharge to account is an asynchronous action. The message returned here indicates that the reload action is complete and the request has been accepted.

1. The Channel SDK client processes the request for an accepted message. Return to TYPESDK Client
2. TYPESDK Client wrapper request received message, return to game client
3. The game client will request an accepted message to notify the game server to modify the order status

This completes the payment process of the recharge process, the user completed the payment of money to the channel platform. The channel platform then processes the order asynchronously after confirming the account, and then notifies the TYPESDK server in the form of a callback. When the callback is received by the TYPESDK server, it is possible to query the corresponding game server callback address according to the internal Order Number field in the callback and notify the corresponding game servers.

Looking back at the simple recharge-to-account flowchart we made in the first article of this series, you can modify the process as shown:

Process description

1. After the top-up order is credited, the channel service side asynchronously notifies the TYPESDK server
2. The TYPESDK service side inquires the order information according to the internal order number
3. Type server notification Game Service side issue
4. After the game server receives the shipment request, it first saves the request, immediately returns to the TYPESDK service side, indicating that the shipment request has been received.
5. TYPESDK return to channel service side
6. The game server asynchronously processes the shipping logic. and notify the game client

In this way, we have satisfactorily solved the common requirements in this practical scenario. In the next chapter, we will continue to analyze other issues that exist in this process and discuss how to resolve them.

The project is open source, and you are interested in writing your own aggregation SDK for your own research or reference project.

Project Address: Https://code.csdn.net/typesdk_code

Project Address: HTTPS://GITHUB.COM/TYPESDK

TYPESDK Hand Tour Aggregation SDK Service-side design ideas and Architecture III: Process optimization of order preservation and notification