Payment status processing method and device

Abstract

The present disclosure provides a payment status processing method, which can be applied to the field of Internet technology. The method includes: monitoring the payment status of the message middleware, consuming the payment status message; determining that the consumption time is greater than a preset threshold, calling the payment query interface through the Feign method to synchronize the payment status. The present disclosure also provides a payment status processing device, equipment, storage medium and program product.

Description

Technical Field

[0001] The present disclosure relates to the field of Internet financial technology, and more specifically to a payment status processing method, device, equipment, medium and program product. Background Art

[0002] The banking system implements user payment status message transmission through the message middleware, in which the payment system (message producer) produces the payment status message and stores the payment status message in the message queue in the message middleware. The third-party access system (message consumer) obtains the message from the message queue and notifies the user.

[0003] In the prior art, system jitter and network congestion often cause message middleware failures, resulting in the loss of payment status messages, which in turn leads to inconsistent payment statuses of users in the third-party access system and the payment system.

[0004] In one example, polling is usually used to query the processing status of messages in the message queue to ensure the synchronization of payment status messages. This processing method increases the request pressure on server resources, has poor real-time performance, and affects the user payment experience. Summary of the invention

[0005] In view of the above problems, the present disclosure provides a payment status processing method, apparatus, device, medium and program product.

[0006] According to a first aspect of the present disclosure, there is provided a method for processing payment status, which is applied to a third-party access system, and includes: in response to a user payment initiation request, calling a payment service interface;

[0007] Monitor the payment status of the message middleware and consume payment status messages;

[0008] Determining the consumption time of the payment status message;

[0009] If it is determined that the consumption time is greater than the preset threshold, the payment query interface is called through Feign to synchronize the payment status.

[0010] According to an embodiment of the present disclosure, the payment status message includes the payment order number, payment initiation time, access system ID and payment status parameters, and calling the payment query interface in a Feign manner to synchronize the payment status includes:

[0011] Obtain the user's payment order number and access system ID;

[0012] Call the payment query interface through Feign;

[0013] The payment status is determined based on the payment order number and the access system ID.

[0014] According to an embodiment of the present disclosure, it also includes:

[0015] If it is determined that the consumption time is less than a preset threshold, the payment status parameter is obtained through the payment status message.

[0016] According to an embodiment of the present disclosure, after synchronizing the payment status, the following is further included:

[0017] The payment status message is sent to the user.

[0018] A second aspect of the present disclosure provides a payment status processing device, including: a calling module, configured to call a payment service interface in response to a user payment initiation request;

[0019] A monitoring module, used to monitor the payment status of the message middleware and consume the payment status message; a timing module, used to determine the consumption time of the payment status message; and

[0020] The synchronization module is used to call the payment query interface through Feign to synchronize the payment status if it is determined that the consumption time is greater than a preset threshold.

[0021] The third aspect of the present disclosure provides an electronic device, comprising: one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the above-mentioned payment status processing method.

[0022] The fourth aspect of the present disclosure further provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the above-mentioned payment status processing method.

[0023] The fifth aspect of the present disclosure also provides a computer program product, including a computer program, which implements the above-mentioned payment status processing method when executed by a processor.

[0024] The payment status processing method and device provided by the embodiment of the present disclosure monitors the payment status topic in the message middleware, determines the synchronization mode of the payment status parameters according to the duration of the third-party access system consumption message, and when the consumption duration is greater than the preset threshold, calls the payment query service interface in the feign mode to obtain the payment status parameters, thereby ensuring that the payment status message is synchronized without loss, reducing the coupling degree between microservices, achieving high real-time performance, and enhancing user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The above contents and other purposes, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0026] Figure 1 A diagram schematically illustrates an application scenario of a payment status processing method, apparatus, device, medium, and program product according to an embodiment of the present disclosure;

[0027] Figure 2 A system framework diagram of a payment status processing method according to an embodiment of the present disclosure is schematically shown;

[0028] Figure 3 A flowchart schematically shows a method for processing payment status according to an embodiment of the present disclosure;

[0029] Figure 4 A flowchart schematically illustrates another method for processing payment status according to an embodiment of the present disclosure;

[0030] Figure 5 A block diagram schematically shows a structure of a payment status processing device according to an embodiment of the present disclosure; and

[0031] Figure 6 A block diagram of an electronic device suitable for implementing a payment status processing method according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0032] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0033] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0034] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0035] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0036] First, the professional terms appearing in the embodiments of the present disclosure are explained.

[0037] Microservice architecture is an architectural pattern among many architectures. It advocates divide and conquer and independent operation. It splits a complex large application into a group of small services, and the services coordinate and communicate with each other. Each service runs in its own independent process, and services communicate with each other using a lightweight communication mechanism (usually HTTP-based RestfulAPI). Each service is built around a specific business and can be independently deployed to a production environment, a production-like environment, etc.

[0038] Kafka is a high-throughput distributed publish-subscribe messaging system that can process all action stream data of consumers in the system. Kafka is also a distributed message queue. It has high performance, persistence, multi-copy backup, and horizontal expansion capabilities. Producers write messages to the queue, and consumers take messages from the queue to perform business logic. It generally plays the role of decoupling, peak shaving, and asynchronous processing in architectural design.

[0039] OpenFeign, OpenFeign is a pseudo client that provides a solution for calling between services in a microservice architecture. Feign generates requests by processing annotations, thereby simplifying HTTP API development. That is, developers can customize request api templates using annotations. Before sending an http request, feign replaces the parameters in the request template by processing annotations. This implementation method is more direct and understandable.

[0040] The existing banking system uses message middleware, such as Kafka, to implement user payment status message transmission, where the payment system (message producer) produces payment status messages and stores the payment status messages in the message queue in the message middleware. The third-party access system (message consumer) obtains messages from the message queue and notifies the user.

[0041] In the prior art, system jitter and network congestion often cause message middleware failures, resulting in the loss of payment status messages, which in turn leads to inconsistent payment status between the third-party access system and the user's payment system. In one example, polling is usually used to query the processing status of messages in the message queue to ensure the synchronization of payment status messages. This processing method increases the request pressure on server resources, has poor real-time performance, and affects the user's payment experience.

[0042] Based on the above technical problems, an embodiment of the present disclosure provides a payment status processing method, which is applied to a third-party access system, including: responding to a user payment initiation request, calling a payment service interface through Feign; monitoring the payment status of the message middleware, consuming payment status messages; determining the consumption time of the payment status message; if it is determined that the consumption time is greater than a preset threshold, calling the payment query interface through Feign to synchronize the payment status.

[0043] Figure 1 The application scenario diagram of the payment status processing method, apparatus, device, medium and program product according to the embodiment of the present disclosure is schematically shown. Figure 2 The system framework diagram of the payment status processing method according to an embodiment of the present disclosure is schematically shown.

[0044] like Figure 1 As shown, the application scenario 100 according to this embodiment may include a user payment scenario. The network 104 is used to provide a medium for a communication link between the user 101, the third-party access system 102, the core payment system 103 and the database 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0045] The user 101 can use the terminal device to interact with the third-party access system 102 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the terminal device, such as shopping applications, payment applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0046] The terminal device may be any electronic device having a display screen and supporting web browsing, including but not limited to a smart phone, a tablet computer, a laptop computer, a desktop computer, and the like.

[0047] The third-party access system 102 interacts with the user 101 , sends the payment request of the user 101 to the core payment system 103 , and sends the corresponding payment status message to the terminal device of the user 101 .

[0048] The core payment system 103 may be a server that provides payment services, for example, a backend server that provides payment services to the user 101 in response to a payment request initiated by the user 101 using a terminal device (for example only). The backend server may process the received user payment request and other data, and feed back the processing result (for example, payment status message and other data generated according to the payment request initiated by the user) to the user 101 through the third-party access system 102.

[0049] It should be noted that the payment status processing method provided in the embodiment of the present disclosure can generally be executed by the third-party access system 102. Accordingly, the payment status processing device provided in the embodiment of the present disclosure can generally be set in a server installed with a third-party access system. The payment status method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the third-party access system 102 and can communicate with the terminal device and / or the third-party access system 102. Accordingly, the payment status processing device provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the third-party access system 102 and can communicate with the terminal device and / or the third-party access system 102.

[0050] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0051] like Figure 2 As shown in the figure, in the e-government portal service platform, the S002 merchant platform parameter configuration module is used to configure the merchant information related parameters; the S001 core payment service module is independently deployed as a microservice unit to provide external services; S004, as the underlying bank external merchant platform that S001 relies on, provides a data interaction between the payment microservice and the merchant; S003 is an initialization threshold for the consumption time of the message middleware, as a dynamically configurable parameter; the S006 message middleware message queue module provides the publishing and subscription of the payment status topic, and the specific payment microservice publishes the payment status topic, and the S005 access business system module listens to the corresponding topic and consumes the payment status topic; the S005 access business system module performs business logic processing according to the payment status. When the consumption time of the payment status topic of the S005 module exceeds the predetermined threshold, the payment query interface in the S001 core payment service module is selected in the Feign way to query the payment status and perform subsequent business logic processing.

[0052] The following will be based on Figure 1 The scene described and Figure 2 The system architecture described by Figure 3-4The payment status method of the disclosed embodiment is described in detail.

[0053] Figure 3 The flowchart of the method for processing payment status according to an embodiment of the present disclosure is schematically shown.

[0054] like Figure 3 As shown, the payment status processing method of this embodiment includes operations S201 to S205, and the processing method can be executed by a third-party access system. The third-party access system disclosed in this disclosure can be a variety of payment channels, and the user initiates a payment request through the third-party access system during the transaction process.

[0055] In operation S201, in response to a user payment initiation request, a payment service interface is called.

[0056] In an example, after receiving a payment request initiated by a user, the third-party access system calls the payment service interface through Feign. The payment service interface is exposed by the core payment service module in the following form:

[0057] @FeignClinet(name="rlg-site-pay-platform", url="XXip:8080") publicinterface DntnPayService extens DntnRlgPayServiceInterface{}

[0058] After receiving the payment service call request from the third-party access system, the core payment service module creates a payment status topic while sending a request to the underlying external merchant platform, and writes the payment status topic to the message middleware. The message middleware in this disclosure can be Kafka, or zookeeper, redis, and other message middleware that supports publishing and subscription. The topic rules are as follows:

[0059] Payment status topic = docking system + "paymentNotice".

[0060] In operation S202, the payment status of the message middleware is monitored, and the payment status message is consumed.

[0061] In an example, a third-party access system subscribes to the payment status topic and monitors the payment status topic of the message middleware in real time as a consumer consumes payment status messages, where the payment status message includes the payment order number, payment initiation time, access system ID and payment status parameters. The payment initiation time is the time when the user starts to initiate the payment, the access system ID is used to represent the payment channel, and the payment status parameter is used to represent whether the current payment is successful.

[0062] In operation S203, the consumption time of the payment status message is determined.

[0063] In operation S204, if it is determined that the consumption time is greater than the preset threshold, the payment query interface is called through Feign to synchronize the payment status.

[0064] In one example, the third-party access system continuously monitors the payment status message in the message middleware. Specifically, it determines the payment status parameters by obtaining the payment status message, and notifies the user of the payment status of the order to complete the entire payment process. However, due to some uncontrollable factors such as network congestion and system jitter, the third-party access system cannot obtain the payment status parameters from the message middleware, resulting in the payment status in the core payment module and the payment status in the third-party access system cannot be synchronized in time, which in turn causes the user to be unable to obtain the current payment status after initiating payment, affecting the user's payment experience. In the prior art, when the third-party access system does not obtain the payment status parameters, it will continue to poll and query to obtain the payment status parameters, which will aggravate the congestion of consumption messages and occupy certain system resources.

[0065] In the disclosed embodiment, the synchronization method of the payment status parameters is determined according to the duration of the consumption message, that is, if the consumption message duration is less than the preset threshold, it indicates that the payment status parameters are obtained within the preset time, and the payment status of the third-party access system and the core payment module has been synchronized; if the consumption message duration is greater than the preset threshold, it indicates that the payment status parameters are not obtained within the preset time. At this time, in order to ensure the synchronization of the payment status, the payment status query service is called through the Feign method to obtain the payment status parameters. The preset threshold is pre-set in combination with the specific payment scenario and the actual business processing situation. In this embodiment, the preset threshold is set to 5S, that is, if the third-party access system does not obtain the payment status of a payment order within 5s, in order to avoid the user waiting too long and affecting the user experience, the payment status query interface is called through the Feign method to obtain the payment status of the order, and the payment status is sent to the user.

[0066] In this embodiment, the payment status is obtained by calling the payment status query interface through the Feign method. The Feign method call specifically refers to the custom request api template that can be used to annotate @FeignClient. Before sending the httprequest request, Feign replaces the parameters in the request template by processing the annotation to generate a request. @FeignClient is an annotation in the Spring Cloud technical architecture system, which allows the current service to call the interface of other services. The payment query service is provided by the core payment service and pre-registered in the service center. For example, according to the payment order number and access system ID, these parameters are added to the request template to generate a new request, and the payment status query service is called to query the payment status corresponding to the order number, and the payment amount, payment date and payment result corresponding to the order number are returned, where the payment result is the payment status. It should be noted that this embodiment can also use traditional HTTP requests to implement the call to the payment status query interface, but because the Feign call method of the microservice provides load balancing and remote calls compared to traditional HTTP requests, it is convenient and simple to operate during the call process.

[0067] Through the embodiments of the present disclosure, by monitoring the payment status topic of the message middleware and determining the synchronization method of the payment status parameters according to the duration of the consumption message, it is possible to prevent the loss of the payment status message during the consumption process, ensure timely synchronization of the payment status between services, and reduce the coupling between microservices by judging the synchronization method of the payment status according to the duration of the consumption message, thereby achieving high real-time performance and enhancing the user payment experience.

[0068] Figure 4 A flowchart schematically illustrates another method for processing payment status according to an embodiment of the present disclosure.

[0069] like Figure 4 As shown, the payment status processing method of this embodiment includes operations S301 to S305.

[0070] In operation S301, in response to a user payment initiation request, a payment service interface is called.

[0071] According to the disclosed embodiment, before the core payment module provides payment services to users, it first performs initialization configuration. Specifically, the core payment module starts the payment microservice and initializes the merchant information corresponding to the payment through the merchant platform parameter configuration module. After the third-party access system calls the payment service interface, the core payment module sends a request to the underlying external merchant platform and creates a payment status topic. As a producer, the core payment module writes the payment status message of the generated order to the payment status topic. As a consumer, the third-party access system subscribes to the payment status topic of the message middleware and consumes the payment status message in the payment status topic.

[0072] In operation S302, the payment status of the message middleware is monitored, and the payment status message is consumed.

[0073] Operation S302 and Figure 3 The technical solution and principle of operation S202 are the same as those shown and will not be described in detail.

[0074] In operation S303, the consumption time of the payment status message is determined.

[0075] According to an embodiment of the present disclosure, the payment initiation time of the user is obtained; and the consumption time of the payment status message is determined according to the payment initiation time.

[0076] In one example, the payment status message includes the user's payment initiation time, and the consumption time of the payment status message can be determined according to the user's payment initiation time and the system current time.

[0077] In operation S304, if it is determined that the consumption time is greater than the preset threshold, the payment query interface is called through Feign to synchronize the payment status.

[0078] According to the embodiment of the present disclosure, the user's payment initiation time is first obtained, and the consumption message duration is determined according to the user's payment initiation time. When the consumption message duration is greater than the preset threshold, the payment query service interface is called through the Feign method to obtain the payment status parameters. Specifically, the user's payment order number and access system ID are obtained; the payment query service interface is called through the Feign method; in response to the payment query service call request, the payment status parameters are determined according to the payment order number and the access system ID.

[0079] If the consumption message duration is less than the preset threshold, it indicates that the payment status message is not lost, then the payment status parameter is obtained through the payment status message, the payment status in the third-party access system and the core payment module are synchronized, and operation S305 is performed. The preset threshold is pre-set, combined with the specific payment scenario and actual business processing situation, in the embodiment of the present disclosure, the preset threshold is set to 5S.

[0080] In operation S305, a payment status message is sent to the user.

[0081] After the payment status synchronization is completed, the third-party access system sends the payment status message obtained in operation S304 to the user's terminal device.

[0082] Through the embodiments of the present disclosure, by monitoring the payment status topic of the message middleware and determining the synchronization method of the payment status parameters according to the duration of the consumption message, it is possible to prevent the loss of the payment status message during the consumption process, ensure timely synchronization of the payment status between services, and reduce the coupling between microservices by judging the synchronization method of the payment status according to the duration of the consumption message, thereby achieving high real-time performance and enhancing the user payment experience.

[0083] Based on the above payment status processing method, the present disclosure also provides a payment status processing device. Figure 5 The device is described in detail.

[0084] Figure 5 The structural block diagram of the payment status processing device according to the embodiment of the present disclosure is schematically shown.

[0085] like Figure 5 As shown, the device 500 of this embodiment includes a calling module 510 , a monitoring module 520 , a timing module 530 and a synchronization module 540 .

[0086] The calling module 510 is used to call the payment service interface in response to the user's payment initiation request. In one embodiment, the calling module 510 can be used to perform the operation S201 described above, which will not be repeated here.

[0087] The monitoring module 520 is used to monitor the payment status of the message middleware, and consume the payment status message, wherein the payment status message includes the payment order number, the payment initiation time, the access system ID and the payment status parameter. In one embodiment, the monitoring module 520 can be used to perform the operation S202 described above, which will not be repeated here.

[0088] The timing module 530 is used to determine the consumption time of the payment status message. In one embodiment, the timing module 530 can be used to perform the operation S203 described above, which will not be repeated here.

[0089] The synchronization module 540 is used to call the payment query interface through Feign to synchronize the payment status parameters if it is determined that the consumption time is greater than the preset threshold. In one embodiment, the synchronization module 540 can be used to perform the operation S204 described above, which will not be repeated here.

[0090] According to an embodiment of the present disclosure, any multiple modules of the calling module 510, the monitoring module 520, the timing module 530 and the synchronization module 540 can be combined into one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the calling module 510, the monitoring module 520, the timing module 530 and the synchronization module 540 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware and firmware or in any appropriate combination of any of them. Alternatively, at least one of the calling module 510, the monitoring module 520, the timing module 530 and the synchronization module 540 can be at least partially implemented as a computer program module, and when the computer program module is run, the corresponding function can be executed.

[0091] Figure 6 A block diagram of an electronic device suitable for implementing a payment status processing method according to an embodiment of the present disclosure is schematically shown.

[0092] like Figure 6 As shown, the electronic device 600 according to an embodiment of the present disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include an onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0093] In RAM 603, various programs and data required for the operation of electronic device 600 are stored. Processor 601, ROM 602 and RAM 603 are connected to each other via bus 604. Processor 601 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 602 and / or RAM 603. It should be noted that the program can also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 can also perform various operations of the method flow according to the embodiment of the present disclosure by executing the program stored in the one or more memories.

[0094] According to an embodiment of the present disclosure, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to the bus 604. The electronic device 600 may further include one or more of the following components connected to the I / O interface 605: an input portion 606 including a keyboard, a mouse, etc.; an output portion 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 608 including a hard disk, etc.; and a communication portion 609 including a network interface card such as a LAN card, a modem, etc. The communication portion 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage portion 608 as needed.

[0095] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0096] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 602 and / or RAM 603 described above and / or one or more memories other than ROM 602 and RAM 603.

[0097] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the payment status processing method provided by the embodiment of the present disclosure.

[0098] The above functions defined in the system / device of the embodiment of the present disclosure are performed when the computer program is executed by the processor 601. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0099] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 609, and / or installed from a removable medium 611. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0100] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, the above functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the system, device, apparatus, module, unit, etc. described above can be implemented by a computer program module.

[0101] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0102] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0103] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0104] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A payment status processing method, applied to a third-party access system, characterized in that: include: In response to the user's payment initiation request, the payment service interface is called through Feign; Monitor the payment status topic of the message middleware to obtain payment status messages; Determine the consumption time of the payment status message; if it is determined that the consumption time is greater than a preset threshold, call the payment query interface through Feign to synchronize the payment status.

2. The method according to claim 1, characterized in that: The payment status message includes the payment order number, payment initiation time, access system ID and payment status parameters. The payment query interface is called by Feign to synchronize the payment status, including: Obtain the user's payment order number and access system ID; Call the payment query interface through Feign; The payment status parameters are determined according to the payment order number and the access system ID.

3. The method according to claim 2, characterized in that Also includes: If it is determined that the consumption time is less than a preset threshold, the payment status parameter is obtained through the payment status message.

4. The method according to any one of claims 1 to 3, characterized in that: After synchronizing the payment status, it also includes: The payment status message is sent to the user.

5. A payment status processing device, comprising: The calling module is used to respond to the user's payment initiation request and call the payment service interface through Feign; The monitoring module is used to monitor the payment status topic of the message middleware to obtain payment status messages; A timing module, used to determine the consumption time of the payment status message; as well as The synchronization module is used to call the payment query interface through Feign to synchronize the payment status if it is determined that the consumption time is greater than a preset threshold.

6. An electronic device comprising: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors execute the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to execute the method according to any one of claims 1 to 4.

8. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images