WO2020181936A1 - 支付防抖方法及装置 - Google Patents

支付防抖方法及装置 Download PDF

Info

Publication number
WO2020181936A1
WO2020181936A1 PCT/CN2020/073839 CN2020073839W WO2020181936A1 WO 2020181936 A1 WO2020181936 A1 WO 2020181936A1 CN 2020073839 W CN2020073839 W CN 2020073839W WO 2020181936 A1 WO2020181936 A1 WO 2020181936A1
Authority
WO
WIPO (PCT)
Prior art keywords
shake
payment
service request
current
abnormal
Prior art date
Application number
PCT/CN2020/073839
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 WO2020181936A1 publication Critical patent/WO2020181936A1/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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment 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/42—Confirmation, e.g. check or permission by the legal debtor of payment

Definitions

  • the present disclosure generally relates to the field of network application technology, and more specifically, to a method and device for anti-shake payment.
  • the delay in the network refers to the delay time from transmission to reception of information, which is generally composed of transmission delay and processing delay, and jitter refers to the time difference between the maximum delay and the minimum delay.
  • the maximum delay is 20 milliseconds and the minimum delay is 5 milliseconds.
  • the network jitter is 15 milliseconds, which mainly identifies the stability of a network.
  • Mobile payment refers to the use of mobile phones or other smart devices to complete or confirm payment, rather than cash, cheque or bank card payment.
  • Bottom line refers to the relief measures taken when the payment system fails.
  • the present disclosure provides a method and device for anti-shake payment.
  • the normal result of the simulation is returned from the service request from the time when the system is found to be jittered to the last service request. It has the multi-stage anti-shake capability of the payment link and reduces the impact of system jitter on the business. Impact and business loss.
  • a method for anti-shake payment including: intercepting a current business request sent by a client to a server during a payment process, the current business request at least including a unique stage identifier, wherein the payment process It includes multiple payment stages, and the unique stage identifier is used to uniquely identify the payment stage corresponding to the current service request; based on the anti-shake flag corresponding to the current service request, determine the remote service for the current service request Whether the call is abnormal; when the remote service call for the current service request is determined to be abnormal, generating a bottom processing result, the bottom processing result including at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier; And sending the bottom processing result to the client.
  • determining whether the remote service call for the current service request is abnormal includes: when the flag value of the anti-shake flag indicates the remote service When the call is abnormal, determine the remote service call abnormal for the current service request.
  • determining whether the remote service call for the current service request is abnormal includes: indicating the flag value of the anti-shake flag When the remote service call is normal, execute the remote service call according to the current service request; and determine whether the remote service call for the current service request is abnormal based on whether the returned result of the remote service call is abnormal.
  • the payment anti-shake method further includes: when the return result of the remote service call is abnormal, assigning the anti-shake flag with a flag value indicating the abnormality of the remote service call And included in the bottom of the bag processing results.
  • assigning the anti-shake flag with a flag value indicating that the remote service call is abnormal includes: When the requested remote service call is abnormal, identify whether the remote service call abnormality is an abnormality that can be handled under the hood; and when it is recognized that the remote service call exception is an abnormality that can be handled under the hood, give the anti-shake mark The tag value used to indicate the abnormality of the remote service call is included in the bottom processing result.
  • the anti-shake flag is created after intercepting the current service request, or when the current service request is wrong At the first service request, the anti-shake mark is the anti-shake mark returned in the previous service request processing process.
  • an anti-shake mark is created for the current service request through the following process: after intercepting the current service request, Analyze the intercepted current service request to determine the service type to which the current service request belongs; when the determined service type belongs to a service type that requires anti-shake processing, create the anti-shake flag for the current service request.
  • the service type requiring anti-shake processing includes an offline payment code payment service.
  • the method further includes: after sending the bottom-up processing result to the client, According to the payment information corresponding to the payment process, a corresponding amount of payment is paid from the advance account to the seller.
  • the payment anti-shake method further includes: in response to paying a corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has arrived.
  • a payment anti-shake device including: an interception unit configured to intercept a current business request sent by a client to a server during a payment process, the current business request at least including a unique stage identifier, Wherein, the payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the payment stage corresponding to the current service request; the abnormality determination unit is configured to be based on the protection corresponding to the current service request.
  • the jitter flag determines whether the remote service call for the current service request is abnormal; the bottom processing unit is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal, and the bottom processing
  • the result includes at least a simulated normal result corresponding to the payment stage identified by the unique stage identifier; and a sending unit configured to send the bottom-up processing result to the client.
  • the abnormality determination unit is further configured to determine that the remote service invocation for the current service request is abnormal when the flag value of the anti-shake flag indicates that the remote service invocation is abnormal.
  • the payment anti-shake device further includes: a service invocation unit configured to, when the flag value of the anti-shake flag indicates that the remote service invocation is normal, according to the current service request The remote service call is executed, wherein the abnormality determining unit is further configured to determine whether the remote service call for the current service request is abnormal based on whether the return result of the remote service call is abnormal.
  • the payment anti-shake device further includes: a mark value adjustment unit configured to give the anti-shake mark to the anti-shake mark when the return result of the remote service call is abnormal The flag value indicating the abnormality of the remote service call is included in the bottom processing result.
  • the payment anti-shake device further includes: an abnormality recognition unit configured to recognize whether the abnormality of the remote service call is abnormal when the return result of the remote service call is abnormal Performing an abnormality in the bottom-up processing, wherein the mark value adjustment unit is further configured to, when it is recognized that the remote service invocation abnormality is an abnormality that can be handled in the bottom-out processing, assign the anti-shake flag to indicate the remote service invocation abnormality The tag value of is included in the bottom processing result.
  • an abnormality recognition unit configured to recognize whether the abnormality of the remote service call is abnormal when the return result of the remote service call is abnormal Performing an abnormality in the bottom-up processing
  • the mark value adjustment unit is further configured to, when it is recognized that the remote service invocation abnormality is an abnormality that can be handled in the bottom-out processing, assign the anti-shake flag to indicate the remote service invocation abnormality
  • the tag value of is included in the bottom processing result.
  • the payment anti-shake device further includes: an anti-shake mark creation unit configured to intercept the current service request when the current service request is the first service request Then, the anti-shake flag is created for the current service request.
  • the payment anti-shake device further includes: a service type determining unit configured to, when the current service request is the first service request, after intercepting the current service request Analyze the intercepted current service request to determine the service type to which the current service request belongs, wherein the anti-shake mark creation unit is further configured to, when the determined service type belongs to a service type that requires anti-shake processing, Create the anti-shake flag for the current service request.
  • a service type determining unit configured to, when the current service request is the first service request, after intercepting the current service request Analyze the intercepted current service request to determine the service type to which the current service request belongs
  • the anti-shake mark creation unit is further configured to, when the determined service type belongs to a service type that requires anti-shake processing, Create the anti-shake flag for the current service request.
  • a computing device including: one or more processors, and a memory coupled with the one or more processors, the memory storing instructions, when the instructions are When one or more processors are executed, the one or more processors are caused to execute the above-mentioned payment anti-shake method.
  • a non-transitory machine-readable storage medium that stores executable instructions that, when executed, cause the machine to execute the above-mentioned payment anti-shake method.
  • a high-availability architecture level guarantee is provided for future core business scenarios to reach an availability target of 99.999% or even higher, and guarantees financial level Stability, reduce the public impact caused by system failures, and reduce merchants' collection losses.
  • the impact of system jitter and failure on core services and business losses from the general high-availability architecture level are reduced, the success rate of the overall business link is improved, and the user experience is improved.
  • the business link is re-examined from the point of view of the terminal, and the daily business link can be optimized through decoupling, heterogeneous, asynchronous and other ideas, and even some business scenarios can be upgraded to normal and overall asynchronous. ability.
  • Figure 1 is an example of each payment stage included in the offline payment code payment service
  • FIG. 2 shows a flow chart of the method for anti-shake payment provided in Embodiment 1 of the present disclosure
  • FIG. 3 is an example in which the current service request shown in FIG. 2 is the first service request in the payment process
  • FIG. 4 is an example of a non-first service request in which the current service request shown in FIG. 2 is a payment process
  • Figure 5 is a schematic diagram of a simulated normal result returned from the client during the intermediate stage of payment as provided by an example
  • Fig. 6 is a schematic diagram of the simulated normal result returned at the end of the payment example shown in Fig. 5;
  • FIG. 7 is a flowchart of the entire payment process of the payment anti-shake method provided by Embodiment 2 of the disclosure.
  • FIG. 8 is a schematic structural diagram of a payment anti-shake device 800 provided by an embodiment of the disclosure.
  • FIG. 9 is a schematic structural diagram of a payment anti-shake device 900 provided by another embodiment of the present disclosure.
  • Fig. 10 is a structural block diagram of a computing device for realizing payment anti-shake provided by an embodiment of the disclosure.
  • the term “including” and its variants means open terms, meaning “including but not limited to.”
  • the term “based on” means “based at least in part on.”
  • the terms “one embodiment” and “an embodiment” mean “at least one embodiment.”
  • the term “another embodiment” means “at least one other embodiment.”
  • the terms “first”, “second”, etc. may refer to different or the same objects. Other definitions can be included below, either explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.
  • the one-time payment process includes one payment stage or multiple payment stages, and the present disclosure mainly focuses on payment services including multiple stages.
  • the client initiates a service request to the next service request as a stage, or the client initiates a service request until the client displays the payment completion as a stage.
  • the client scans the seller’s payment code as the first service request.
  • the client initiates the first service request until the client displays the payment returned by the server.
  • the amount input box is the stage 110 of creating the transaction number; the user enters the amount of money paid into the payment amount input box displayed on the client and confirms the submission as the second business request.
  • the second business request is initiated from the client to the client display service
  • the payment method option and payment password input box returned by the client is the stage 120 when the cashier is pulled up; the user selects the payment method through the client and enters the payment password and confirms the submission is the third service request, and the third service is initiated from the client
  • the request to the client shows that the notification of "paying" returned by the server is the stage 130 of the payment submission; the fourth service request initiated calls polling to query the transaction status of the order. If the transaction is successful, the client receives the "payment Therefore, the fourth stage is the stage 140 of polling the payment result. It can be seen that the offline payment code payment business includes the above four stages.
  • the service link of the distributed system on the server side is long and it is prone to jitter, in order to avoid interruption or errors in the payment process due to jitter, for a certain service request, once the remote call of the server is abnormal, the service request and After that, all business requests were dealt with. Identify the business jitter according to the error code, anomaly, and/or business parameters returned by the remote call, handle the business jitter, return the simulation result, and record the business jitter. The asynchronous recovery process can be triggered according to the bottom line flow, and the payment can be sent to the seller from the advance account.
  • Fig. 2 shows a flow chart of a payment anti-shake method provided in Embodiment 1 of the present disclosure, and the process can be executed by a payment anti-shake device.
  • Embodiment 1 mainly considers the processing of a business request in the payment process.
  • the current business request sent by the client to the server during the payment process is intercepted.
  • the current business request includes at least a unique stage identifier.
  • the payment process includes multiple payment stages and a unique stage identifier. It uniquely identifies the payment stage corresponding to the current business request.
  • AOP is the abbreviation of Aspect Oriented Programming, which means aspect-oriented programming. It is a technology that achieves unified maintenance of program functions through pre-compilation and runtime dynamic agents .
  • AOP can be understood as an interceptor framework, but this interceptor will be very arbitrary. If it intercepts a class, then it will intercept all methods in this class.
  • the remote service call for the current service request is abnormal.
  • the value of the anti-shake flag carried by the non-first service request is abnormal
  • the remote service call for the current service request is abnormal.
  • the anti-shake flag created during the processing of the first service request and the value of the anti-shake flag is empty, and the case where the value of the anti-shake flag carried by the non-first service request is normal
  • the current service request is determined The remote business call is normal.
  • a bottom processing result is generated, and the bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier.
  • the bottom processing result is sent to the client. Therefore, the returned result from the client is the normal result of the simulation.
  • Fig. 3 is an example of a payment anti-shake method when the current service request is the first service request of the payment process.
  • the payment anti-shake device intercepts the first service request sent by the client to the server during the payment process, and the first service request includes at least a unique stage identifier.
  • the intercepted first service request is parsed to determine the service type to which the first service request belongs.
  • an anti-shake flag is created for the first service request, and the anti-shake flag is used to indicate that the current payment service is a service that requires anti-shake processing.
  • the types of services that require anti-shake processing may include offline payment code payment services.
  • the anti-shake flag is, for example, appfuse_type. Because the server is a distributed system, processing business requests requires remote business calls.
  • the mark value of the anti-shake flag is used to indicate whether the remote service call is normal or abnormal, and the abnormality refers to the jitter of the link of the remote service call.
  • the mark value of the anti-shake flag is, for example, normal or shake, where shake represents jitter, and normal represents normal, that is, no jitter occurs.
  • a remote service call is made according to the first service request.
  • the payment anti-shake device can be used as the upstream system to make remote business calls to the downstream system of the server.
  • the payment anti-shake device can also instruct the upstream system of the server to make remote business calls to the downstream system.
  • block 350 based on the call result returned by the remote service call, it is determined whether the remote service call for the first service request is abnormal. If the call result returned by the remote service call is abnormal, it is determined that the remote service call for the first service request is abnormal, and the process proceeds to block 360. If the call result returned by the remote service call is normal, it is determined that the remote service call for the first service request is normal, and the process proceeds to block 380.
  • the anti-shake flag is assigned a flag value indicating the abnormality of the remote service call, such as shake, and a bottom processing result is generated based on the simulated normal result and the anti-shake flag corresponding to the payment stage identified by the unique stage identifier.
  • the normal result of the simulation corresponding to the payment stage identified by the unique stage identifier is stored in the memory of the payment anti-shake device.
  • the payment anti-shake device analyzes the intercepted business request, and finds the corresponding simulation in its memory according to the unique stage identifier analyzed Normal results, resulting in bottom processing results. The flow proceeds to block 370.
  • the bottom processing result is sent to the client. Therefore, the returned result from the client is the normal result of the simulation.
  • the anti-shake flag is assigned a flag value indicating that the remote service call is normal, such as normal, and a normal processing result is generated based on the call result returned by the remote service call and the anti-shake flag. Therefore, the normal processing result includes the information and the anti-shake flag in the call result returned by the remote service call.
  • the flow proceeds to block 390.
  • the normal processing result is sent to the client.
  • Fig. 4 is an example of a payment anti-shake method when the current service request is a non-first service request in the payment process.
  • the payment anti-shake device intercepts the non-first service request sent by the client to the server during the payment process, and the non-first service request includes at least a unique stage identifier and an anti-shake mark.
  • the anti-shake mark is the anti-shake mark returned in the previous service request processing process.
  • block 410 it is determined whether the flag value of the anti-shake flag included in the non-first service request indicates whether the remote service call is abnormal. If the value of the anti-shake flag indicates that the remote service call is abnormal, it is determined that the remote service call for the non-first service request is abnormal, and the flow proceeds to block 420. If the flag value of the anti-shake flag indicates that the remote service call is normal, the flow proceeds to block 440.
  • a bottom processing result is generated.
  • the bottom processing result includes a simulation normal result corresponding to the payment stage identified by the unique stage identifier and an anti-shake flag.
  • the anti-shake flag has a flag value for indicating abnormal remote service calls, such as shake .
  • Fig. 5 is a schematic diagram of a simulated normal result returned from the intermediate stage of payment seen by the client as an example.
  • Fig. 6 is a schematic diagram of the simulated normal result returned in the final stage of the payment example shown in Fig. 5.
  • a remote service call is made according to a non-first service request.
  • the flow proceeds to block 450.
  • block 450 based on whether the call result returned by the remote service call is abnormal, it is determined whether the remote service call for the non-first service request is abnormal. If the call result is abnormal, such as SYSTEM_ERROR, it is determined that the remote service call is abnormal, and the flow proceeds to block 460. If the call result is normal, it is determined that the remote service call is normal, and the flow proceeds to block 480.
  • the call result such as SYSTEM_ERROR
  • the anti-shake flag is assigned a flag value indicating the remote service call abnormality, such as shake, and a bottom processing result is generated based on the simulated normal result and the anti-shake flag corresponding to the payment stage identified by the unique stage identifier.
  • the flow proceeds to block 470.
  • the bottom processing result is sent to the client.
  • a normal processing result is generated.
  • the normal processing result includes the information in the call result returned by the remote service call and an anti-shake flag.
  • the anti-shake flag has a flag value for indicating that the remote service call is normal, such as normal. The flow proceeds to block 490.
  • the normal processing result is sent to the client.
  • the payment anti-shake method of this embodiment may further include Jitter identification step.
  • the jitter identification step may include: identifying whether the remote service invocation abnormality is an abnormality that can be handled under the hood, and when it is identified that the remote service invocation abnormality is an anomaly that can be handled under the circumstance, assigning the anti-shake mark to the anti-shake flag indicating the abnormality of the remote service invocation The value is included in the bottom processing result.
  • the payment anti-shake device can record the payment information in the service request and the multi-stage context state cache.
  • the payment information may include information such as the order amount, payment account, and payment account.
  • the order is generated based on the payment information, and the order may include a serial number.
  • the payment information corresponding to the payment process can also come from the server.
  • the payment information is recorded to facilitate the anti-shake asynchronous recovery after the synchronization process.
  • the state cache of the multi-stage context is the information needed for anti-shake in the multi-stage state.
  • the payment anti-shake method of this embodiment may further include: after sending the bottom processing result to the client, according to the payment process corresponding to the payment process Information, pay the corresponding amount of payment to the seller from the advance account.
  • the process of paying a corresponding amount of payment to the seller from the advance account can be called an asynchronous recovery process, because this process is completed in an asynchronous recovery mode.
  • the payment anti-shake method of this embodiment may further include: in response to paying the corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has been made Arrived.
  • the seller can be notified by voice broadcast, SMS notification, or any other existing methods.
  • the asynchronous recovery process can be triggered in real time, timed, or manually.
  • the link through which the asynchronous recovery process and the foregoing service request processing process pass in the distributed system is likely to be a different link or the same link.
  • the asynchronous recovery process is triggered in real-time, about 1 to 2 seconds after the seller is notified that the payment has been received, a corresponding amount of payment is transferred from the advance account to the seller's account.
  • the payment can be transferred from the advance account to the seller's account after a preset period of time has elapsed from the time the seller is notified that the payment has arrived.
  • FIG. 7 is a flowchart of the entire payment process of the payment anti-shake method provided in Embodiment 2 of the disclosure.
  • Embodiment 2 takes the current payment process including three stages as an example.
  • the payment anti-shake device is a basic functional module that undertakes the anti-shake capability, and the payment anti-shake device may be a component connected to the server, or an independent device between the client and the server.
  • the payment anti-shake device intercepts the first service request sent by the client to the server during the payment process.
  • the first service request includes a unique stage identifier, where the unique stage identifier is used to uniquely identify the current The first payment phase corresponding to the business request.
  • a remote service call is made according to the first service request.
  • the anti-shake flag is assigned a flag value indicating that the remote service call is normal, such as normal, and a normal processing result is generated based on the call result returned by the remote service call and the anti-shake flag.
  • the normal processing result is sent to the client.
  • the payment anti-shake device intercepts the second service request sent by the client to the server during the payment process.
  • the second service request includes a unique stage identifier and an anti-shake mark.
  • the unique stage identifier is used to uniquely identify the current service request
  • the anti-shake flag has a flag value used to indicate that the remote service call is normal, such as normal.
  • a remote service call is made according to the second service request.
  • the anti-shake flag is assigned a tag value indicating the remote service call abnormality, such as shake, based on the simulation corresponding to the second payment stage identified by the unique stage identifier
  • the normal result and the anti-shake mark generate the bottom processing result.
  • the bottom processing result is sent to the client.
  • the payment anti-shake device intercepts the last service request sent by the client to the server during the payment process.
  • the last service request includes a unique stage identifier and an anti-shake mark.
  • the unique stage identifier is used to uniquely identify the last service request corresponding to the current service request.
  • the anti-shake flag has a flag value used to indicate abnormal remote service calls, such as shake.
  • the remote service call abnormality is indicated based on the flag value of the anti-shake flag, and the remote service call abnormality for the last service request is determined.
  • a bottom processing result is generated.
  • the bottom processing result includes a simulation normal result corresponding to the last payment stage identified by the unique stage identifier and an anti-shake flag, the anti-shake flag having a flag value for indicating abnormal remote service invocation, such as shake.
  • the bottom processing result is sent to the client.
  • the client shows that the payment is completed, and the user sees the simulated normal results.
  • the asynchronous recovery process is initiated to achieve the final consistency of the business.
  • a corresponding amount of payment is paid from the advance account to the seller.
  • the payment anti-shake method of this embodiment may further include: in response to paying a corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has arrived.
  • the seller can be notified by voice broadcast, SMS notification, or any other existing methods.
  • Example 2 It can be seen from Example 2 that for the anti-shake processing service, except for the last service request of this payment, for each previous service request, the payment anti-shake device sends the returned result to the client at the same time as the marked value Anti-shake mark to the client. When the client sends the next service request, it will take the anti-shake mark and enter the payment anti-shake device again. If the anti-shake value of the anti-shake mark indicates that the remote service call is abnormal, it will be recognized as the previous payment process. The stage has already been dealt with, and the stage continues to go through the procedure until the user completes the payment.
  • the payment anti-shake device sends the return result to the client, and it can also send the anti-shake mark with the marked value to the client at the same time, but this stage is the last stage of the payment process.
  • the payment anti-shake device sends the anti-shake flag with the flag value indicating the abnormal remote service call to the client while sending the return result. Request, the payment anti-shake device no longer sends the anti-shake mark to the client.
  • the information sent to the client is concise, the client's program needs to be modified.
  • the payment anti-shake method of the present disclosure is not limited to the technical solutions disclosed in the above embodiments.
  • the various embodiments disclosed above for processing a business request in the payment process can be combined, modified, and modified without departing from the essence of the invention. Modifications, in addition, various combinations, modifications, and modifications can also be made to the various embodiments at various stages of the entire payment process without departing from the essence of the invention.
  • the service-end link jitter the impact of the fault on the business and the business loss are reduced, the success rate of the overall business link is improved, and the user experience is improved.
  • FIG. 8 is a schematic structural diagram of a payment anti-shake device 800 provided by an embodiment of the disclosure.
  • the payment anti-shake device can be an independent device or a component connected to the server.
  • the payment anti-shake device 800 of this embodiment may include: an interception unit 810, an abnormality determination unit 820, a pocket processing unit 830, and a sending unit 840.
  • the intercepting unit 810 is configured to intercept the current business request sent by the client to the server during the payment process.
  • the current business request includes at least a unique stage identifier.
  • the payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the current business.
  • the operation of the interception unit 810 may refer to the operation of the block 210 described above with reference to FIG. 2.
  • the abnormality determining unit 820 is configured to determine whether the remote service call for the current service request is abnormal based on the anti-shake flag corresponding to the current service request.
  • the operation of the abnormality determination unit 820 may refer to the operation of the block 220 described above with reference to FIG. 2.
  • the bottom processing unit 830 is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal.
  • the bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier.
  • the operation of the bottom processing unit 830 may refer to the operation of the block 230 described above with reference to FIG. 2.
  • the sending unit 840 is configured to send the bottom processing result to the client.
  • the operation of the sending unit 840 may refer to the operation of the block 240 described above with reference to FIG. 2.
  • FIG. 9 is a schematic structural diagram of a payment anti-shake device 900 provided by another embodiment of the present disclosure.
  • the payment anti-shake device 900 of this embodiment may include: an interception unit 910, an anti-shake mark creation unit 920, an abnormality determination unit 930, a service invocation unit 940, a pocket processing unit 950, a mark value adjustment unit 960, And the sending unit 970.
  • the intercepting unit 910 is configured to intercept the current business request sent by the client to the server during the payment process.
  • the current business request includes at least a unique stage identifier.
  • the payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the current business.
  • the operations of the interception unit 910 may refer to the operations of 700, 725, and 755 described above with reference to FIG. 7.
  • the anti-shake mark creation unit 920 is configured to create an anti-shake mark for the current service request after intercepting the current service request when the current service request is the first service request.
  • the operation of the anti-shake mark creation unit 920 may refer to the operation of 705 described above with reference to FIG. 7.
  • the abnormality determining unit 930 is configured to determine whether the remote service call for the current service request is abnormal based on the anti-shake flag corresponding to the current service request.
  • the abnormality determining unit 930 may also be configured to determine that the remote service call for the current service request is abnormal when the flag value of the anti-shake flag indicates that the remote service call is abnormal.
  • the operation of the abnormality determination unit 930 may refer to the operations of 735 and 760 described above with reference to FIG. 7.
  • the service invocation unit 940 is configured to execute the remote service invocation according to the current service request when the mark value of the anti-shake flag indicates that the remote service invocation is normal.
  • the mark value of the anti-shake flag indicates that the remote service call is normal.
  • the operation of the service invoking unit 940 may refer to the operations of 710 and 730 described above with reference to FIG. 7.
  • the abnormality determining unit 930 may also be configured to determine whether the remote service call for the current service request is abnormal based on whether the return result of the remote service call is abnormal.
  • the operation of the abnormality determination unit 930 may refer to the operation of 735 described above with reference to FIG. 7.
  • the bottom processing unit 950 is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal.
  • the bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier.
  • the operation of the pocket bottom processing unit 950 can refer to the operations of 745 and 765 described above with reference to FIG. 7.
  • the mark value adjustment unit 960 is configured to, when the return result of the remote service call is abnormal, give the anti-shake mark a mark value indicating the abnormality of the remote service call and include it in the bottom processing result.
  • the operation of the flag value adjustment unit 960 may refer to the operation of 745 described above with reference to FIG. 7.
  • the sending unit 970 is configured to send the bottom processing result to the client.
  • the operation of the sending unit 970 may refer to the operations of 750 and 770 described above with reference to FIG. 7.
  • the payment anti-shake device of this embodiment may further include a normal processing unit.
  • the normal processing unit is configured to generate a normal processing result when the remote service call for the current service request is determined to be normal, and the normal processing result includes at least information in the call result returned by the remote service call.
  • the operation of the normal processing unit may refer to the operation of 715 described above with reference to FIG. 7.
  • the mark value adjustment unit 960 may also be configured to, when the return result of the remote service call is normal, determine that the remote service call for the current service request is normal, and assign the anti-shake mark a mark value indicating that the remote service call is normal and include it in the normal Processing results.
  • the operation of the flag value adjustment unit 960 may refer to the operation of 715 described above with reference to FIG. 7.
  • the sending unit 970 can also be configured to send the normal processing result to the client.
  • the operation of the sending unit 970 may refer to the operation of 720 described above with reference to FIG. 7.
  • the payment anti-shake device of this embodiment may further include a service type determining unit.
  • the service type determining unit is configured to, when the current service request is the first service request, after intercepting the current service request, analyze the intercepted current service request to determine the service type to which the current service request belongs.
  • the operation of the service type determining unit may refer to the operation of block 320 described above with reference to FIG. 3.
  • the anti-shake mark creation unit 920 may also be configured to create an anti-shake mark for the current service request when the determined service type belongs to a service type that requires anti-shake processing.
  • the operation of the mark creation unit 920 may refer to the operation of the block 330 described above with reference to FIG. 3.
  • the payment anti-shake device of this embodiment may further include an abnormality recognition unit.
  • the abnormality recognition unit is configured to recognize whether the abnormality of the remote service call is an abnormality that can be dealt with when the return result of the remote service call is abnormal.
  • the operation of the abnormality recognition unit may refer to the operation of 740 described above with reference to FIG. 7.
  • the mark value adjustment unit 960 may also be configured to, when it is recognized that the remote service call abnormality is an abnormality that can be processed, give the anti-shake mark a mark value indicating the remote service call abnormality and include it in the bottom processing result.
  • the operation of the flag value adjustment unit 960 may refer to the operation of 745 described above with reference to FIG. 7.
  • the payment anti-shake device of this embodiment may further include a payment processing unit.
  • a payment processing unit When the current service request is the final service request of the payment process, after sending the bottom processing result to the client, according to the payment information corresponding to the payment process, a corresponding amount of payment is paid from the advance account to the seller.
  • the operation of the payment processing unit may refer to the operations of 780-785 described above with reference to FIG. 7.
  • the payment anti-shake device of the present disclosure is not limited to the technical solutions disclosed in the above embodiments, and the various embodiments disclosed above can be combined, modified, and modified without departing from the essence of the invention.
  • the above payment anti-shake device can be implemented by hardware, or by software or a combination of hardware and software.
  • Fig. 10 is a structural block diagram of a computing device for realizing payment anti-shake provided by an embodiment of the present disclosure.
  • the computing device 1000 may include at least one processor 1010, a memory 1020, a memory 1030, a communication interface 1040, and an internal bus 1050.
  • the at least one processor 1010 executes on a computer-readable storage medium (ie, the memory 1020).
  • At least one computer-readable instruction ie, the above-mentioned element implemented in the form of software stored or encoded in the computer.
  • a computer executable instruction is stored in the memory 1020, which when executed causes at least one processor 1010 to intercept the current business request sent by the client to the server during the payment process, and the current business request includes at least a unique stage Identification, where the payment process includes multiple payment phases, and the unique phase identification is used to uniquely identify the payment phase corresponding to the current service request; based on the anti-shake mark corresponding to the current service request, determine whether the remote service call for the current service request is Abnormal; when the remote service call for the current business request is determined to be abnormal, generate the bottom processing result, which includes at least the simulated normal result corresponding to the payment stage identified by the unique stage identifier; and sends the bottom processing result to the customer end.
  • the computing device 1000 may include, but is not limited to: personal computers, server computers, workstations, desktop computers, laptop computers, notebook computers, mobile computing devices, smart phones, tablet computers, cellular phones, personal digital assistants (PDA), handheld devices, messaging devices, wearable computing devices, consumer electronic devices, etc.
  • PDA personal digital assistants
  • a program product such as a non-transitory machine-readable medium.
  • the non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the various embodiments described above in conjunction with FIGS. 2-9 in the various embodiments of the present disclosure. Operation and function.
  • a system or device equipped with a readable storage medium may be provided, and the software program code for realizing the function of any one of the above embodiments is stored on the readable storage medium, and the computer or device of the system or device The processor reads out and executes the instructions stored in the readable storage medium.
  • the program code itself read from the readable medium can realize the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present invention a part of.
  • Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, Volatile memory card and ROM.
  • the program code can be downloaded from a server computer or cloud via a communication network.
  • the device structure described in the foregoing embodiments may be a physical structure or a logical structure. That is, some units may be realized by the same physical entity, or some units may be realized by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.
  • the hardware unit or module can be implemented mechanically or electrically.
  • a hardware unit, module or processor may include permanent dedicated circuits or logic (such as a dedicated processor, FPGA or ASIC) to complete the corresponding operation.
  • the hardware unit or processor may also include programmable logic or circuits (such as general-purpose processors or other programmable processors), which may be temporarily set by software to complete corresponding operations.
  • the specific implementation mode mechanical method, or dedicated permanent circuit, or temporarily set circuit

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付防抖方法及装置。该方法包括：拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识（210）；基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常（220）；在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果（230）；将兜底处理结果发送给客户端（240）。该装置包括拦截单元、异常确定单元、兜底处理单元和发送单元。利用该方法和装置，保障更高的可用率目标，保障金融级别的稳定，减少商户收款损失，减少系统抖动、故障对业务带来的影响及业务损失，提升整体业务链路的成功率，同时提升用户体验。

Description

支付防抖方法及装置 技术领域
本公开通常涉及网络应用技术领域，更具体地，涉及支付防抖方法及装置。
背景技术
如果网络发生拥塞，排队延迟将影响端到端的延迟，并导致通过同一连接传输的分组延迟各不相同，而抖动，就是用来描述这一延迟变化的程度。网络中的延迟是指信息从发送到接收经过的延迟时间，一般由传输延迟及处理延迟组成，而抖动是指最大延迟与最小延迟的时间差，如最大延迟是20毫秒，最小延迟为5毫秒，那么网络抖动就是15毫秒，它主要标识一个网络的稳定性。
移动支付是指使用手机或其他智能设备完成支付或确认支付，而不是用现金、支票或银行卡支付。兜底是指支付系统出故障时采取的救济措施。
随着移动支付的越来越普及，并发访问量和交易量呈爆发式增长态势，支付安全也是被关注的一个问题。在目前互联网规模以及复杂的企业级分布式架构体系下，当有大量用户访问时网络抖动是不可避免的，因此容易造成事务失败，或者由于事务正在进行中，锁定资源太多，比如锁定数据表记录太多，导致其他事务等待时间较长。比如在进行移动支付过程中如果链路发生抖动，可能造成支付错误，造成支付失败，导致商户收款损失，因此分布式系统需要进一步提高系统稳定性，进一步提高可用率。
发明内容
鉴于上述问题，本公开提供了一种支付防抖方法及装置。利用该方法及装置，对于本次支付从发现系统出现抖动时起的业务请求到最后一次业务请求均返回模拟的正常结果，具有支付链路多阶段防抖能力，减少系统抖动对业务带来的影响以及业务损失。
根据本公开的一个方面，提供了一种支付防抖方法，包括：拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；在针对所述当前业务请求的远程业务调用被确定为异常 时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及将所述兜底处理结果发送给所述客户端。
可选地，在上述方面的一个示例中，基于与所述当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常包括：在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。
可选地，在上述方面的一个示例中，基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常包括：在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用；以及基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。
可选地，在上述方面的一个示例中，所述支付防抖方法还包括：在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
可选地，在上述方面的一个示例中，在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值包括：在确定针对所述当前业务请求的远程业务调用异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常；以及在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
可选地，在上述方面的一个示例中，在所述当前业务请求是首次业务请求时，所述防抖标记是在拦截到所述当前业务请求后创建的，或者在所述当前业务请求是非首次业务请求时，所述防抖标记是上一业务请求处理过程所返回的防抖标记。
可选地，在上述方面的一个示例中，在所述当前业务请求是首次业务请求时，通过下述过程来为所述当前业务请求创建防抖标记：在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型；在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。
可选地，在上述方面的一个示例中，所述需要防抖处理的业务类型包括线下收钱码支付业务。
可选地，在上述方面的一个示例中，在所述当前业务请求是所述支付过程的最后业务请求时，所述方法还包括：在将所述兜底处理结果发送给所述客户端后，根据与所述支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。
可选地，在上述方面的一个示例中，所述支付防抖方法还包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知所述卖家相应数目的支付款已到账。
根据本公开的另一方面，提供一种支付防抖装置，包括：拦截单元，被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；异常确定单元，被配置为基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；兜底处理单元，被配置为在针对所述当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及发送单元，被配置为将所述兜底处理结果发送给所述客户端。
可选地，在上述方面的一个示例中，所述异常确定单元进一步被配置为：在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。
可选地，在上述方面的一个示例中，所述支付防抖装置还包括：业务调用单元，被配置为在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用，其中，所述异常确定单元还被配置为：基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。
可选地，在上述方面的一个示例中，所述支付防抖装置还包括：标记值调整单元，被配置为在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
可选地，在上述方面的一个示例中，所述支付防抖装置还包括：异常识别单元，被配置为在所述远程业务调用的返回结果异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常，其中，所述标记值调整单元还被配置为在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
可选地，在上述方面的一个示例中，所述支付防抖装置还包括：防抖标记创建单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后为所述当前业务请求创建所述防抖标记。
可选地，在上述方面的一个示例中，所述支付防抖装置还包括：业务类型确定单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后，解析 所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型，其中，所述防抖标记创建单元还被配置为在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。
根据本公开的又一方面，提供一种计算设备，包括：一个或多个处理器，以及与所述一个或多个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行如上所述的支付防抖方法。
根据本公开的再一方面，提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的支付防抖方法。
利用本公开的方法和装置，在目前互联网规模以及复杂的企业级分布式架构体系下，为未来核心业务场景达到99.999％甚至更高的可用率目标提供高可用架构层面的保障，保障金融级别的稳定性，降低系统故障造成的公众影响，减少商户收款损失。
利用本公开的方法和装置，从通用高可用架构层面减少系统抖动、故障对核心业务带来的影响以及业务损失，提升整体业务链路的成功率，同时提升用户体验。
利用本公开的方法和装置，从端的视角重新审视业务链路，通过解耦、异构、异步化等思路可以反哺优化日常的业务链路，甚至可以对于一些业务场景升级为常态整体异步化的能力。
附图说明
通过参照下面的附图，可以实现对于本公开内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。
图1为线下收钱码支付业务所包括的各个支付阶段的示例；
图2示出了本公开实施例1提供的支付防抖方法的流程图；
图3为图2中所示的当前业务请求为支付过程的首次业务请求的示例；
图4为图2中所示的当前业务请求为支付过程的非首次业务请求的示例；
图5为一个示例提供的从客户端看到的支付的中间阶段返回的模拟正常结果的示意图；
图6为图5所示的支付示例的最后返回的模拟正常结果的示意图；
图7为本公开实施例2提供的支付防抖方法的整个支付过程的流程图；
图8为本公开一个实施例提供的支付防抖装置800的结构示意图；
图9为本公开另一个实施例提供的支付防抖装置900的结构示意图；
图10为本公开的一个实施例提供的实现支付防抖的计算设备的结构框图。
具体实施方式
现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本公开内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
一次支付过程包括一个支付阶段或多个支付阶段，本公开主要针对包括多阶段的支付业务。可以将客户端发起一次业务请求至下一次业务请求看作一个阶段或者将客户端发起一次业务请求至客户端显示支付完成看作一个阶段。例如，对于线下收钱码支付业务，如图1所示，客户端扫卖家的收钱码为第一次业务请求，从客户端发起第一次业务请求至客户端显示服务端返回的付款金额输入框为创建交易号的阶段110；用户向客户端显示的付款金额输入框输入支付的钱数后确认提交为第二次业务请求，从客户端发起第二次业务请求到客户端显示服务端返回的支付方式选项和支付密码输入框为拉起收银台的阶段120；用户通过客户端选择支付方式并输入支付密码后确认提交则为第三次业务请求，从客户端发起第三次业务请求至客户端显示服务端返回的“正在支付”的通知为提交支付的阶段130；发起的第四次业务请求调用轮询，查询订单的交易状态，如果交易成功，则客户端收到“付款成功”的通知，因此第四阶段为轮询支付结果的阶段140。可见，线下收钱码支付业务包括上述四个阶段。
因为服务端的分布式系统业务链路较长，比较容易发生抖动，所以为了避免支付过程因抖动而中断或出现错误，对于某次业务请求一旦服务端进行远程调用发生异常则对这次业务请求及其后各次业务请求均进行兜底处理。根据远程调用返回结果的错误码、异常和/或业务参数等识别业务抖动，对业务抖动进行兜底处理，返回模拟结果，记录兜底流水。可以根据兜底的流水触发异步恢复流程，从垫支账户打款给卖家。
图2示出了本公开实施例1提供的支付防抖方法的流程图，该过程可以由支付防抖装置执行。实施例1主要考虑支付过程中一次业务请求的处理。
如图2所示，在块210中，拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。
可以通过AOP拦截客户端发送到服务端的当前业务请求，其中，AOP为Aspect Oriented Programming的缩写，意为面向切面编程，是通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。AOP可以理解为一个拦截器框架，但是这个拦截器会非常武断，如果它拦截一个类，那么它就会拦截这个类中的所有方法。
在块220中，基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。作为该实施例的一方面，对于非首次业务请求所带的防抖标记的标记值为异常的情况，确定针对当前业务请求的远程业务调用为异常。对于在首次业务请求处理期间创建的防抖标记并且防抖标记的标记值为空的情况，以及非首次业务请求所带的防抖标记的标记值为正常的情况，都确定针对当前业务请求的远程业务调用为正常。
在块230中，当针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。
在块240中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。
图3为在当前业务请求为支付过程的首次业务请求时的支付防抖方法的示例。
在块310中，支付防抖装置拦截客户端在支付过程中发送到服务端的首次业务请求，首次业务请求至少包括唯一阶段标识。
在块320中，解析所拦截的首次业务请求，以确定首次业务请求所属的业务类型。
在块330中，在所确定的业务类型属于需要防抖处理的业务类型时，为首次业务请求创建防抖标记，防抖标记用于指示本次支付业务是需要防抖处理的业务。在本公开的一个示例中，需要防抖处理的业务类型可以包括线下收钱码支付业务。防抖标记例如为appfuse_type。因为服务端为分布式系统，所以对业务请求进行处理需要进行远程业务调用。防抖标记的标记值用于指示远程业务调用是正常还是异常，异常指远程业务调用的链路发生抖动。防抖标记的标记值例如为normal或shake，其中shake代表抖动，normal表示正常，即没发生抖动。
在块340中，根据首次业务请求进行远程业务调用。这里可以由支付防抖装置作为上游系统向服务端的下游系统进行远程业务调用，作为替换方式，也可以由支付防抖装置指示服务端的上游系统向下游系统进行远程业务调用。
在块350中，基于远程业务调用返回的调用结果，确定针对首次业务请求的远程业务调用是否异常。如果远程业务调用返回的调用结果异常，则确定针对首次业务请求的远程业务调用异常，流程进行到块360。如果远程业务调用返回的调用结果正常，则确定针对首次业务请求的远程业务调用正常，流程进行到块380。
在块360中，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。与唯一阶段标识所标识的支付阶段对应的模拟正常结果保存在支付防抖装置的存储器中，支付防抖装置解析所拦截的业务请求，根据解析出来的唯一阶段标识在其存储器中找到对应的模拟正常结果，从而生成兜底处理结果。流程进行到块370。
在块370中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。
在块380中，为防抖标记赋予用于指示远程业务调用正常的标记值，比如normal，基于远程业务调用返回的调用结果和防抖标记生成正常处理结果。因此，正常处理结果包括远程业务调用返回的调用结果中的信息和防抖标记。流程进行到块390。
在块390中，将正常处理结果发送给客户端。
图4为当前业务请求为支付过程的非首次业务请求时的支付防抖方法的示例。
在块400中，支付防抖装置拦截客户端在支付过程中发送到服务端的非首次业务请求，非首次业务请求至少包括唯一阶段标识和防抖标记。其中，防抖标记是上一业务请求处理过程所返回的防抖标记。
在块410中，判断非首次业务请求所包括的防抖标记的标记值指示远程业务调用是否异常。如果防抖标记的标记值指示远程业务调用异常，则确定针对非首次业务请求的远程业务调用异常，流程进行到块420。如果防抖标记的标记值指示远程业务调用正常，则流程进行到块440。
在块420中，生成兜底处理结果，兜底处理结果包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记，防抖标记具有用于指示远程业务调用异常的标记值，比如shake。流程进行到块430。
在块430中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。图5为一个示例提供的从客户端看到的支付的中间阶段返回的模拟正常结果的示意图。图6为图5所示的支付示例的最后阶段返回的模拟正常结果的示意图。
在块440中，根据非首次业务请求进行远程业务调用。流程进行到块450。
在块450中，基于远程业务调用返回的调用结果是否异常，确定针对非首次业务请求的远程业务调用是否异常。如果调用结果异常比如SYSTEM_ERROR时，则确定远程业务调用异常，流程进行到块460。如果调用结果正常，则确定远程业务调用正常，流程进行到块480。
在块460中，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。流程进行到块470。
在块470中，将兜底处理结果发送给客户端。
在块480中，生成正常处理结果，正常处理结果包括远程业务调用返回的调用结果中的信息和防抖标记，防抖标记具有用于指示远程业务调用正常的标记值，比如normal。流程进行到块490。
在块490中，将正常处理结果发送给客户端。
作为一个可选实施例，在图3的块360和/或图4的块460中为防抖标记赋予用于指示远程业务调用异常的标记值之前，该实施例的支付防抖方法还可以包括抖动识别步骤。抖动识别步骤可以包括：识别远程业务调用异常是否为能够进行兜底处理的异常，在识别出远程业务调用异常是能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。
如果当前的业务请求包括支付信息，支付防抖装置可以记录业务请求中的支付信息和多阶段上下文的状态缓存。支付信息可以包括订单金额、付款账户、以及收款账户等信息，根据支付信息生成订单，订单可以包括流水号。此外，与支付过程对应的支付信息还可以来自服务端。记录支付信息以便于在同步兜底处理之后进行防抖异步恢复。多阶段上下文的状态缓存是多阶段状态中防抖需要用到的信息。作为一个可选实施例，在当前业务请求是支付过程的最后业务请求时，该实施例的支付防抖方法还可以包括：在将兜底处理结果发送给客户端后，根据与支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。从垫支账户中支付相应数目的支付款给卖家的过程可以称为异步恢复流程，因为这个过程是以异步恢复方式完成的。在从垫支账户中支付相应数目的支付款给卖家之前，该实施例的支付防抖方法还可以包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知卖家相应数目的支付款已到账。通知卖家可以采用语音播报、短信通知、或者其他任何现有的方式。
在同步兜底处理之后，异步恢复流程可以通过实时、定时、或者手动等方式触发。其中，异步恢复的过程与前述业务请求的处理过程在分布式系统中经由的链路大概率是不同的链路，也有可能是相同的链路。通常异步恢复流程是以实时方式触发，大约从通知卖家支付款已到账时起的例如1～2秒钟后从垫支账户打相应数目的支付款到卖家的账户。在极少数情况下，如果以实时方式触发异步恢复流程时系统仍然有故障，则可以定时方式从通知卖家支付款已到账时起经过预设时长后从垫支账户打支付款到卖家的账户。在极特殊情况下，如果以定时方式触发异步恢复流程时系统仍然有故障，则可以人工介入以手动方式从垫支账户打支付款到卖家的账户。
整个支付过程对用户而言是有体感的，看到的是免单优惠，如图5和图6所示，对卖家而言是无感知的，用户支付完成后，同步地使卖家收到语音播报或短信通知等，而在资金处理方面需要在防抖异步恢复的时候从支付垫资账户打款给卖家，而买家账户没有资金变动而且可以事后从买家账户追款或者不从买家账户追款。
图7为本公开实施例2提供的支付防抖方法的整个支付过程的流程图，实施例2以本次支付过程包括3个阶段为例。其中，支付防抖装置为承担防抖能力的基础功能模块，支付防抖装置可以是接入服务端中的组件，也可以是客户端和服务端之间的独立装置。
如图7所示，在700，支付防抖装置拦截客户端在支付过程中发送到服务端的第一次业务请求，第一次业务请求包括唯一阶段标识，其中，唯一阶段标识用于唯一标识当 前业务请求所对应的第一支付阶段。
在705，为第一次业务请求创建防抖标记，比如appfuse_type，以标识本次支付为需要防抖的业务。
在710，根据第一次业务请求进行远程业务调用。
在715，基于远程业务调用返回的调用结果是否异常，确定针对第一次业务请求的远程业务调用是否异常。在确定远程业务调用正常时，为防抖标记赋予用于指示远程业务调用正常的标记值，比如normal，基于远程业务调用返回的调用结果和防抖标记生成正常处理结果。
在720，将正常处理结果发送给客户端。
在725，支付防抖装置拦截客户端在支付过程中发送到服务端的第二次业务请求，第二次业务请求包括唯一阶段标识和防抖标记，其中，唯一阶段标识用于唯一标识当前业务请求所对应的第二支付阶段，防抖标记具有用于指示远程业务调用正常的标记值，比如normal。
在730，根据第二次业务请求进行远程业务调用。
在735，基于远程业务调用返回的调用结果异常，确定针对第二次业务请求的远程业务调用异常。
在740，在确定远程业务调用异常时，识别远程业务调用异常是否为能够进行兜底处理的异常，即识别返回的调用结果的错误码是否在兜底的范围内，如果在兜底范围内则进行兜底处理。
在745，在识别出异常为能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的第二支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。
在750，将兜底处理结果发送给客户端。
在755，支付防抖装置拦截客户端在支付过程中发送到服务端的最后业务请求，最后业务请求包括唯一阶段标识和防抖标记，其中，唯一阶段标识用于唯一标识当前业务请求所对应的最后支付阶段，该防抖标记具有用于指示远程业务调用异常的标记值，比如shake。
在760，基于防抖标记的标记值指示远程业务调用异常，确定针对最后业务请求的 远程业务调用异常。
在765，生成兜底处理结果，兜底处理结果包括与唯一阶段标识所标识的最后支付阶段对应的模拟正常结果和防抖标记，防抖标记具有用于指示远程业务调用异常的标记值，比如shake。
在770，将兜底处理结果发送给客户端。
在775，客户端显示完成本次支付，用户看到的都是模拟正常结果。
在780，启动异步恢复过程，以实现业务的最终一致。
在785，根据与该支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。
该实施例的支付防抖方法还可以包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知卖家相应数目的支付款已到账。通知卖家可以采用语音播报、短信通知、或者其他任何现有的方式。
由实施例2可见，对于防抖处理的业务，除了本次支付的最后一次业务请求，对于之前的每一次业务请求，支付防抖装置均在发送返回结果给客户端的同时，发送具有标记值的防抖标记给客户端。客户端发送下一次业务请求的时候会带上该防抖标记，再次进入到支付防抖装置内，如果防抖标记的防抖值指示远程业务调用异常，则会被识别为这个支付过程上一阶段已经被兜底处理，当次阶段继续走兜底流程，直到用户完成这次支付。当然，对于本次支付的最后一次业务请求，支付防抖装置发送返回结果给客户端，也可以同时发送具有标记值的防抖标记给客户端，只是这一阶段是支付过程的最后阶段，后面不会再有客户端发送的业务请求了，因此发送防抖标记给客户端的话信息不够简洁。另外，如果对于当前业务请求进行远程业务调用异常，支付防抖装置在发送返回结果的同时发送具有用于指示远程业务调用异常的标记值的防抖标记给客户端，对于客户端后续发起的业务请求，支付防抖装置都不再发送防抖标记给客户端，则虽然发送给客户端的信息简洁，但是需要修改客户端的程序。
本公开的支付防抖方法不限于上述各实施例所公开的技术方案，上面公开的对于支付过程一次业务请求处理的各个实施例可以在不偏离发明实质的情况下做出各种组合、变形和修改，此外，整个支付过程的各个阶段的各个实施例也可以在不偏离发明实质的情况下做出各种组合、变形和修改。
利用本公开的方案，从通用高可用架构层面减少服务端的链路抖动、故障对业务 带来的影响以及业务损失，提升整体业务链路的成功率，同时提升用户体验。
利用本公开的方案，在目前互联网规模以及复杂的企业级分布式架构体系下，为未来核心业务场景达到99.999％甚至更高的可用率目标提供高可用架构层面的保障，保障金融级别的稳定性，降低系统抖动造成的公众影响，减少商户收款损失。
图8为本公开一个实施例提供的支付防抖装置800的结构示意图。其中，支付防抖装置既可以为一个独立的装置，也可以为接入服务端的组件。如图8所示，该实施例的支付防抖装置800可以包括：拦截单元810、异常确定单元820、兜底处理单元830、以及发送单元840。
拦截单元810被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。拦截单元810的操作可以参照上面参考图2描述的块210的操作。
异常确定单元820被配置为基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。异常确定单元820的操作可以参照上面参考图2描述的块220的操作。
兜底处理单元830被配置为在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。兜底处理单元830的操作可以参照上面参考图2描述的块230的操作。
发送单元840被配置为将兜底处理结果发送给客户端。发送单元840的操作可以参照上面参考图2描述的块240的操作。
图9为本公开另一个实施例提供的支付防抖装置900的结构示意图。如图9所示，该实施例的支付防抖装置900可以包括：拦截单元910、防抖标记创建单元920、异常确定单元930、业务调用单元940、兜底处理单元950、标记值调整单元960、以及发送单元970。
拦截单元910被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。拦截单元910的操作可以参照上面参考图7描述的700、725和755的操作。
防抖标记创建单元920，被配置为在当前业务请求是首次业务请求时，在拦截到当 前业务请求后为当前业务请求创建防抖标记。防抖标记创建单元920的操作可以参照上面参考图7描述的705的操作。
异常确定单元930被配置为基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。异常确定单元930还可以被配置为在防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。异常确定单元930的操作可以参照上面参考图7描述的735和760的操作。
业务调用单元940被配置为在防抖标记的标记值指示远程业务调用正常时，根据当前业务请求执行远程业务调用。作为该实施例的一方面，对于在首次业务请求处理期间创建防抖标记并且防抖标记的标记值为空的情况，以及非首次业务请求所带的防抖标记的标记值为正常的情况，都认为防抖标记的标记值指示远程业务调用正常。业务调用单元940的操作可以参照上面参考图7描述的710和730的操作。异常确定单元930还可以被配置为基于远程业务调用的返回结果是否异常，确定针对当前业务请求的远程业务调用是否异常。异常确定单元930的操作可以参照上面参考图7描述的735的操作。
兜底处理单元950被配置为在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。兜底处理单元950的操作可以参照上面参考图7描述的745和765的操作。
标记值调整单元960被配置为在远程业务调用的返回结果异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的745的操作。
发送单元970被配置为将兜底处理结果发送给客户端。发送单元970的操作可以参照上面参考图7描述的750和770的操作。
作为该实施例的一方面，该实施例的支付防抖装置还可以包括正常处理单元。正常处理单元被配置为在针对当前业务请求的远程业务调用被确定为正常时，生成正常处理结果，正常处理结果至少包括远程业务调用返回的调用结果中的信息。正常处理单元的操作可以参照上面参考图7描述的715的操作。标记值调整单元960还可以被配置为在远程业务调用的返回结果正常时，确定针对当前业务请求的远程业务调用正常，为防抖标记赋予用于指示远程业务调用正常的标记值并包括在正常处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的715的操作。发送单元970还可以被配 置为将正常处理结果发送给客户端。发送单元970的操作可以参照上面参考图7描述的720的操作。
作为该实施例的另一方面，该实施例的支付防抖装置还可以包括业务类型确定单元。业务类型确定单元被配置为在当前业务请求是首次业务请求时，在拦截到当前业务请求后，解析所拦截的当前业务请求，以确定当前业务请求所属的业务类型。业务类型确定单元的操作可以参照上面参考图3描述的块320的操作。防抖标记创建单元920还可以被配置为在所确定的业务类型属于需要防抖处理的业务类型时，为当前业务请求创建防抖标记。标记创建单元920的操作可以参照上面参考图3描述的块330的操作。
作为该实施例的又一方面，该实施例的支付防抖装置还可以包括异常识别单元。异常识别单元被配置为在远程业务调用的返回结果异常时，识别远程业务调用异常是否为能够进行兜底处理的异常。异常识别单元的操作可以参照上面参考图7描述的740的操作。标记值调整单元960还可以被配置为在识别出远程业务调用异常是能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的745的操作。
作为该实施例的在一方面，该实施例的支付防抖装置还可以包括支付处理单元。在当前业务请求是所述支付过程的最后业务请求时，在将兜底处理结果发送给客户端后，根据与支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。支付处理单元的操作可以参照上面参考图7描述的780-785的操作。
本公开的支付防抖装置不限于上述各实施例所公开的技术方案，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种组合、变形和修改。
如上参照图2-9，对本公开的支付防抖方法及装置的实施例进行了描述。应当理解的是，以上对于方法实施例的细节描述同样适用于装置实施例。以上的支付防抖装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。
图10是本公开的一个实施例提供的实现支付防抖的计算设备的结构框图。
如图10所示，计算设备1000可以包括至少一个处理器1010、存储器1020、内存1030、通信接口1040以及内部总线1050，该至少一个处理器1010执行在计算机可读存储介质(即，存储器1020)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器1020中存储有计算机可执行指令，其当执行时使得 至少一个处理器1010：拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段；基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常；在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及将兜底处理结果发送给客户端。
应该理解的是，在存储器1020中存储的计算机可执行指令当执行时使得至少一个处理器1010进行本公开的各个实施例中以上结合图2-9描述的各种操作和功能。
在本公开中，计算设备1000可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴计算设备、消费电子设备等等。
根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图2-9描述的各种操作和功能。
具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。
需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即， 有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。
上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (19)

  1. 一种支付防抖方法，包括：
    拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；
    基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；
    在针对所述当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及
    将所述兜底处理结果发送给所述客户端。
  2. 如权利要求1所述的方法，其中，基于与所述当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常包括：
    在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。
  3. 如权利要求1或2所述的方法，其中，基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常包括：
    在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用；以及
    基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。
  4. 如权利要求3所述的方法，还包括：
    在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
  5. 如权利要求4所述的方法，其中，在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值包括：
    在确定针对所述当前业务请求的远程业务调用异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常；以及
    在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
  6. 如权利要求1所述的方法，其中，在所述当前业务请求是首次业务请求时，所 述防抖标记是在拦截到所述当前业务请求后创建的，或者
    在所述当前业务请求是非首次业务请求时，所述防抖标记是上一业务请求处理过程所返回的防抖标记。
  7. 如权利要求6所述的方法，其中，在所述当前业务请求是首次业务请求时，通过下述过程来为所述当前业务请求创建防抖标记：
    在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型；
    在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。
  8. 如权利要求7所述的方法，其中，所述需要防抖处理的业务类型包括线下收钱码支付业务。
  9. 如权利要求1所述的方法，其中，在所述当前业务请求是所述支付过程的最后业务请求时，所述方法还包括：
    在将所述兜底处理结果发送给所述客户端后，根据与所述支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。
  10. 如权利要求9所述的方法，还包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知所述卖家相应数目的支付款已到账。
  11. 一种支付防抖装置，包括：
    拦截单元，被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；
    异常确定单元，被配置为基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；
    兜底处理单元，被配置为在针对所述当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及
    发送单元，被配置为将所述兜底处理结果发送给所述客户端。
  12. 如权利要求11所述的装置，其中，所述异常确定单元还被配置为：
    在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。
  13. 如权利要求11或12所述的装置，还包括：
    业务调用单元，被配置为在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用，
    其中，所述异常确定单元还被配置为：基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。
  14. 如权利要求13所述的装置，还包括：
    标记值调整单元，被配置为在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
  15. 如权利要求14所述的装置，还包括：
    异常识别单元，被配置为在所述远程业务调用的返回结果异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常，
    其中，所述标记值调整单元还被配置为在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。
  16. 如权利要求11所述的装置，还包括：
    防抖标记创建单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后为所述当前业务请求创建所述防抖标记。
  17. 如权利要求16所述的装置，还包括：
    业务类型确定单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型，
    其中，所述防抖标记创建单元还被配置为在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。
  18. 一种计算设备，包括：
    一个或多个处理器，以及
    与所述一个或多个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求1到10中任一项所述的方法。
  19. 一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到10中任一项所述的方法。
PCT/CN2020/073839 2019-03-08 2020-01-22 支付防抖方法及装置 WO2020181936A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910176397.2 2019-03-08
CN201910176397.2A CN110033280B (zh) 2019-03-08 2019-03-08 支付防抖方法及装置

Publications (1)

Publication Number Publication Date
WO2020181936A1 true WO2020181936A1 (zh) 2020-09-17

Family

ID=67235195

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/073839 WO2020181936A1 (zh) 2019-03-08 2020-01-22 支付防抖方法及装置

Country Status (3)

Country Link
CN (1) CN110033280B (zh)
TW (1) TWI771616B (zh)
WO (1) WO2020181936A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110033280B (zh) * 2019-03-08 2021-08-17 创新先进技术有限公司 支付防抖方法及装置
CN110866034B (zh) * 2019-10-25 2022-12-13 福建天泉教育科技有限公司 服务端节流的方法、存储介质
CN111586172A (zh) * 2020-05-07 2020-08-25 支付宝(杭州)信息技术有限公司 数据处理方法、装置、设备及介质
CN113781720B (zh) * 2021-09-13 2023-03-14 深圳市乐唯科技开发有限公司 一种去抖电路及自助支付设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103514565A (zh) * 2012-06-27 2014-01-15 中国银联股份有限公司 金融交易处理系统的交易异常处理单元及方法
CN104618106A (zh) * 2014-12-29 2015-05-13 芜湖乐锐思信息咨询有限公司 一种安全可靠的互联网在线交易系统
US20180240117A1 (en) * 2017-02-22 2018-08-23 Square, Inc. Line-based chip card tamper detection
CN109299946A (zh) * 2018-07-27 2019-02-01 阿里巴巴集团控股有限公司 一种支付流程的处理方法和装置
CN110033280A (zh) * 2019-03-08 2019-07-19 阿里巴巴集团控股有限公司 支付防抖方法及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050021462A1 (en) * 2003-07-21 2005-01-27 Don Teague Method and system to process a billing failure in a network-based commerce facility
CN102045682B (zh) * 2009-10-19 2014-03-12 中兴通讯股份有限公司 一种支付业务异常交易的处理方法及系统
CN105931036A (zh) * 2016-05-31 2016-09-07 北京小米移动软件有限公司 支付方法及装置
CN106874183B (zh) * 2016-07-05 2020-05-05 阿里巴巴集团控股有限公司 业务异常检测方法及装置
CN109345220A (zh) * 2018-08-15 2019-02-15 北京三快在线科技有限公司 支付处理方法、装置及计算机可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103514565A (zh) * 2012-06-27 2014-01-15 中国银联股份有限公司 金融交易处理系统的交易异常处理单元及方法
CN104618106A (zh) * 2014-12-29 2015-05-13 芜湖乐锐思信息咨询有限公司 一种安全可靠的互联网在线交易系统
US20180240117A1 (en) * 2017-02-22 2018-08-23 Square, Inc. Line-based chip card tamper detection
CN109299946A (zh) * 2018-07-27 2019-02-01 阿里巴巴集团控股有限公司 一种支付流程的处理方法和装置
CN110033280A (zh) * 2019-03-08 2019-07-19 阿里巴巴集团控股有限公司 支付防抖方法及装置

Also Published As

Publication number Publication date
CN110033280A (zh) 2019-07-19
TWI771616B (zh) 2022-07-21
TW202034242A (zh) 2020-09-16
CN110033280B (zh) 2021-08-17

Similar Documents

Publication Publication Date Title
WO2020181936A1 (zh) 支付防抖方法及装置
US20240296444A1 (en) Display apparatus having frame with regions to discharge heat generated by printed circuit board
CN112334933A (zh) 区块链交易处理
US10901818B2 (en) System and method for common request processing
US10776771B2 (en) Electronic resource processing method and device
US20220027873A1 (en) Peer-to-peer (p2p) payment with security protection for payee
CN111213172B (zh) 通过数字钱包访问ach交易功能
US20240281802A1 (en) Digital Currency-Based Payment Method, Platform and System, and Terminal
US20230103746A1 (en) Systems and methods for providing split control of multiple execution environments
US20190034927A1 (en) Payment transaction processing systems and methods
US20220327523A1 (en) Systems and methods for generating and transmitting electronic transaction account information messages
CN111242614A (zh) 钱包账户资产找回方法、收款保障方法、设备和存储介质
KR20210068039A (ko) 거래 시스템을 구현하는 네트워크 노드들의 서브세트 내의 컨텍스트 기반 필터링
US20160063404A1 (en) Universal back office workflow
WO2021121030A1 (zh) 一种资源转移的方法及结账终端、服务器节点
US11314710B2 (en) System and method for database sharding using dynamic IDs
US11244322B2 (en) Methods and apparatus for chargebacks of push payment transactions
US20210201275A1 (en) System and method for smart device communication and transaction processing
CN115994760B (zh) 第三方支付业务的实现方法和装置
US20240311810A1 (en) Web3 transfer protocol
US20240311811A1 (en) Web3 transfer protocol
US20220051232A1 (en) Payment information correlation system and method
US20230237470A1 (en) Digital card integration with card processing system of card issuer
US20240232822A1 (en) Systems and methods for implementing off-network services
US20240053999A1 (en) Reconciliation systems and methods for unbounded streams

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: 20770572

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20770572

Country of ref document: EP

Kind code of ref document: A1