Methods, apparatuses, devices, media, and program products for payment

Abstract

Methods, apparatus, devices, media, and program products for payment are provided. The method includes: in response to receiving a payment request from an intelligent agent, acquiring time information associated with the payment request, the time information including multiple occurrence times of multiple events corresponding to the payment request, the multiple events being associated with the intelligent agent; determining, based on the multiple occurrence times, whether the payment request satisfies a time constraint; and processing the payment request based on the determination.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computers, and in particular to methods, apparatus, devices, media, and program products used for payment. Background Technology

[0002] In intelligent agent payment scenarios, user input, intelligent agent planning, and payment submission may be completed by different devices, services, or gateways at different times. The intervals between these time points reflect the timeliness of the payment request to some extent. When a user's intention is generated but payment is triggered after a long period of time, the user's original intention may have changed.

[0003] The industry has raised higher requirements for judging the timeliness of payment requests before payment is accepted. However, when different stages use different time sources, cross-system time comparisons are difficult. Summary of the Invention

[0004] In a first aspect, a method for making a payment is provided. The method includes: in response to receiving a payment request from an agent, acquiring time information associated with the payment request, the time information including multiple occurrence times of multiple events corresponding to the payment request, the multiple events being associated with the agent; determining, based on the multiple occurrence times, whether the payment request satisfies a time constraint; and processing the payment request based on the determination.

[0005] In a second aspect, an apparatus for payment is provided. The apparatus includes: an acquisition module configured to, in response to receiving a payment request from an agent, acquire time information associated with the payment request, the time information including multiple occurrence times of multiple events corresponding to the payment request, the multiple events being associated with the agent; a constraint module configured to determine, based on the multiple occurrence times, whether the payment request satisfies a time constraint; and a processing module configured to process the payment request based on the determination.

[0006] In a third aspect, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the electronic device to perform the method of the first aspect.

[0007] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that can be executed by a processor to implement the method of the first aspect.

[0008] In a fifth aspect, a computer program product is provided. The computer program product is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect.

[0009] In this way, the computer system can make time constraint judgments on payment requests from intelligent agents based on multi-terminal time information before payment is accepted, thereby identifying the risk of old intentions driving new payments without relying on manual review. Furthermore, by integrating the scattered time judgments into a unified machine judgment process before payment is accepted, compared with the current approach of recording and comparing timestamps separately in multiple systems, the number of rounds of time data interaction across systems can be reduced, the end-to-end latency of payment acceptance decisions can be reduced, and the storage and query overhead for post-dispute review can be reduced.

[0010] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0011] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of the example environment is shown; Figure 2 Flowcharts of example payment processes for some embodiments are shown; Figure 3 The diagram illustrates the interactive timing diagrams for timing acquisition and verification of payments in some embodiments; Figure 4 Block diagrams of some embodiments of a payment device are shown; Figure 5 Sequence diagrams of example interaction processes for verifying payment requests in some embodiments are shown; and Figure 6 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

[0012] The examples in this document will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0013] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0014] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0015] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and rules. In the examples, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0016] In this manual and the sample solutions, any processing of personal information will be conducted only on a legal basis (such as with the consent of the data subject or as necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0017] The term "intelligent agent" as used in this article refers to a computational entity that is capable of planning, making decisions, and performing delegated tasks on behalf of the user based on user input, and typically includes, but is not limited to, programs, services, or models running on a client, server, or a combination thereof.

[0018] The term "payment request" as used in this article refers to a request used to trigger payment processing, which typically includes, but is not limited to, messages or calls initiated by an agent to the payment side after completing task planning, to request the execution of a certain payment.

[0019] The term "event" as used in this article refers to an action or state change that occurs at a specific point in time and is associated with a payment request. This may include, but is not limited to, receiving user input that triggers the payment request, freezing the context associated with the payment request, and the submission of the payment request.

[0020] The term “time of occurrence” as used in this article refers to the point in time at which an event occurs, usually expressed in the form of a timestamp, which may include, but is not limited to, the time recorded by the device or service that records the event based on its time source.

[0021] The term "time constraint" as used in this article refers to the constraint conditions used to determine whether the relationship between multiple occurrence times meets the payment acceptance requirements. This may include, but is not limited to, constraints on the causal order between events and constraints on the time intervals between stages.

[0022] The term "context" as used in this article refers to the set of information associated with a payment request and used to support payment decisions, which may include, but is not limited to, task identifiers, task parameters, payment constraint fields, user prompt summaries, and agent runtime identity information.

[0023] The term “freeze” as used in this article refers to the operation of fixing a context at a certain point in time so that it no longer changes with subsequent processing, typically including but not limited to archiving the context and generating a context freeze summary to characterize that version of the context.

[0024] The term “clock source” as used in this article refers to the type of time reference on which the event occurs, which may include, but is not limited to, a device security clock, a trusted execution environment clock, a general system clock, or a synchronization clock.

[0025] The term “clock offset” as used in this article refers to the offset of a clock source relative to the payment-side reference clock, which can be determined based on the most recent time synchronization record and is used to convert the occurrence time of different time sources into normalized time relative to the payment-side reference.

[0026] The term “time source trust level” as used in this article refers to the classification of the trust level of one or more clock sources, which may include, but is not limited to, trustworthy, downgraded trustworthy, and untrustworthy categories, and is used to determine whether time constraints are tightened, whether enhanced confirmation is required, or whether blocking is necessary.

[0027] The term “normalized time” as used in this article refers to the time obtained by converting occurrence times from different clock sources to a unified time representation relative to the payment side’s reference, which typically includes, but is not limited to, time with a unified time zone, a unified time format, and time corrected for clock offset.

[0028] The term “time-anchored object” as used in this article refers to a verifiable evidence object that binds together multiple occurrence times, clock sources, clock offsets, and identifiers and context-freeze summaries associated with the payment request. This typically includes, but is not limited to, objects that are guaranteed not to be silently tampered with during subsequent verification through summaries and signatures.

[0029] The term "anchored digest" as used in this paper refers to the digest value calculated by performing deterministic serialization on the normalized fields of the time-anchored object, along with the identifier of the payment request and the context-freeze digest, and is used to characterize the binding relationship between time evidence, payment request and context.

[0030] The term “context-frozen digest” as used in this paper refers to the digest value calculated after performing deterministic serialization on a frozen context, which is used to detect whether the context has changed after freezing.

[0031] The term "replay identifier" as used in this article refers to a random number or monotonic sequence generated for a time-series anchor object or payment request to prevent replay, which may include, but is not limited to, checking whether the same time-series anchor object or the same replay identifier is reused by different payment requests through a deduplication index.

[0032] The term "window constraint strategy" as used in this article refers to a set of strategies used to limit the time interval between each stage, which may typically include, but are not limited to, risk level, maximum allowable interval for one or more stages, time source credibility coefficient, enhanced confirmation threshold, blocking threshold, retry budget, and out-of-window handling actions.

[0033] The term "strategy snapshot" as used in this article refers to a fixed copy of the version, coefficients, thresholds, validity period, and processing rules of the window constraint strategy actually used in this payment request. Its summary can be written into the time-series anchoring object and audit log to restore the machine judgment basis at that time during dispute inquiries.

[0034] The term "window occupancy" used in this article refers to the ratio between the actual stage interval and the corresponding stage threshold. It can be calculated for multiple stages, and the maximum value is taken as the basis for determining the severity of the window overflow.

[0035] The term “window severity” used in this article refers to the maximum value of window occupancy across multiple stages, which is used to extend the judgment of whether a timeout has occurred from a single threshold to a tiered judgment criterion.

[0036] The term “deviation tolerance” as used in this article refers to a value determined based on the maximum clock deviation and the upper limit of deviation, used to tolerate small ranges of clock deviation in causal order verification and window interval calculation.

[0037] The term "enhanced verification" as used in this article refers to a process that requires further verification before payment is accepted, which may include, but is not limited to, verification through biometrics, passwords, FIDO2 authentication, or SMS verification codes.

[0038] The term “audit log” as used in this article refers to the data that records the inputs, intermediate results, action signals and state transition results of a time-constrained decision, and its summary can be used to reconstruct the reasons why a payment request was released, confirmed or blocked.

[0039] As mentioned above, in the smart agent payment process, user prompt generation, context freezing, and payment submission typically occur at different points in time. The intervals between these points reflect, to some extent, the timeliness of the payment request. When the interval is too long, the user's original intent may have changed, and continuing to execute the payment may no longer align with the user's current true intention.

[0040] In some current solutions, the system can record the timestamp of a single credential, token, or transaction request, or record the creation time, expiration time, or validity period in the authorization or payment credential, to determine whether the credential itself is still valid. However, such mechanisms typically only cover the lifecycle of a single authorization or payment object and are difficult to directly constrain the time interval between the three stages of user prompt generation, context freezing, and payment submission.

[0041] Furthermore, in some current solutions, user input, agent planning, and payment submission use the device's local clock, server clock, and synchronous clock, respectively. Discrepancies exist between these different clock sources, and directly comparing timestamps across systems can lead to misjudgments. Moreover, the reliability level of the time source, synchronization offset, and deviation tolerance are typically not recorded simultaneously. When the time interval exceeds a reasonable threshold, different systems may take different actions, such as direct rejection, continued access, alarms, or requiring reconfirmation, resulting in inconsistent handling.

[0042] In view of the above-mentioned problems and some other potential problems, this disclosure proposes a payment scheme. According to the scheme, in response to receiving a payment request from an agent, time information associated with the payment request is obtained, including multiple occurrence times of multiple events corresponding to the payment request, which are associated with the agent; based on the multiple occurrence times, it is determined whether the payment request meets time constraints; and based on the determination, the payment request is processed. This scheme enables time constraint judgment of payment requests based on the occurrence times of multiple events associated with the agent before payment acceptance, so that the judgment of the timeliness of payment requests no longer relies solely on the validity period of a single voucher or request, thereby identifying the risk of old intentions driving new payments without relying on manual review; furthermore, since the above judgment is completed by a unified machine judgment process before payment acceptance, compared with the current scheme of recording and comparing timestamps separately in multiple systems and then manually verifying them afterwards, it can reduce the number of rounds of cross-system time data interaction, reduce end-to-end latency of payment acceptance decisions, and reduce the number of storage read / write operations and query load required for subsequent dispute review.

[0043] The following describes various examples of this scheme in further detail with reference to the accompanying drawings.

[0044] Figure 1 A schematic diagram of example environment 100 is shown. (e.g.) Figure 1 As shown, example environment 100 may include payment gateway 110 and smart agent 120.

[0045] In some embodiments, payment gateway 110 can accept payment requests from smart agent 120 and verify the payment requests. Payment gateway 110 can communicate with smart agent 120 to send a first request to smart agent 120 and receive a first response from smart agent 120.

[0046] The payment gateway 110 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. The payment gateway 110 may, for example, include computing systems / servers such as mainframes, edge computing nodes, and computing devices in a cloud environment.

[0047] The intelligent agent 120 can be deployed on any type of mobile terminal, fixed terminal, or portable terminal, or on computing devices in a server or cloud environment, including but not limited to mobile phones, desktop computers, laptop computers, notebook computers, tablet computers, handheld computers, servers, edge computing nodes, or any combination thereof, including accessories and peripherals of these devices or any combination thereof.

[0048] A communication connection can be established between the payment gateway 110 and the intelligent agent 120. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections. In some embodiments, the payment gateway 110 and the intelligent agent 120 can interact via their communication connection.

[0049] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme.

[0050] The following description of the example will continue with reference to the accompanying drawings.

[0051] Figure 2 A flowchart of an example process 200 for payment, according to some embodiments, is shown. Figure 2 As shown, system 200 may include payment gateway 110 and smart agent 120. The various modules / components in system 200 may be implemented by hardware, software, firmware, or any combination thereof.

[0052] like Figure 2 As shown in block 210, in response to receiving a payment request from an agent, the payment gateway 110 obtains time information associated with the payment request, which includes multiple occurrence times of multiple events corresponding to the payment request, and these multiple events are associated with the agent 120.

[0053] In some embodiments, the plurality of events may include a first event, the first occurrence time of which is the time when user input is received, which triggers the payment request. For example, the client records the prompt generation time when the user inputs a prompt or confirms the task intent. In this way, the time when the user generates the payment intent is included in the basis for time constraint judgment, thereby enabling the identification of the time misalignment between the user's original intent and the payment submission at the functional level. At the same time, since the occurrence time of user input is uniformly processed on the payment side as part of the time evidence, compared to separately querying user interaction logs on the payment side to infer the intent generation time, the number of queries initiated to the log system can be reduced, and the corresponding database read and write overhead can be lowered.

[0054] In some embodiments, the plurality of events may include a second event, the second occurrence time of which is the time when the context associated with the payment request is frozen. For example, agent 120 records the time when it completes context trimming, task parameter archiving, and payment intent context freezing. In this way, the freezing time of the context version on which the payment request is based is incorporated into the time constraint judgment, thereby enabling functional identification of whether the time interval between context freezing and payment submission is too long; at the same time, since the context freezing time is provided along with the time information, compared to retrieving the context on the payment side to determine its timeliness, the amount of context data transmission between the edge and the cloud can be reduced and the corresponding communication bandwidth usage can be reduced.

[0055] In some embodiments, the plurality of events may include a third event, the third occurrence time of which is the time when the payment request is submitted. For example, after receiving the payment request and completing the request body integrity verification, the payment gateway 110 records the time. In this way, the actual time when the payment request arrives at the payment side is included in the basis for time constraint judgment, thereby enabling the timeliness of the entire link to be determined at the functional level; at the same time, since the third occurrence time is recorded based on the local clock of the payment side, compared with the method of separately correcting the time across ends, the number of calculations required for time correction can be reduced and the computational overhead of the payment side can be reduced.

[0056] In some embodiments, obtaining the time information may further include: obtaining a first clock source and a first clock offset associated with the first event, a second clock source and a second clock offset associated with the second event, determining the time source reliability level based on the first clock source and the second clock source, and converting the multiple occurrence times into normalized time relative to a payment-side benchmark based on the first clock offset and the second clock offset. For example, the client records the prompt generation time when the user inputs a prompt or confirms a task intent, and simultaneously records the client's time source and the most recent time synchronization offset from the client to the payment gateway 110. The time series acquisition module can determine the time source reliability level based on the time source type, the most recent synchronization time, the absolute value of the offset, and the jitter. In this way, occurrence times from different clock sources are converted to a unified benchmark and assigned a trust level before comparison, thereby reducing the risk of false rejection or false release caused by edge clock drift at the functional level. At the same time, since time normalization and trust level assessment are completed before comparison, compared with the method of repeatedly trying to compare and roll back unnormalized timestamps, invalid comparison and rollback calculations can be reduced, the computational overhead on the payment side can be reduced, and the number of edge-cloud interaction rounds caused by repeated confirmations triggered by misjudgment can be reduced.

[0057] In some embodiments, the method may further include binding the plurality of occurrence times, the first clock source, the second clock source, the first clock offset, and the second clock offset into a time-series anchor object, which is used to verify whether the payment request meets the time constraint. In this way, time evidence scattered across multiple stages is bound into a single verifiable object, thereby improving the traceability of time constraint judgment at the functional level. Simultaneously, since the time evidence is assembled into a unified object for storage and transmission, compared to storing and verifying each piece of time evidence separately, the number of stored objects can be reduced, the number of storage read / write operations can be decreased, and the number of reads of multiple scattered objects during the verification phase can be reduced.

[0058] In some embodiments, the time-series anchoring object can be associated with an anchor digest and a signature. The anchor digest is determined based on the normalized fields of the time-series anchoring object, the identifier of the payment request, and a context-freeze digest. The signature is generated based on the payment-side private key of the anchor digest. The formula or state rule for the time-series anchoring module to calculate the anchor digest is as follows:

[0059] In this way, the binding relationship between time evidence, payment request and context is solidified by digest and signature, thereby preventing the time anchor object from being silently tampered with during transmission at the functional level; at the same time, since the binding relationship can be protected with a single digest and signature, the number of calculations required for integrity verification can be reduced and the computational overhead on the payment side can be reduced compared to the method of verifying each field separately.

[0060] In box 220, based on the multiple occurrence times, it is determined whether the payment request meets the time constraints.

[0061] In some embodiments, the method may further include: writing the identifier of the time-series anchor object, the identifier of the payment request, and the replay identifier into a deduplication index; and blocking the payment request in response to the same identifier of the time-series anchor object being associated with different payment requests, or the same replay identifier appearing repeatedly within its validity period. In this way, the reuse of time-series anchor objects is identified and blocked, thereby preventing the risks associated with cross-request reuse of anchor objects at the functional level. Simultaneously, since reuse is identified before acceptance through a short-term deduplication index, compared to discovering reuse only after all verifications are completed, invalid subsequent verification and processing flows can be terminated earlier, reducing invalid calculations and lowering the computational overhead on the payment side.

[0062] In some embodiments, determining whether a payment request meets a time constraint may further include: loading a window constraint policy based on at least one of risk level, time source trust level, payment amount, and merchant category, generating a policy snapshot based on the loaded window constraint policy, and determining the time constraint based on the policy snapshot. For example, the window policy module reads the risk level, payment amount range, merchant category code, user confirmation strength, agent identity trust level, and historical retries. If the upstream does not provide a risk level, it is treated as a high-risk level. The window policy module generates a time source coefficient based on the event source trust level. When the time source is trustworthy, the time source coefficient takes a more lenient value; when the time source is degenerate, the window threshold is shortened; when the time source is untrustworthy, enhanced confirmation or direct blocking is triggered. The window policy module determines three types of window thresholds in the following manner:

[0063]

[0064]

[0065] In this way, time constraints can be adaptively tightened or loosened based on factors such as risk level and time source credibility level, thereby providing differentiated timeliness control for different risk scenarios at the functional level. At the same time, since the strategy used this time is fixed as a strategy snapshot, compared with the method of re-retrieving historical strategy configurations in the event of a dispute, the number of queries to the strategy configuration library during dispute review can be reduced and the corresponding query load can be reduced.

[0066] In some embodiments, determining whether the payment request meets the time constraint may further include: determining the maximum clock deviation based on the offset of the plurality of events relative to the payment-side reference; and processing the payment request as a blocking or enhanced confirmation in response to the maximum clock deviation being greater than the deviation upper limit. The formula or state rule for the timing verification module to calculate the maximum deviation of the key time source relative to the gateway reference is as follows:

[0067]

[0068] in, The gateway's local clock is typically set to 0. This approach prioritizes conservative measures when times are incomparable, thereby reducing the risk of misplacement due to clock incomparability at the functional level. Simultaneously, by prematurely terminating subsequent sequential and window calculations when deviations exceed limits, compared to continuing full verification even when incomparable times, it reduces invalid calculations and lowers computational overhead on the payment side.

[0069] In some embodiments, in response to the maximum clock deviation being less than or equal to the upper limit of deviation, a deviation tolerance value can be determined based on the maximum clock deviation and the upper limit of deviation, and the time constraint can be determined based on the deviation tolerance value. In this way, small-range clock deviations are tolerated during judgment, thereby reducing false rejections caused by small-range clock drift at the functional level. Simultaneously, since the impact of deviation is absorbed all at once through the deviation tolerance value, compared to performing multiple rounds of deviation probing at each stage interval, redundant correction calculations can be reduced, and the computational overhead on the payment side can be lowered.

[0070] In some embodiments, determining whether the payment request meets the time constraint may further include: verifying that the first event precedes the second event and the second event precedes the third event based on the normalized times corresponding to the first event, the second event, and the third event, respectively; and blocking the payment request in response to a failed verification. This approach allows payment requests that violate causal order to be identified and blocked, thereby preventing exceptions such as context freezing before user input, payment submission before context freezing, or timestamp tampering from being allowed at the functional level. Simultaneously, by terminating subsequent window calculations early when the order verification fails, compared to continuing full calculations when the order is abnormal, invalid calculations can be reduced and the computational overhead on the payment side can be lowered.

[0071] In some embodiments, determining whether a payment request meets a time constraint may further include: comparing the context digest carried by the payment request with the context freeze digest in the time-anchored object; and blocking the payment request in response to a difference between the context digest and the context freeze digest. This approach ensures that payment requests whose context is modified after freezing are identified and blocked, thereby guaranteeing at the functional level that the context corresponding to the payment request is consistent with the frozen context. Simultaneously, since tampering is detected through digest comparison rather than re-comparing the complete context content, compared to transmitting and comparing the complete context, the amount of context data transmitted between the endpoint and the cloud can be reduced, and the corresponding communication bandwidth usage can be lowered.

[0072] In some embodiments, determining whether the payment request meets the time constraint may further include: determining the window occupancy of multiple stages based on the ratio of the stage interval between the multiple occurrence times to the corresponding stage threshold in the policy snapshot, and determining the maximum value among the window occupancy of the multiple stages as the window severity. In this way, the timeout judgment is expanded from a single threshold judgment to a tiered occupancy judgment, thereby providing a more granular characterization of the window severity at the functional level. Simultaneously, since a normalized occupancy uniformly represents the window severity of multiple stages, compared to setting independent judgment logic and processing each stage separately, the number of branches in the judgment logic and the corresponding computational overhead can be reduced.

[0073] In box 230, the payment request is processed based on this determination.

[0074] In some embodiments, processing the payment request may include: allowing the payment request if the window severity does not exceed a first threshold; granting enhanced confirmation if the window severity exceeds the first threshold but not a second threshold; and blocking the payment request if the window severity exceeds the second threshold. This allows payment requests with different window severity levels to be processed as allowed, granted enhanced confirmation, or blocked respectively, thereby avoiding coarse-grained rejection based solely on a single timeout threshold at the functional level. Furthermore, by granting enhanced confirmation to minor window requests instead of directly rejecting and re-initiating, compared to directly rejecting and requiring the user to re-initiate the entire payment process, the number of end-to-end cloud interaction rounds and redundant payment processing calculations caused by re-initiation can be reduced.

[0075] In some embodiments, processing the payment request may further include: in response to the main phase of the window being the phase from context freeze to payment submission and the retry budget not being exhausted, processing the payment request as a refreezing of the context, and setting the timing anchor object associated with the payment request to a replaced state. In this way, payment requests that have exceeded the time limit from context freeze to payment submission can be salvaged by refreezing the context, thereby reducing unnecessary payment failures while ensuring timeliness at the functional level. Simultaneously, since only the context is refreezed rather than the entire payment process is restarted, compared to restarting the entire process, the number of repeated processing steps can be reduced, and the computational overhead on the payment side and the number of edge-cloud interaction rounds can be lowered.

[0076] In some embodiments, processing the payment request may include: based on the determination, causing the time-series anchored object associated with the payment request to transition between multiple states, including at least two of the following: anchored, policy locked, verified, executed, blocked, expired, and replaced. In this way, the payment request has a clearly defined machine state under conditions such as normal release, enhanced confirmation, refreezing, blocking, and expiration, thereby clarifying the lifecycle of the time-series anchored object at the functional level. Simultaneously, by constraining the migration path of the anchored object in a state machine manner, compared to maintaining state judgments separately in multiple branches, the number of branches for state judgments can be reduced, the computational overhead of state judgments can be lowered, and invalid duplicate processing of objects in the final state can be reduced.

[0077] In some embodiments, the method may further include: writing the determined time deviation, stage interval, window occupancy, disposal signal, and state transition result into an audit log, and determining an audit summary based on the audit log, which is used to reconstruct the reason why the payment request was released, enhanced, or blocked. In this way, the basis for each time constraint judgment is recorded and solidified with a summary, thereby supporting the reconstruction of disposal reasons during dispute resolution and regulatory inquiries at the functional level. Simultaneously, since the disposal reasons can be reconstructed without relying on manual recall or log splicing, compared to retrieving and splicing from multiple scattered logs to reconstruct the disposal process, the number of queries and data reads during dispute review can be reduced, and the corresponding query load can be lowered.

[0078] By employing the above methods, payment requests can be time-constrained based on the occurrence times of multiple events associated with the agent before payment is accepted. This allows for the identification of abnormal situations such as old intentions driving new payments and insufficient timeliness of payment requests at the functional level without relying on manual review, and payment requests can be processed differently accordingly. Furthermore, since the judgment of the timeliness of payment requests is integrated into a unified machine judgment process on the payment side, compared to the current solution of recording timestamps on the client, agent, and payment sides and then manually verifying them afterward, it can reduce the number of rounds of time data interaction across systems, reduce end-to-end latency in payment acceptance decisions, and reduce the number of storage read / write operations and query load required for post-dispute review.

[0079] The implementation details of the above process 200 are further described below with reference to the accompanying drawings. In some examples, the above process 200 can be executed collaboratively by a timing acquisition module deployed on the client, the smart agent, and the payment gateway, a timing anchoring module deployed on the payment gateway, a window strategy module, a timing verification module, and a hierarchical processing module.

[0080] Regarding multi-terminal time point acquisition and trusted time normalization, the time series acquisition module collects the prompt generation time, context freeze time, and payment submission time at the client, agent, and payment gateway, respectively. The client records the prompt generation time when the user inputs a prompt or confirms the task intent, and simultaneously records the client's clock source, client clock sequence number, and the most recent time synchronization offset from the client to the gateway. If the client has a secure clock or trusted execution environment, the client's clock source is marked as a device secure clock; if only a normal system clock can be read, it is marked as a device untrusted clock. The agent 120 records the context freeze time and generates a context freeze summary when completing context trimming, task parameter archiving, and payment intent context freezing. This context freeze summary can be calculated by performing deterministic serialization on the context identifier, task identifier, payment constraint field, user prompt summary, and agent 120 runtime identity summary, and is used to prove that the context version corresponding to the payment request has not substantially changed after freezing. After receiving a payment request and completing the integrity verification of the request body, the payment gateway records the payment submission time and generates a gateway receiving sequence number. When the same payment request is retried multiple times, the gateway can record the first receiving time, the most recent receiving time, and the number of retryes separately to avoid retry traffic from overwriting the original submission time.

[0081] Regarding time point normalization, the time series acquisition module can convert three time points into a unified time representation. For example, each time point can be converted into a millisecond timestamp in a unified time zone, denoted as input time, context time, and payment time, respectively. For timestamps from the endpoint, correction can be performed based on the synchronization offset from the endpoint to the gateway to obtain normalized input and context times. The payment time, based on the payment gateway clock, does not require further endpoint offset correction. The time series acquisition module can also determine the time source trust level based on the time source type, most recent synchronization time, absolute offset value, and jitter. This trust level can include, for example, trusted, downgraded trusted, and untrustworthy. If any critical time point originates from an untrustworthy time source, a stricter window constraint strategy can be applied subsequently, or enhanced confirmation can be directly triggered.

[0082] Regarding the construction of time-series anchor objects and their binding to payment requests, the time-series anchoring module constructs these objects based on standardized time points and time source information. These anchor objects can be verifiable evidence objects bound to payment requests, task credentials, agent runtime identities, and context-freeze summaries. The time-series anchoring module performs deterministic serialization on all fields in the anchor object except the signature field, according to a preset field order, a unified time format, and null value filling rules. This results in a standardized anchor payload, ensuring that the same payment request generates the same summary under the same input, avoiding inconsistencies in subsequent signature verification due to differences in field order or serialization.

[0083] Subsequently, the timing anchoring module can calculate the anchoring summary, for example, using the following formula: It is equivalent to performing a cryptographic digest operation on the concatenation of the normalized anchored payload, payment request identifier, task credential identifier, agent runtime identity identifier, context freeze digest, and replay identifier.

[0084] The cryptographic digest operation can employ alternative digest algorithms; in some examples, the specific hash algorithm is not limited. Its function is to bind the time-based evidence, payment request, task credential, and context-freeze digest to the same verifiable object. After calculating the anchor digest, the payment gateway can use its private key to generate a signature on the anchor digest and initialize the state of the time-series anchor object to anchored. If the signature fails, it can return an exception indicating that the anchor object signature failed, preventing the payment request from proceeding to subsequent verification. The time-series anchoring module can also write the identifier of the time-series anchor object, the identifier of the payment request, and the replay identifier into a short-term deduplication index. If it is subsequently discovered that the identifier of the same time-series anchor object is bound to different payment requests, or that the same replay identifier appears repeatedly within its validity period, the replay risk handling branch is initiated.

[0085] Regarding window policy loading, snapshot locking, and parameter generation, the window policy module can load a window constraint policy based on at least one of the following: transaction risk level, time source trust level, payment amount, merchant category, and number of retries, and generate a policy snapshot for the current payment request. If the upstream does not provide a risk level, it can be processed according to the higher risk level. The window policy module can generate a time source coefficient based on the time source trust level: when the time source is trustworthy, the time source coefficient takes a more lenient value; when the time source is downgraded trustworthy, the window threshold is shortened; when the time source is untrustworthy, enhanced confirmation or direct blocking is triggered.

[0086] The window strategy module can determine thresholds for multiple window types in the following ways, for example: It equals the product of the base threshold for the corresponding stage and the time source coefficient, amount risk coefficient, and merchant category risk coefficient. The thresholds for each stage correspond to the maximum allowed window from the prompt to the context freeze, the maximum allowed window from the context freeze to payment submission, and the maximum allowed window across the entire process; each coefficient can be configured by the platform strategy, rather than being hardcoded as a fixed value.

[0087] The window policy module can also encapsulate the policy version, base threshold, coefficient, effective time, action, retry budget, and enhanced confirmation threshold used in this instance into a policy snapshot, and calculate a policy snapshot summary. This summary can be written to a time-series anchor object, enabling subsequent audits to restore the window policy used at that time and avoid the impact of post-event policy changes on dispute resolution. If the policy configuration is missing, the policy version is outdated, or the policy snapshot cannot be generated, the window policy module can return an exception indicating that the window policy is unavailable. The tiered handling module can then output either a blocking or enhanced confirmation according to a conservative policy.

[0088] Regarding clock skew and time source reliability verification, the timing verification module first verifies the comparability of cross-system timestamps before comparing multiple time points. The timing verification module can calculate the maximum clock skew of key time sources relative to the gateway benchmark. For example, take the maximum value of the absolute values ​​of the offsets of each time source relative to the gateway, where the offset of the payment gateway's local clock is usually zero.

[0089] If the maximum clock skew exceeds the skew limit in the policy snapshot, a clock skew exceeding the limit exception can be returned; if the time source is unreliable and no recent synchronization record can be provided, a time source unreliable exception can be returned. If the skew does not exceed the limit, the timing verification module can generate a skew tolerance value for subsequent sequential and window calculations. For example, take the smaller value between the maximum clock deviation and the upper limit of deviation, and write the relevant result into the intermediate verification record.

[0090] Regarding time sequence verification and context freeze validity verification, the time sequence verification module can check whether multiple time points meet the causal order required for payment execution based on the deviation tolerance value. For example, it checks whether the normalized input time is no later than the normalized context time and the normalized context time is no later than the normalized payment time under the tolerance deviation. If these conditions are not met, a time sequence error exception can be returned, indicating the risk that the context freeze occurred before the prompt was generated, the payment was submitted before the context freeze, or the timestamp was tampered with. The time sequence verification module can also read the context digest carried in the payment request and compare it with the context freeze digest in the time sequence anchor object. If they do not match, a context digest inconsistency exception can be returned. If the agent changes the task parameters, amount, merchant, payee, or payment purpose fields after the context freeze, and the change does not generate a new context freeze digest, an exception indicating that the context has been modified after freezing can be returned. Time sequence anomalies, digest inconsistencies, or modifications after freezing can all be treated as high-risk anomalies, which will be blocked by default by the tiered handling module and written into the corresponding audit event.

[0091] Regarding window interval calculation, normalized occupancy, and window severity determination, the timing verification module can calculate the time interval for each stage after sequential verification passes. For example, it can calculate the interval from the prompt message to the context freeze, the interval from the context freeze to payment submission, and the total interval across the entire chain. To avoid false rejections caused by small-range clock deviations, the timing verification module can subtract the deviation tolerance value from each stage interval and take the non-negative value to obtain the corrected window interval. Subsequently, the timing verification module can calculate the window occupancy for each stage and take the maximum value. As the severity of the window.

[0092] when A severity level of 1 or less indicates that all windows are within the allowed range; a severity level greater than 1 indicates that at least one stage has exceeded the window limit. The window strategy can set enhanced confirmation thresholds and blocking thresholds. The timing verification module can generate window judgment results according to the following rules: when the window severity level is not greater than 1, it is judged as passable; when the window severity level is not greater than the enhanced confirmation threshold, it is judged as requiring enhanced confirmation; when the window severity level is not greater than the blocking threshold and the retry budget is greater than zero, it is judged as refreezing the context; otherwise, it is judged as blocking. Here, the retry budget represents the maximum number of times the same payment request is allowed to refreeze the context or resubmit. The timing verification module can also generate corresponding window reason codes based on the stage with the highest occupancy, and when multiple windows exceed the limit simultaneously, output the main reason code according to risk priority and retain all exceeding items in the audit record.

[0093] Regarding tiered handling and state transition, the tiered handling module can output handling signals based on the above verification results and policy snapshots, and update the state of the time-series anchored object. If the clock deviation, time sequence, context digest, and window interval all pass verification, the state of the time-series anchored object can be updated to verified, a release signal can be output, and the payment request can proceed to the subsequent payment decision or execution token generation process. If the window is slightly exceeded and the policy allows for enhanced confirmation, the state can be updated to require enhanced confirmation, and an enhanced confirmation signal can be output. After the client completes confirmation such as biometrics, password, FIDO2 authentication, or SMS verification code, the system can generate a new confirmation time point and recalculate the relevant stage intervals. If the main reason for exceeding the window limit is that the context freeze to the payment submission stage exceeds the limit and the retry budget is not exhausted, the state can be updated to refreeze the context, requiring the agent to refreeze the context based on the current user task and generate a new context freeze digest. The old time-series anchored object is marked as replaced and cannot continue to be used for payment execution. If the clock is unreliable, the time sequence is reversed, the context digest is inconsistent, replay hit occurs, there is a severe window exceedance, or the retry budget is exhausted, the state can be updated to blocked, and a blocking signal can be output. If the total interval of the entire link exceeds the absolute expiration threshold of the entire link in the policy, the status can be updated to expired, an expiration signal can be output, and a request to re-initiate task confirmation or regenerate payment request can be required.

[0094] As an example, the state transitions of a time-series anchored object can include: normal paths such as created, anchored, policy locked, verified, executed, and audited; enhanced confirmation paths such as policy locked, enhanced confirmation required, and verified; refreeze paths such as policy locked, refreeze context, and superseded; blocking paths such as policy locked and blocked; and expired paths such as policy locked and expired.

[0095] In terms of audit event generation and evidence chain writing, the tiered handling module can write each time-series verification process into the audit record, forming a traceable evidence chain. The audit record can include at least one of the following: audit event identifier, time-series anchor object identifier, payment request identifier, task credential identifier, agent runtime identity identifier, anchor summary, policy snapshot summary, time source trust level, maximum clock deviation, deviation tolerance value, interval between each stage, window occupancy at each stage, window exceedance severity, window judgment result, handling signal, reason code, anchor object status before and after verification, and creation time. The audit module can perform deterministic serialization on the audit record and calculate the audit summary. The audit summary, along with the anchor summary and policy snapshot summary, can be written into the evidence storage service to prove the consistency between verification inputs, policy versions, and handling results. When users, merchants, regulators, or platform risk control systems need to query disputed transactions, they can recover the original time point, window policy, calculation inputs and outputs, and handling signals based on the payment request identifier, time-series anchor object identifier, task credential identifier, and agent runtime identity identifier. If the evidence storage service is unavailable, the system must not silently allow the transaction: for high-risk transactions, a blocking message can be output; for medium- and low-risk transactions, an enhanced confirmation message can be output and the audit record can be written to the local compensation queue. The transaction must not be marked as final approval until the compensation is successful.

[0096] In addition, the system can also include exception branching and concurrent retry control. For example, if a window policy does not exist, the policy version is invalid, or the policy snapshot digest generation fails, an exception indicating that the window policy is unavailable can be output, and the system can block or enhance the confirmation according to a conservative policy. If signature verification fails, the anchor digest does not match the anchor object, or the context digest is inconsistent with the payment request, an exception indicating that the anchor object integrity fails or the context digest is inconsistent can be output, and the system can block the request. If the same time-series anchor object identifier, replay identifier, or anchor digest is used in different payment requests, or if the same anchor object is resubmitted after being executed, blocked, expired, or replaced, an exception indicating that the anchor object is replayed can be output, and the system can block the request. If multiple retry requests carry the same payment request identifier, the payment gateway can select the request with the smallest gateway-received sequence number that has not expired as the valid candidate, and mark the remaining requests as duplicate retry and ignore them. If audit or evidence storage is unavailable, the system can choose conservative handling according to the risk level.

[0097] In some examples, the fields of a time-series anchor object may be as shown in the table below. The table below illustrates the fields included in a time-series anchor object and their uses, corresponding to the features described above that bind multiple occurrence times, clock sources, clock offsets, and identifiers and context freeze summaries associated with payment requests as verifiable evidence objects.

[0098]

[0099] In some examples, the fields of a window constraint policy may be as shown in the table below. The table below illustrates the fields included in a window constraint policy and their uses, corresponding to the features described above that load a window constraint policy and generate a policy snapshot based on at least one of risk level, time source trust level, payment amount, and merchant category.

[0100]

[0101] In some examples, the exception codes that may be output during the timing verification process, their triggering conditions, and suggested handling methods are shown in the table below. The table illustrates the handling methods under different exception scenarios, corresponding to the aforementioned features of processing payment requests as blocking or enhanced confirmation.

[0102]

[0103] In some examples, the fields for a timing audit event may be as shown in the table below. The table below illustrates the fields included in the audit record and their uses, corresponding to the characteristics described above for writing time skew, stage intervals, window occupancy, action signals, and state transition results into the audit record and determining the audit summary.

[0104]

[0105] As an example, after a user enters a prompt to trigger payment at a certain moment, the client records the prompt generation time. The agent then freezes the context and generates a context freeze summary shortly thereafter. The payment side receives the payment request shortly thereafter and records the payment submission time. The payment side generates a time-series anchor object, locks the policy snapshot for the corresponding risk level, calculates the interval between each stage, and, provided the window severity is no greater than one, transitions the anchor object's state from "policy locked" to "verified," outputting a release signal.

[0106] As another example, after the user enters a prompt, the payment request arrives late after the context freezes, with a window severity greater than one but not exceeding the enhanced confirmation threshold. The tiered handling module updates the anchored object status to require enhanced confirmation, requiring the client to perform FIDO2 authentication or biometric confirmation; after confirmation, a new confirmation time point is generated and re-verified, and a release signal is output after successful verification.

[0107] As another example, if the main reason for the window overflow is that the context freeze to the payment submission stage exceeds the limit and the retry budget is not exhausted, the system outputs a signal to refreeze the context, requiring the agent to refreeze the context and generate a new context freeze summary. The old time-anchored object is marked as replaced and can no longer be used for payment execution.

[0108] As another example, if the same time-series anchor object identifier or replay identifier is used in different payment requests, the time-series anchoring module hits the deduplication index, outputs an exception for anchor object replay, the hierarchical handling module updates the anchor object status to blocked, and writes the replay event to the audit log.

[0109] Figure 3 An interactive timing diagram for timing acquisition and verification of payments, according to some embodiments, is shown. Figure 3 The interaction shown can be generated by Figure 1 The payment gateway 110 and the smart agent 120 shown are provided.

[0110] like Figure 3 As shown, the client records the prompt generation time when the user inputs information and submits the task prompt or payment intention to the agent. The agent trims the task context, freezes the context, generates a context freeze summary, records the context freeze time, and then submits a payment request to the payment gateway. This payment request can carry the context freeze summary, task credential identifier, and agent runtime identity identifier. Upon receiving the payment request, the payment gateway records the payment submission time, generates a timing anchor object, calculates and signs the anchor summary, requests the window constraint policy to be loaded from the window policy module, receives the returned window threshold, risk coefficient, and handling policy, generates a policy snapshot summary, and submits the timing anchor object and policy snapshot to the timing verification module. The timing verification module sequentially verifies the clock deviation, time sequence, and context freeze summary, and calculates the window occupancy at each stage. Upon successful verification, the payment gateway outputs a release signal, allowing the payment decision or execution to proceed. In the event of a minor window exceeding the limit, the payment gateway outputs an enhanced confirmation signal, requiring the client to provide enhanced confirmation. If the context to payment stage exceeds the limit and retry is allowed, the payment gateway outputs a signal to refreeze the context, requiring the agent to refreeze the context. In the event of a severe anomaly, the payment gateway outputs a blocking or expiration signal and rejects the payment request. Finally, the audit evidence storage module writes audit information such as anchor summary, policy snapshot summary, window exceeding severity, and handling signals.

[0111] It should be understood that the above interaction sequence is described for illustrative purposes only and does not imply any limitation on the scope of the scheme.

[0112] A corresponding apparatus for implementing the above methods or processes is also provided.

[0113] Figure 4A block diagram of an example process 400 for payment according to some embodiments is shown. Example process 400 may involve a payment gateway 110 and an agent 120.

[0114] In process 400, in box 402, multiple time points are collected, including user input time, context freeze time, and payment submission time. In box 404, time normalization processing is performed, such as unifying the time zone, unifying the format, and calculating the time source offset. In box 406, a time-series anchoring object is constructed. In box 408, a context digest is bound. In box 411, an anchoring digest is generated, and in box 412, a clock skew check is performed. In box 414, it is checked whether the clock skew is allowed; if allowed, an exception is output in box 428. If not allowed, a window strategy is loaded in box 416, and a time sequence check is performed in box 418. In box 421, it is verified whether the causal order is valid; if invalid, an exception is output in box 431. If valid, the window occupancy is calculated in box 422. After determining whether the window constraint is exceeded in box 422, a hierarchical decision output is output in box 426, and a state machine update is performed in box 432. Finally, in box 434, audit digest generation and evidence generation are performed and written into the audit chain.

[0115] Figure 5 A timing diagram of an example interaction process 300 for verifying a payment request, according to some embodiments, is shown. The interaction process 300 may involve a payment gateway 110, an agent 120, a client 510, a window strategy module 520, a timing verification module 530, and an audit and evidence storage module 540. References are provided below. Figure 5 To describe the interaction process 500.

[0116] like Figure 5 As shown, client 510 can record (502) the prompt generation time and send (404) the task prompt or payment intent to agent 110. After receiving the task prompt or payment intent, agent 110 trims (506) the context. Agent 110 freezes (508) the context and generates a context freeze summary, and records (511) the context freeze time. Then agent 110 submits (512) a payment request to payment gateway 120, which carries the context freeze summary, the payment authorization object, and the agent's runtime identity.

[0117] In process 500, after receiving a payment request, the payment gateway 120 records (514) the payment submission time and generates (516) a timing anchor object. The payment gateway 120 calculates (518) the anchor object digest and signs it. The payment gateway 120 sends (521) a request to load a window policy to the window policy module 520. After receiving the request, the window policy module 520 sends (522) a handling policy to the payment gateway 120. After receiving the handling policy, the payment gateway 120 can generate (524) a policy snapshot digest and send the anchor object and policy snapshot to the (526) timing verification module 530.

[0118] In process 500, after receiving the anchored object and policy snapshot, the timing verification module 530 verifies (528) the clock skew, (531) the time sequence, and (532) the context freeze summary. The timing verification module 530 calculates (534) the window occupancy.

[0119] In some embodiments, if the payment request passes verification, the timing verification module 530 sends (536) "Execute" to the payment gateway 120, and the payment gateway 120 sends (538) "Allow" to the agent 110 to proceed to payment decision or execution. In some embodiments, if the payment request slightly exceeds the window limit, the timing verification module 530 sends (541) "STEP_UP" to the payment gateway, and the payment gateway 120 requests (542) "Enhanced Confirmation" from the agent 110. In some embodiments, if the payment request context exceeds the payment window limit and retry is allowed, the timing verification module 530 sends (544) "Retry Context Freeze" to the payment gateway 120, and the payment gateway 120 requests (538) "Refreeze Context" from the agent 110. In some embodiments, if the payment request is severely abnormal, the timing verification module 530 sends (548) "Block" to the payment gateway 120, and the payment gateway 120 sends (551) "Reject Payment Request" to the agent 110. Furthermore, the payment gateway 120 can write (552) the timing verification process to the audit and evidence storage module.

[0120] Figure 6 A block diagram of an electronic device 600 in which one or more examples may be implemented is shown. It should be understood that... Figure 6 The electronic device 600 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 6 The electronic device 600 shown can be used to implement the payment gateway 110 as discussed above.

[0121] like Figure 6As shown, electronic device 600 is in the form of a general-purpose electronic device. Components of electronic device 600 may include, but are not limited to, one or more processing units or processors 610, memory 620, storage device 630, one or more communication units 640, one or more input devices 650, and one or more output devices 660. Processor 610 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 620. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 600.

[0122] Electronic device 600 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 600, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 620 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof). Storage device 630 can be removable or non-removable media and may include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 600.

[0123] Electronic device 600 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 6 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 620 may include computer program product 625 having one or more program modules configured to perform various methods or actions of various examples.

[0124] The communication unit 640 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 600 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 600 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.

[0125] Input device 650 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 660 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 600 can also communicate with one or more external devices (not shown) via communication unit 640 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 600, or with any device that enables electronic device 600 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interfaces (not shown).

[0126] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0127] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0128] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0129] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0130] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0131] Various examples have been described above. The foregoing descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for making a payment, comprising: In response to receiving a payment request from an intelligent agent, time information associated with the payment request is obtained, the time information including multiple occurrence times of multiple events corresponding to the payment request, the multiple events being associated with the intelligent agent; Based on the multiple occurrence times, determine whether the payment request meets the time constraint; as well as Based on the determination, the payment request is processed.

2. The method according to claim 1, wherein the plurality of events includes a first event, the first occurrence time of the first event being the time when user input is received, and the user input triggers the payment request.

3. The method of claim 1, wherein the plurality of events includes a second event, the second occurrence time of which is the time when the context associated with the payment request is frozen.

4. The method according to claim 1, wherein the plurality of events includes a third event, and the third occurrence time of the third event is the time when the payment request is submitted.

5. The method according to claims 2 to 4, wherein determining whether the payment request satisfies the time constraint further includes: Based on the normalized times corresponding to the first event, the second event, and the third event, it is verified that the first event precedes the second event and the second event precedes the third event. as well as In response to the failure of verification, the payment request is blocked.

6. The method according to claims 1 to 4, wherein obtaining the time information further includes: Obtain the first clock source and first clock offset associated with the first event, and the second clock source and second clock offset associated with the second event. The reliability level of the time source is determined based on the first clock source and the second clock source, and the plurality of occurrence times are converted into normalized time relative to the payment side benchmark based on the first clock offset and the second clock offset.

7. The method of claim 1, further comprising: The multiple occurrence times, the first clock source, the second clock source, the first clock deviation, and the second clock deviation are bound to a time-series anchor object, which is used to verify whether the payment request meets the time constraint.

8. The method of claim 7, wherein the time-series anchoring object is associated with an anchor digest and a signature, the anchor digest is determined based on the normalized fields of the time-series anchoring object, the identifier of the payment request, and a context-freeze digest, and the signature is generated based on the payment-side private key of the anchor digest.

9. The method of claim 7, further comprising: Write the identifier of the time-series anchored object, the identifier of the payment request, and the replay identifier into the deduplication index; as well as In response to the identification of the same time-anchored object being associated with different payment requests, or the same replay identification appearing repeatedly within the validity period, the payment request is processed as blocked.

10. The method of claim 9, wherein in response to the maximum clock deviation being less than or equal to the deviation upper limit, a deviation tolerance value is determined based on the maximum clock deviation and the deviation upper limit, and the time constraint is determined based on the deviation tolerance value.

11. The method of claim 7, wherein determining whether the payment request satisfies the time constraint further comprises: Compare the context digest carried in the payment request with the context freeze digest in the time-anchored object; as well as In response to the context digest being different from the context freeze digest, the payment request is processed as blocked.

12. The method of claim 1, wherein determining whether the payment request satisfies the time constraint further comprises: The maximum clock deviation is determined based on the offset of the multiple events relative to the payment-side benchmark; as well as In response to the maximum clock deviation being greater than the deviation limit, the payment request is processed as a blocking or enhanced confirmation.

13. The method of claim 1, wherein determining whether the payment request satisfies the time constraint further comprises: Based on at least one of the risk level, the time source trust level, the payment amount, and the merchant category, a window constraint policy is loaded, a policy snapshot is generated according to the loaded window constraint policy, and the time constraint is determined based on the policy snapshot.

14. The method of claim 13, wherein determining whether the payment request satisfies the time constraint further comprises: Based on the ratio of the stage interval between the multiple occurrence times to the corresponding stage threshold in the policy snapshot, the window occupancy of multiple stages is determined, and the maximum value among the window occupancy of multiple stages is determined as the window severity.

15. The method of claim 14, wherein processing the payment request comprises: If the severity of the window does not exceed the first threshold, the payment request will be allowed. In response to the window severity exceeding the first threshold but not exceeding the second threshold, the payment request is processed as an enhanced confirmation; and In response to the window severity exceeding the second threshold, the payment request is processed as blocked.

16. The method of claim 15, wherein processing the payment request further comprises: In response to the main phase of the window, which is when the context is frozen until the payment is submitted and the retry budget is not exhausted, the payment request is processed as a refreeze of the context, and the timing anchor object associated with the payment request is set to a superseded state.

17. The method of claim 1, wherein processing the payment request comprises: Based on the determination, the time-series anchored object associated with the payment request is migrated between multiple states, including at least two of the following: anchored, policy locked, verified, executed, blocked, expired, and replaced.

18. The method according to claim 1, further comprising: The time deviation, stage interval, window occupancy, processing signal and state transition result used in the determination are written into the audit record, and an audit summary is determined based on the audit record. The audit summary is used to reconstruct the reasons why the payment request was released, enhanced, or blocked.

19. A device for making payments, comprising: The acquisition module is configured to, in response to receiving a payment request from an intelligent agent, acquire time information associated with the payment request, the time information including multiple occurrence times of multiple events corresponding to the payment request, the multiple events being associated with the intelligent agent; The constraint module is configured to determine whether the payment request meets the time constraint based on the multiple occurrence times; as well as The processing module is configured to process the payment request based on the determination.

20. An electronic device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 18 when executed by the at least one processing unit.

21. A computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the method according to any one of claims 1 to 18.

22. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 18.

Images