CN109583873B

CN109583873B - Transaction communication method, server, POS machine and electronic equipment

Info

Publication number: CN109583873B
Application number: CN201710897733.3A
Authority: CN
Inventors: 罗宇平
Original assignee: Beijing Sankuai Online Technology Co Ltd
Current assignee: Beijing Sankuai Online Technology Co Ltd
Priority date: 2017-09-28
Filing date: 2017-09-28
Publication date: 2021-02-02
Anticipated expiration: 2037-09-28
Also published as: CN109583873A

Abstract

The disclosure provides a transaction communication method, a server, a POS machine and electronic equipment, and belongs to the technical field of internet. The transaction communication method comprises the following steps: receiving a transaction request from a POS machine and sending the transaction request to a request processing party, wherein the transaction request is triggered in response to a card swiping transaction of the POS machine; receiving and caching response information returned by the request processing party; and updating the state of the card swiping transaction according to the response information. According to the method and the device, the response information returned by the request processing party is cached at the server side, so that the state of the server (namely the transaction background) for the transaction is not updated according to the result reported by the POS machine any more, but the state cached by the server is taken as the standard, the updating can be carried out in real time, a merchant can also know the state of the transaction in time, and the complaint rate caused by abnormal orders is greatly reduced.

Description

Transaction communication method, server, POS machine and electronic equipment

Technical Field

The present disclosure relates generally to the field of internet technology, and in particular, to a transaction communication method, a server, a POS device, an electronic device, and a computer-readable medium.

Background

POS (point of sale) machines almost entirely support card swiping transactions, which are also an indispensable choice for payments in our lives. For the implementing party of the card swiping transaction on the POS machine, some interaction specifications of Unionpay POS must be complied with, but the old specifications are not adjusted along with the development of the technology, and the experience of the whole card swiping transaction and the indexes of the transaction are poor.

Fig. 1 shows a flow chart of communication interaction of an existing POS in a related implementation example, and the interaction process needs to involve the POS, a transaction background and an acquirer. As shown in fig. 1, after the card is swiped by the POS machine, the card swiping transaction is sent to the transaction background, the transaction background transmits the transaction ciphertext to the acquiring unit, and then the acquiring unit returns the packet to the transaction background, and the transaction background returns the packet to the POS. If the POS machine receives the packet to indicate that the transaction is successful, the POS machine reports the successful transaction result to the transaction background, and the transaction background updates the state of the current transaction result in the database. However, if the POS does not receive the reply packet, it may cause the transaction to be performed, that is, the POS sends a reply request to the transaction background, the transaction background sends the reply request to the acquiring mechanism in the form of ciphertext transparent transmission, the acquiring mechanism receives the reply request and transmits the reply packet (i.e., the reply packet) to the transaction background, and the transaction background transmits the reply packet back to the POS. And after receiving the correction packet, the POS machine reports the result of successful correction to the transaction background, and the transaction background updates the state of the result of the current correction in the database.

In the transaction and correction processes, card swiping transactions of the POS machine are based on the POS machine, the transaction background serves as a transparent transmission role, the transaction background is not informed of transaction results and correction results, and the order state of the database is updated depending on the results reported by the POS machine, so that interactive messages are easily lost once any one process is abnormal in network communication. As shown in fig. 1, when the POS does not receive a return packet of the transaction request, the POS initiates a correction request, which results in a high correction rate of the transaction. In addition, whether the transaction request or the positive request is made, the order state updating of the transaction background database simply depends on the report of the POS machine. When the result (transaction or correction) reported by the POS machine is not sent to a transaction background, the transaction state is inconsistent; when the transaction request is not successfully sent out, money of the customer is deducted, but because the order state of the transaction background is not updated, the merchant cannot know the transaction state in real time, so that a large amount of customer complaint work orders occur.

Therefore, there is still a need for improvement in the prior art solutions.

The above information disclosed in this background section is only for enhancement of understanding of the background of the disclosure and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

The present disclosure provides a transaction communication method, a server, a POS machine, an electronic device, and a computer-readable medium, which solve the above technical problems.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to an aspect of the present disclosure, there is provided a transaction communication method including:

receiving a transaction request from a POS machine and sending the transaction request to a request processing party, wherein the transaction request is triggered in response to a card swiping transaction of the POS machine; receiving and caching response information returned by the request processing party; and updating the state of the card swiping transaction according to the response information.

In one embodiment of the disclosure, the response information is transaction response data characterizing a transaction result, and the transaction communication method further includes:

sending the transaction response data to the POS; if the POS machine does not receive the transaction response data, triggering a transaction inquiry request; and the server responds to the transaction inquiry request and sends the cached transaction response data to the POS machine.

In one embodiment of the present disclosure, further comprising:

if the server does not receive the positive request, the POS machine repeatedly sends the positive request within a preset time period until the server receives the positive request, wherein the positive request is triggered and sent by the POS machine when the POS machine still does not receive the transaction response data after the inquiry strategy of the transaction inquiry request is invalid.

In one embodiment of the disclosure, the response information is positive response data characterizing a positive result, and the transaction communication method further includes:

and if the server receives the positive flushing request but the POS machine does not receive the positive flushing response data, the server responds to the positive flushing inquiry request of the POS machine and sends the cached positive flushing response data to the POS machine.

if the server receives the positive-going request but the POS machine does not receive the positive-going response data, the server waits for the next positive-going request and responds to the next positive-going request to send the cached positive-going response data to the POS machine.

In one embodiment of the present disclosure, further comprising:

and analyzing the cached transaction response data and the ciphertext of the positive reversal response data, and updating the state of the card swiping transaction according to the analyzed transaction result and the positive reversal result.

According to another aspect of the present disclosure, there is also provided a server, including:

a communication module configured to receive a transaction request from a POS and send the transaction request to a request handler, wherein the transaction request is triggered in response to a card swipe transaction of the POS;

the cache module is configured to receive and cache response information returned by the request processing party;

and the updating module is configured to update the database state according to the response information.

In one embodiment of the disclosure, the response information is transaction response data characterizing a transaction result, and the communication module includes:

a transaction response data sending module configured to send the transaction response data to the POS machine;

and the transaction inquiry module is configured to respond to the transaction inquiry request and send the cached transaction response data to the POS machine when the POS machine does not receive the transaction response data and triggers the transaction inquiry request.

In one embodiment of the present disclosure, the communication module further includes:

and the forward request receiving module is configured to repeatedly send the forward request within a preset time period by the POS machine when the server does not receive the forward request until the server receives the forward request, wherein the forward request is triggered and sent by the POS machine when the POS machine still does not receive the transaction response data after the query policy of the transaction query request is invalid.

In an embodiment of the disclosure, the response information is positive response data characterizing a positive result, and the communication module further includes:

and the forward-flushing query module is configured to respond to the POS machine forward-flushing query request and send the cached forward-flushing response data to the POS machine when the server receives the forward-flushing request but the POS machine does not receive the forward-flushing response data.

a waiting positive-going module configured to wait for a next positive-going request when the server receives the positive-going request but the POS machine does not receive the positive-going response data, and send the cached positive-going response data to the POS machine in response to the next positive-going request.

In one embodiment of the present disclosure, further comprising:

and the analysis module is configured to analyze the transaction response data and the ciphertext of the correction response data in the cache module and send the analyzed transaction result and the corrected result to the update module for database state update.

According to another aspect of the present disclosure, there is also provided a transaction communication method, including:

triggering and sending a transaction request in response to a card swiping transaction; and inquiring response information returned by the request processing party from a server, wherein the server caches the response information.

if the POS machine does not receive the transaction response data, triggering a transaction query request and sending the transaction query request to the server; the POS machine receives the transaction response data returned by the server in response to the transaction inquiry request.

In one embodiment of the present disclosure, further comprising:

and when the POS machine does not receive the transaction response data after the query strategy of the transaction query request is invalid, triggering a correction request by the POS machine.

In one embodiment of the present disclosure, further comprising:

if the POS machine does not successfully send the positive making request, the POS machine repeatedly sends the positive making request within a preset time period until the positive making request is successfully sent.

if the POS machine has successfully sent the positive conflict request but does not receive the positive conflict response data, triggering and sending a positive conflict query request by the POS machine; and the POS machine receives the positive response data returned by the server in response to the positive query request.

if the POS machine has successfully sent the positive making request but does not receive the positive making response data, the POS machine receives the positive making response data which is cached by the server and waits for the next positive making request.

In one embodiment of the present disclosure, the POS sends the transaction query request and the positive query request using a polled query policy.

According to another aspect of the present disclosure, there is also provided a POS machine, including:

the transaction request module is configured to respond to card swiping transaction and trigger and send out a transaction request;

and the response data query module is configured to query the server for response information returned by the request processing party, wherein the server caches the response information.

In one embodiment of the disclosure, the response information is transaction response data characterizing a transaction result, and the POS machine further includes:

a transaction inquiry module configured to trigger a transaction inquiry request if the POS machine does not receive the transaction response data, and send the transaction inquiry request to the server;

a transaction response data receiving module configured to receive the transaction response data returned by the server in response to the transaction query request.

In one embodiment of the present disclosure, further comprising:

and the positive-making request triggering module is configured to trigger a positive-making request when the POS machine still does not receive the transaction response data after the query strategy of the transaction query request is invalid.

In one embodiment of the present disclosure, further comprising:

and the positive flushing request sending module is configured to repeatedly send the positive flushing request within a preset time period when the POS machine does not successfully send the positive flushing request until the positive flushing request is successfully sent.

In an embodiment of the disclosure, the response information is positive-going response data representing a positive-going result, and the POS machine further includes:

the positive-going query module is configured to trigger and send a positive-going query request when the POS machine has successfully sent the positive-going request but does not receive the positive-going response data;

and the positive response data receiving module is configured to receive the positive response data returned by the server in response to the positive query request.

and the positive response data waiting module is configured to wait and receive the positive response data returned by the server in response to the next positive response request when the POS machine has successfully sent the positive request but does not receive the positive response data.

According to the transaction communication method, the server, the POS machine, the electronic device and the computer readable medium provided by the embodiment of the disclosure, the response data returned by the request processing party is cached at the server side, so that the state of the server (namely, the transaction background) for the transaction is not updated according to the result reported by the POS machine any more, but the state cached by the server is taken as the standard, the update can be carried out in real time, a merchant can also know the state of the transaction in time, and the complaint rate caused by abnormal order is greatly reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

Fig. 1 shows a flow chart of communication interaction of an existing POS machine in a related implementation example.

Fig. 2 shows a flow chart of a transaction communication method provided in an embodiment of the present disclosure.

Fig. 3 shows a flowchart after step S203 in an embodiment of the present disclosure.

Fig. 4 shows a flowchart of the steps in the case where a flushing request is not issued in an embodiment of the present disclosure.

Fig. 5 is a flow chart illustrating steps in the case where a flushing request is successfully issued but no flushing reply packet is received in an embodiment of the present disclosure.

FIG. 6 shows an interaction diagram of a method in an embodiment of the present disclosure throughout a transaction flow.

Fig. 7 shows a schematic diagram of a server provided in another embodiment of the present disclosure.

Fig. 8 shows a schematic diagram of a communication module in another embodiment of the present disclosure.

Fig. 9 shows a schematic diagram of another server provided in another embodiment of the present disclosure.

Fig. 10 illustrates a flow chart of another transaction communication method provided in an embodiment of the present disclosure.

Fig. 11 shows a flowchart after step S101 in an embodiment of the present disclosure.

Fig. 12 is a flow chart illustrating steps of a flush phase in an embodiment of the present disclosure.

Fig. 13 is a schematic diagram of a POS machine provided in another embodiment of the disclosure.

Fig. 14 shows a schematic diagram of an electronic device provided in another embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. In other instances, well-known structures, methods, devices, implementations, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to specific embodiments and the accompanying drawings.

The acquirer in fig. 1 is used as a business processor, and refers to the business processor engaged in development and management, authorization request, bill settlement and other activities of a special merchant in the bank card payment transaction, and its benefits mainly come from the commission of the merchant, other service fees (such as rental fee and monthly fee of a POS machine) paid by the merchant, and the increase of deposit of the merchant, and the request processor capable of realizing the acquiring business has some non-bank professional service institutions in addition to most issuing banks (i.e. acquirers).

In the transaction flow shown in fig. 1, the transaction background only serves as a transparent transmission role, and the transaction result and the positive result are reported by the POS and the state of the database is updated. In addition, the core part in the transaction, namely the order state, is always stored at one side of the POS machine in the whole transaction flow, but as the POS machine is exposed in the public network for a long time and the security of the public network is poor, the POS machine is very easy to be attacked by lawbreakers, so that the lawbreakers have a chance to tamper with the order state recorded by the POS machine and the security of the transaction is poor.

Fig. 2 shows a flowchart of a transaction communication method provided in an embodiment of the present disclosure, which is used for a server in a transaction system, i.e., a transaction background. The method comprises the following steps:

as shown in fig. 2, in step S201, a transaction request from the POS is received, wherein the transaction request in the present embodiment is triggered in response to a card-swiping transaction of the POS.

As shown in fig. 2, in step S202, a transaction request is sent to a request handler.

As shown in fig. 2, in step S203, response information returned by the request processing party is received and cached.

As shown in fig. 2, in step S204, the status of the card-swiping transaction is updated according to the response information.

It should be noted that, in this embodiment, in the request phase (i.e., the phase in which the POS issues the request to the server and the server sends the request to the request handler), the server still plays the role of transparent transmission, but in the response phase (i.e., the phase in which the request handler sends the response information to the server and the server sends the response information to the POS), the server no longer plays the role of transparent transmission of the response information, but caches the received response information, where "request" refers to the transaction request and the corrective request, and "response information" refers to the transaction response data and the corrective response data. The transaction return packet appearing in the following embodiments is response data indicating whether the transaction was successful, and the positive return packet is response data indicating whether the transaction was successful.

According to the flow shown in fig. 1, the POS first enters a transaction stage after triggering the card swiping transaction, and if the POS does not receive a transaction receipt at the transaction stage, the POS triggers the next stage, i.e., a transaction positive stage. Therefore, in the transaction stage, the response information received in step S203 is a transaction response packet, which represents whether the request processing party successfully transacts the transaction request.

In the present embodiment, fig. 3 shows a flowchart after step S203, including the following steps:

as shown in fig. 3, in step S301, a transaction reply packet is sent to the POS, and if the POS does not receive the transaction reply packet, a transaction inquiry request is triggered, then step S302 is performed. Although the server transmits the transaction return packet to the POS after receiving the transaction return packet returned by the request processing party, the POS may not receive the transaction return packet due to the influence of the communication condition, and thus the POS needs to actively perform a transaction inquiry to the server.

As shown in fig. 3, in step S302, the server sends the cached transaction reply to the POS machine in response to the transaction query request. That is, the transaction return packet is sent to the POS through the server so as to inform the merchant of the transaction result, and the merchant knows whether the result of the card swiping transaction is successful.

The method firstly inquires under the condition that the transaction return packet is not received, the inquiry can be continuously retried, the transaction can be completed if the transaction return packet can be received through the inquiry and the retried inquiry, and the correction is not required, so that the correction rate can be reduced.

Based on the step S301, the POS sends a transaction query request to the server according to a certain query policy, in this embodiment, the query policy may be polling, that is, query is performed for a preset time (e.g., 1 minute) until a transaction packet returned by the server is received. However, if the POS machine still does not receive the transaction repackage after the query policy of the transaction query request fails (i.e., the transaction repackage is not received through multiple queries within the preset time), the POS machine triggers and issues the alignment request, i.e., enters the alignment stage.

In this embodiment, the positive phase includes two cases due to the influence of the communication condition: in the first case, a positive request is not issued; in the second case, the forward flushing request is successfully sent but the corresponding backward packet is not received, at this time, the backward packet in the forward flushing stage is a forward flushing backward packet, which represents whether the forward flushing request is successfully flushed by the request processing party.

Fig. 4 shows a flowchart of steps in the case where a flushing request is not issued in the present embodiment, including the following steps:

as shown in fig. 4, in step S401, the POS repeatedly sends out the request for positive flushing for a preset time period until the server receives the request for positive flushing.

As shown in fig. 4, in step S402, after receiving the request for cancellation, the server sends the request for cancellation to the request processing side.

As shown in fig. 4, in step S403, the request handler generates a corresponding hedge reply packet for the current hedge request, and sends the generated hedge reply packet to the server.

As shown in fig. 4, in step S404, the server updates the status of the card swiping transaction according to the hedge and receipt packet, and sends the hedge and receipt packet to the POS machine, so as to inform the merchant of the hedge result, and the merchant knows whether the hedge result is successful.

Fig. 5 is a flowchart illustrating steps in the case where the flushing request is successfully issued but no flushing loopback packet is received in the present embodiment, and includes the following steps:

as shown in fig. 5, in step S501, the POS sends a positive query request to the server, that is, performs a positive query, similar to the process of transaction query.

As shown in fig. 5, in step S502, the server sends the cached positive flushing loopback packet to the POS machine in response to the positive flushing query request of the POS machine, so as to inform the merchant of the positive flushing result, and the merchant knows whether the positive flushing result is successful.

In the embodiment, the POS machine is not influenced by the communication condition of one accidental time to receive the transaction repackage or the correction repackage, but the transaction inquiry and the correction inquiry are carried out before the receipt of the transaction repackage or the correction repackage, and the repeated inquiry is carried out, so that the customer complaints caused by abnormal orders can be greatly reduced, and the good card swiping experience is brought to the customer.

For the case that the flushing request is successfully sent but the flushing return packet is not received, the following scheme can be adopted:

the server waits for the next positive request and sends the cached positive feedback packet to the POS machine in response to the next positive request. Since the general POS can perform automatic correction, even if the correction repackage is not received, a correction request for correcting the current card swiping operation is sent from the POS, and the server can also send the correction repackage to the POS so as to inform the merchant of the correction result, so that the merchant knows whether the correction result is successful.

It should be noted that if the step of sending the flushing return packet to the POS machine by the server in step S404 is unsuccessful, the subsequent processing refers to a processing scheme for the case where the flushing request is successfully sent but the flushing return packet is not received, and details are not described here.

It should be further noted that, in this embodiment, the server further analyzes the ciphertext of the transaction repackage and the ciphertext of the correction repackage, and caches the analyzed transaction result and the correction result, so that the whole transaction result does not depend on the report of the POS machine as in the existing scheme, but the result cached in the background of the server is used as the standard. Compared with the existing scheme that the result of the transaction is based on the result reported by the POS machine in the public network, the method in the embodiment can prevent the transaction result from being maliciously tampered by people, thereby improving the security of the transaction.

Fig. 6 shows an interaction diagram of the method in the present embodiment in the whole transaction flow.

As shown in fig. 6, in the transaction stage, the POS triggers card swiping transaction, sends a transaction request to the server (all represented by the transaction background in fig. 6), the transaction background sends the transaction request to the request processing party in a transaction ciphertext transparent transmission manner, the request processing party sends a transaction return packet to the transaction background, the transaction background caches the transaction return packet, and updates the database state according to the transaction result in the transaction return packet. The transaction background also sends the transaction return packet to the POS machine, and if the POS machine does not receive the transaction return packet, the inquiry stage is entered to carry out transaction inquiry.

The POS machine sends a query request to the transaction background, retries repeatedly within a certain time in a polling mode before the query strategy is invalid, and the transaction background sends a transaction return packet to the POS machine.

If the inquiry strategy is reached, the POS machine still does not receive the transaction return package, then the reversal stage is initiated. If the transaction background does not receive the hedge request, the POS machine retries sending until the hedge request is sent. If the transaction background has received the reversal request but the POS machine does not receive the corresponding reversal repackage, entering an inquiry stage for inquiring, and similarly to the transaction inquiry, sending the cached reversal repackage to the POS machine by the transaction background; or the transaction background waits for the next positive making request and responds to the next positive making request to send the cached positive making repackage to the POS machine.

In summary, in the transaction communication method provided in this embodiment, the repackage returned by the request processing party is cached at the server side, so that the state of the server (i.e., the transaction background) for the transaction is not updated according to the result reported by the POS machine any more, but the state cached by the server is taken as the standard, and the server can update in real time, so that the merchant can also know the state of the transaction in time, and the complaint rate caused by the abnormal order is greatly reduced. By improving the interaction process, the positive punching rate is reduced as much as possible, but the positive punching success rate is also improved as much as possible under the condition that repeated inquiry does not result.

Fig. 7 is a schematic diagram of a server provided in another embodiment of the present disclosure, which is a transaction background in the transaction system, and completes the entire transaction process together with the POS and the request processing party. As shown in fig. 7, the server 700 includes a communication module 710, a caching module 720, and an updating module 730.

Wherein the communication module 710 is configured to receive a transaction request from a POS and to transmit the transaction request to a request handler, wherein the transaction request is triggered in response to a card swipe transaction by the POS. Briefly, the communication module 710 completes the communication between the server and the POS machine and the request handler 730. The caching module 720 is configured to receive and cache the response information returned by the request processing party, which is also the main difference between the server in this embodiment and the existing solution, that is, the server not only plays the role of transparent transmission, but also caches the response information in the process of returning the transaction return packet or the transaction return packet. The update module 730 is configured to update the status of the card swiping transaction according to the response information, so the transaction result or transaction correction result in this embodiment is based on the updated status of the update module 730 in the server.

In this embodiment, the communication module has two functions, one is to interact with the POS, that is, receive a transaction request and a transaction request reversal request sent by the POS, and return a transaction repackage and a reversal repackage to the POS; and secondly, interacting with the request processing party, namely sending a transaction request and a correction request to the request processing party, and receiving a transaction repackage and a correction repackage returned by the request processing party.

Fig. 8 shows a schematic diagram of a communication module in another embodiment of the present disclosure. In this embodiment, the transaction stage server receives a response packet returned by the request processing party as a transaction response packet, where the transaction response packet represents whether the transaction request is successful or not by the request processing party. As shown in fig. 8, the communication module 710 includes: a transaction reply transmission module 711 and a transaction query module 712, the transaction reply transmission module 711 being configured to transmit the transaction reply to the POS machine. The transaction query module 712 is configured to send the cached transaction reply to the POS in response to the transaction query request when the transaction reply is not received by the POS to trigger the transaction query request. Through the inquiry of the POS machine, the server sends the transaction return packet to the POS machine so as to inform the merchant of the transaction result, and the merchant knows whether the result of the card swiping transaction is successful or not. The query policy may be polling, i.e. query for a preset time (e.g. 1 minute) until receiving a transaction packet returned by the server.

By arranging the transaction query module, the query is carried out under the condition that the transaction return packet is not received, the query can be continuously retried, if the transaction return packet can be received through the query and the retry query, the transaction can be completed without being corrected, and therefore the correction rate can be reduced.

When the query strategy of the transaction query request is invalid (that is, the transaction repackage is not received even after multiple queries within the preset time), the POS machine still does not receive the transaction repackage, the POS machine triggers and sends out the positive-making request, namely, the positive-making stage is entered.

The straightening phase also includes two cases: in the first case, a positive request is not issued; in the second case, the forward flushing request is successfully sent but the corresponding backward packet is not received, at this time, the backward packet in the forward flushing stage is a forward flushing backward packet, which represents whether the forward flushing request is successfully flushed by the request processing party.

As shown in fig. 8, the communication module 710 further includes a positive request receiving module 713 configured to, when the server does not receive the positive request, the POS repeatedly sends the positive request within a preset time period until the server receives the positive request. That is, repeated retries are performed to ensure that the forward request receiving module 713 can receive the forward request, and then the forward request is sent to the request processing party, and the request processing party generates a corresponding forward packet for the forward request and sends the forward packet to the server. The server updates the state of the card swiping transaction according to the positive-making repackage, and sends the positive-making repackage to the POS machine so as to inform the merchant of the positive-making result, and the merchant knows whether the positive-making result is successful or not.

As shown in fig. 8, the communication module 710 further includes a forward-looking query module 714 configured to send the buffered forward-looking packets to the POS machine in response to the POS machine forward-looking query request when the server receives the forward-looking request but the POS machine does not receive the forward-looking packets.

By arranging the correction query module, transaction query and correction query are carried out after the order is not received, and repeated query is carried out, so that customer complaints caused by abnormal orders can be greatly reduced, and good card swiping experience is brought to customers.

As shown in fig. 8, the communication module 710 further includes a wait for positive going module 715 configured to wait for a next positive going request when the server receives the positive going request but the POS does not receive the positive going packet, and send the buffered positive going packet to the POS in response to the next positive going request.

Compared with the prior scheme that the transaction result is based on the result reported by the POS machine in the public network, the embodiment can prevent the transaction result from being maliciously tampered by people, thereby improving the security of the transaction.

In addition, the functions that are not related in each module in the server refer to the relevant description in the above method embodiment, and are not described again here.

The server in this embodiment can achieve the same technical effect as the transaction communication method of the server, and details are not described here.

Fig. 9 also shows a schematic diagram of another server, which includes, in addition to the communication module 710, the caching module 720 and the updating module 730, the parsing module 740 configured to parse the ciphertext of the transaction reply packet and the ciphertext of the correction reply packet received by the communication module 710, and send the parsed transaction result and the resolved correction result to the caching module 720 for caching.

Fig. 10 shows a flow diagram of another transaction communication method provided in an embodiment of the present disclosure for use with a POS in a transaction system. The method comprises the following steps:

as shown in fig. 10, in step S1001, a transaction request is triggered and issued in response to a card swipe transaction.

As shown in fig. 10, in step S1002, the server is queried for response information returned by the request processing side, where the server caches the response information.

In the request phase (i.e., the phase in which the POS sends a request to the server and the server sends the request to the request handler), the server still plays the role of transparent transmission, but in the response phase (i.e., the phase in which the request handler sends a response message to the server and the server sends the response message to the POS), the server no longer plays the role of transparent transmission packet, but caches the received response message, where "request" refers to a transaction request and a forwarding request, and "response message" refers to a transaction return packet and a forwarding return packet.

In the transaction phase, the response information received by the POS from the server is a transaction response packet, which is a response packet representing whether the transaction request was a successful transaction on behalf of the request handler.

In the present embodiment, fig. 11 shows a flowchart after step S1001, including the following steps:

as shown in fig. 11, in step S1101, if the POS machine does not receive the transaction reply packet, a transaction inquiry request is triggered and sent to the server. Although the server sends the transaction return packet to the POS after receiving the transaction return packet returned by the request processing party, the POS may not receive the transaction return packet due to the influence of the communication condition, and thus the POS needs to actively send a transaction inquiry request to the server to perform a transaction inquiry.

As shown in fig. 11, in step S1102, the POS receives a transaction return packet returned by the server in response to the transaction query request, so that the merchant knows whether the result of the current card swiping transaction is successful.

Through the steps shown in fig. 11, the POS performs inquiry before receiving the transaction receipt, and the inquiry can be retried continuously, and if the transaction receipt can be received through the inquiry and the retried inquiry, the transaction can be completed without re-correcting, so that the rate of correction can be reduced.

In step S111, the POS sends a transaction query request to the server according to a certain query policy, in this embodiment, the query policy may be polling, that is, the query is continued for a preset time (e.g., 1 minute) until a transaction packet returned by the server is received. However, if the POS machine still does not receive the transaction repackage after the query policy of the transaction query request fails (i.e., the transaction repackage is not received through multiple queries within the preset time), the POS machine triggers the rectification request, i.e., enters the rectification stage.

In this embodiment, after triggering the request for positive going, the positive going phase further includes two situations due to the influence of the communication condition: in the first case, a positive request is not issued; in the second case, the forward flushing request is successfully sent but the corresponding backward packet is not received, at this time, the backward packet in the forward flushing stage is a forward flushing backward packet, which represents whether the forward flushing request is successfully flushed by the request processing party.

Fig. 12 shows a flowchart of steps in the alignment phase in the present embodiment, which includes the following steps:

as shown in fig. 12, in step S1201, if the POS machine has not successfully issued the flushing request, the POS machine repeatedly issues the flushing request within a preset time period until the flushing request is successfully issued. Then, after receiving the request for correcting, the server sends the request for correcting to the request processing party; the request processing party generates a corresponding correction return packet aiming at the correction request and sends the correction return packet to the server; and the server updates the state of the database according to the positive flushing packet and sends the positive flushing packet to the POS machine, and the POS machine acquires whether the positive flushing result is successful according to the received positive flushing packet.

As shown in fig. 12, in step S1202, if the POS has successfully issued the positive-going request but has not received the positive-going reply packet, the POS triggers and issues a positive-going inquiry request, i.e., performs a positive-going inquiry, similar to the transaction inquiry process. In this embodiment, the POS sends the transaction query request and the transaction query request is forwarded using a polling query policy.

As shown in fig. 12, in step S1203, the POS machine receives a positive feedback packet returned by the server in response to the positive feedback query request to know whether the positive feedback result is successful.

For the case that the POS has successfully sent out the flushing request but has not received the flushing loopback packet, the following scheme may also be adopted:

the POS machine receives the next positive-making request waiting for the server and responds to the next positive-making request to return the cached positive-making packets. Since a general POS can perform automatic correction, even if the correction packet is not received, a correction request for correcting the current card swiping operation is sent from the POS, and the server may also send the correction packet to the POS, and the POS receives the correction packet to know whether the correction result is successful.

It should be noted that, if the above-mentioned step forward flushing request is not successfully sent for the first time and sent after a plurality of retries, and the step of sending the forward flushing packet to the POS machine by the server is unsuccessful, the subsequent processing refers to a processing scheme for the case where the forward flushing request is successfully sent but the forward flushing packet is not received, and is not described herein again.

In this embodiment, before the POS receives the transaction return packet or the positive-making return packet, the server further parses the ciphertext of the transaction return packet and the positive-making return packet, and caches the parsed transaction result and the positive-making result, so that the result of the whole transaction does not depend on the report of the POS as in the existing scheme, but the result cached in the background of the server is used as the standard. Compared with the existing scheme that the result of the transaction is based on the result reported by the POS machine in the public network, the method in the embodiment can prevent the transaction result from being maliciously tampered by people, thereby improving the security of the transaction.

In summary, in the transaction communication method provided by this embodiment, the POS queries the server for the response information returned by the request processing party cached in the server, so that the state of the server (i.e., the transaction background) for the transaction is not updated according to the result reported by the POS any more, but the state cached by the server is taken as the standard, and the update can be performed in real time, so that the merchant can also know the state of the transaction in time, and the complaint rate caused by abnormal orders is greatly reduced. In the transaction stage, the POS machine repeatedly inquires the transaction repackage, so that the conflict rate can be reduced. However, the positive flushing stage is entered under the condition that the repeated inquiry is not successful, and the repeated retry is also carried out under the condition that a positive flushing request is not sent out, so that the positive flushing success rate is improved as much as possible.

Fig. 13 is a schematic diagram of a POS device provided in another embodiment of the disclosure, which completes the whole transaction process together with the server (i.e., the transaction background) and the request processing party in the above embodiment, and the POS device mainly completes the communication function with the server. As shown in fig. 13, POS 1300 includes a transaction request module 1301 and a response packet query module 1302.

The transaction request module 1301 is configured to trigger and send a transaction request in response to a card swiping transaction, and the response packet query module 1302 is configured to query response information returned by a request processing party to a server, where the server caches the response information.

In this embodiment, the response message received by the POS in the transaction stage is a transaction response packet, which represents whether the request processing party successfully transacts the request. The POS machine receives the response information of the correction stage, namely a correction repackage which represents whether the correction request is successful or not by the request processing party.

As shown in fig. 13, the POS machine further includes a transaction query module 1303 configured to trigger a transaction query request if the POS machine does not receive a transaction reply packet, and send the transaction query request to the server.

As shown in fig. 13, the POS machine further includes a transaction return packet receiving module 1304 configured to receive a transaction return packet returned by the server in response to the transaction inquiry request. And through the inquiry of the POS machine, the POS machine receives a transaction return packet returned by the server, so that the merchant can know whether the result of the card swiping transaction is successful or not. The query policy may be polling, i.e. query for a preset time (e.g. 1 minute) until receiving a transaction packet returned by the server.

In this embodiment, the POS machine, by setting the transaction query module, performs the query first without receiving the transaction receipt, and the query may retry continuously, and if the transaction receipt can be received by the query and the retry query, the transaction can be completed without performing correction again, so that the correction rate may be reduced.

As shown in fig. 13, the POS machine further includes a forward request triggering module 1305 configured to trigger a forward request when the POS machine still does not receive a transaction repackage after the query policy of the transaction query request is expired.

If the flushing request is not issued, as shown in FIG. 13, the POS machine further comprises a flushing request sending module 1306 configured to repeatedly issue the flushing request within a preset time period when the POS machine does not successfully issue the flushing request until the flushing request is successfully issued. That is, repeated retries are carried out to ensure that the server can receive the correction request, then the correction request is sent to the request processing party, and the request processing party generates a corresponding correction loopback packet aiming at the correction request and sends the correction loopback packet to the server. The server updates the state of the database according to the positive-making repackage and sends the positive-making repackage to the POS machine so as to inform the merchant of the positive-making result, and the merchant knows whether the positive-making result is successful or not.

If the hedge request has been successfully sent but the corresponding loopback packet has not been received, as shown in fig. 13, the POS machine further includes a hedge query module 1307 configured to trigger and send a hedge query request when the POS machine has successfully sent the hedge request but has not received the hedge loopback packet.

As shown in fig. 13, the POS machine further includes a positive reply packet receiving module 1308 configured to receive a positive reply packet returned by the server in response to the positive reply query request.

In this embodiment, the POS performs transaction query and correction query, and repeatedly queries after failing to receive the transaction query and the correction query by setting the correction query module, so that customer complaints caused by abnormal orders can be greatly reduced, and a good card swiping experience is brought to customers.

As shown in fig. 13, the POS machine further comprises a forward packet waiting module 1309 configured to wait and receive a forward packet returned by the server in response to the next forward request when the POS machine has successfully issued the forward request but did not receive the forward packet.

The result of the whole transaction is based on the result cached in the server's background, and the POS machine receives the transaction repackage or the correction repackage returned by the server, so that the merchant can know whether the transaction or the correction result is successful. Compared with the existing scheme that the result of the transaction is based on the result reported by the POS machine in the public network, the embodiment can prevent the transaction result from being maliciously tampered by people, thereby improving the security of the transaction.

The POS machine in this embodiment can achieve the same technical effects as the transaction communication method of the POS machine, and details are not described here.

In addition, the functions that are not related in each module in the POS refer to the related description in the above method embodiment, and are not described again here.

In another aspect, the present disclosure also provides an electronic device, including a processor and a memory, the memory storing instructions for the processor to control the following operations:

receiving a transaction request from a POS machine and sending the transaction request to a request processing party, wherein the transaction request is triggered in response to a card swiping transaction of the POS machine; receiving and caching response information returned by a request processing party; and updating the state of the card swiping transaction according to the response information.

In another aspect, the present disclosure also provides another electronic device, including a processor and a memory, the memory storing instructions for the processor to control the following operations:

triggering and sending a transaction request in response to a card swiping transaction; and inquiring the response information returned by the request processing party from the server, wherein the server caches the response information.

Referring now to FIG. 14, shown is a block diagram of a computer system 1400 suitable for use in implementing the electronic device of an embodiment of the present application. The electronic device shown in fig. 14 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 14, the computer system 1400 includes a Central Processing Unit (CPU)1401, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)1402 or a program loaded from a storage portion 1407 into a Random Access Memory (RAM) 1403. In the RAM 1403, various programs and data necessary for the operation of the system 1400 are also stored. The CPU 1401, ROM 1402, and RAM 1403 are connected to each other via a bus 1404. An input/output (I/O) interface 1405 is also connected to bus 1404.

The following components are connected to the I/O interface 1405: an input portion 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker and the like; a storage portion 1408 including a hard disk and the like; and a communication portion 1409 including a network interface card such as a LAN card, a modem, or the like. The communication section 1409 performs communication processing via a network such as the internet. The driver 1410 is also connected to the I/O interface 1405 as necessary. A removable medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1410 as necessary, so that a computer program read out therefrom is installed into the storage section 1408 as necessary.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable medium 1411. The above-described functions defined in the system of the present application are executed when the computer program is executed by a Central Processing Unit (CPU) 1401.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable medium or any combination of the two. A computer readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a transmitting unit, an obtaining unit, a determining unit, and a first processing unit. The names of these units do not in some cases constitute a limitation to the unit itself, and for example, the sending unit may also be described as a "unit sending a picture acquisition request to a connected server".

In another aspect, the present disclosure also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: receiving a transaction request from a POS machine and sending the transaction request to a request processing party, wherein the transaction request is triggered in response to a card swiping transaction of the POS machine; receiving and caching response information returned by a request processing party; and updating the state of the card swiping transaction according to the response information.

In another aspect, the present disclosure also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: triggering and sending a transaction request in response to a card swiping transaction; and inquiring the response information returned by the request processing party from the server, wherein the server caches the response information.

It should be clearly understood that this disclosure describes how to make and use particular examples, but the principles of this disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

Exemplary embodiments of the present disclosure are specifically illustrated and described above. It is to be understood that the present disclosure is not limited to the precise arrangements, instrumentalities, or instrumentalities described herein; on the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A transaction communication method for a server, comprising:

receiving a transaction request from a POS machine and sending the transaction request to a request processing party, wherein the transaction request is triggered in response to a card swiping transaction of the POS machine;

receiving and caching response information returned by the request processing party; updating the state of the card swiping transaction according to the response information;

the response information is transaction response data characterizing a transaction result, and the transaction communication method further comprises:

sending the transaction response data to the POS;

if the POS machine does not receive the transaction response data, triggering a transaction inquiry request;

the server responds to the transaction inquiry request and sends the cached transaction response data to the POS machine;

the method further comprises the following steps: and after the query strategy of the transaction query request is invalid, if the POS machine still does not receive the transaction response data, receiving a positive conflict request sent by the POS machine.

2. The transaction communication method according to claim 1, further comprising:

3. The transaction communication method according to claim 2, wherein the response information is positive-going response data representing a positive-going result, the transaction communication method further comprising:

4. The transaction communication method according to claim 2, wherein the response information is positive-going response data representing a positive-going result, the transaction communication method further comprising:

5. The transaction communication method according to claim 1, 3 or 4, further comprising:

6. A server, comprising:

the updating module is configured to update the state of the card swiping transaction according to the response information;

the response information is transaction response data characterizing a transaction result, and the communication module includes:

the transaction inquiry module is configured to trigger a transaction inquiry request when the POS machine does not receive the transaction response data, respond to the transaction inquiry request and send the cached transaction response data to the POS machine;

the communication module is further configured to receive a correction request sent by the POS machine if the POS machine has not received the transaction response data after the query policy of the transaction query request is invalid.

7. The server of claim 6, wherein the communication module further comprises:

8. The server according to claim 7, wherein the response information is positive-going response data characterizing a positive-going result, and the communication module further comprises:

9. The server according to claim 7, wherein the response information is positive-going response data characterizing a positive-going result, and the communication module further comprises:

10. The server according to claim 8 or 9, further comprising:

and the analysis module is configured to analyze the transaction response data and the ciphertext of the positive conflict response data in the cache module, and send the analyzed transaction result and the positive conflict result to the updating module to update the state of the card swiping transaction.

11. A transaction communication method for a POS machine, comprising:

triggering and sending a transaction request in response to a card swiping transaction;

inquiring response information returned by the request processing party from a server, wherein the server caches the response information;

if the POS machine does not receive the transaction response data, triggering a transaction query request and sending the transaction query request to the server;

the POS machine receives the transaction response data returned by the server in response to the transaction inquiry request;

12. The transaction communication method according to claim 11, further comprising:

13. The transaction communication method according to claim 11, wherein the response information is positive-going response data representing a positive-going result, the transaction communication method further comprising:

if the POS machine has successfully sent the positive conflict request but does not receive the positive conflict response data, triggering and sending a positive conflict query request by the POS machine;

and the POS machine receives the positive response data returned by the server in response to the positive query request.

14. The transaction communication method according to claim 11, wherein the response information is positive-going response data representing a positive-going result, the transaction communication method further comprising:

15. The transaction communication method of claim 13, wherein the POS sends the positive inquiry request using a polled inquiry policy.

16. A POS machine, comprising:

the response data query module is configured to query response information returned by the request processing party to a server, wherein the server caches the response information;

the response information is transaction response data representing a transaction result, and the POS machine further comprises:

a transaction response data receiving module configured to receive the transaction response data returned by the server in response to the transaction query request;

17. The POS machine of claim 16, further comprising:

18. The POS machine of claim 16, wherein the response information is positive-going response data that characterizes a positive-going result, the POS machine further comprising:

19. The POS machine of claim 16, wherein the response information is positive-going response data that characterizes a positive-going result, the POS machine further comprising:

20. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the program realizes the method steps of any of claims 1-5 when executed by the processor.

21. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any one of claims 1 to 5.

22. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the program realizes the method steps of any of claims 11-15 when executed by the processor.

23. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any one of claims 11 to 15.