JP7036826B2 - Service processing method and equipment - Google Patents

Description

The present application relates to the field of computer technology, in particular to transaction processing methods and devices.

Online systems (eg websites) can provide many trading services to users with the support of back-end trading systems. Several transactions can be carried out in tandem by different trading systems. In current technology, transaction requests can be initiated by the user via a client such as a browser or application (APP). The processing of the service request may be, for example, as follows. According to the order of the transaction flow, the transaction system that processes the transaction request first can generate the corresponding processing result (which can be called an intermediate result) and return the processing result to the client. According to the interim result, the client transfers to the next transaction system in the transaction flow and makes a request (which can be called an interim request) for the next transaction system to perform subsequent processing until the entire transaction flow is completed. You can start and so on.

For example, a transaction request sent by a client can be executed in cooperation with the transaction system A and the transaction system B. According to the transaction flow, the transaction request is first processed by the transaction system A to generate an interim result, which returns the interim result to the client. The client transfers to the transaction system B according to the intermediate result a, and further sends the request to the transaction system B. The transaction system B can process the request, generate the processing result b, and return the processing result b to the client.

However, in the method of the current technology, the trading system interacts with the client via the Internet, while the network environment of the Internet is relatively unstable and network delay is caused by the influence of the network environment. obtain. As a result, it can take a relatively long time for the client to send an intermediate request to the next service system according to the intermediate result. In addition, in the above method, the trading system performs the corresponding processing only after receiving the request from the client. However, online systems typically face a huge amount of user access. Therefore, the trading system can have a high workload and cause delays in the processing queue of the trading system. Obviously, delays can occur both in the sending phase and in the processing phase of the request, which inevitably leads to long client wait times and poor timing of transaction processing.

Embodiments of the present application provide transaction processing methods and devices for solving the problem of improper timing in existing transaction processing.

The embodiments of the present application provide a transaction processing method, wherein the method is:
The second server receives the first transaction result generated after the first server processes the first transaction request sent by the client, which is sent by the first server.
Determining the type corresponding to the first transaction result and
To generate a second transaction result that matches the type according to the type and the first transaction result,
The second server has to feed back the generated second transaction result to the client after receiving the second transaction request sent by the client.

The embodiments of the present application further provide a transaction processing method, wherein the method is:
When the first server receives the first transaction request sent by the client,
To generate the first transaction result corresponding to the type of the first server according to the first transaction request,
The first transaction result is sent to the second server, the second server is made to determine the type corresponding to the first transaction result, and the first transaction result is dealt with according to the first transaction result and the type corresponding to the first transaction result. Generates a second transaction result that matches the type of transaction, and causes the second server to send the generated second transaction result to the client after receiving the second transaction request generated by the client according to the first take result. Have that.

An embodiment of the present application provides a transaction processing device, wherein the device is:
A receiving module configured to receive the first transaction result, which is sent by the first server and is generated after the first server processes the first transaction request sent by the client.
A type determination module configured to determine the type corresponding to the first transaction result,
A generation module configured to generate a second transaction result that matches the type according to the type and the first transaction result,
The second server has a feedback module configured to feed back the generated second transaction result to the client after receiving the second transaction request sent by the client.

Embodiments of the present application further provide a transaction processing device, wherein the device is:
A receiving module configured to receive the first transaction request sent by the client,
A generation module configured to generate a first transaction result corresponding to the type of first server according to the first transaction request.
The first transaction result is sent to the client and the second server, the second server is made to determine the type corresponding to the first transaction result, and the second transaction result is determined according to the first transaction result and the type corresponding to the first transaction result. A shipping module configured to generate and send the generated second transaction result to the client after the second server receives the second transaction request generated by the client according to the first take result. Have.

Embodiments of the present application provide transaction processing methods and devices. According to the method, after the first server receives the first transaction request sent by the client, the first server processes the first transaction request to generate the corresponding first transaction result. At this point, in addition to returning the first transaction result to the client, the first server can also send the first transaction result to the second server according to the transaction flow, and the second server will be the first transaction result. The type corresponding to can be determined. In this way, the second server can process the first transaction result and pre-generate a second transaction result that matches the type. By applying this method, the second server can generate the second transaction result before the second server receives the second transaction request sent by the client. When the second server receives the second transaction request sent by the client, the second server can send the generated second transaction result to the client. Further, the generated second transaction result is consistent with the transaction type of the first transaction result. In contrast to the methods in current technology, the second server can pre-generate the second transaction result according to the first transaction result before the second server receives the second transaction request from the client. It is obvious that it effectively saves client latency and improves the timing for processing transaction requests.

The accompanying drawings described herein are used to provide a better understanding of the present application and form part of the present application. The embodiments as an example of the present application and the description of the embodiments as an example are used to describe the present application and are not inappropriate restrictions on the present application.
It is a schematic diagram of the architecture based on the process for transaction processing according to some embodiments of the present application. It is a schematic diagram of the process for transaction processing based on the 2nd server side which concerns on some embodiments of this application. It is a schematic diagram of the process for the transaction processing process based on the 1st server side which concerns on some embodiments of this application. It is a schematic diagram of the process for transaction processing in the example of application which concerns on some embodiments of this application. It is a schematic structure diagram of the transaction processing apparatus based on the 2nd server side which concerns on some embodiments of this application. It is a schematic structure diagram of the transaction processing apparatus based on the 1st server side which concerns on some embodiments of this application.

To better clarify the objectives, technical solutions, and advantages of the present application, the technical solutions of the present application are described clearly and completely below with reference to embodiments and accompanying drawings of the present application. It is clear that the embodiments described are merely examples and not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments that can be obtained by those skilled in the art without creative effort shall be included in the scope of the present application.

As mentioned above, when a user obtains a transaction from an online system via a client that is executed in tandem by two or more trading systems, the client typically returns an interim transaction result that is returned by a different trading system. Is received, transferred according to the interim result, and the request is sent to the next transaction system until the entire transaction flow is completed. However, in this process, when the client sends a request to the trading system, the client tends to be affected by the network environment and may experience transmission delays. Further, the trading system in the current technology can perform processing only after the trading system receives the transaction request sent by the client. In situations where the trading system has a high workload, processing delays can also be triggered when the trading system processes the transaction request. In this way, the client is susceptible to both transmission delay and processing delay, which leads to a long waiting time for the client. Obviously, the timing of transaction requests is very sensitive.

Considering the above, there is a need for a service processing method that can reduce the waiting time of the client. That is, in the embodiment of the present application, a transaction processing method is provided.

In embodiments of the present application, a transaction service obtained by a user from an online system via a client is often performed in conjunction by two or more transaction systems, so that the client follows the flow of the transaction. It should be noted that different trading systems initiate different trading requests. However, different transaction requests can be considered to be initiated by the client to execute the same transaction.

The transaction processing method according to the embodiment of the present application is based on the architecture shown in FIG. 1a. From FIG. 1a, it can be seen that the architecture includes a trading client (hereinafter also shortly referred to as a "client") used by the user, a first server, and a second server. The client may be a browser, an application (“APP”), or the like running on the terminal. The first server and the second server have different transaction functions. In one example, the first server and the second server may be two transaction servers that are adjacent to each other in the transaction flow. The second server may be a transaction server after the first server in the processing order of the transaction flow. For example, it is assumed that there are three transaction servers A, B, and C, and the transaction is executed by the three transaction servers in the order of server A, server B, and server C. Regarding the transaction servers A and B, the first server may be the transaction server A, and the second server may be the transaction server B. Regarding the transaction servers B and C, the first server may be the transaction server B, and the second server may be the transaction server C. In other words, the first server and the second server in the present application are not limited to the scenario of only two servers.

The transaction processing method according to the present application is described below with reference to the architecture shown in FIG. 1a. In one example, the transaction processing process can include the following steps, as shown in FIG. 1b.

Step S101: The second server receives the first transaction result sent by the first server.

Here, the first transaction result is generated after the first server processes the first transaction request sent by the client.

In an example application scenario, when a user uses a client to obtain a transaction, the client typically sends a transaction request to the corresponding transaction server. For example, after a user places an order for a product, the client sends a request to place the order to a server for placing the order. In this example, the server for placing an order is the first server, and the request for placing an order is the first transaction request. The first transaction request may be received by the first server. The first transaction request is either a transaction request sent by the client according to a user's operation command, or a transaction request sent by the client after the client receives an intermediate transaction result fed back by the previous transaction server in the transaction flow. It is not a limitation on the present application.

The first transaction result can be considered as an intermediate transaction result generated after the first server executes the corresponding process for the first transaction request.

In the application as an example, the delay can occur in the process of the client sending the second transaction request to the second server due to the influence of the network environment, and the processing delay also causes the second server to send the second transaction request. It can happen when receiving and processing. Obviously, both of these situations can lead to long wait times for the client. Therefore, in order to reduce the waiting time of the client, in the embodiment of the present application, in addition to sending the first transaction result to the client, the first server also sends the first transaction result directly to the second server. Can be done. Then, the second server can execute the process in advance according to the first transaction result.

S102: Determine the type corresponding to the first transaction result.

In the embodiment of the present application, the type corresponding to the first transaction result can be considered as the type corresponding to the first server. In the application as an example, it should be understood that the first server of a different transaction provider typically has a different type (eg, the type of transaction offered, the type of transaction provider). .. Therefore, there may be different requirements for the type of second transaction result.

For example, a telecommunications operator (in contrast, a first server is a telecommunications operator server) and a bank (in contrast, a first server is a bank server) are different transaction providers. Obviously, the first transaction result generated by the telecommunications operator server is typically related to the telecommunications transaction, while the first transaction result generated by the bank server is typically a financial transaction. Is related to. It should be understood that the types of second transaction results subsequently produced by the two transaction providers should also be different. Therefore, the type corresponding to the first transaction result is determined in the embodiments of the present application to facilitate subsequent operations.

S103: According to the type and the first transaction result, a second transaction result consistent with this type is generated.

After the second server receives the first transaction result, the second server can preprocess the first transaction result in order to generate a second transaction result consistent with this type.

S104: The generated second transaction result is fed back to the client after the second server receives the second transaction request sent by the client.

After the second server receives the second transaction request, the second server can directly feed back the pre-generated second transaction result to the client, thereby reducing or avoiding the client's waiting time.

Through the above steps, after the first server receives the first transaction request sent by the client, the first server processes the first transaction request to generate the corresponding first transaction result. At this point, in addition to returning the first transaction result to the client, the first server can also send the first transaction result to the second server according to the transaction flow, and the second server will be the first transaction result. The type corresponding to can be determined. In this way, the second server can process the first transaction result and pre-generate a second transaction result that matches the type. By applying this method, the second server can generate a second transaction result before the second server receives the second transaction request sent by the client. When the second server receives the second transaction request actually sent by the client, the second server can directly return the generated second transaction result to the client. Further, the generated second transaction result is consistent with the transaction type of the first transaction result. In contrast to the methods of current technology, the second server can pre-generate the second transaction result according to the first transaction result before the second server receives the second transaction request from the client. It is clear that this can effectively save client latency and improve the timing for processing transaction requests.

In order to clearly describe the above transaction processing method of the present application, an example payment transaction scenario is described in detail. Users can use the shopping website client to buy products from the shopping website. A user's product purchase operation through a client can be considered to include two transactions, eg, placing an order for a product and making a payment. A payment transaction provider (eg, a payment platform) provides a payment transaction in this process (ie, a purchase order transaction is performed by a server for placing an order in the back end of a shopping website, while a payment transaction is a payment. Performed by the payment server on the back end of the platform). Then, in this scenario, the first transaction request is a request for placing an order, the first server includes a server for placing an order, the first transaction result contains order information, and the second server is a payment server. The second transaction result contains a payment interface or exception page.

In this scenario, in step S101 above, when the second server receives the first transaction result sent by the first server, the payment server receives the data of the order sent by the server for placing the order. The order data can include the serial order number, the type identifier of the first server, the payment status data, the account information, the product information, the payment amount, etc., which is here by embodiment. Not limited.

In step S102 described above, determining the type corresponding to the first transaction result includes determining the type identifier of the server for placing the order, which is included in the order data.

Here, the type identifier actually reflects the type identifier of the first server. In embodiments of the present application, the type identifier of the first server may include the name of the trading provider to which the first server belongs, industry category information, the name of the first server, device serial number, etc., which is a limitation of the present application. do not have.

Producing a second transaction result that matches this type according to the type and the first transaction result is a page template that corresponds to the order data according to a pre-established correspondence between the type identifier and the page template. It has to determine, to label the data of the order that is consistent with the page template according to the determined page template, and to draw and build the payment page according to the data of the labeled order. ..

In an example payment scenario, different payment pages are typically generated for a different first server, i.e., a server for placing orders (eg, a shopping website server, a telecommunications operator server, etc.). It should be noted that. Therefore, different payment page templates are typically stored on payment servers for different servers for placing orders. The order data sent by the server for placing the order can also include the type identifier of the server for placing the order, so that the corresponding payment page template can be determined accordingly.

Different payment page templates can have different data for the drawn orders. For example, for payment pages on shopping websites, user data such as order number, payment amount, email address, etc. can be displayed on the payment page, while for payment pages that replenish mobile phone cards. Data such as order number, mobile phone number to be replenished, replenishment amount, etc. will be displayed on the payment page. Obviously, the ordered data drawn is different for these two types of payment pages.

In addition, in the payment scenario as an example, there can be two situations for the payment page. In one situation the payment page is successfully drawn and in the other situation there is a problem with the payment process and an exception page is displayed. Therefore, before the payment server renders the page, the payment server can also determine if the payment can be successfully executed. That is, drawing and building a payment page according to the data of the labeled order determines the payment status according to the data of the order, and the payment status is determined to mean that the payment is allowed to be executed. Then you have to draw and build the payment page according to the data of the labeled order.

It should be noted here that, as one method according to an embodiment of the present application, the process by which the payment server determines the payment status according to the order data can be realized by the user based on the pre-registered account. .. There are two situations that follow this method.

First, if the server for placing orders and the payment server belong to the same trading provider, the account registered with the trading provider by the user can be used by both the server for placing orders and the payment server. It may be there. In other words, the payment server is empowered to check the balance of the user's account and thereby determine if the payment is successful.

Second, if the server for placing orders and the payment server belong to different trading providers, the accounts registered by the user with the two trading providers should be associated with each other. In this way, the payment server is still empowered to check the balance of the account registered with the server for placing orders by the user, thereby determining whether the payment is successful.

The above two situations are not restrictions on the present application.

If it is determined that the payment status represented by the notification message is that the payment is not allowed to be executed, the method further removes the sign of the order data and draws and builds an exception page. Includes doing.

A potential method in the embodiments of the present application is to successfully render the data after the corresponding page (including the payment page or exception page described above) has been generated for subsequent optimization of the system. It can be labeled, which is not detailed here.

The order data in the embodiments of the present application further comprises a client identifier, based on which the method further comprises establishing a correspondence between the client identifier and the payment or exception page. In this way, feeding back the generated second transaction result to the client determines the client's identifier in the second transaction request and sends the generated payment page or exception page corresponding to the client's identifier to the client. Includes feedback.

According to the above, after the payment server receives the payment request sent by the client, the payment server can feed back the pre-drawn and constructed payment page or exception page to the client.

Therefore, adopting the above method can save the time it takes for the client to complete the payment flow.

The above is from the second server side. In the embodiment of the present application, a transaction processing method based on the first server side is further provided. As shown in FIG. 2, the method comprises the following steps.

Step S201: The first server receives the first transaction request sent by the client.

Step S202: Generates a first transaction result corresponding to the type of first server according to the first transaction request.

After the first server receives the first transaction request, the first server processes the first transaction request to generate the corresponding transaction result, i.e., the first transaction result. Here, the first transaction result is typically an interim transaction result. In one method of the embodiment of the present application, the first transaction request often carries the identifier information of the client. The first transaction result generated by the first server also contains the identifier information of the client.

Step S203: The first transaction result is sent to the second server, the second server is made to determine the type corresponding to the first transaction result, and the second transaction result consistent with this type is generated according to the first transaction result and the type. Then, the second server sends the generated second transaction result to the client after receiving the second transaction result generated by the client according to the first transaction result.

In the application as an example, the transaction flow in the above scenario is shown in FIG.

Step S301: The user sends an instruction to place an order to the client.

Step S302: The client sends a request for placing an order to a server for placing an order in accordance with an order for placing an order.

Step S303: The server for placing an order processes the received request for placing an order and generates order information.

Step S304: The server for placing an order sends the order information to the payment server, and causes the payment server to execute step S306.

Step S305: The server for placing an order sends the order information to the client, and causes the client to execute step S307.

Step S306: The payment server determines the corresponding payment page template according to the order information and generates a payment page.

Step S307: The client forwards to the payment server according to the order information and sends a request for the payment page to the payment server.

Step S308: The payment server returns the payment page to the client.

From the above content and examples, in the payment scenario as an example, once the server for placing an order generates order information, the server for placing the order immediately sends the order information to the payment server for processing. You can see that it will generate a send and pay page. Then, after the client sends a request for the payment page to the payment server, the payment server can immediately return the generated payment page to the client. Obviously, this method effectively reduces the client's wait time for the payment page to be generated, allowing the user to browse the payment page more quickly and complete the payment transaction on the payment page. Allows you to do.

Some embodiments of the transaction processing methods provided by the present application have been described above. Based on the same concept, the present application further provides embodiments of a transaction processing apparatus, as shown in FIG. The transaction processing device shown in FIG. 4 can be provided in the second server, and the device is
A receiving module 401 configured to receive the first transaction result, which is sent by the first server and is generated after the first server processes the first transaction request sent by the client.
A type determination module 402 configured to determine the type corresponding to the first transaction result, and
A generation module 403 configured to generate a second transaction result consistent with the type according to the type and the first transaction result.
It includes a feedback module 404 configured to send the generated second transaction result to the client after the second server receives the second transaction request sent by the client.

In the scenario of the embodiment of the present application, the first transaction request is a request for placing an order. The first server includes a server for placing an order. The first transaction result contains the data of the order. The second server includes a payment server and the second transaction result contains a payment interface or exception page.

Based on the above description, the order data contains a server type identifier for placing the order. The type determination module 402 is configured to determine the type identifier of the server for placing an order included in the order data. The generation module 403 determines the page template corresponding to the order data according to the pre-established correspondence between the type identifier and the page template, and according to the determined page template, the order data consistent with the page template. It is configured to tag the data and draw and build the payment page according to the data of the labeled order.

The generation module 403 determines the payment status according to the data of the order, and when the payment status is determined that the payment is allowed to be executed, the payment page is determined according to the data of the labeled order. Is configured to draw and build. If the generation module 403 determines that the payment status is that the payment is not allowed to be executed, the generation module 403 removes the indicator of the order data and draws and builds an exception page.

The order data carries the client's identifier, and the device further contains a relationship establishment module 405 that is configured to establish a correspondence between the client's identifier and the payment or exception page. .. The feedback module 404 is configured to determine the client's identifier in the second transaction request and feed back the generated payment or exception page corresponding to the client's identifier to the client.

The present application further provides a transaction processing device on the first server side, as shown in FIG. The device can be provided on the first server
A receiver module 501 configured to receive a first transaction request sent by a client, and
A generation module 502 configured to generate a first transaction result corresponding to a type of first server according to a first transaction request.
The first transaction result is sent to the client and the second server, the second server is made to determine the type corresponding to the first transaction result, and the second transaction result is generated according to the first transaction result and the type. The second transaction result includes a shipping module 503 configured to send the second transaction result to the client after the second server receives the second transaction request generated by the client according to the first transaction result.

In the 1990s, technological improvements can be clearly categorized as hardware improvements (eg, circuit structure improvements such as diodes, transistors, switches, etc.) or software improvements (method flow improvements). However, with the development of technology, many current improvements in the flow of methods can be considered as direct improvements in the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the flow of the improved method into the hardware circuit. Therefore, it is not possible to conclude that the improvement of the method flow cannot be achieved with hardware modules. For example, a programmable logic device (PLD) (eg, a field programmable gate array (FPGA)) is an integrated circuit in which the user can determine the integrated circuit logic function by programming the device. Designers can program themselves to "integrate" digital systems on a single PLD without having to ask the chip maker to design and manufacture a dedicated IC chip. Nowadays, moreover, this type of programming is mostly achieved through "logic compiler" software rather than manually manufacturing IC chips. Logic compiler software is similar to the software compiler used to develop and write programs, but prior to compilation, a special programming language can be used to write the source code, which is hardware. It is called a description language (HDL). There is not only one HDL, but ABEL (Advanced Boolean Expression Language (advanced Boolean language)), AHDL (Altera Hardware Description Language (Altera Hardware Description Language)), Confluence (Altera Hardware Description Language), Confluence (Confluence) Cornell University Programming Language)), HDCal, JHDL (Java® Hardware Description Language (Java Hardware Description Language)), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description) There are many types of HDL such as. Currently, the most commonly used HDLs are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. A person skilled in the art with normal skill realizes the flow of the logic method by performing some simple logic programming for the flow of the method and using the above HDL to program the flow of the method into the IC. It should also be recognized that it is very easy to get the hardware circuit to do this.

The controller can be implemented in any suitable way. For example, the controller may be in the form of a microprocessor or processor, for example, and at the same time a computer-readable medium, logic gate, that stores computer-readable program code (eg, software or firmware) that can be executed by the (micro) processor. , Switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the memory control logic. For those of ordinary skill, the controller is implemented in the form of pure computer readable program code, plus in the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. It should also be recognized that performing logic programming is fully feasible for the steps of how to allow a controller to achieve the same functionality. Thus, such a controller can be thought of as a hardware component, while devices contained within the controller and configured to perform various functions are also considered to be the internal structure of the hardware component. Can be done. Alternatively, a device configured to achieve various functions can even be thought of as both the software for implementing the method and the internal structure of the hardware component.

The system, device, module, or unit described in the above embodiments can be realized by a computer chip or an entity, or by a product having a function. A typical realization device is a computer. Computers are, for example, personal computers, laptop computers, cellular phones, camera phones, smartphones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or a combination thereof. You can do it.

For convenience of description, the above device is divided into various units by function for description. The functionality of the unit can be realized in one or more software and / or hardware when the present application is realized.

One of ordinary skill in the art should understand that embodiments of the present invention can be provided as a method, system, or computer program product. Therefore, the present invention can be realized as a complete hardware embodiment, a complete software embodiment, or a combination of software and hardware embodiments. Further, the present invention includes one or more computer-usable storage media (but not limited to, magnetic disk memory, CD-ROM, optical memory, etc.) having a computer-usable program code. It may be in the form of a computer program product realized above).

The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It is understood that computer program instructions can be used to implement each process and / or block in flowcharts and / or block diagrams, and a combination of processes and / or blocks in flowcharts and / or block diagrams. Should be. These computer program instructions can be provided to a general purpose computer, a special purpose computer, an embedded processor, or the processor of another programmable data processing device for producing a machine, a computer, or another programmable data processing device. Causes an instruction executed by a computer to generate a device for realizing a function specified in one or more processes in a flowchart and / or one or more blocks in a block diagram.

These computer program instructions can also be stored in computer readable memory that can instruct the computer or other programmable data processing device to operate in a special way, and the instructions stored in computer readable memory are instructed. Generate manufactured products, including equipment. The instruction device implements the functions specified in one or more processes in the flow chart and / or in one or more blocks in the block diagram.

These computer program instructions can also be loaded into a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable data device, thereby producing the processing achieved by the computer. do. Thus, instructions executed on a computer or other programmable device provide steps to implement the functions specified in one or more processes in the flow chart and / or one or more blocks in the block diagram. ..

In a typical configuration, the arithmetic unit includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

Memory can include volatile memory, random access memory (RAM), and / or computer-readable media such as non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer readable medium.

Computer-readable media include permanent, volatile, movable, and non-movable media, which can be capable of storing information by any method or technique. The information may be computer readable instructions, data structures, program modules, or other data. Examples of computer storage media are, but are not limited to, phase change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (RAM), and other types. Random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other memory technology, compact disk read-only memory (CD-ROM), digital multipurpose disk (DVD), or other optical memory, cassettes, cassettes and disk memories, or other magnetic memory devices, or any other non-transmission medium, to store information accessible to the computing device. It can be used. As described herein, computer readable media do not include transient media such as modulated data signals and carriers.

A term that is "contains," "provides," or any other variant of those terms is intended to include non-exclusive inclusion and includes a process, method, product, or a set of elements. Not only do the devices include these elements, but they also include other elements that are not explicitly listed, or they include more elements that are inherent in the process, method, product, or device. It should be noted further. In the absence of further restrictions, the elements defined by the description "having one" or "containing one" are the processes, methods, products, etc. that contain the above elements. Or it does not preclude that the device further contains additional identical elements.

One of ordinary skill in the art should understand that embodiments of the present application may be provided as a method, system, or computer program product. Therefore, the present application can be realized as a complete hardware embodiment, a complete software embodiment, or a combination of software and hardware embodiments. Further, the present application relates to one or more computer-usable storage media having a computer-usable program code (including, but not limited to, magnetic disk memory, CD-ROM, optical memory, etc.). It may be in the form of a computer program product realized above.

The present application can be described in the normal context of computer-executable instructions executed by a computer, such as a program module. In general, a program module has routines, programs, objects, components, data structures, etc. to perform special tasks or to implement special abstract data types. The present application can also be practiced in a distributed computational environment. In these distributed computing environments, remote processing devices connected via a communication network perform the work. In a distributed computing environment, program modules can be placed on local and remote computer storage media, including storage devices.

The embodiments described herein are described in such a way that each embodiment is gradually advanced by paying attention to the difference from the other embodiments, and the embodiments are referred to each other with the same or similar parts. obtain. In particular, the embodiments of the system are described in a relatively simple manner, as the embodiments of the system are substantially similar to the embodiments of the method. Descriptions of embodiments of the method may be referenced for relevant parts.

The above embodiments are merely embodiments of the present application and are not used to limit the present application. For those skilled in the art of ordinary skill, the present application may have various modifications and modifications. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be incorporated by claim of the present application.

Claims (12)

It ’s a transaction processing method.
The second server receives the first transaction result generated after the first server processes the first transaction request sent by the client, which is sent by the first server.
Determining the type corresponding to the first transaction result and
The second server generates a second transaction result consistent with the type according to the type and the first transaction result before receiving the second transaction request sent by the client.
The second server has to feed back the generated second transaction result to the client after receiving the second transaction request.
The first transaction request is a request for placing an order, the first server includes a server for placing the order, and the first transaction result includes the data of the order.
The second server comprises a payment server, the second transaction result is drawn and constructed to match the type according to the data of the order prior to receiving the second transaction request and displayed to the client. How to have a payment page . The data of the order comprises the type identifier of the server for placing the order.
The determination of the type corresponding to the first transaction result is
It comprises determining the type identifier of the server for placing the order, which is contained in the data of the order.
To generate a second transaction result that is consistent with the type according to the type and the first transaction result
Determining the page template corresponding to the data in the order according to a pre-established correspondence between the type identifier and the page template.
Marking the order data consistent with the page template according to the determined page template.
The method of claim 1, wherein the payment page is drawn and constructed according to the labeled data of the order. Drawing and constructing the payment page according to the labeled data of the order
Determining the payment status according to the data of the order
The payment status has the ability to draw and build the payment page according to the labeled data of the order when it is determined that the payment is authorized to be executed. The method according to claim 2, wherein the method is characterized by the above. When it is determined that the payment status is that the payment is not allowed to be made, the method further comprises.
To remove the label on the data of the order with the label,
The method of claim 3, wherein the exception page is to be drawn and constructed. The data of the order carries the identifier of the client.
The method further
It comprises establishing a correspondence between the identifier of the client and the payment page .
Feeding back the generated second transaction result to the client
Determining the identifier of the client in the second transaction request
The method of claim 3 or 4, wherein the client is fed back the generated payment page corresponding to the identifier of the client. It ’s a transaction processing method.
When the first server receives the first transaction request sent by the client,
To generate a first transaction result corresponding to the type of the first server according to the first transaction request.
The first transaction result is sent to the second server, the second server is made to determine the type corresponding to the first transaction result, and before the second server receives the second transaction request sent by the client. To generate a second transaction result that matches the type corresponding to the first transaction result according to the first transaction result and the type corresponding to the first transaction result, and the generated second transaction result. The second server has received the second transaction request generated by the client according to the first transaction result, and then sends the second transaction request to the client.
The first transaction request is a request for placing an order, the first server includes a server for placing the order, and the first transaction result includes the data of the order.
The second server comprises a payment server, the second transaction result is drawn and constructed to match the type according to the data of the order prior to receiving the second transaction request and displayed to the client. How to have a payment page . It ’s a transaction processing device,
A receiving module configured to receive the first transaction result sent by the first server, which is generated after the first server processes the first transaction request sent by the client.
A type determination module configured to determine the type corresponding to the first transaction result,
According to the type and the first transaction result, the transaction processing device is configured to generate a second transaction result consistent with the type before receiving the second transaction request sent by the client. Modules and
The transaction processing device has a feedback module configured to feed back the generated second transaction result to the client after receiving the second transaction request.
The first transaction request is a request for placing an order, the first server includes a server for placing the order, and the first transaction result includes the data of the order.
The transaction processing device comprises a payment server, the second transaction result is drawn and constructed to match the type according to the data of the order prior to receiving the second transaction request and displayed to the client. A device that has a payment page . The data of the order comprises the type identifier of the server for placing the order.
The type determination module determines the type identifier of the server for placing the order, which is included in the data of the order.
The generation module determines the page template corresponding to the data of the order according to a pre-established correspondence between the type identifier and the page template, and matches the page template according to the determined page template. 7. The apparatus of claim 7, wherein the data of the order is labeled and the payment page is drawn and constructed according to the labeled data of the order. The generation module determines the payment status according to the data of the order, and when the payment status is determined that the payment is permitted to be executed, the ordered with the label. 8. The apparatus of claim 8, wherein the payment page is drawn and constructed according to the data of. When the generation module determines that the payment status is that the payment is not allowed to be executed, the generation module removes the indicator of the data of the order and draws and builds an exception page. 9. The apparatus according to claim 9. The data of the order carries the identifier of the client.
The device further comprises a relationship establishment module configured to establish a correspondence between the identifier of the client and the payment page .
The feedback module is characterized in that it determines the identifier of the client in the second transaction request and feeds back to the client the generated payment page corresponding to the identifier of the client. 9. Or 10. It ’s a transaction processing device,
A receiving module configured to receive the first transaction request sent by the client,
Generation that the second server is configured to generate a first transaction result corresponding to the type of transaction processing device according to the first transaction request before receiving the second transaction request sent by the client. Modules and
The first transaction result is sent to the client and the second server, and the second server is made to determine the type corresponding to the first transaction result, and corresponds to the first transaction result and the first transaction result. A second transaction result is generated according to the type, and the generated second transaction result is received after the second server receives the second transaction request generated by the client according to the first transaction result. Has a shipping module that is configured to send to the client
The first transaction request is a request for placing an order, the transaction processing device includes a server for placing the order, and the first transaction result includes the data of the order.
The second server comprises a payment server, the second transaction result is drawn and constructed to match the type according to the data of the order prior to receiving the second transaction request and displayed to the client. A device that has a payment page .

Images