WO2019196244A1 - 实时回调订单的方法和系统 - Google Patents

实时回调订单的方法和系统 Download PDF

Info

Publication number
WO2019196244A1
WO2019196244A1 PCT/CN2018/096479 CN2018096479W WO2019196244A1 WO 2019196244 A1 WO2019196244 A1 WO 2019196244A1 CN 2018096479 W CN2018096479 W CN 2018096479W WO 2019196244 A1 WO2019196244 A1 WO 2019196244A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
processing
party
current process
queue
Prior art date
Application number
PCT/CN2018/096479
Other languages
English (en)
French (fr)
Inventor
刘红彬
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019196244A1 publication Critical patent/WO2019196244A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0607—Regulated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the present application relates to the field of Internet service technologies, and in particular, to an order process processing method and system.
  • the traditional order process is a serial interaction process, that is, for the business request initiated by the client (professional company, or end user), the background management system (ie, the server) needs to process each process one by one according to the order process. (sub-process), after processing, the final processing result can be returned to the client that initiated the service request.
  • the experience depends largely on the time-consuming processing of the service request by the server. If the server performs a business processing operation that takes a very long time and/or is difficult to predict, then This will cause the client to be in a wait state, and the user is not aware of the length of waiting, so that the user (accessor) cannot see the result of the order processing in time.
  • the back-end management system may need to access third parties (for example, query commodity inventory status) to obtain the required information in the processing flow, and the response time of the third party is often difficult to accurately grasp. Therefore, if the server and the client stay connected for a long time, a large amount of resources are wasted and the throughput is low.
  • the main purpose of the present application is: in order to facilitate the user, according to the actual processing needs of the process in the business logic, in various scenarios, the synchronous/asynchronous processing mode can be freely switched to complete the transaction order. All the steps.
  • an order process processing solution which may include the following aspects:
  • the transaction scenario can be determined;
  • the specific order processes the transaction according to the process, performs asynchronous judgment in real time, and feeds back the processing situation to the client.
  • an order process processing system including the following steps:
  • Step 1 Receive an order processing request from a client, and obtain a process queue of the order according to the order processing request, where the process queue includes all processes required to process the order;
  • Step 2 Determine whether the current process in the process queue needs to be asynchronously processed.
  • Step 3 If the current process needs to be asynchronously processed, the notification client will push the order processing result in an asynchronous manner, put the current process into the asynchronous queue, and push the processing result to the client after the asynchronous processing ends;
  • Step 4 If the current process does not need to perform asynchronous processing, perform synchronization processing on the current process to obtain a processing state of the current process.
  • Step 5 If the processing status of the current process is “processing exception”, record processing information of the current process, where the processing information includes information required to perform the current process again;
  • Step 6 If the processing status of the current process is “Processing Successfully”, determine whether the current process is the last process in the process queue, if the current process is not the last process in the process queue. Then, the next process in the process queue is taken as the current process, and the process returns to step 2; otherwise, the order processing result is output.
  • an order process processing system for executing the method, including an order acceptance component, a process processing component, an order feedback component, a process asynchronous determination component, and a process recording component.
  • the order accepting component is configured to receive an order processing request from a client, and obtain a process queue of the order from the order processing request, where the process queue includes all processes required to process the order;
  • the order feedback component is used to feed back the order processing result to the client.
  • the process asynchronous determining component is configured to perform asynchronous judgment on the current process in the process queue.
  • the process processing component is configured to: put the current process into an asynchronous queue when asynchronous processing is needed on the current process;
  • the process processing component is further configured to: when performing synchronization processing on the current process, perform corresponding processing, generate a processing result of the current process, and feed back the processing result to the client by using the order feedback component;
  • the process recording component is configured to record a process processing state and a history processing record of each order, including the number of processes, the processing mode of each time, and the processing state (delay, success, failure).
  • a computer readable storage medium having stored thereon a program for the above method, the program being executed by a processor, performing the operations of:
  • Step 1 Receive an order processing request from a client, and obtain a process queue of the order according to the order processing request, where the process queue includes all processes required to process the order;
  • Step 2 Determine whether the current process in the process queue needs to be asynchronously processed.
  • Step 3 If the current process needs to be asynchronously processed, the notification client will push the order processing result in an asynchronous manner, put the current process into the asynchronous queue, and push the processing result to the client after the asynchronous processing ends;
  • Step 4 If the current process does not need to perform asynchronous processing, perform synchronization processing on the current process to obtain a processing state of the current process.
  • Step 5 If the processing status of the current process is “processing exception”, record processing information of the current process, where the processing information includes information required to perform the current process again;
  • Step 6 If the processing status of the current process is “Processing Successfully”, determine whether the current process is the last process in the process queue, if the current process is not the last process in the process queue. Then, the next process in the process queue is taken as the current process, and the process returns to step 2; otherwise, the order processing result is output.
  • the beneficial effects of the present application are mainly as follows: 1.
  • the external access points professional companies
  • the maintenance cost of the system is low; 3.
  • the process queues in advance, whether the same scenario can be used
  • the synchronous and asynchronous switching is performed, and the process queues in the same scenario can be reused.
  • the parameterized configuration can be quickly launched.
  • the payment channel can be configured and can be configured according to a preset process. , quickly process business, and solve business needs of different professional companies in different scenarios.
  • FIG. 1 is a partial flow chart of an order process processing method according to an embodiment of the present application.
  • FIG. 2 is a partial flow chart of an order process processing method according to another embodiment of the present application.
  • FIG. 3 is a schematic diagram showing the functional architecture of an order process processing system according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram of an operating environment of a system in which an application is installed, according to an embodiment of the present application.
  • the order routing parameters of the order are obtained, and the different business processing processes (process configuration and process queue) that the order process should obtain are determined according to the scene routing parameters.
  • the order process is parameterized and configured, so that the processing method can be quickly applied to the application; at the same time, the business can be quickly processed according to the manually preset process, and the business of different scenarios of different professional companies can be solved. demand.
  • the manual can perform the synchronous switching between the same scene and the process queue of the same scenario.
  • the process parameters are set, including the execution process to determine the relevant parameters asynchronously, and the alarm message can be sent to the background, and the human intervention can be used to reduce the failure rate of human error and improve the customer experience.
  • the breakpoint reconnection can be realized by recording the interrupted process and the processing details of each process.
  • FIG. 1 is a partial flow chart of an order process processing method according to an embodiment of the present application.
  • 2 is a partial flow chart of an order process processing method according to another embodiment of the present application.
  • an embodiment of the present application provides an order process processing method, wherein the process of processing an order includes stages of order verification, order asynchronous processing judgment, and order process processing, and the method includes:
  • Step S100 Receive an order processing request from a client, and obtain a process queue of the order from the order processing request, where the process queue includes all processes required to process the order;
  • the process queue is determined according to a scenario routing parameter related to the order
  • the scene routing parameter may include specific parameters such as a product provider, a product code, a primary channel, a secondary channel, a transaction type, a payment method, an order management platform, and a payment rule, and different parameter combinations correspond to different order processing scenarios. , that is, the order processing scenario is determined by a multidimensional condition;
  • the merchandise provider may be a company that provides travel services
  • the merchandise code corresponds to a specific product (eg, a taxi product)
  • the payment method corresponds to the user's payment channel (eg, Alipay, WeChat, UnionPay, etc.)
  • payment rules include prepayment (such as a price), post payment (for example, according to the itinerary), and so on.
  • a plurality of order processing scenarios such as travel scenario 1, travel scenario 2, travel scenario 3, and the like, can be defined according to various combinations of the above parameters.
  • the same order pre-processing process for example, a pre-process dedicated to the travel service, including verifying the identity of the driver and the passenger
  • different transaction processing processes for example, prepaid and postpaid, Alipay, and WeChat each correspond to different reconciliation methods, ie, different reconciliation processes).
  • the order processing scenario may be converted into an expression of a multi-dimensional condition by the scene routing parameter, and each dimension may involve a different processing process/process queue, and the combination of each dimension forms a corresponding corresponding to the order processing scenario.
  • a complete process represented by a process/process queue;
  • Step S200 Perform asynchronous judgment on the current process in the process queue.
  • the process parameter of the current process may be used to determine whether the current process needs to be asynchronously processed. If asynchronous processing is required, the client cannot immediately obtain an order. Correspondingly, in the normal case, the current process is synchronized, and the client can immediately obtain the processing result of the order, such as successful transaction, payment failure, verification failure, insufficient inventory of the commodity, and the like.
  • the asynchronous queue is maintained by the background management system, and the process that needs to be processed asynchronously is usually a relatively time-consuming process in the order processing process, and/or a process that depends on the third-party response; meanwhile, as an example, the processing does not affect
  • the processing of subsequent processes synchronous processes or asynchronous processes
  • the background management system can process processes in the asynchronous queue by broadcasting, for example
  • the process in the asynchronous queue is processed in a periodic manner, and the process is repeatedly processed cyclically if the third party does not respond to the asynchronous process or processes the timeout.
  • the service processing time-consuming reference value corresponding to the current process determines whether the current process needs to be asynchronously processed
  • calculating a reference time for processing the current process according to the estimated time-consuming processing of the current process and the network environment data carried in the current process
  • the network environment data includes: a network type, a network standard, and/or a signal strength of a currently used network, and a network transmission speed of a currently used network;
  • the processing information of the current process it may be determined whether the current process needs to be asynchronously processed, for example, if the current process has a history processing record (previously an exception was processed), The previous synchronization process is changed to asynchronous processing, that is, asynchronous processing is performed on the process that performs the synchronization processing unfinished;
  • Step S300 If the current process needs to be asynchronously processed, notify the client to push the order processing result in an asynchronous manner (for example, popping up a message “Pushing the order processing result later, please wait” on the client), The current process is placed in an asynchronous queue, and the processing result is pushed to the client after the asynchronous processing ends;
  • Step S400 If the current process does not need to perform asynchronous processing, perform synchronization processing on the current process to obtain a processing state of the current process.
  • Step S500 If the processing status of the current process is “processing abnormality” (the synchronization processing is abnormal, and the processing cannot be completed and the processing result is obtained, which does not mean that the processing fails), the order status is recorded as “order processing”. And record the processing information of the current process (this means that the synchronization processing of some processes in the order is delayed, and the information of the deferred process can be recorded (for example, including the location of the current process in the process queue, the process serial number, the exception) Type, etc.), for use in future breakpoint reconnection, or change the synchronous processing mode to asynchronous processing mode), go to step S700;
  • the process status information of the current process may also be generated in real time during the execution of the corresponding process. For example, if the current process is suspended for some reason, the status information may be generated and displayed as “xx process remains in process”. ;
  • the server can automatically re-process, or the client can initiate a re-processing request, and it is not necessary to repeatedly execute the processed process, which can improve the reuse rate of the order processing.
  • Step S600 If the processing status of the current process is “Processing Successfully”, determine whether the current process is the last process in the process queue;
  • the status information may be generated and displayed as “xx process successfully processed” or “xx process failed”;
  • step S200 If the current process is not the last process in the process queue, the next process in the process queue is taken as the current process, and the process returns to step S200; otherwise, the method is ended;
  • Step S700 The processing status of the current process is “processing exception” or “processing failure” (that is, the processing has been completed, but the processing fails, which means that the process confirms the failure, confirms that the order processing fails, and no further processing is required.
  • the method can be ended. After that, if the same order needs to be processed again, the client needs to re-initiate the request and re-process all processes in the process queue;
  • the partial synchronization processing process may be repeatedly executed according to the processing failure reason (step S702). For example, if the reason for the failure of the processing is that the third party has no response or the response timed out, the related process can be automatically executed cyclically and the client is notified that "the partial synchronization processing process is retrying, please wait".
  • the history processing records of all processes in the process queue may be summarized, including the number of processes, the processing mode (synchronous/asynchronous), and the processing state (delay, success, failure).
  • the server can set specific loop rules, and the pending process (for processing) can be processed again periodically if the entire order processing has not expired (including the case where the necessary process has not failed).
  • the asynchronous queue may be automatically put into the asynchronous queue (S704), and the asynchronous processing is directly performed, and the asynchronous determination of step S200 is not required.
  • each process in the process queue may also have an identifier related to the repeated processing, for example, the number of times of re-processing, the timeout period, and the like, wherein if the number of times of repeatable processing is set to 0, Indicates that the processing cannot be repeated. In the case of handling an exception, once the timeout period is reached, the processing status is determined as "processing failure.”
  • an order process processing system for performing various steps of the method in the present application.
  • the order process processing system mainly includes an order acceptance component and a process process.
  • the order accepting component is configured to receive an order processing request from a client, and obtain a process queue of the order from the order processing request, where the process queue includes all processes required to process the order;
  • the process queue is determined according to a scenario routing parameter related to the order
  • the scene routing parameter may include specific parameters such as a product provider, a product code, a primary channel, a secondary channel, a transaction type, a payment method, an order management platform, and a payment rule, and different parameter combinations correspond to different order processing scenarios. That is, the order processing scenario is determined by a multidimensional condition.
  • the order feedback component is used to feed back the order processing results to the client.
  • the process asynchronous determining component is configured to perform asynchronous judgment on the current process in the process queue.
  • the process processing component is configured to: put the current process into an asynchronous queue when asynchronous processing is needed on the current process;
  • the process processing component is further configured to: when performing synchronization processing on the current process, perform corresponding processing, generate a processing result of the current process, and feed back the processing result to the client by using the order feedback component;
  • the process processing component is further configured to: sequentially execute all processes in the process queue, and send related information generated in process processing to the process recording component.
  • the process recording component is configured to record the process processing status and the history processing record of each order, including the number of processes, the processing mode (synchronous/asynchronous), and the processing state (delay, success, failure).
  • various embodiments of the present application can also be implemented by a software module or computer readable instructions stored on one or more computer readable medium, where the computer readable instructions are when When executed, the various embodiments described herein are performed.
  • any combination of software modules, computer readable media, and hardware components are contemplated by the present application.
  • the software modules can be stored on any type of computer readable storage medium such as RAM, EPROM, EEPROM, flash memory, registers, hard disk, CD-ROM, DVD, and the like.
  • FIG. 4 an operating environment of a system in which an application is installed according to an embodiment of the present application is illustrated.
  • the system for installing the application is installed and runs in the electronic device.
  • the electronic device may be a computing device such as a desktop computer, a notebook, a palmtop computer, or a server.
  • the electronic device can include, but is not limited to, a memory, a processor, and a display. Only electronic devices having the above-described components are shown, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.
  • the memory may be an internal storage unit of the electronic device, such as a hard disk or memory of the electronic device, in some embodiments.
  • the memory may also be an external storage device of the electronic device in other embodiments, such as a plug-in hard disk equipped on the electronic device, a smart memory card (SMC), and a secure digital (Secure Digital) , SD) card, flash card (Flash Card), etc.
  • the memory may also include both an internal storage unit of the electronic device and an external storage device.
  • the memory is used to store application software installed on the electronic device and various types of data, such as program code of the system in which the application is installed.
  • the memory can also be used to temporarily store data that has been output or is about to be output.
  • the processor may, in some embodiments, be a central processing unit (CPU), a microprocessor, or other data processing chip for executing program code or processing data stored in the memory, such as performing the Install the application's system, etc.
  • CPU central processing unit
  • microprocessor microprocessor
  • other data processing chip for executing program code or processing data stored in the memory, such as performing the Install the application's system, etc.
  • the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch sensor, or the like in some embodiments.
  • the display is for displaying information processed in the electronic device and a client interface for displaying visualizations, such as an application menu interface, an application icon interface, and the like.
  • the components of the electronic device communicate with one another via a system bus.
  • the method in the foregoing embodiment can be implemented by means of software plus a necessary general hardware platform, and can also be implemented by hardware, but in many cases.
  • the former is a better implementation.
  • the technical solution of the present application which is essential or contributes to the prior art, may be embodied in the form of a software commodity stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.
  • a computer readable storage medium having stored thereon a program for executing the method according to an embodiment of the present application, the program When executed by the processor, the various steps of the method are performed.
  • the present application relates to the field of computer service technologies, and in particular, to a method and system for real-time callback order.
  • a method for real-time callback order includes the following steps:
  • Step 1 Send an order inquiry request to a third-party payment channel for an order generated by the user after the transaction is performed by the access party;
  • Step 2 determining whether the third-party payment channel responds to the order query request, and if yes, proceeding to step 3; otherwise, increasing the number of response failures, and determining whether the number of response failures is less than a first threshold, and if so, returning Go to step 1; otherwise, output "query no response" to the access party, and end the method;
  • Step 3 receiving payment results about the order from the third-party payment channel, if the payment result is normally received, then go to step 4, otherwise go to step 5;
  • Step 4 query the transaction route callback configuration table according to the order query request, obtain an order callback address, perform callback according to the order callback address, and thereby push the payment result to the access party, and end the method;
  • Step 5 The number of receiving failures is incremented, and it is determined whether the number of receiving failures is less than a second threshold. If yes, the process returns to step 1; otherwise, the receiving party fails to receive the payment result, and the method ends.
  • a system for real-time callback ordering the system for performing various steps according to the method, the system comprising:
  • the order query request sending module is configured to send an order query request to the third-party payment channel for the order generated after the user performs the transaction with the merchant, wherein the third-party payment is repeated if the number of response failures is less than the first threshold
  • the channel sends an order inquiry request
  • the order query result output module is configured to output “query no response” to the access party if the number of response failures reaches the first threshold, and to access the access failure number to reach the second threshold
  • the party outputs "failure to receive payment result", and after receiving the payment result normally, pushes the payment result to the access party;
  • An order callback module configured to query a transaction route callback configuration table according to the order query request, obtain an order callback address, and perform callback according to the order callback address;
  • a timing module configured to set a time that the system needs to wait according to the number of response failures and the number of reception failures.
  • a computer readable storage medium wherein the computer readable storage medium stores thereon a program for performing the above method according to the present application, the program being executed by a processor , perform the following steps:
  • Step 1 Send an order inquiry request to a third-party payment channel for an order generated by the user after the transaction is performed by the access party;
  • Step 2 determining whether the third-party payment channel responds to the order query request, and if so, Go to step 3; otherwise, increase the number of response failures, and determine whether the number of response failures is less than the first threshold, and if yes, return to step 1; otherwise, output "query no response" to the access party, and end the present method;
  • Step 3 receiving payment results about the order from the third-party payment channel, if the payment result is normally received, then go to step 4, otherwise go to step 5;
  • Step 4 query the transaction route callback configuration table according to the order query request, obtain an order callback address, perform callback according to the order callback address, and thereby push the payment result to the access party, and end the method;
  • Step 5 The number of receiving failures is incremented, and it is determined whether the number of receiving failures is less than a second threshold. If yes, the process returns to step 1; otherwise, the receiving party fails to receive the payment result, and the method ends.
  • the asynchronous callback technology is applied to the scenario that the platform obtains the payment result from the third-party payment channel, and the scenario can be changed by changing the query frequency and limiting the number of queries.
  • the three-party payment channel performs polling to receive the payment result of the inquiry in time, and pushes the payment result to the accessing party in real time. At the same time, after pushing the payment result to the accessing party, it also polls continuously to check whether the accessing party is Received a response. In this way, the access party as the platform client can obtain the payment result faster, thereby notifying the user of the access party of the payment result more quickly, thereby improving the system efficiency and the user experience.
  • FIG. 1 is a schematic flow chart of a method for real-time callback order according to an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a stage of pushing a payment result to an access party in a method for real-time callback order according to an embodiment of the present application
  • FIG. 3 is a schematic structural diagram of a system for real-time callback order according to an embodiment of the present application
  • FIG. 4 is a schematic diagram of an operating environment of a system in which an application is installed, in accordance with an embodiment of the present application.
  • the main idea of the present application is to apply the asynchronous callback technology to the merchant access platform to obtain the return result of the third-party payment channel.
  • the scenario occurs in the terminal user (for example, through the merchant access platform, purchasing an access to an access merchant) The consumer of the product), after the payment is completed, the merchant who is the accessor wants to know the payment result.
  • the payment callback is to notify the merchant/user of the payment result in time. Because the user is in the transaction business (for example, to purchase goods from a merchant on the platform), only the merchant access platform (where various merchants are settled) is accessed on the terminal, and no instant connection is established with the payment channel (there is The APP corresponding to the payment channel may not be installed. The user cannot obtain the payment result through the payment channel from the merchant or the payment channel. Similarly, if the merchant accessing the platform needs to obtain the payment result independently, the order can only be used. The information is queried to the payment channel, and the query result is fed back to the user. The efficiency of this approach is relatively low.
  • the idea of the present application is that the platform notifies the merchant (access party) of the payment result through the background notification through the callback interface, so as to avoid, for example, the payment channel has been successfully debited, but the merchant still believes that the payment is still made. Unsuccessful situation.
  • the polling of the order payment result is continuously performed to the third-party payment channel by periodically changing the frequency of the query (the number of times the query can be changed), and the payment result of the current order can be received in time, and The payment result is pushed to the access party in real time.
  • the access party and the user do not need any additional operations/development.
  • FIG. 1 is a schematic flow chart of a method for real-time callback order according to an embodiment of the present application.
  • a method for real-time callback order is provided, wherein an access party refers to a system (a platform accessible to various merchants), and receives the system through the system.
  • the merchant of the payment platform result of the three-party payment channel ie, the "access party” and the "business” refer to the same object
  • the method includes the following steps performed by the system:
  • the order inquiry request is a request for querying the payment situation of the order to the third-party payment channel
  • the accessor/merchant can be a software platform that interfaces with the system and provides specific transaction services to the end user.
  • the merchant can be a shopping APP/website (it can be understood that the meaning of the APP can also be extended to the front-end program and The collective name of the back-end program, which runs on the back-end server, which requires access to the system in addition to the terminal (eg, a mobile phone) used by the user (eg, via the Internet).
  • an ID number identifying the service type parameter and the scene parameter is provided for determining the service type and the transaction scenario of the query request.
  • step S200 Determine whether the third-party payment channel responds to the order query request, and if yes, go to step S300; otherwise, increase the number of response failures, and determine whether the number of response failures is less than a first threshold (S201), and if so, Returning to step S100; otherwise, outputting "query no response" to the access party, and ending the method;
  • the third-party payment channel does not respond to the order inquiry for various reasons, which is more common in the actual transaction scenario.
  • step S300 receiving a payment result about the order from a third-party payment channel, if the payment result is normally received, then go to step S400, otherwise go to step S500;
  • the payment result of the order may be success or failure, and may also include “suspend” (in the case of asynchronous, for example, in the process of payment channel processing).
  • the system performs the query in the transaction route callback configuration table by obtaining the identifier service type parameter and the ID number of the scene parameter in the order query request, where the callback address of all the service types and the transaction scenario is recorded, and the Callback address, the system makes a callback and pushes the payment result to the access party.
  • step S500 If the payment result is not received normally, the number of receiving failures is incremented, and it is determined whether the number of receiving failures is less than a second threshold (S501), and if yes, returning to step S100; otherwise, accessing The party outputs "Failed to receive payment result" and ends the method.
  • S501 a second threshold
  • step S100 it is necessary to initialize the number of reception failures and the number of response failures.
  • the number of response failures and the number of reception failures can be limited.
  • manual intervention is required to check the payment status of the order.
  • step S200 if the number of response failures is less than the first threshold, after the first preset time interval, returning to step S100, wherein the first preset time interval follows the response The number of failures is incremented and incremented.
  • step S500 if the number of receiving failures is less than the second threshold, after the second preset time interval, returning to step S100, wherein the second preset time interval is followed by the receiving The number of failures is incremented and incremented.
  • the increment of the preset time interval may be in the form of, for example, 5 seconds, 10 seconds, and 15 seconds, so as not to affect the normal operation of the third-party payment channel, or to be determined as an abnormal request by the third-party payment channel.
  • step S200 while the “query is not responding” is output to the accessing party, the alerting email and/or the message may also be sent to the accessing platform of the accessing party, so that the prompting requires a manual intervention.
  • step S500 while the "receive payment result failure" is output to the accessing party, the alert mail and/or message may also be sent to the accessing party's management platform, so that the prompt prompting requires manual intervention.
  • FIG. 2 is a flow chart showing a stage of pushing a payment result to an access party in a method for real-time callback order according to an embodiment of the present application.
  • step S400 when the payment result is pushed to the access party, it is determined whether the access party responds to the push and successfully receives the payment result (S401) And if the access party fails to respond to the push, or fails to successfully receive the payment result, repeating the push, repeating the predetermined number of pushes in the push and the accessor fails to respond
  • S403 manual intervention is required.
  • the system can send alert emails and/or messages to the accessing party's management platform for faster prompting requiring manual intervention.
  • a system for real-time callback order the system for performing various steps of the method, the system mainly comprising:
  • the order query request sending module is configured to send an order query request to the third-party payment channel for the order generated after the user performs the transaction with the merchant, wherein the third-party payment is repeated if the number of response failures is less than the first threshold
  • the channel sends an order inquiry request
  • the order query result output module is configured to output “query no response” to the access party if the number of response failures reaches the first threshold, and to access the access failure number to reach the second threshold
  • the party outputs "failure to receive payment result", and after receiving the payment result normally, pushes the payment result to the access party;
  • An order callback module configured to query a transaction route callback configuration table according to the order query request, obtain an order callback address, and perform callback according to the order callback address;
  • a timing module configured to set a time that the system needs to wait according to the number of response failures and the number of reception failures.
  • system may further comprise an early warning module, configured to send an alert email and/or a message to the accessing party's management platform, so as to prompt the prompt for manual intervention.
  • an early warning module configured to send an alert email and/or a message to the accessing party's management platform, so as to prompt the prompt for manual intervention.
  • various embodiments of the present application can also be implemented by a software module or computer readable instructions stored on one or more computer readable medium, where the computer readable instructions are when When executed, the various embodiments described herein are performed.
  • any combination of software modules, computer readable media, and hardware components are contemplated by the present application.
  • the software modules can be stored on any type of computer readable storage medium such as RAM, EPROM, EEPROM, flash memory, registers, hard disk, CD-ROM, DVD, and the like.
  • FIG. 4 there is shown an operating environment of a system in which an application is installed, in accordance with an embodiment of the present application.
  • the system for installing the application is installed and runs in the electronic device.
  • the electronic device may be a computing device such as a desktop computer, a notebook, a palmtop computer, or a server.
  • the electronic device can include, but is not limited to, a memory, a processor, and a display.
  • Figure 4 shows only the electronic device with the above components, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.
  • the memory may be an internal storage unit of the electronic device, such as a hard disk or memory of the electronic device, in some embodiments.
  • the memory may also be an external storage device of the electronic device in other embodiments, such as a plug-in hard disk equipped on the electronic device, a smart memory card (SMC), and a secure digital (Secure Digital) , SD) card, flash card (Flash Card), etc.
  • the memory may also include both an internal storage unit of the electronic device and an external storage device.
  • the memory is used to store application software installed on the electronic device and various types of data, such as program code of the system in which the application is installed.
  • the memory can also be used to temporarily store data that has been output or is about to be output.
  • the processor may, in some embodiments, be a central processing unit (CPU), a microprocessor, or other data processing chip for executing program code or processing data stored in the memory, such as performing the Install the application's system, etc.
  • CPU central processing unit
  • microprocessor microprocessor
  • other data processing chip for executing program code or processing data stored in the memory, such as performing the Install the application's system, etc.
  • the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch sensor, or the like in some embodiments.
  • the display is for displaying information processed in the electronic device and a user interface for displaying visualizations, such as an application menu interface, an application icon interface, and the like.
  • the components of the electronic device communicate with one another via a system bus.
  • the method in the foregoing embodiment can be implemented by means of software plus a necessary general hardware platform, and can also be implemented by hardware, but in many cases.
  • the former is a better implementation.
  • the technical solution of the present application which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.
  • a computer readable storage medium having stored thereon a program for executing a reconciliation difference processing method, the program being processed by a processor At the time of execution, the steps of the reconciliation difference processing method according to the embodiment of the present application are executed.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请涉及实时回调订单的方法和系统，该方法包括：步骤1、针对用户通过接入方进行交易后产生的订单，向支付通道发送订单查询请求；步骤2、判断支付通道是否对订单查询请求作出响应，若是，则转到步骤3；否则，重复发送订单查询请求；步骤3、从支付通道接收关于订单的支付结果，如果正常接收到支付结果，则转到步骤4，否则转到步骤5；步骤4、根据订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据订单回调地址进行回调，并由此向接入方推送支付结果，并结束本方法；步骤5、向接入方重复推送支付结果。通过本申请，作为平台客户的接入方能够更快获取支付结果，从而能够更快将支付结果通知给用户，提升了系统效率和用户体验。

Description

实时回调订单的方法和系统
本申请申明享有2018年5月30日递交的申请号为201810538022.1、名称为“订单流程处理方法和系统”的中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请涉及互联网服务技术领域，尤其涉及一种订单流程处理方法和系统。
背景技术
随着科学技术的发展，人们生活水平的逐步提高，网络已经在社会生活中广泛应用，其中，交易的多样化使得后台管理系统所对接的专业公司(商家)各不相同，每个专业公司所处理的业务亦不相同。市面上很多程序处理交易类流程时对外提供接口比较多，接口多就意味着对接成本和维护成本都变得较高。
传统的订单流程处理方式是串行的交互过程，即：针对客户端(专业公司、或者最终用户)发起的业务请求，后台管理系统(即，服务端)需要根据订单流程而逐一处理每个进程(子流程)，处理完毕之后，才能够将最终处理结果返回到发起业务请求的客户端。
因此，对于客户端用户来说，其体验很大程度上依赖于服务端对业务请求的处理耗时情况，如果服务端执行耗时非常长和/或耗时难以预估的业务处理操作，那么就会导致客户端一直处于等待状态，而用户并不清楚等待的时长，使得用户(接入方)无法及时看到订单处理的结果。例如：对于某些订单业务，后台管理系统可能需要再接入第三方(例如，查询商品库存状况)而获得处理流程中的所需信息，而第三方的响应时间往往难以精确掌握。因 此，如果服务端与客户端长时间的保持连接状态，会导致大量的资源被浪费，吞吐能力很低。
由此可见，在后台管理系统对接多个客户(例如商家、专业公司)的情况下，由于每个客户端处理的业务并不相同、可能涉及第三方(甚至还有更多参与方)，在这些不同的业务场景中，存在基于交易路由场景理念来解决不同客户不同场景的业务需求，以便克服服务端处理效率低、用户等待时间长的问题。
发明内容
考虑到现有技术的上述问题，本申请的主要目的在于：为了方便用户，根据业务逻辑中的进程的实际处理需要，在各种场景下，同步/异步处理方式均可自由切换，完成交易订单的所有步骤。
具体地，本申请提出了订单流程处理方案，可包括以下方面：
1、根据场景路由参数中的商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台、支付规则等参数，可确定交易场景；
2、根据确定的场景，获取在该场景下已预先配置的订单预处理功能和通道功能；
3、对于特定订单，根据订单预处理功能功能，组装成一个完整的交易处理流程，即，进一步确定处理进程组合；
4、特定订单根据所述流程处理交易，实时进行异步判断，并向客户端反馈处理情况。
根据本申请的实施例，提供了订单流程处理系统，包括以下步骤：
步骤1、从客户端接收订单处理请求，根据所述订单处理请求获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
步骤2、判断对所述进程队列中的当前进程是否需要进行异步处理；
步骤3、如果对所述当前进程需要进行异步处理，则通知客户端将以异步方式推送订单处理结果，将所述当前进程放入异步队列，并在异步处理结束后向客户端推送处理结果；
步骤4、如果对所述当前进程无需执行异步处理，则对所述当前进程执行同步处理，获得所述当前进程的处理状态；
步骤5、如果所述当前进程的处理状态为“处理异常”，则记录所述当前进程的处理信息，所述处理信息包括用于再次执行所述当前进程所需的信息；
步骤6、如果所述当前进程的处理状态为“处理成功”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2，否则，输出订单处理结果。
根据本申请的实施例，提供了一种用于执行所述方法的订单流程处理系统，包括订单受理组件、进程处理组件、订单反馈组件、进程异步判断组件、进程记录部件，
其中，所述订单受理组件用于从客户端接收订单处理请求，从所述订单处理请求中获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
其中，订单反馈组件用于将订单处理结果反馈给客户端。
其中，所述进程异步判断组件用于对所述进程队列中的当前进程进行异步判断，
其中，所述进程处理组件用于：在需要对当前进程进行异步处理时，将所述当前进程放入异步队列；
其中，所述进程处理组件还用于：在对当前进程进行同步处理时，执行相应处理，生成当前进程的处理结果，并通过所述订单反馈组件向客户端反馈处理结果；
其中，所述进程记录部件用于记录各个订单的进程处理状态、历史处理记录，包括处理次数、每次的处理方式、处理状态(延缓、成功、失败)。
根据本申请的实施例，提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有用于上述方法的程序，所述程序被处理器执行时，执行以下步骤的操作：
步骤1、从客户端接收订单处理请求，根据所述订单处理请求获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
步骤2、判断对所述进程队列中的当前进程是否需要进行异步处理；
步骤3、如果对所述当前进程需要进行异步处理，则通知客户端将以异步方式推送订单处理结果，将所述当前进程放入异步队列，并在异步处理结束后向客户端推送处理结果；
步骤4、如果对所述当前进程无需执行异步处理，则对所述当前进程执行同步处理，获得所述当前进程的处理状态；
步骤5、如果所述当前进程的处理状态为“处理异常”，则记录所述当前进程的处理信息，所述处理信息包括用于再次执行所述当前进程所需的信息；
步骤6、如果所述当前进程的处理状态为“处理成功”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2，否则，输出订单处理结果。
本申请的有益效果主要在于：1、对外部的各个接入方(专业公司)可以统一接口；2、系统的维护成本较低；3、通过对进程队列的事先配置，使得可以对同一场景是否进行同步异步进行自由切换，同时，同一个场景的进程队列可以进行复用；4、场景建模后，经过参数化配置能够快速上线；5、支付通道可配置化，可以根据预设好的流程，快速处理业务，解决不同专业公司不同场景的业务需求。
附图说明
图1为根据本申请的一个实施例的订单流程处理方法的部分流程示意图；
图2为根据本申请的另一个实施例的订单流程处理方法的部分流程示意图；
图3为根据本申请的实施例的订单流程处理系统的功能架构示意图；
图4为根据本申请实施例的安装了应用程序的系统的运行环境的示意图。
具体实施方式
下面，结合附图对技术方案的实施作进一步的详细描述。
本领域的技术人员能够理解，尽管以下的说明涉及到有关本申请的实施例的很多技术细节，但这仅为用来说明本申请的原理的示例、而不意味着任何限制。本申请能够适用于不同于以下例举的技术细节之外的场合，只要它们不背离本申请的原理和精神即可。
另外，为了避免使本说明书的描述限于冗繁，在本说明书中的描述中，可能对可在现有技术资料中获得的部分技术细节进行了省略、简化、变通等处理，这对于本领域的技术人员来说是可以理解的，并且这不会影响本说明书的公开充分性。
下文中，将描述用于进行本申请的实施例。注意，将以下面的次序给出描述：1、发明构思的概要；2、订单流程处理方法(图1和2)；3、订单流程处理系统(图3)；4、根据本申请的实施例的安装了应用程序的系统、以及存储所述应用程序的计算机可读介质(图4)。
1、发明构思的概要
本申请的构思要点在于：
1、在订单受理时，通过获取订单的场景路由参数，根据其场景路由参数判断订单流程所应获取的不同业务处理流程(流程配置以及进程队列)。通过前述场景建模以及订单场景路由化，使得订单流程参数化配置，使得处理方法能够快速上线应用；同时，可以根据人工事先预设好的流程，快速处理业务，解决不同专业公司不同场景的业务需求。
2、通过对进程队列的事先配置，使得人工可以对同一场景是否进行同步异步进行自由切换，同时，同一个场景的进程队列可以进行复用。
3、通过在订单流程配置中，设置进程参数，包括执行进程异步判断相关的参数，并可通过向后台发出告警邮件，由人工介入查看，降低人为失误的失败率，提升客户体验。
4、在订单处理未成功的情况下，通过记录处理所中断的进程、以及每个进程的处理细节，可以实现断点重连。
2、订单流程处理方法
图1为根据本申请的一实施例的订单流程处理方法的部分流程示意图。图2为根据本申请的另一实施例的订单流程处理方法的部分流程示意图。
如图1所示，本申请的实施例提供了一种订单流程处理方法，其中，处理订单的过程包括订单校验、订单异步处理判断以及订单进程处理这几个阶段，所述方法包括：
步骤S100、从客户端接收订单处理请求，从所述订单处理请求中获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
其中，所述进程队列是根据与所述订单相关的场景路由参数确定的；
其中，所述场景路由参数可包括商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台以及支付规则等具体参数，不同的参数组合对应不同的订单处理场景，即，订单处理场景是由多维条件共同决定的；
例如，对于出行类服务订单的订单处理场景，商品提供方可为提供出行 服务的公司，商品编码对应于具体产品(例如打车产品)，支付方式对应于用户的支付通道(例如，支付宝、微信、银联等)，支付规则包括先付(例如一口价)、后付(例如根据行程)，等等。
这样，可根据上述参数的多种组合定义多种订单处理场景，如出行场景1、出行场景2、出行场景3，等等。作为示例，由于出行场景1、出行场景2、出行场景3等均属于出行场景，可具有相同的订单预处理进程(例如专属于出行服务的预处理进程，包括校验驾驶员和乘客的身份)、以及不同的交易处理进程(例如，先付和后付、支付宝和微信各对应于不同的对账方式，即，不同的对账进程)。
换句话说，所述订单处理场景可由所述场景路由参数转换为多维条件的表达形式，每个维度都可以涉及不同的处理进程/进程队列，各个维度的组合形成所述订单处理场景所对应的完整流程，其通过处理进程/进程队列来表示；
步骤S200、对所述进程队列中的当前进程进行异步判断；
其中，可根据当前进程的进程参数(例如，执行当前进程所涉及的业务类型，如支付、查询等)，判断是否需要对当前进程进行异步处理，如需异步处理，则客户端不能即时获得订单的处理结果，相应地，在正常情况下，对当前进程进行同步处理，客户端可以即时获得订单的处理结果，如交易成功、支付失败、校验失败、商品库存不足等等。
其中，所述异步队列由后台管理系统维护，需要异步处理的进程通常是订单处理进程中相对耗时的进程、和/或依赖于第三方响应的进程；同时，作为示例，其处理并不影响后续进程(同步进程或者异步进程)的处理，也就是说，后续进程(同步进程)的处理并不依赖于前一进程的处理结果；后台管理系统可通过广播方式处理异步队列中的进程，例如，以定期方式处理异步队列中的进程，在第三方对异步进程无响应或处理超时的情况下，循环重复处理所述进程。
作为示例，可通过判断所述当前进程中是否携带了请求异步处理的标识、或通过判断所述当前进程涉及的第三方/业务操作是否被标识为需要采用异步处理方式、或通过判断与所述当前进程对应的业务处理耗时参考值，来判断所述当前进程是否需要进行异步处理；
可选地，根据与所述当前进程相对应的业务处理耗时参考值，估算处理所述当前进程的耗时；
可选地，根据估算的处理所述当前进程的耗时、以及所述当前进程中携带的网络环境数据，计算处理所述当前进程的参考时间；
作为示例，所述网络环境数据包括：当前所用网络的网络类型、网络制式和/或信号强度、当前所用网络的网络传输速度；
此外，还可根据所述当前进程的处理信息(包括历史处理信息)，判断是否需要对当前进程进行异步处理，例如，如果所述当前进程存在历史处理记录(之前曾经处理异常)，则可将之前的同步处理改为异步处理，即，对执行同步处理未完成的进程进行异步处理；
步骤S300、若对所述当前进程需要进行异步处理，则通知客户端以异步方式推送订单处理结果(例如，在客户端上弹出消息“稍后推送订单处理结果，请等待”)，将所述当前进程放入异步队列，并在异步处理结束后向客户端推送处理结果；
这样，用户在看到上述消息后，不会一直在客户端等待“同步”处理结果，改善了用户体验。
步骤S400、若对所述当前进程无需执行异步处理，则对所述当前进程执行同步处理，获得所述当前进程的处理状态；
步骤S500、若当前进程的处理状态为“处理异常”(同步处理出现异常，暂无法处理完毕并获得处理结果，这并非意味着处理失败)，则将所述订单状态记录为“订单处理中”，并记录所述当前进程的处理信息(这意味着订单中的部分进程的同步处理出现延缓，可记录这些延缓进程的信息(例如， 包括当前进程在进程队列中的位置、进程序列号、异常类型，等等)，以便用于将来的断点重连，或者将同步处理方式改为异步处理方式)，转到步骤S700；
其中，在执行相应处理的过程中，还可实时生成所述当前进程的处理状态信息，例如，如果当前进程因为某种原因被挂起，可生成并显示状态信息为“xx进程保持处理中”；
其中，对于“保持处理中”的各个进程，可由服务端自动重新处理，或可由客户端发起重新处理的请求，并无需重复执行已经处理完毕的进程，这样能够提高订单处理的复用率。
步骤S600、若当前进程的处理状态为“处理成功”，则判断当前进程是否为所述进程队列中的最后一个进程；
其中，如果当前进程处理结束，也可生成并显示状态信息为“xx进程处理成功”、或者“xx进程处理失败”；
如果当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤S200；否则，结束本方法；
步骤S700、对于当前进程的处理状态为“处理异常”或“处理失败”(即，已经完成了处理，但处理失败，其意味着该进程确认失败、确认订单处理失败，已无需再进行重复处理)的，可结束本方法，之后，如果需要再次处理同一订单，则需要客户端重新发起请求，重新处理进程队列中的全部进程；
如图2所示，可选地，如果部分同步处理进程处理失败，则可根据处理失败原因，重复执行部分同步处理进程(步骤S702)。例如，如果处理失败原因是第三方无响应或响应超时，则可自动循环执行相关的进程，并向客户端通知“部分同步处理进程正在重试，请等待”。
其中，通过上述步骤S200至S700的循环逻辑，可以汇总所述进程队列中的全部进程的历史处理记录，包括处理次数、每次的处理方式(同步/异步)、处理状态(延缓、成功、失败)，这样，服务端可以设定具体的循环规 则，在整个订单处理未失效的情况下(包括必要进程尚未失败的情况)，可定期对未决进程(为处理完毕)进行再次处理。
其中，对于同步处理异常的进程，如果达到一定限制(例如，重复次数限制)，也可自动放入异步队列(S704)，直接转为异步处理，而无需再进行步骤S200的异步判断。
其中，可选地，进程队列中的各个进程也可带有与重复处理相关的标识，例如，可重复处理的次数、超时时间等等，其中，如果将可重复处理的次数设置为0，即表示不能进行重复处理，对处理异常的情况，一旦到达超时时间，即将处理状态确定为“处理失败”
3、订单流程处理系统
根据本申请的实施例，提供了一种订单流程处理系统，用于执行本申请中的所述方法的各个步骤，如图3所示，所述订单流程处理系统主要包括订单受理组件、进程处理组件、订单反馈组件、进程异步判断组件、进程记录部件。
其中，所述订单受理组件用于从客户端接收订单处理请求，从所述订单处理请求中获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
其中，所述进程队列是根据与所述订单相关的场景路由参数确定的；
其中，所述场景路由参数可包括商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台以及支付规则等具体参数，不同的参数组合对应不同的订单处理场景，即，订单处理场景是由多维条件共同决定的。
订单反馈组件用于将订单处理结果反馈给客户端。
其中，所述进程异步判断组件用于对所述进程队列中的当前进程进行异步判断。
其中，所述进程处理组件用于：在需要对当前进程进行异步处理时，将所述当前进程放入异步队列；
其中，所述进程处理组件还用于：在对当前进程进行同步处理时，执行相应处理，生成当前进程的处理结果，并通过所述订单反馈组件向客户端反馈处理结果；
其中，所述进程处理组件还可用于：依次执行所述进程队列中的全部进程，并将进程处理中生成的相关信息发送到所述进程记录部件。
其中，所述进程记录部件用于记录各个订单的进程处理状态、历史处理记录，包括处理次数、每次的处理方式(同步/异步)、处理状态(延缓、成功、失败)。
此外，本申请的不同实施例也可以通过软件模块或存储在一个或多个计算机可读介质上的计算机可读指令的方式实现，其中，所述计算机可读指令是当被处理器或设备组件执行时，执行本申请所述的不同的实施例。类似地，软件模块、计算机可读介质和硬件部件的任意组合都是本申请预期的。所述软件模块可以被存储在任意类型的计算机可读存储介质上，例如RAM、EPROM、EEPROM、闪存、寄存器、硬盘、CD-ROM、DVD等等。
4、根据本申请的实施例的安装了应用程序的系统
参照图4，其示出了根据本申请实施例的安装了应用程序的系统的运行环境。
在本实施例中，所述的安装应用程序的系统安装并运行于电子装置中。所述电子装置可以是桌上型计算机、笔记本、掌上电脑及服务器等计算设备。该电子装置可包括但不限于存储器、处理器及显示器。图中仅示出了具有上述组件的电子装置，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
所述存储器在一些实施例中可以是所述电子装置的内部存储单元，例如 该电子装置的硬盘或内存。所述存储器在另一些实施例中也可以是所述电子装置的外部存储设备，例如所述电子装置上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器还可以既包括所述电子装置的内部存储单元也包括外部存储设备。所述存储器用于存储安装于所述电子装置的应用软件及各类数据，例如所述安装应用程序的系统的程序代码等。所述存储器还可以用于暂时地存储已经输出或者将要输出的数据。
所述处理器在一些实施例中可以是中央处理单元(Central Processing Unit，CPU)、微处理器或其他数据处理芯片，用于运行所述存储器中存储的程序代码或处理数据，例如执行所述安装应用程序的系统等。
所述显示器在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。所述显示器用于显示在所述电子装置中处理的信息以及用于显示可视化的客户界面，例如应用菜单界面、应用图标界面等。所述电子装置的部件通过系统总线相互通信。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解，上述实施方式中的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件商品的形式体现出来，该计算机软件商品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
也就是说，根据本申请的实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有用于执行根据本申请的实施例的所述方法的程序，所述程序被处理器执行时，执行所述方法的各个步骤。
由上，将理解，为了说明的目的，这里已描述了本申请的具体实施例， 但是，可作出各个修改，而不会背离本申请的范围。本领域的技术人员将理解，流程图步骤中所绘出或这里描述的操作和例程可以多种方式变化。更具体地，可重新安排步骤的次序，可并行执行步骤，可省略步骤，可包括其它步骤，可作出例程的各种组合或省略。因而，本申请仅由所附权利要求限制。
订单流程处理方法和系统
本申请申明享有2018年4月10日递交的申请号为201810316255.7、名称为“实时回调订单的方法和系统”的中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请涉及计算机服务技术领域，尤其涉及一种实时回调订单的方法和系统。
背景技术
随着互联网技术的不断发展，支付通道日益增多，作为接收各支付通道的支付信息的平台(例如，进驻了多个商户的电商平台)，需要对用户通过各个支付通道的订单进行处理，以便通过支付订单回调而将用户的支付情况及时反馈给商户(接入所述平台的接入方)。此时，由于不同的支付通道的订单处理时间以及响应时间的不同、或者查询处理规则的不同、或者同步异步处理方式的不同，使得如果接入方需要知晓结果，经常需要由接入方主动向支付平台提出查询请求，这对用户体验会造成不利影响，同时，信息反馈的时效性亦较低。
发明内容
基于此，有必要针对上述技术问题，提供一种新的技术方案，其能够根据需要不断向第三方支付通道进行轮询，以便及时获取支付结果，并实时向接入方推送支付结果。
根据本申请的实施例，提供了一种实时回调订单的方法，其特征在于包括以下步骤：
步骤1、针对用户通过接入方进行交易后产生的订单，向第三方支付通道发送订单查询请求；
步骤2、判断第三方支付通道是否对所述订单查询请求作出响应，若是，则转到步骤3；否则使响应失败次数递增，并判断所述响应失败次数是否小于第一阈值，若是，则返回到步骤1；否则，向接入方输出“查询无响应”，并结束本方法；
步骤3、从第三方支付通道接收关于所述订单的支付结果，如果正常接收到所述支付结果，则转到步骤4，否则转到步骤5；
步骤4、根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调，并由此向接入方推送所述支付结果，并结束本方法；
步骤5、使接收失败次数递增，并判断所述接收失败次数是否小于第二阈值，若是，则返回到步骤1；否则，向接入方输出“接收支付结果失败”，并结束本方法。
根据本申请的实施例，还提供了一种用于实时回调订单的系统，所述系统用于执行根据所述方法的各个步骤，所述系统包括：
订单查询请求发送模块，用于针对用户与商户进行交易后产生的订单，向第三方支付通道发送订单查询请求，其中，在所述响应失败次数小于第一阈值的情况下，重复向第三方支付通道发送订单查询请求；
订单查询结果输出模块，用于在所述响应失败次数达到第一阈值的情况下，向接入方输出“查询无响应”，在所述接收失败次数达到第二阈值的情况下，向接入方输出“接收支付结果失败”，在正常接收到支付结果之后，向接入方推送所述支付结果；
订单回调模块，用于根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调；
定时模块，用于根据所述响应失败次数和所述接收失败次数而设定系统需要等待的时间。
根据本申请的实施例，还提供了一种计算机可读存储介质，其中，所述计算机可读存储介质上存储有用于执行根据本申请的上述方法的程序，所述程序在被处理器执行时，执行以下步骤的操作：
步骤1、针对用户通过接入方进行交易后产生的订单，向第三方支付通道发送订单查询请求；
步骤2、判断第三方支付通道是否对所述订单查询请求作出响应，若是， 则转到步骤3；否则使响应失败次数递增，并判断所述响应失败次数是否小于第一阈值，若是，则返回到步骤1；否则，向接入方输出“查询无响应”，并结束本方法；
步骤3、从第三方支付通道接收关于所述订单的支付结果，如果正常接收到所述支付结果，则转到步骤4，否则转到步骤5；
步骤4、根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调，并由此向接入方推送所述支付结果，并结束本方法；
步骤5、使接收失败次数递增，并判断所述接收失败次数是否小于第二阈值，若是，则返回到步骤1；否则，向接入方输出“接收支付结果失败”，并结束本方法。
本申请的有益效果主要在于：与该现有技术相比，将异步回调技术应用于平台从第三方支付通道获取支付结果这一场景，可通过变更查询频率、限制查询次数等方式，不断向第三方支付通道进行轮询，以便及时收到查询的支付结果，并将支付结果实时推送给接入方；同时，在向接入方推送支付结果后，亦通过不断轮询，查看接入方是否收到响应结果。这样，作为平台客户的接入方能够更快获取支付结果，从而更快将支付结果通知给接入方自身的用户，提升了系统效率和用户体验。
附图说明
图1为根据本申请的实施例的一种实时回调订单的方法的流程示意图；
图2为根据本申请的实施例的一种实时回调订单的方法的向接入方推送支付结果阶段的流程示意图；
图3为根据本申请的实施例的一种实时回调订单的系统的架构示意图；
图4为根据本申请的实施例的安装了应用程序的系统的运行环境的示意图。
具体实施方式
下面，结合附图对技术方案的实施作进一步的详细描述。
本领域的技术人员能够理解，尽管以下的说明涉及到有关本申请的实施例的很多技术细节，但这仅为用来说明本申请的原理的示例、而不意味着任何限制。本申请能够适用于不同于以下例举的技术细节之外的场合，只要它们不背离本申请的原理和精神即可。
另外，为了避免使本说明书的描述限于冗繁，在本说明书中的描述中，可能对可在现有技术资料中获得的部分技术细节进行了省略、简化、变通等处理，这对于本领域的技术人员来说是可以理解的，并且这不会影响本说明书的公开充分性。
下文中，将描述用于进行本申请的实施例。注意，将以下面的次序给出描述：1、发明构思的概要；2、一种实时回调订单的方法(图1-图3)；3、一种实时回调订单的系统(图3)；5、根据本申请的实施例的安装了应用程序的系统、以及存储所述应用程序的计算机可读介质(图4)。
1、发明构思的概要
本申请的构思要点是将异步回调技术应用于商户接入平台获取第三方支付通道返回结果的场景，该场景出现在终端用户(例如，通过商户接入平台、向某个接入商户购买某个产品的消费者)完成支付后、作为接入方的商户想了解支付结果的场合。
具体而言，支付回调是为了把支付结果及时通知给商户/用户。因为用户在进行交易业务(例如，向平台上的某个商户购买商品)时，仅在终端上访问商户接入平台(其中入驻了各类商户)，而并未与支付通道建立即时连接(有可能并未安装支付通道对应的APP)，用户无法从商户或者支付通道即时获取通过所述支付通道的支付结果；类似地，接入所述平台的商户如需独立获取支付结果，只能通过订单信息向支付通道进行查询，再将查询结果通过反馈给用户，这种途径的工作效率是较为低下的。
相比之下，本申请的构思在于，平台通过回调接口，通过后台通知的方式把支付结果通知到商户(接入方)，这样可避免出现例如支付通道已经扣款成功、但是商户仍认为支付未成功的情况。
具体地，根据本申请的实施例，通过定期多次(可变更查询频率、限制查询次数)不断向第三方支付通道进行订单支付结果的轮询，可及时收到当前订单的支付结果，并将支付结果实时推送到接入方。在此情况下，接入方和用户无需任何附加操作/开发。
2、一种实时回调订单的方法(图1-2)
图1为根据本申请的实施例的一种实时回调订单的方法的流程示意图。
如图1所示，根据本申请的实施例，提供了一种实时回调订单的方法，其中，接入方是指与系统(可供各类商户接入的平台)对接、并通过系统接收第三方支付通道的支付平台结果的商户(即，本文中的“接入方”与“商户”指代的是同一对象)，所述方法包括由系统执行的如下步骤：
S100、针对用户与商户进行交易后产生的订单，向第三方支付通道发送订单查询请求；
其中，在用户与商户之间发生交易并通过第三方支付通道进行了支付后，生成了特定订单，所述订单查询请求是用于向第三方支付通道查询所述订单的支付情况的请求，
其中，接入方/商户可为与系统对接、并向终端用户提供具体交易服务的软件平台，典型地，商户可为购物类APP/网站(可以理解，APP的含义也可扩展至前端程序和后端程序的统称，后端程序运行于后端服务器)，其除了与用户所使用的终端(例如手机)连接(例如，经由互联网)之外，还需接入所述系统。
作为示例，在所述订单查询请求中，设有标识业务类型参数和场景参数的ID号码，用于判断该查询请求的业务类型和交易场景。
S200、判断第三方支付通道是否对所述订单查询请求作出响应，若是，则转到步骤S300；否则将响应失败次数递增，并判断所述响应失败次数是否小于第一阈值(S201)，若是，则返回到步骤S100；否则，向接入方输出“查询无响应”，并结束本方法；
其中，第三方支付通道因为各种原因而未对所述订单查询作出响应，这在实际交易场景中是较为常见的。
S300、从第三方支付通道接收关于所述订单的支付结果，如果正常接收到所述支付结果，则转到步骤S400，否则转到步骤S500；
在实际场景中，有可能出现这样的情况：尽管第三方支付通道对所述订单查询请求做出了响应，但未能向系统成功发送支付结果，此时需要重新进行查询。
其中，所述订单的支付结果可为成功或者失败，可选地，也可包括“挂起”(在异步情况下，例如，正在支付通道处理的过程中)。
S400、根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调(即，在接入方APP/网站中跳转回到相关页面)，并由此向接入方推送所述支付结果，并结束本方法；
其中，系统通过获取订单查询请求中的标识业务类型参数和场景参数的ID号码，在交易路由回调配置表中进行查询，该表中记录有所有业务类型与交易场景进行组合的回调地址，通过该回调地址，系统进行回调，并向接入方推送支付结果。
S500、在未能正常接收到所述支付结果的情况下，接收失败次数递增，并判断所述接收失败次数是否小于第二阈值(S501)，若是，则返回到步骤S100；否则，向接入方输出“接收支付结果失败”，并结束本方法。
其中，可以理解，在步骤S100之前，需要初始化接收失败次数和响应失败次数。
通过上述步骤，可以限定响应失败次数和接收失败次数，在所述次数中的一个达到预定阈值时，需要人工介入来核对该订单的支付情况。
可选地，在步骤S200中，如果所述响应失败次数小于第一阈值，则在第一预设时间间隔后，返回到步骤S100，其中，所述第一预设时间间隔随着所述响应失败次数的递增而递增。
可选地，在步骤S500中，如果所述接收失败次数小于第二阈值，则在第二预设时间间隔后，返回到步骤S100，其中，所述第二预设时间间隔随着所述接收失败次数的递增而递增。
例如，上述预设时间间隔的递增可以例如5秒、10秒、15秒的形式，从而不会影响到第三方支付通道的正常工作，或者避免被第三方支付通道判定为异常请求。
可选地，在步骤S200中，在向接入方输出“查询无响应”的同时，也可向接入方的管理平台发送预警邮件和/或消息，以便更快的提示需要人工介入。
类似地，在步骤S500中，在向接入方输出“接收支付结果失败”的同时，也可向接入方的管理平台发送预警邮件和/或消息，以便更快的提示需要人工介入。
图2为根据本申请的实施例的一种实时回调订单的方法的向接入方推送支付结果阶段的流程示意图。
可选地，如图2所示，在步骤S400中，在向所述接入方推送所述支付结果时，判断所述接入方是否响应所述推送并成功接收到所述支付结果(S401)，如果所述接入方未能响应所述推送、或未能成功接收到所述支付结果，则重复所述推送，在所述推送重复了预定推送次数而所述接入方未能响应所述推送、或未能成功接收到所述支付结果的情况下(S402)，提示需要人工介入(S403)。在此情况下，类似地，系统可向接入方的管理平台发送预警邮件和/或消息，以便更快的提示需要人工介入。
3、一种实时回调订单的系统(图3)
参照图3，根据本申请的实施例，还提供了一种用于实时回调订单的系统，所述系统用于执行所述方法的各个步骤，所述系统主要包括：
订单查询请求发送模块，用于针对用户与商户进行交易后产生的订单，向第三方支付通道发送订单查询请求，其中，在所述响应失败次数小于第一阈值的情况下，重复向第三方支付通道发送订单查询请求；
订单查询结果输出模块，用于在所述响应失败次数达到第一阈值的情况下，向接入方输出“查询无响应”，在所述接收失败次数达到第二阈值的情况下，向接入方输出“接收支付结果失败”，在正常接收到支付结果之后，向接入方推送所述支付结果；
订单回调模块，用于根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调；
定时模块，用于根据所述响应失败次数和所述接收失败次数而设定系统需要等待的时间。
可选地，所述系统还可包括预警模块，用于向接入方的管理平台发送预警邮件和/或消息，以便更快地提示需要人工介入。
此外，本申请的不同实施例也可以通过软件模块或存储在一个或多个计算机可读介质上的计算机可读指令的方式实现，其中，所述计算机可读指令是当被处理器或设备组件执行时，执行本申请所述的不同的实施例。类似地，软件模块、计算机可读介质和硬件部件的任意组合都是本申请预期的。所述软件模块可以被存储在任意类型的计算机可读存储介质上，例如RAM、EPROM、EEPROM、闪存、寄存器、硬盘、CD-ROM、DVD等等。
4、根据本申请的实施例的安装了应用程序的系统
参照图4，其示出了根据本申请的实施例的安装了应用程序的系统的运行环境。
在本实施例中，所述的安装应用程序的系统安装并运行于电子装置中。所述电子装置可以是桌上型计算机、笔记本、掌上电脑及服务器等计算设备。该电子装置可包括但不限于存储器、处理器及显示器。图4仅示出了具有上述组件的电子装置，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
所述存储器在一些实施例中可以是所述电子装置的内部存储单元，例如该电子装置的硬盘或内存。所述存储器在另一些实施例中也可以是所述电子装置的外部存储设备，例如所述电子装置上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器还可以既包括所述电子装置的内部存储单元也包括外部存储设备。所述存储器用于存储安装于所述电子装置的应用软件及各类数据，例如所述安装应用程序的系统的程序代码等。所述存储器还可以用于暂时地存储已经输出或者将要输出的数据。
所述处理器在一些实施例中可以是中央处理单元(Central Processing Unit，CPU)、微处理器或其他数据处理芯片，用于运行所述存储器中存储的程序代码或处理数据，例如执行所述安装应用程序的系统等。
所述显示器在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。所述显示器用于显示在所述电子装置中处理的信息以及用于显示可视化的用户界面，例如应用菜单界面、应用图标界面等。所述电子装置的部件通过系统总线相互通信。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解，上述实施方式中的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
也就是说，根据本申请的实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有用于执行一种对账差异处理方法的程序，所述程序被处理器执行时，执行根据本申请的实施例的对账差异处理方法的步骤。
由上，将理解，为了说明的目的，这里已描述了本申请的具体实施例，但是，可作出各个修改，而不会背离本申请的范围。本领域的技术人员将理解，流程图步骤中所绘出或这里描述的操作和例程可以多种方式变化。更具体地，可重新安排步骤的次序，可并行执行步骤，可省略步骤，可包括其它步骤，可作出例程的各种组合或省略。因而，本申请仅由所附权利要求限制。

Claims (40)

  1. 一种实时回调订单的方法，其特征在于包括以下步骤：
    步骤1、针对用户通过接入方进行交易后产生的订单，向第三方支付通道发送订单查询请求；
    步骤2、判断第三方支付通道是否对所述订单查询请求作出响应，若是，则转到步骤3；否则使响应失败次数递增，并判断所述响应失败次数是否小于第一阈值，若是，则返回到步骤1；否则，向接入方输出“查询无响应”，并结束本方法；
    步骤3、从第三方支付通道接收关于所述订单的支付结果，如果正常接收到所述支付结果，则转到步骤4，否则转到步骤5；
    步骤4、根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调，并由此向接入方推送所述支付结果，并结束本方法；
    步骤5、使接收失败次数递增，并判断所述接收失败次数是否小于第二阈值，若是，则返回到步骤1；否则，向接入方输出“接收支付结果失败”，并结束本方法。
  2. 根据权利要求1所述的实时回调订单的方法，其特征在于，所述接入方是指与执行所述方法的系统对接、并通过所述系统接收第三方支付通道的支付结果的商户系统，
    其中，在用户通过商户系统发生交易、并通过第三方支付通道进行了支付后，生成所述订单。
  3. 根据权利要求1所述的实时回调订单的方法，其特征在于，所述订单查询请求中包括业务类型参数和场景参数，其分别用于标识所述订单查询请求的业务类型和交易场景。
  4. 根据权利要求1所述的实时回调订单的方法，其特征在于，在步骤4中，通过获取所述订单查询请求中的业务类型参数和场景参数，查询交易路由回调配置表，
    其中，在所述交易路由回调配置表中记录有与各个业务类型和各个交易场景相对应的订单回调地址。
  5. 根据权利要求1所述的实时回调订单的方法，其特征在于，在步骤2中，在向接入方输出“查询无响应”的同时，向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入，
    并且，在步骤5中，在向接入方输出“接收支付结果失败”的同时，向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入。
  6. 根据权利要求1所述的实时回调订单的方法，其特征在于，在步骤2中，如果所述响应失败次数小于第一阈值，则在第一预设时间间隔后，返回到步骤1，其中，所述第一预设时间间隔随着所述响应失败次数的递增而递增。
  7. 根据权利要求1所述的实时回调订单的方法，其特征在于，在步骤5中，如果所述接收失败次数小于第二阈值，则在第二预设时间间隔后，返回到步骤1，其中，所述第二预设时间间隔随着所述接收失败次数的递增而递增。
  8. 根据权利要求1所述的实时回调订单的方法，其特征在于，在步骤4中，在向所述接入方推送所述支付结果时，判断所述接入方是否响应所述推送并成功接收到所述支付结果，如果所述接入方未能响应所述推送、或未能成功接收到所述支付结果，则重复所述推送，在所述推送重复了预定推送次数而所述接入方未能响应所述推送、或未能成功接收到所述支付结果的情况下，提示需要人工介入，并结束本方法。
  9. 一种用于实时回调订单的系统，所述系统用于执行实时回调订单的方法的各个步骤，所述系统包括：
    订单查询请求发送模块，用于针对用户与商户进行交易后产生的订单，向第三方支付通道发送订单查询请求，其中，在所述响应失败次数小于第一阈值的情况下，重复向第三方支付通道发送订单查询请求；
    订单查询结果输出模块，用于在所述响应失败次数达到第一阈值的情况下，向接入方输出“查询无响应”，在所述接收失败次数达到第二阈值的情况下，向接入方输出“接收支付结果失败”，在正常接收到支付结果之后，向接入方推送所述支付结果；
    订单回调模块，用于根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调；
    定时模块，用于根据所述响应失败次数和所述接收失败次数而设定系统需要等待的时间。
  10. 根据权利要求9所述的实时回调订单的系统，其特征在于，所述系统还包括：预警模块，用于向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入。
  11. 根据权利要求9所述的实时回调订单的系统，其特征在于，所述接入方是指与执行所述方法的系统对接、并通过所述系统接收第三方支付通道的支付结果的商户系统，
    其中，在用户通过商户系统发生交易、并通过第三方支付通道进行了支付后，生成所述订单；
    所述订单查询请求中包括业务类型参数和场景参数，其分别用于标识所述订单查询请求的业务类型和交易场景。
  12. 根据权利要求9所述的实时回调订单的系统，其特征在于，所述订单查询结果输出模块在向接入方输出“查询无响应”或者“接收支付结果失败”的同时，向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入。
  13. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有用于执行一种实时回调订单的方法的程序，所述程序被处理器执行时，执行以下步骤的操作：
    步骤1、针对用户通过接入方进行交易后产生的订单，向第三方支付通道发送订单查询请求；
    步骤2、判断第三方支付通道是否对所述订单查询请求作出响应，若是，则转到步骤3；否则使响应失败次数递增，并判断所述响应失败次数是否小于第一阈值，若是，则返回到步骤1；否则，向接入方输出“查询无响应”，并结束本方法；
    步骤3、从第三方支付通道接收关于所述订单的支付结果，如果正常接收到所述支付结果，则转到步骤4，否则转到步骤5；
    步骤4、根据所述订单查询请求，查询交易路由回调配置表，获取订单回调地址，根据所述订单回调地址进行回调，并由此向接入方推送所述支付结果，并结束本方法；
    步骤5、使接收失败次数递增，并判断所述接收失败次数是否小于第二阈值，若是，则返回到步骤1；否则，向接入方输出“接收支付结果失败”，并结束本方法。
  14. 根据权利要求13所述的计算机可读存储介质，其特征在于，所述接入方是指与执行所述方法的系统对接、并通过所述系统接收第三方支付通道的支付结果的商户系统，
    其中，在用户通过商户系统发生交易、并通过第三方支付通道进行了支付后，生成所述订单。
  15. 根据权利要求13所述的计算机可读存储介质，其特征在于，所述订单查询请求中包括业务类型参数和场景参数，其分别用于标识所述订单查询请求的业务类型和交易场景。
  16. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤4中，通过获取所述订单查询请求中的业务类型参数和场景参数，查询交易路由回调配置表
    其中，在所述交易路由回调配置表中记录有与各个业务类型和各个交易场景相对应的订单回调地址。
  17. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤2中，在向接入方输出“查询无响应”的同时，向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入，
    并且，在步骤5中，在向接入方输出“接收支付结果失败”的同时，向接入方的管理平台发送预警邮件和/或消息，以提示需要人工介入。
  18. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤2中，如果所述响应失败次数小于第一阈值，则在第一预设时间间隔后，返回到步骤1，其中，所述第一预设时间间隔随着所述响应失败次数的递增而递增。
  19. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤5中，如果所述接收失败次数小于第二阈值，则在第二预设时间间隔后，返回到步骤1，其中，所述第二预设时间间隔随着所述接收失败次数的递增而递增。
  20. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤4中，在向所述接入方推送所述支付结果时，判断所述接入方是否响应所述推送并成功接收到所述支付结果，如果所述接入方未能响应所述推送、或未能成功接收到所述支付结果，则重复所述推送，在所述推送重复了预定推送次数而所述接入方未能响应所述推送、或未能成功接收到所述支付结果的情况下，提示需要人工介入，并结束本方法。
  21. 一种订单流程处理方法，其特征在于包括以下步骤：
    步骤1、从客户端接收订单处理请求，根据所述订单处理请求获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
    步骤2、判断对所述进程队列中的当前进程是否需要进行异步处理；
    步骤3、如果对所述当前进程需要进行异步处理，则通知客户端将以异步方式推送订单处理结果，将所述当前进程放入异步队列，并在异步处理结束后向客户端推送处理结果；
    步骤4、如果对所述当前进程无需执行异步处理，则对所述当前进程执行同步处理，获得所述当前进程的处理状态；
    步骤5、如果所述当前进程的处理状态为“处理异常”，则记录所述当前进程的处理信息，所述处理信息包括用于再次执行所述当前进程所需的信息；
    步骤6、如果所述当前进程的处理状态为“处理成功”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2，否则，输出订单处理结果。
  22. 根据权利要求1所述的订单流程处理方法，其特征在于，所述订单的进程队列是根据与所述订单相关的场景路由参数确定的，
    其中，所述场景路由参数包括商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台以及支付规则，其中，不同的参数组合对应不同的订单处理场景。
  23. 根据权利要求1所述的订单流程处理方法，其特征在于，在步骤2中，根据所述当前进程的进程参数，判断对所述进程队列中的当前进程是否需要进行异步处理，
    其中，所述当前进程的进程参数包括执行当前进程所涉及的业务类型、是否请求异步处理的标识、所述当前进程对应的业务处理耗时的参考值。
  24. 根据权利要求3所述的订单流程处理方法，其特征在于，在步骤2中，根据所述当前进程的进程参数、以及所述当前进程的历史处理信息，来判断所述当前进程是否需要进行异步处理。
  25. 根据权利要求4所述的订单流程处理方法，其特征在于还包括：
    步骤7、如果所述当前进程的处理状态为“处理失败”，则记录所述当前进程的处理信息，不再处理所述进程队列中的其余进程，
    其中，步骤5还包括：
    步骤5-1、如果所述当前进程的处理状态为“处理异常”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2。
  26. 根据权利要求5所述的订单流程处理方法，其特征在于还包括：
    步骤8、再次从客户端接收订单执行请求，重复执行之前未执行成功的各个进程。
  27. 根据权利要求6所述的订单流程处理方法，其特征在于，步骤8包括：
    步骤8-1、如果所述进程队列中的某个进程的同步处理的重复执行次数超过了预定阈值，则将该进程的是否请求异步处理的标识置为“请求异步处理”。
  28. 根据权利要求1所述的订单流程处理方法，其特征在于，步骤3还包括：
    步骤3-1、通过广播方式启动异步队列中的进程，并且，在所述异步队列中的进程执行异常或者超时的情况下，按照预定重复周期和重复次数，重复执行所述异步队列中的进程。
  29. 一种用于执行订单流程处理方法的订单流程处理系统，其特征在于，包括订单受理组件、进程处理组件、订单反馈组件、进程异步判断组件、进程记录部件，
    其中，所述订单受理组件用于从客户端接收订单处理请求，从所述订单处理请求中获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
    其中，订单反馈组件用于将订单处理结果反馈给客户端，
    其中，所述进程异步判断组件用于对所述进程队列中的当前进程进行异步判断，
    其中，所述进程处理组件用于：在需要对当前进程进行异步处理时，将所述当前进程放入异步队列；
    其中，所述进程记录部件用于记录各个订单的进程处理状态、历史处理记录，包括处理次数、每次的处理方式、处理状态。
  30. 根据权利要求9所述的订单流程处理系统，其特征在于，所述进程处理组件还用于：在对当前进程进行同步处理时，执行相应处理，生成当前进程的处理结果，并通过所述订单反馈组件向客户端反馈处理结果；
  31. 根据权利要求9所述的订单流程处理系统，其特征在于，所述进程处理组件还用于：依次执行所述进程队列中的全部进程，并将进程处理中生成的相关信息发送到所述进程记录部件。
  32. 根据权利要求9所述的订单流程处理系统，其特征在于，所述订单的进程队列是根据与所述订单相关的场景路由参数确定的，
    其中，所述场景路由参数包括商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台以及支付规则，其中，不同的参数组合对应不同的订单处理场景。
  33. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有用于执行订单流程处理方法的程序，所述程序被处理器执行时，执 行以下步骤的操作：
    步骤1、从客户端接收订单处理请求，根据所述订单处理请求获取所述订单的进程队列，所述进程队列中包含处理所述订单所需的全部进程；
    步骤2、判断对所述进程队列中的当前进程是否需要进行异步处理；
    步骤3、如果对所述当前进程需要进行异步处理，则通知客户端将以异步方式推送订单处理结果，将所述当前进程放入异步队列，并在异步处理结束后向客户端推送处理结果；
    步骤4、如果对所述当前进程无需执行异步处理，则对所述当前进程执行同步处理，获得所述当前进程的处理状态；
    步骤5、如果所述当前进程的处理状态为“处理异常”，则记录所述当前进程的处理信息，所述处理信息包括用于再次执行所述当前进程所需的信息；
    步骤6、如果所述当前进程的处理状态为“处理成功”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2，否则，输出订单处理结果。
  34. 根据权利要求13所述的计算机可读存储介质，其特征在于，所述订单的进程队列是根据与所述订单相关的场景路由参数确定的，
    其中，所述场景路由参数包括商品提供方、商品编码、一级渠道、二级渠道、交易类型、支付方式、订单管理平台以及支付规则，其中，不同的参数组合对应不同的订单处理场景。
  35. 根据权利要求13所述的计算机可读存储介质，其特征在于，在步骤2中，根据所述当前进程的进程参数，判断对所述进程队列中的当前进程是否需要进行异步处理，
    其中，所述当前进程的进程参数包括执行当前进程所涉及的业务类型、是否请求异步处理的标识、所述当前进程对应的业务处理耗时的参考值。
  36. 根据权利要求15所述的计算机可读存储介质，其特征在于，在步骤2中，根据所述当前进程的进程参数、以及所述当前进程的历史处理信息，来判断所述当前进程是否需要进行异步处理。
  37. 根据权利要求16所述的计算机可读存储介质，其特征在于还包括：
    步骤7、如果所述当前进程的处理状态为“处理失败”，则记录所述当前进程的处理信息，不再处理所述进程队列中的其余进程，
    其中，步骤5还包括：
    步骤5-1、如果所述当前进程的处理状态为“处理异常”，则判断所述当前进程是否为所述进程队列中的最后一个进程，如果所述当前进程不是所述进程队列中的最后一个进程，则将所述进程队列中的下一个进程作为当前进程，返回到步骤2。
  38. 根据权利要求17所述的计算机可读存储介质，其特征在于还包括：
    步骤8、再次从客户端接收订单执行请求，重复执行之前未执行成功的各个进程。
  39. 根据权利要求18所述的计算机可读存储介质，其特征在于，步骤8包括：
    步骤8-1、如果所述进程队列中的某个进程的同步处理的重复执行次数超过了预定阈值，则将该进程的是否请求异步处理的标识置为“请求异步处理”。
  40. 根据权利要求13所述的计算机可读存储介质，其特征在于，步骤3还包括：
    步骤3-1、通过广播方式启动异步队列中的进程，并且，在所述异步队列中的进程执行异常或者超时的情况下，按照预定重复周期和重复次数，重复执行所述异步队列中的进程。
PCT/CN2018/096479 2018-04-10 2018-08-08 实时回调订单的方法和系统 WO2019196244A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810316255.7 2018-04-10
CN201810316255.7A CN108520454B (zh) 2018-04-10 2018-04-10 实时回调订单的方法和系统

Publications (1)

Publication Number Publication Date
WO2019196244A1 true WO2019196244A1 (zh) 2019-10-17

Family

ID=63432339

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/096479 WO2019196244A1 (zh) 2018-04-10 2018-08-08 实时回调订单的方法和系统

Country Status (2)

Country Link
CN (1) CN108520454B (zh)
WO (1) WO2019196244A1 (zh)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111049938A (zh) * 2020-01-08 2020-04-21 贵阳货车帮科技有限公司 消息通知方法、装置、电子设备及可读存储介质
CN111091358A (zh) * 2019-12-16 2020-05-01 中国建设银行股份有限公司 多支付渠道的统一处理方法及系统
CN111311377A (zh) * 2020-03-20 2020-06-19 时时同云科技(成都)有限责任公司 订单处理方法、装置及系统
CN111325599A (zh) * 2020-01-22 2020-06-23 腾讯科技（深圳）有限公司 订单数据处理方法、装置、设备及存储介质
CN111488236A (zh) * 2020-04-16 2020-08-04 北京思特奇信息技术股份有限公司 一种订单异常处理方法、服务器、存储介质及处理装置
CN111581078A (zh) * 2020-04-09 2020-08-25 苏宁云计算有限公司 一种业务异常定位方法、装置、计算机设备及存储介质
CN112200622A (zh) * 2020-09-14 2021-01-08 深圳市华拓谷科技有限公司 一种跨境电商订单自动效验和自动审核的方法
CN112465599A (zh) * 2020-12-04 2021-03-09 车智互联（北京）科技有限公司 订单处理方法、订单处理系统及计算设备
CN112508380A (zh) * 2020-12-03 2021-03-16 浪潮云信息技术股份公司 一种应用于高并发评价数据异步处理的系统及方法
CN112613955A (zh) * 2020-12-31 2021-04-06 苏州天聚人合科技有限公司 订单处理方法、装置、电子设备及存储介质
CN112633965A (zh) * 2020-12-11 2021-04-09 汉海信息技术(上海)有限公司 订单处理方法、装置、电子设备及存储介质
CN112837122A (zh) * 2021-02-05 2021-05-25 河南印爱文化艺术有限公司 一种影像批量生产系统及方法
CN112966876A (zh) * 2021-03-19 2021-06-15 北京京东振世信息技术有限公司 订单的生产调度方法、装置、电子设备及可读介质
CN113034165A (zh) * 2019-12-09 2021-06-25 腾讯科技（深圳）有限公司 数据处理方法和装置、存储介质及电子装置
CN113256276A (zh) * 2021-06-07 2021-08-13 深圳华南城网科技有限公司 一种基于订单回调的支付状态维护方法及系统
CN113268334A (zh) * 2021-06-24 2021-08-17 中国平安人寿保险股份有限公司 Rpa机器人的调度方法、装置、设备以及存储介质
CN113518097A (zh) * 2020-04-09 2021-10-19 北京意锐新创科技有限公司 交易数据推送方法和装置
CN113643036A (zh) * 2021-07-01 2021-11-12 深圳市晨北科技有限公司 支付验证方法、计算机设备及可读存储介质
CN113742078A (zh) * 2021-09-08 2021-12-03 上海哔哩哔哩科技有限公司 资源处理方法及装置
CN113779138A (zh) * 2021-02-04 2021-12-10 北京京东振世信息技术有限公司 一种订单管理方法和装置
CN113793139A (zh) * 2021-01-29 2021-12-14 北京京东拓先科技有限公司 支付异常的处理方法、处理装置、存储介质及电子设备
CN114385267A (zh) * 2022-01-13 2022-04-22 平安壹钱包电子商务有限公司 一种用于出款交易业务的数据推送方法
CN116384993A (zh) * 2023-06-05 2023-07-04 山东师创云服务有限公司 基于云支付中心实现订单支付状态高一致性的方法与系统
CN117271108A (zh) * 2023-03-21 2023-12-22 广东南粤分享汇控股有限公司 应用于电商平台的大数据处理方法、系统、介质及计算机

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109559102A (zh) * 2018-12-18 2019-04-02 厦门商集网络科技有限责任公司 一种聚合支付方法及终端
CN109785069A (zh) * 2019-01-22 2019-05-21 北京顺丰同城科技有限公司 一种订单轮询方法及装置
CN109961279A (zh) * 2019-03-18 2019-07-02 厦门市易联众易惠科技有限公司 一种基于多策略的his支付状态获取方法及设备
CN109961273A (zh) * 2019-03-20 2019-07-02 广州精选速购网络科技有限公司 支付回调处理方法、系统及存储介质
CN110633977A (zh) * 2019-08-02 2019-12-31 深圳市融壹买信息科技有限公司 支付异常处理方法、装置及终端设备
CN112819479A (zh) * 2019-11-15 2021-05-18 上海际链网络科技有限公司 订单状态的处理方法及装置、存储介质、服务器
CN111861626A (zh) * 2020-01-16 2020-10-30 北京嘀嘀无限科技发展有限公司 一种充电处理方法及装置
CN111429128A (zh) * 2020-03-19 2020-07-17 携程计算机技术（上海）有限公司 移动终端跨平台支付方法、系统、设备及存储介质
CN111598563B (zh) * 2020-05-19 2023-12-05 北京思特奇信息技术股份有限公司 一种实时与异步支付相结合的移动业务受理方法及系统
CN112101937A (zh) * 2020-09-01 2020-12-18 武汉华盛美业科技有限公司 一种订单安全支付方法及其系统
CN113762677B (zh) * 2020-10-29 2023-11-03 北京京东振世信息技术有限公司 一种业务处理方法和装置
CN112712370A (zh) * 2020-12-17 2021-04-27 宝付网络科技（上海）有限公司 一种支付接口挪用监测方法及系统
CN113095809A (zh) * 2021-03-31 2021-07-09 聚好看科技股份有限公司 一种智能眼镜、服务器及支付方法
CN113312538B (zh) * 2021-07-30 2022-02-25 深圳市工易付电子科技有限公司 交易查询方法、装置、设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102999862A (zh) * 2012-11-29 2013-03-27 北京掌上汇通科技发展有限公司 一种订单处理方法、装置及系统、支付装置
US20140298486A1 (en) * 2013-03-26 2014-10-02 Pottermore Limited Granting access to digital content obtained from a third-party service
CN107392722A (zh) * 2017-07-27 2017-11-24 福建中金在线信息科技有限公司 订单处理方法、装置、电子设备及存储介质
CN107480981A (zh) * 2017-07-21 2017-12-15 深圳市金立通信设备有限公司 一种发送通知信息的方法及服务器

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110178915A1 (en) * 2010-01-15 2011-07-21 Lime Brokerage Holding Llc Trading Order Validation System and Method and High-Performance Trading Data Interface
US20120036045A1 (en) * 2010-08-09 2012-02-09 William Patrick Lowe Methods and Systems for Reserving and Completing Purchases
KR101447282B1 (ko) * 2012-08-20 2014-10-16 주식회사 네오위즈인터넷 모바일 결제 서비스를 제공하는 방법, 모바일 단말기, 기록매체 및 시스템

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102999862A (zh) * 2012-11-29 2013-03-27 北京掌上汇通科技发展有限公司 一种订单处理方法、装置及系统、支付装置
US20140298486A1 (en) * 2013-03-26 2014-10-02 Pottermore Limited Granting access to digital content obtained from a third-party service
CN107480981A (zh) * 2017-07-21 2017-12-15 深圳市金立通信设备有限公司 一种发送通知信息的方法及服务器
CN107392722A (zh) * 2017-07-27 2017-11-24 福建中金在线信息科技有限公司 订单处理方法、装置、电子设备及存储介质

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113034165A (zh) * 2019-12-09 2021-06-25 腾讯科技（深圳）有限公司 数据处理方法和装置、存储介质及电子装置
CN113034165B (zh) * 2019-12-09 2023-10-31 腾讯科技（深圳）有限公司 数据处理方法和装置、存储介质及电子装置
CN111091358A (zh) * 2019-12-16 2020-05-01 中国建设银行股份有限公司 多支付渠道的统一处理方法及系统
CN111091358B (zh) * 2019-12-16 2024-04-16 中国建设银行股份有限公司 多支付渠道的统一处理方法及系统
CN111049938A (zh) * 2020-01-08 2020-04-21 贵阳货车帮科技有限公司 消息通知方法、装置、电子设备及可读存储介质
CN111049938B (zh) * 2020-01-08 2022-10-18 贵阳货车帮科技有限公司 消息通知方法、装置、电子设备及可读存储介质
CN111325599A (zh) * 2020-01-22 2020-06-23 腾讯科技（深圳）有限公司 订单数据处理方法、装置、设备及存储介质
CN111311377A (zh) * 2020-03-20 2020-06-19 时时同云科技(成都)有限责任公司 订单处理方法、装置及系统
CN111581078B (zh) * 2020-04-09 2023-05-16 苏宁云计算有限公司 一种业务异常定位方法、装置、计算机设备及存储介质
CN113518097A (zh) * 2020-04-09 2021-10-19 北京意锐新创科技有限公司 交易数据推送方法和装置
CN111581078A (zh) * 2020-04-09 2020-08-25 苏宁云计算有限公司 一种业务异常定位方法、装置、计算机设备及存储介质
CN111488236A (zh) * 2020-04-16 2020-08-04 北京思特奇信息技术股份有限公司 一种订单异常处理方法、服务器、存储介质及处理装置
CN111488236B (zh) * 2020-04-16 2023-09-05 北京思特奇信息技术股份有限公司 一种订单异常处理方法、服务器、存储介质及处理装置
CN112200622A (zh) * 2020-09-14 2021-01-08 深圳市华拓谷科技有限公司 一种跨境电商订单自动效验和自动审核的方法
CN112508380A (zh) * 2020-12-03 2021-03-16 浪潮云信息技术股份公司 一种应用于高并发评价数据异步处理的系统及方法
CN112465599B (zh) * 2020-12-04 2023-11-07 车智互联（北京）科技有限公司 订单处理方法、订单处理系统及计算设备
CN112465599A (zh) * 2020-12-04 2021-03-09 车智互联（北京）科技有限公司 订单处理方法、订单处理系统及计算设备
CN112633965A (zh) * 2020-12-11 2021-04-09 汉海信息技术(上海)有限公司 订单处理方法、装置、电子设备及存储介质
CN112613955A (zh) * 2020-12-31 2021-04-06 苏州天聚人合科技有限公司 订单处理方法、装置、电子设备及存储介质
CN113793139A (zh) * 2021-01-29 2021-12-14 北京京东拓先科技有限公司 支付异常的处理方法、处理装置、存储介质及电子设备
CN113779138A (zh) * 2021-02-04 2021-12-10 北京京东振世信息技术有限公司 一种订单管理方法和装置
CN112837122A (zh) * 2021-02-05 2021-05-25 河南印爱文化艺术有限公司 一种影像批量生产系统及方法
CN112966876A (zh) * 2021-03-19 2021-06-15 北京京东振世信息技术有限公司 订单的生产调度方法、装置、电子设备及可读介质
CN112966876B (zh) * 2021-03-19 2024-04-12 北京京东振世信息技术有限公司 订单的生产调度方法、装置、电子设备及可读介质
CN113256276A (zh) * 2021-06-07 2021-08-13 深圳华南城网科技有限公司 一种基于订单回调的支付状态维护方法及系统
CN113268334A (zh) * 2021-06-24 2021-08-17 中国平安人寿保险股份有限公司 Rpa机器人的调度方法、装置、设备以及存储介质
CN113268334B (zh) * 2021-06-24 2022-10-14 中国平安人寿保险股份有限公司 Rpa机器人的调度方法、装置、设备以及存储介质
CN113643036A (zh) * 2021-07-01 2021-11-12 深圳市晨北科技有限公司 支付验证方法、计算机设备及可读存储介质
CN113742078A (zh) * 2021-09-08 2021-12-03 上海哔哩哔哩科技有限公司 资源处理方法及装置
CN114385267A (zh) * 2022-01-13 2022-04-22 平安壹钱包电子商务有限公司 一种用于出款交易业务的数据推送方法
CN117271108A (zh) * 2023-03-21 2023-12-22 广东南粤分享汇控股有限公司 应用于电商平台的大数据处理方法、系统、介质及计算机
CN116384993B (zh) * 2023-06-05 2023-08-22 山东师创云服务有限公司 基于云支付中心实现订单支付状态高一致性的方法与系统
CN116384993A (zh) * 2023-06-05 2023-07-04 山东师创云服务有限公司 基于云支付中心实现订单支付状态高一致性的方法与系统

Also Published As

Publication number Publication date
CN108520454A (zh) 2018-09-11
CN108520454B (zh) 2023-04-18

Similar Documents

Publication Publication Date Title
WO2019196244A1 (zh) 实时回调订单的方法和系统
WO2019227606A1 (zh) 订单流程处理方法和系统
WO2018019139A1 (zh) 信息推送方法和装置
US8688540B1 (en) System and method for fulfillment services coordination
JP2019530908A (ja) インターネットクラウドでホストされる自然言語による対話型メッセージングシステムサーバ連携
US8612348B1 (en) Systems and methods for interfacing merchants with third-party service providers
JP2019530033A (ja) インターネットクラウドでホストされる自然言語による対話型メッセージングシステムセッション化部
US9021064B2 (en) Web service architecture for product configuration
US11226979B2 (en) Data system with asynchronous batch processing
CN108765083B (zh) 路由化订单配置及处理方法、以及系统
US20120278513A1 (en) Priority scheduling for multi-channel context aware communication technology
CN112288577B (zh) 分布式服务的交易处理方法、装置、电子设备和介质
CN111861745B (zh) 一种业务风控方法和装置
CN110599277A (zh) 一种库存扣减方法和装置
WO2011150601A1 (zh) 交易处理系统
US20220270159A1 (en) Systems and methods for processing electronic requests
CN113793139A (zh) 支付异常的处理方法、处理装置、存储介质及电子设备
US8140406B2 (en) Personal data submission with options to purchase or hold item at user selected price
US20220180284A1 (en) Systems and methods for integrating ordered services
CN108122124B (zh) 信息推送方法、平台及系统
US10521841B2 (en) Method and apparatus for integrating an e-commerce provider with third-party vendors
EP1671229B1 (en) Automatic registration and deregistration of message queues
US20160094690A1 (en) Packet transport protocol processing
WO2018076701A1 (zh) 一种结算方法、服务器和终端
CN113762677B (zh) 一种业务处理方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18914008

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 21/01/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18914008

Country of ref document: EP

Kind code of ref document: A1