A payment permission management method and system for multiple payment channels

Abstract

The application relates to a payment authority management method and system of multiple payment channels, which receives a payment request for a medicine transaction order and determines a candidate channel set, determines a target payment channel from the candidate channel set, respectively performs reduction according to an observation age period corresponding to each time window basis quantity, issues a payment authorization token binding the medicine transaction order and the target payment channel according to the minimum value in each reduced time window basis quantity, the effective time window of the payment authorization token is calculated from the token issuance time and the time obtained by adding the minimum value to the token issuance time as the upper limit, the current time is checked to fall within the effective time window before initiating channel payment, and the payment is released after the check is passed. The application makes the payment authority determination accommodate the decay of the authorization basis with time and the time span of the payment execution period before the payment execution, and has the advantage of reducing the risk of cross-period payment overreach.

Description

Technical Field

[0001] This application relates to the technical field of electronic payment, and in particular to a method and system for managing payment permissions across multiple payment channels. Background Technology

[0002] Online pharmaceutical transactions typically require settlement across multiple payment channels, such as instant third-party payments, quick payments via designated bank cards, and corporate transfers. Unlike general consumer payments, pharmaceutical transactions are subject to restrictions on business qualifications and transaction entity registration. Only payment requests initiated by counterparties with the corresponding business qualifications and included in the transaction platform's whitelist are permitted to be released. Therefore, before releasing each payment, the payment platform needs to determine whether it has the authority to release the payment based on the counterparty's business qualifications and registration status, as well as the payment capacity of the selected payment channel.

[0003] The business qualifications and whitelist entries of the counterparty each have their own expiration dates. Business qualifications become invalid due to license expiration or revocation, and whitelist entries also lose their validity as the filing period expires. Meanwhile, the payment channel's own payment capabilities, such as the timeliness of a single payment, vary at different times. Once a payment is sent to the channel, funds flow out, and most payment channels do not support the withdrawal of the transaction after acceptance. Once funds have been transferred, the platform lacks the technical means to recover them. Therefore, the determination of payment authority must be completed before the payment is actually executed, and it needs to cover the changes in the timeliness of the aforementioned criteria during the payment execution process.

[0004] Existing payment authorization management solutions fall into two categories: one allows the authorizing party or user to set the authorization window directly at the time of issuance, with the length of the authorization window not adjusting according to the age of the qualification and channel capability data used as the basis; the other treats the selection of payment channels as a single attribute matching at the time of payment initiation, comparing the static attributes of the channel with the payment request item by item to select an available payment channel, without distinguishing between the time of this determination and the time of the final completion of the payment. Since the expiration of the qualifications and registrations upon which payment authorization is based is a time-limited event that does not actively reach the platform, signals of license revocation or registration expiration are not synchronized to the platform's data copy in real time. Furthermore, a payment spans multiple moments—initiation, channel acceptance, and callback confirmation—the validity of authorization at the determination moment does not guarantee the validity of authorization at the completion moment. Moreover, since an irreversible flow of funds occurs once a payment is issued, even if an audit discovers unauthorized actions, the revocation channel relied upon for recovering funds is unavailable on most channels, and the remedial channel has already failed by the time it is truly needed. In this way, the timeliness of the authorization basis and the irreversibility of payment execution are misaligned on the timeline, making it difficult for existing solutions to provide a release criterion that both accommodates the decay of the authorization basis over time and covers the time span of the payment execution period before payment execution. Summary of the Invention

[0005] In order to provide a release criterion that both accommodates the decay of authorization over time and covers the time span of payment execution before payment is executed, and to overcome the misalignment between the timeliness of authorization and the irreversibility of payment execution on the timeline, this application provides a payment permission management method and system for multiple payment channels.

[0006] Firstly, this application provides a method for managing payment permissions across multiple payment channels, employing the following technical solution: A method for managing payment permissions across multiple payment channels includes the following steps: S1. Receive a payment request for a drug transaction order, extract the identifier of the counterparty from the payment request, and determine a set of candidate channels; S2. Determine the target payment channel from the candidate channel set, and reduce each time window basis quantity according to the observation age corresponding to each time window basis quantity to obtain the reduced time window basis quantity. The time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero. S3. Execute token issuance based on the minimum value among the reduced time windows to obtain a payment authorization token that binds the drug transaction order and the target payment channel. The effective time window of the payment authorization token starts from the execution time of token issuance, and the upper bound of the effective time window is the execution time plus the minimum value. S4. Before initiating channel payment, verify that the current time falls within the valid time window, and after the verification is successful, execute the channel payment initiation to allow the payment. The channel payment initiation is to issue a channel payment instruction to the target payment channel.

[0007] By adopting the above technical solution, the time-lapse of the authorization basis itself is incorporated into the time window basis quantity by reducing the observation age. Then, the upper limit of the effective time window of the payment authorization token is determined according to the minimum value of each time window basis quantity after reduction. This allows a single release criterion to simultaneously accommodate the time-lapse changes of compliance qualifications and payment capabilities during the payment execution process. The effective time window of the token is calculated from the time of issuance, and whether the current time falls within the time window is used as an admission condition before the channel payment is initiated. This ensures that the initiation of payment is constrained to the interval within which none of the bases have reached their reduced and confirmed existence boundary. Thus, before the irreversible action of payment is actually executed, the situation where the bases have become inaccurate due to time-lapse is reduced but are still used for release is reduced.

[0008] Optionally, the compliance qualifications include the whitelist entries of the counterparty in the filing whitelist and the business qualifications of the counterparty. The payment capabilities include the single payment timeliness of the target payment channel. In step S1, a compliance payment strategy is matched based on the compliance dimension group composed of the counterparty's customer type and the drug compliance category of the transaction target. The compliance payment strategy outputs a capability demand vector. The capability demand vector is compared with the capability supply vector pre-registered by each payment channel in a dimension-by-dimensional coverage manner. The payment channels with dimension-by-dimensional coverage as the comparison result are included in the candidate channel set.

[0009] By adopting the above technical solution, the candidate channel set is narrowed by comparing the capability demand vector output by the compliant payment strategy with the capability supply vector pre-registered by each payment channel in a dimension-by-dimensional manner. This makes channel selection independent of hard-coded mapping of specific channels, and the increase or decrease of compliance constraints is only reflected in the adjustment of vector dimensions.

[0010] Optionally, after step S4, the following qualification timeliness observation operations are performed sequentially on the channel receipts returned by each payment channel: The entity status type receipt code is selected from the channel receipts. The entity status type receipt code is the receipt code returned by the payment channel when the account status, real name information and business qualification of the counterparty fail to pass the verification. The ratio of the number of occurrences of the subject status type receipt code within the set observation window to the number of normal acceptances of the counterparty within the same set observation window is used as the qualification doubt ratio. The number of normal acceptances is the number of payment transactions in the set observation window in which the payment channel returns a successful acceptance receipt to the counterparty. The qualification doubt ratio is calculated one by one for each payment channel whose number of normal acceptances is greater than zero. Payment channels whose qualification doubt ratio reaches a preset doubt threshold are included in the doubt channel set. Payment channels whose normal acceptance count is zero and whose main entity status type receipt code occurrence count reaches a preset minimum occurrence count threshold are also included in the doubt channel set. The whitelist entries are then processed according to the number of payment channels in the doubt channel set. The status processing includes setting the whitelist entries to a pending review state and maintaining the whitelist entries in a normal state.

[0011] By adopting the above technical solution, the entity status receipt code returned when the payment channel verification fails is used as a bypass signal for qualification failure. The whitelist entry status is written back based on its proportion in the accepted samples, so that qualification failure that does not actively reach the platform side can be indirectly perceived through the byproducts of the payment link.

[0012] Optionally, in the qualification validity observation operation, the following positive renewal operation is also performed sequentially for zero hits of the subject status type receipt code: The number of normal transactions accepted by the counterparty on each payment channel within the set observation window is counted, and the payment channel whose number of normal transactions reaches the preset acceptance threshold is included in the independent verification channel set. In response to the fact that the set of independent verification channels includes multiple independent payment channels and the number of occurrences of the entity status type receipt code of the counterparty within the set observation window is zero, the observation corresponding to the zero hit is determined as the renewal verification of the expiration time of the business qualification. The observation age corresponding to the expiration time of the business qualification is recalculated from the time of the renewal verification. The multiple independent payment channels are multiple payment channels belonging to different operating entities.

[0013] By adopting the above technical solution, the situation where multiple independent channels continuously and normally accept the same counterparty and have zero entity status receipt codes is identified as a renewal verification at the time of expiration of the business qualification, so that the validity of the qualification can be refreshed by relying on the independent acceptance results of the channel side when there is a lack of proactive signals from the platform side.

[0014] Optionally, the status handling is divided according to the number of payment channels in the set of questionable channels: In response to the set of suspicious channels being empty, the whitelist entries are maintained in the normal state. In response to the fact that the suspicious channel set contains only a single payment channel, it is determined that the payment channel in the suspicious channel set has a verification abnormality, the whitelist entry is kept in the normal state, and the payment channel in the suspicious channel set is removed from the candidate channel set of the counterparty within the set isolation time. In response to the fact that the set of questionable channels includes multiple payment channels, if it is determined that the business qualification of the counterparty has expired, the whitelist entry is set to the pending review status.

[0015] By adopting the above technical solution, the status of whitelist entries is handled separately according to the number of channels in the set of questionable channels. This distinguishes between verification anomalies of a single channel and the genuine invalidation of the counterparty's qualifications, and avoids mistakenly setting whitelist entries to a pending review status due to occasional anomalies of individual channels.

[0016] Optionally, in step S1, based on the remaining validity period of the whitelist entry at the execution time of S1 and the status of the whitelist entry at the execution time of S1, one of the parallel execution channel sets is selected for contraction from S1a, S1b, and S1c, wherein the remaining validity period of the whitelist entry is the difference between the expiration time of the whitelist entry and the execution time of S1: S1a. In response to the whitelist entry being in the normal state and the remaining validity period of the whitelist entry being longer than a preset shrinkage threshold, maintain the candidate channel set; S1b. In response to the whitelist entry being in the normal state and the remaining validity period of the whitelist entry falling within the preset shrinkage threshold, the payment channel with a single payment timeout longer than the remaining validity period of the whitelist entry is removed from the candidate channel set; S1c. In response to the whitelist entry being in the pending review state, the candidate channel set is narrowed down to payment channels whose single payment time falls within the preset review period window.

[0017] By adopting the above technical solution, the candidate channel set is narrowed down according to the remaining validity period and status of the whitelist entries at the time of execution. This allows channels with a single payment timeout longer than the remaining validity period to be removed when they are close to the expiration date, reducing the in-transit window caused by the channel completion time exceeding the expiration date.

[0018] Optionally, the capability supply vector of each payment channel further includes an irreversible point duration dimension and a revocation link delay dimension. The irreversible point duration dimension represents the time from when the payment is initiated by the channel to when the payment enters an irreversible state. The revocation link delay dimension represents the time from when a revocation instruction is issued to the payment channel to when the payment channel completes the revocation. S4 sequentially includes the following sub-steps: S41. The irreversible point time of this payment is obtained by adding the irreversible point duration dimension of the target payment channel to the channel payment initiation scheduled time. The channel payment initiation scheduled time is the execution time of S41. The latest revocable time is obtained by subtracting the cancellation link delay dimension of the target payment channel from the irreversible point time. S42. Compare the cancellation link delay dimension and the irreversible point duration dimension of the target payment channel. If the cancellation link delay dimension is shorter than the irreversible point duration dimension, determine the compliance review of this payment as a post-review. If the cancellation link delay dimension is not shorter than the irreversible point duration dimension, determine the compliance review of this payment as a pre-review. S43. Before the channel payment is initiated, the pre-review is performed. In the pre-review, if the earliest of the expiration times of the counterparty is earlier than the irreversible point time, it is determined to be non-compliant and the payment is blocked. S44. Compare the irreversible point time with the upper bound of the effective time window. If the irreversible point time is not earlier than the upper bound of the effective time window, intercept the payment and return the alternative channel set to the initiator. If the irreversible point time is earlier than the upper bound of the effective time window, allow the payment. The alternative channel set is a set of payment channels in the candidate channel set whose candidate irreversible point times are earlier than the upper bound of the effective time window. The candidate irreversible point time of each payment channel in the candidate channel set is the time obtained by adding the irreversible point duration dimension of each payment channel to the predetermined time of payment initiation. Following S4, the following post-review operation is performed on the payment for which compliance review is determined to be post-review: the post-review is performed no later than the latest revocable time in accordance with the determination method of the pre-review, and if the post-review is determined to be non-compliant, the revocation is initiated to the target payment channel no later than the latest revocable time.

[0019] By adopting the above technical solution, the comparison between the irreversible point and the upper limit of the effective time window is used as the admission criterion, and the compliance review is scheduled after acceptance and before the irreversible point by comparing the cancellation link delay dimension and the irreversible point duration dimension, so that the irreversible window can obtain the opportunity for review and cancellation during the period when it can still be cancelled.

[0020] Optionally, in step S3, the compliance qualification or payment capability corresponding to the minimum value of the reduced time window basis quantity among each of the reduced time window basis quantities is also determined as a tight constraint source, and the identifier of the tight constraint source is bound to the payment authorization token. In response to two or more reduced time window basis quantities simultaneously reaching the minimum value, the tight constraint source is determined according to a preset order in which the compliance qualification takes precedence over the payment capability.

[0021] By adopting the above technical solution, the reduced window that takes the minimum value is determined as the source of tight constraint based on the compliance qualification or payment ability corresponding to the quantity and bound to the payment authorization token, so that the subsequent handling of token expiration and window-crossing transactions can take different paths according to the source of constraint.

[0022] Optionally, after step S4, the following windowing aggregation and distribution operations are also performed on the payment result callback returned by the target payment channel: The arrival time of the payment result callback is compared with the upper bound of the effective time window. If the arrival time of the payment result callback is later than the upper bound of the effective time window and the payment result callback indicates that the payment has been completed, the payment is registered as a window-crossing transaction record carrying the identifier of the tight constraint source and sent to the window-crossing reconciliation queue. In response to the fact that the tight constraint source carried by the over-the-window transaction record is the payment capability, and the expiration time corresponding to the single payment validity period is later than the arrival time of the payment result callback, the over-the-window transaction record is determined to be a compliant transaction and transferred to the automatic posting channel. In response to the fact that the tight constraint source carried by the over-the-window transaction record is the payment capability, and the expiration time corresponding to the single payment validity period is not later than the arrival time of the payment result callback, the over-the-window transaction record is transferred to the manual compliance supplementary registration channel. In response to the fact that the tight constraint source carried by the window-over transaction record is the compliance qualification, the window-over transaction record is transferred to the manual compliance supplementation channel.

[0023] By adopting the above technical solution, callbacks that have been paid for but whose arrival time is later than the upper limit of the effective time window are registered as out-of-window transactions and diverted according to the tight constraint source category. This allows out-of-window transactions that occur due to the expiration of the execution period to be automatically recorded or manually and compliantly supplemented according to their constraint source.

[0024] Secondly, the payment authorization management system for multiple payment channels provided in this application adopts the following technical solution: A payment authorization management system for multiple payment channels includes: The access request module is configured to receive payment requests for drug transaction orders, extract the identifier of the counterparty from the payment request, and determine a set of candidate channels. The token issuance module, which is communicatively connected to the request access module, is configured to determine the target payment channel from the candidate channel set, perform reduction according to the observation age corresponding to each time window basis quantity to obtain each reduced time window basis quantity, and execute token issuance according to the minimum value among the reduced time window basis quantities. The resulting payment authorization token is bound to the drug transaction order and the target payment channel. The effective time window of the payment authorization token is calculated from the execution time of the token issuance and the time obtained by adding the minimum value to the execution time is the upper bound. The time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero. The time window verification module is communicatively connected to the token issuance module. It is configured to verify that the current time falls within the valid time window before executing the channel payment initiation, and to execute the channel payment initiation after the verification is passed. The channel payment initiation is to issue a channel payment instruction to the target payment channel.

[0025] By adopting the above technical solution, the system uses a request access module, a token issuance module, and a time window verification module to carry out the construction and verification of the above release criteria, and completes the unified processing of the authorization basis time decay and execution period before the channel payment is initiated.

[0026] Optionally, the system further includes a quota control module communicatively connected to the token issuance module. The token issuance module is further configured to determine the compliance qualification or payment capability corresponding to the minimum value of the discounted time window basis quantity among the discounted time window basis quantities as a tight constraint source and bind it to the payment authorization token. The quota control module is configured to pre-allocate the payment amount of this payment from the available payment quota of the counterparty at the same time as the token is issued. In response to the completion of this payment within the effective time window, the pre-allocated quota is cancelled. In response to the payment authorization token expiring before the completion of this payment and the bound tight constraint source being the payment capability, the pre-allocated quota is returned to the available payment quota. In response to the payment authorization token expiring before the completion of this payment and the bound tight constraint source being the compliance qualification, the pre-allocated quota is returned to the frozen quota of the counterparty. After the pre-allocated quota is returned, when a payment result callback indicating that this payment has been completed is received, the amount is deducted from the return destination according to the payment amount.

[0027] By adopting the above technical solution, the quota control module pre-occupies the payment amount at the same time as the token is issued, and determines the destination of the quota return when the token expires according to the category of the tight constraint source bound to the token, so that the quota occupation under concurrent payment is consistent with the token status.

[0028] In summary, this application includes at least one of the following beneficial technical effects: 1. The determination of payment authority incorporates the time decay of the authorization basis and the time span of the execution period into the same release criterion before payment is executed. The initiation of payment is restricted to the interval within which none of the bases have reached their reduced and confirmed existence boundary, reducing the risk that the basis has become inaccurate due to time decay but is still released on the basis.

[0029] 2. The main status type receipt code in the payment channel receipt is used as a bypass observation source for the failure of the counterparty's qualifications. The consistency of multiple uninformed channels is used to distinguish between qualification failure and channel abnormality, so that qualification failure events that do not actively reach the platform can be indirectly perceived and handled when there is no local signal.

[0030] 3. Compliance review is scheduled after acceptance and before the irreversible point by comparing the delay dimension of the cancellation link and the duration dimension of the irreversible point. Out-of-window transactions are diverted according to the tight constraint source category, so that the irreversible window during the execution period and the in-transit transactions at the expiration time have an operable processing path. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the overall process of a payment permission management method for multiple payment channels in one embodiment of this application.

[0032] Figure 2 This is a schematic diagram illustrating the relationship between the effective time window construction of the payment authorization token and the payment execution period in one embodiment of this application.

[0033] Figure 3 This is a schematic diagram illustrating the relationship between qualification validity observation operations and status feedback in one embodiment of this application.

[0034] Figure 4 This is a schematic diagram of the structure of a payment authorization management system for multiple payment channels in one embodiment of this application. Detailed Implementation

[0035] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0036] This application discloses a method for managing payment permissions across multiple payment channels. This method extends the determination of payment permissions from a single-moment verification to a commitment over an execution period by reducing the basis quantity for each time window according to the observation period and determining the upper bound of the effective time window for the payment authorization token based on the minimum value among the reduced basis quantities. First, a payment request for a drug transaction order is received, and a set of candidate channels and the target payment channel are determined. Then, the basis quantity for each time window is reduced, and a token is issued based on the minimum value, resulting in a payment authorization token binding the order and the channel. Finally, before the channel payment is initiated, it is verified that the current moment falls within the effective time window; if the verification passes, the payment is allowed. Therefore, the permission at the time of determination can be effectively extended to a commitment interval covering the time span of the payment execution period, reducing the outflow of funds that is valid at the time of determination but exceeds the authority upon completion.

[0037] To facilitate understanding of the issues addressed in this application, let's first illustrate with an example. Counterparty A is a pharmaceutical distributor whose whitelist entry on the platform expires at 6 PM that day. At 5:30 PM, Counterparty A initiates a payment request for a pharmaceutical transaction order, using channel three, a corporate bank transfer channel. From the initiation of payment through this channel to the completion of the fund transfer, approximately two hours are required. If payment authorization is only verified at the moment of payment initiation, the whitelist entry at 5:30 PM is still before its expiration date, so the verification passes and the payment is released. Channel three completes the fund transfer around 7:30 PM, by which time the whitelist entry has expired. The payment no longer has the filing basis for release at the time of completion, and since the funds have already been transferred, channel three does not support withdrawal after acceptance, leaving the platform with no recourse. This example demonstrates that if payment authorization verification does not cover the entire payment execution period, the natural expiration date will fall within the in-transit window of an initiated but uncompleted transaction. The following section provides a detailed explanation of the terminology, application environment, overall methodology, qualification validity monitoring, cross-window collection and distribution, and system implementation.

[0038] Before detailing the embodiments of this application, several technical terms will be explained. A payment channel is a settlement channel through which funds are transferred from the payer to the payee, such as third-party payment, bank card quick payment, and corporate transfer. Payment authority is the basis for a platform's determination of whether a payment is allowed to be executed before releasing it. It is jointly determined by the compliance qualifications of the counterparty and the payment capability of the payment channel. Both compliance qualifications and payment capability are time-limited, and this time limit is incorporated into the processing framework of this application through the following terms.

[0039] The time window basis quantity is a candidate duration quantity used to calculate the upper limit of the effective time window, reflecting the remaining time before the expiration time of a certain authorized basis. Each authorized basis involved in a payment corresponds to its own time window basis quantity, the composition and acquisition method of which are explained in detail in step S2.

[0040] The observation period is the time span between the platform's most recent verification of a certain criterion's expiration date and the current time. The longer the observation period, the greater the possibility of deviation between the platform's data copy and the actual status of the criterion. Taking two types of criterions as examples, the filing whitelist is maintained by the platform itself, and each read of an entry constitutes a verification, so its observation period tends to be zero; the status of business qualifications comes from external filing data sources, and the platform only obtains its latest status at the time of synchronization, so its observation period is the time from the most recent synchronization to the current time.

[0041] Reduction is a process that shortens the effective time window based on the observation age before calculating the upper limit of the time window. No reduction is made when the observation age is zero, and the reduction is greater as the observation age increases. This process absorbs the uncertainty caused by outdated data and makes the upper limit of the time window on which it is issued more conservative.

[0042] A payment authorization token is an authorization certificate generated by the issuing side for a combination of a drug transaction order and a target payment channel. Once issued, it is bound to the order and the channel. The effective time window is the time interval bound to the payment authorization token, calculated from the execution time of token issuance. The semantics of the effective time window are not the latest expiration time of each document, but rather a commitment interval. That is, at any time within this interval, none of the authorization documents have reached their reduced and confirmed validity period. Therefore, initiating payment within this interval does not require repeated verification of each document. The effective time window constrains the initiating side of the payment, ensuring that the completion time of the payment falls within the validity period of each document. This is further addressed by comparing the irreversible point with the upper limit of the effective time window, as well as by over-window aggregation and distribution. The conditions for its establishment are detailed in step S3, in conjunction with the token issuance process.

[0043] The capability requirement vector is a set of capability requirements for payment channels generated based on the compliance requirements of this transaction, with each dimension corresponding to a compliance constraint. The capability supply vector is a set of pre-registered capability values ​​for each payment channel, representing the capabilities that the channel can provide under each compliance constraint. These two vectors correspond to each other and are used for dimensional comparison to select payment channels capable of handling this transaction.

[0044] The entity status receipt code is a type of receipt code returned by the payment channel when the verification fails due to reasons on the counterparty's side. It is different from receipt codes returned due to reasons unrelated to the entity's qualifications, such as channel malfunction or insufficient balance.

[0045] The tight constraint source is the compliance qualification or payment capability corresponding to the minimum value among the factors in each discounted time window, which is the constraint source that truly determines the upper limit of the effective time window.

[0046] The irreversible point is the moment when a payment enters an irrevocable state on the payment channel side. After the irreversible point, even if a cancellation instruction is issued to the payment channel, the transfer of funds cannot be stopped.

[0047] A transaction record that is over-the-window is a transaction record registered for a payment when the arrival time of the payment result callback is later than the upper limit of the effective time window and the callback indicates that the payment has been completed. It is used for subsequent compliance reconciliation and diversion processing.

[0048] The application environment of this method is described below. This method can be applied to a pharmaceutical transaction service platform, which provides order management and payment settlement services for pharmaceutical purchasers and sellers, and connects to multiple payment channels. The platform includes an initiating end and an issuing end service. The initiating end is the application page operated by the purchaser, used to create pharmaceutical transaction orders and initiate payments. The issuing end service is the platform's server, responsible for determining the candidate channel set, issuing payment authorization tokens, and verifying payments at various points in time. The issuing end service interfaces with each payment channel, issuing channel payment instructions to the payment channels and receiving channel receipts and payment result callbacks.

[0049] The following steps will use counterparty A and a single pharmaceutical transaction order as a case study. Counterparty A is a pharmaceutical distributor included in the platform's whitelist, whose customer type is a corporate purchaser, and the order involves a category of pharmaceuticals with high regulatory oversight. The platform uses three payment channels: Channel 1 is an instant third-party payment channel with a single payment processing time of 10 minutes; Channel 2 is a bank card quick payment channel with a single payment processing time of 30 minutes; and Channel 3 is a corporate bank transfer channel with a single payment processing time of 2 hours.

[0050] The following is combined Figure 1 The overall process of this method is described in detail. This method includes steps S1 to S4, which are executed sequentially. S1 completes the receipt of payment requests and the determination of the candidate channel set; S2 completes the reduction of the amount based on each time window; S3 completes the issuance of payment authorization tokens; and S4 completes the time window verification and release before the channel payment is initiated.

[0051] Before S1 is executed, the preparation of real-name information can be completed in advance. In some embodiments, at the time of drug transaction order creation before S1, the real-name strength requirement of this transaction is predicted based on the compliance dimension group consisting of the counterparty's customer type and the drug compliance category of the transaction target. In response to the real-name strength requirement reaching the real-name level, the real-name status pre-fetching of the counterparty is initiated at the time of drug transaction order creation, and the real-name information is supplemented to obtain a time-limited real-name pre-fetching result. The real-name pre-fetching result is directly used in the subsequent dimension-by-dimensional coverage comparison. In response to the real-name pre-fetching result exceeding the time limit, the real-name status pre-fetching is re-executed. The real-name strength requirement is set according to the level, for example, it is divided into non-real-name level, ordinary real-name level, and strong real-name level. Ordinary real-name level and above are considered to have reached the real-name level. For example, if counterparty A creates an order at 17:10, and the real-name authentication requirement for this transaction is a strong real-name profile, the issuing service will pre-fetch the real-name status at the time of creation. The validity period of the pre-fetched result is 30 minutes. When S1 executes at 17:30, the result is still within the validity period and will directly participate in the comparison. There is usually a gap between order creation and payment initiation. Preparing the real-name information at the creation time ensures that the comparison in the payment process is not blocked by the time consumption of external real-name verification.

[0052] S1. Receive payment requests for drug transaction orders, extract the counterparty's identifier from the payment request, and determine a set of candidate channels. In specific implementation, the payment request is sent by the initiating party to the issuing service when the purchasing party confirms payment, carrying the order identifier of the drug transaction order and the counterparty's identifier. The issuing service reads the counterparty's registration and qualification data based on the counterparty's identifier, and reads the transaction information based on the order identifier, thereby determining a set of candidate channels that can undertake this transaction.

[0053] In some embodiments, the compliance qualifications include the counterparty's whitelist entries in the filing whitelist and the counterparty's business qualifications; the payment capabilities include the single payment timeliness of the target payment channel. In S1, a compliance payment strategy is matched based on a compliance dimension group consisting of the counterparty's customer type and the drug compliance category of the transaction target. The compliance payment strategy outputs a capability demand vector. The capability demand vector is then compared with the pre-registered capability supply vectors of each payment channel in a dimension-by-dimensional coverage manner. Payment channels that achieve dimension-by-dimensional coverage in the comparison are included in the candidate channel set. The following describes this process in stages.

[0054] The construction of the compliance dimension group is the first phase. Customer type is retrieved from the platform's existing customer profiles. These profiles are created when the counterparty joins the platform and updated with any changes to the registration process; for example, counterparty A's customer type is a corporate purchaser. In some embodiments, the drug compliance category is obtained by reverse-looking up the drug code in the drug transaction order from the drug catalog, and is assigned a value according to the level of regulatory intensity. The value of the real-name strength dimension of the capability requirement vector is determined by the level of the drug compliance category. For example, if the drug code of the target item in this order corresponds to a category with higher regulatory intensity in the drug catalog, this level of intensity will result in the real-name strength dimension being set to "strong real-name file".

[0055] Based on compliance dimension groups, the second stage matches compliant payment strategies and generates a capability requirement vector. Compliance payment strategies are pre-configured by dimension values, declaring the capability requirements for payment channels under that value combination. In some embodiments, compliant payment strategies are maintained in the form of a configuration table. The matching compliant payment strategy is obtained by looking up the table according to the dimension value combination of the compliance dimension group. Adding, deleting, and adjusting strategies are completed through changes to the configuration table. In response to the compliant payment strategies matching multiple dimensions of the compliance dimension group, different values ​​are given on the same dimension of the capability requirement vector. The capability requirement vector takes the upper bound of each matched value on that dimension. For example, if the strategy matching the customer type dimension provides a standard real-name registration for the real-name strength dimension, and the strategy matching the drug compliance category dimension provides a strong real-name registration for the real-name strength dimension, then the real-name strength dimension of the capability requirement vector takes the more stringent strong real-name registration.

[0056] The capability requirement vector expresses compliance requirements in a channel-independent manner. That is, the requirement vector only declares what capabilities are required for this transaction, without pointing to any specific payment channel. Therefore, the addition or removal of compliance constraints is only reflected in the adjustment of the vector dimension and the update of the strategy configuration. When a new payment channel joins the platform, it only needs to register its capability supply vector to participate in the comparison, without the need to modify the existing strategy one by one.

[0057] In some embodiments, each dimension of the capability requirement vector corresponds to a compliance constraint, and each dimension corresponds one-to-one with each dimension of the capability supply vector and adopts a unified compliance constraint dimension. In some embodiments, the capability requirement vector and the capability supply vector each include a real-name verification strength dimension, a payment entity nature dimension, a single transaction limit dimension, a traceability dimension, a whitelist requirement dimension, an irreversible point duration dimension, a cancellation link delay dimension, and a verification strength dimension. Among them, the real-name verification strength dimension and the verification strength dimension are valued according to tiers, the single transaction limit dimension, the irreversible point duration dimension, and the cancellation link delay dimension are valued according to quantity, and the whitelist requirement dimension and the traceability dimension are valued according to whether they are supported or not. The value type of the dimension determines the coverage determination rule adopted for that dimension.

[0058] The third stage is the dimension-by-dimensional coverage comparison. The capability supply vectors of each payment channel are registered when the channel accesses the platform. In some embodiments, this registration is done by operations personnel according to the channel's interface documentation and protocol, and is updated as the channel's capabilities change. In some embodiments, the dimension-by-dimensional coverage comparison is performed separately according to the dimension type. For ordinal dimensions, coverage is determined by ensuring the value of the capability supply vector is not lower than the value of the capability demand vector; for numerical dimensions, coverage is determined by ensuring the value of the capability supply vector is not lower than the value of the capability demand vector; and for Boolean dimensions, coverage is determined by ensuring the value of the capability supply vector implies the value of the capability demand vector.

[0059] For example, in the capability requirement vector of this order, the real-name authentication strength dimension is "strong real-name registration," the single transaction limit dimension is 200,000 yuan, the whitelist requirement dimension is "requirement to support," and the traceability dimension is "requirement to support." In the capability supply vector of Channel 1, the real-name authentication strength dimension is "strong real-name registration," the single transaction limit dimension is 1 million yuan, the whitelist requirement dimension is "support," and the traceability dimension is "support." The ordinal value dimension is no lower than the requirement, the numerical value dimension is no less than the requirement, and the Boolean dimension implies the requirement, thus achieving dimension-by-dimensional coverage. The capability supply vectors of Channel 2 and Channel 3 also cover the requirements in each dimension; therefore, Channel 1, Channel 2, and Channel 3 are all included in the candidate channel set. For another example, if the single transaction limit dimension of a certain payment channel is 100,000 yuan, which is less than the requirement of 200,000 yuan, then the numerical dimension is not covered, and this channel is not included in the candidate channel set.

[0060] When the candidate channel set is empty, this method also provides a controlled fallback path. In some embodiments, in response to an empty candidate channel set, the value of the preset degradable dimension in the capability requirement vector is rolled back one level, and the dimension-by-dimensional coverage comparison is re-executed. The current payment is then marked as degraded and pending review. For example, if the traceability dimension is preset as a degradable dimension, and no payment channel meets the requirements of this dimension, the dimension is rolled back one level, and the comparison is re-executed. The payment channels obtained from the comparison are included in the candidates, and the current payment carries the mark of degraded and pending review before entering subsequent manual review. The degraded fact is explicitly recorded, ensuring that transactions are not completely blocked during the transition period when compliance requirements are updated but channel capabilities have not yet kept up.

[0061] The above describes one implementation method for determining the candidate channel set, namely, screening payment channels by comparing the dimension-wise coverage of the capability demand vector and the capability supply vector. In other embodiments, a mapping table from compliance dimension groups to the list of available channels can be maintained in advance, and the candidate channel set can be obtained directly by looking up the table in S1 according to the combination of dimension values ​​of the compliance dimension groups. Unlike the dimension-wise coverage comparison, the table lookup method pre-fixes compliance judgments in the mapping table, which is suitable for scenarios where the number of payment channels and compliance constraints are stable in the long term. This table lookup method is also an implementation method for determining the candidate channel set.

[0062] In some embodiments, in S1, the execution channel set is further shrunk by selecting one of the parallel S1a, S1b and S1c based on the remaining validity period of the whitelist entry at the execution time of S1 and the state of the whitelist entry at the execution time of S1. The remaining validity period of the whitelist entry is the difference between the expiration time of the whitelist entry and the execution time of S1.

[0063] S1a. In response to a whitelist entry being in a normal state and the remaining validity period of the whitelist entry being longer than the preset shrinkage threshold, maintain the candidate channel set.

[0064] S1b. In response to a whitelist entry being in a normal state and the remaining validity period of the whitelist entry falling within a preset shrinkage threshold, remove payment channels with a single payment timeout longer than the remaining validity period of the whitelist entry from the candidate channel set.

[0065] S1c. In response to a whitelist entry being in a pending review state, the candidate channel set is narrowed down to payment channels whose single payment time falls within the preset review period window.

[0066] The purpose of channel set contraction is to eliminate payment channels based on their remaining validity period during the channel selection phase when whitelist entries are nearing expiration or have questionable status, thus reducing in-transit overruns at the source. For example, if the preset contraction threshold is 4 hours, and counterparty A's whitelist entries expire at 6 PM that day, a payment initiated at 10 AM has a remaining validity period of 8 hours, longer than the preset contraction threshold, thus meeting S1a, and the candidate channel set remains Channel 1, Channel 2, and Channel 3. A payment initiated at 5:30 PM has a remaining validity period of 30 minutes, falling within the preset contraction threshold, thus meeting S1b. Channel 3, with a single payment time of 2 hours, is longer than its remaining validity period and is eliminated. Channel 2, with a single payment time of 30 minutes, has a single payment time equal to but not longer than its remaining validity period and is retained. Channel 1, with a single payment time of 10 minutes, is also retained. The contracted candidate channel set is Channel 1 and Channel 2. Therefore, the scenario in the previous example where Channel 3 only completed the transfer around 7:30 PM, exceeding the 6:00 PM deadline, was excluded during the channel selection phase.

[0067] In response to a whitelist entry being in a pending review state, the contraction rules are further tightened. For example, with a preset review period window of 15 minutes, when S1c is hit, the candidate channel set is contracted to Channel 1, where the single payment time is 10 minutes. The pending review state indicates that there are doubts about the filing basis of the whitelist entry. At this time, only payment channels whose completion speed falls within the preset review period window are retained, so that even if the subsequent review determines that the basis is invalid, the time span of exposure in transit is compressed to the shortest possible. The normal state and pending review state of a whitelist entry are determined by the status handling in the qualification timeliness observation operation, which will be elaborated in the following explanation of the qualification timeliness observation operation.

[0068] S2. Determine the target payment channel from the candidate channel set, and reduce the basis quantity of each time window according to the observation age corresponding to each time window basis quantity to obtain the reduced time window basis quantity. The time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero.

[0069] In practice, the target payment channel can be determined by the initiator, i.e., the initiator presents a narrowed set of candidate channels to the purchaser, who then selects from them; alternatively, it can be determined from the candidate channel set based on the platform's preset channel priority. For example, counterparty A selects channel one as the target payment channel from channel one and channel two presented by the initiator.

[0070] Once the target payment channel is determined, the time window criteria are also determined. The compliance qualification side includes two time window criteria: one corresponding to a whitelist entry, whose expiration time is read from the validity period field of that entry in the platform's filing record; the other corresponding to business qualifications, whose expiration time is read from the qualification data synchronized from the filing data source. The payment capability side includes one time window criterion, corresponding to the single payment timeliness of the target payment channel. The expiration time of this criterion is the current time plus the single payment timeliness, representing the latest completion time if the payment is initiated immediately and the target payment channel completes it within its promised completion time. Therefore, before reduction, this time window criterion is numerically equal to the single payment timeliness. For example, if the current time is 5:30 PM, and the whitelist entry expires at 6:00 PM today, the corresponding time window criterion is 30 minutes; the business qualification expires approximately 180 days from now, so the corresponding time window criterion is approximately 180 days; the single payment timeliness of Channel 1 is 10 minutes, so the corresponding time window criterion is 10 minutes.

[0071] Each time window measures the observation age based on the data source. In some embodiments, the observation age corresponding to the expiration time of a whitelist entry is zero, and the observation age corresponding to the expiration time of a business qualification is the duration from the most recent synchronization time of the business qualification's filing data source to the current time. The filing whitelist is maintained by the platform itself. The issuing service completes one verification by reading the entry in S1. The verification time coincides with the current time, and the observation age is zero. The status of the business qualification is stored in the external filing data source. The platform only obtains its latest status at the synchronization time. At any time after synchronization, the platform-side copy may have deviated from the true status, and the probability of deviation increases with the time elapsed after synchronization. For example, if the filing data source was last synchronized at 5:30 on the same day, and the current time is 17:30, the observation age corresponding to the business qualification is 12 hours.

[0072] The timeliness of a single payment is itself a time-varying observational data point. In some embodiments, the timeliness of a single payment is determined by the sliding quantile of the measured completion time of the target payment channel within the recent observation window. The observation age corresponding to the timeliness of a single payment is the duration from the end of the recent observation window to the current time. If the measured sample size within the recent observation window is insufficient to meet a preset sample threshold, the timeliness of a single payment is reverted to the completion time declared in the target payment channel's documentation. The higher quantile is used instead of the mean because the mean is lowered by a small number of extremely fast-completing samples. The higher quantile indicates that the vast majority of payments are completed within that duration, making the value more conservative. For example, if the recent observation window is the last 24 hours, the quantile is the 19th percentile, and the preset sample threshold is 30 transactions; if the measured sample size for channel one within the recent observation window is 500 transactions, and the 19th percentile completion time is 10 minutes, the sample size exceeds the threshold, so the timeliness of a single payment is the measured 10 minutes; if the end of the recent observation window is 5 PM, the observation age corresponding to the timeliness of a single payment is 30 minutes. For example, if a newly connected payment channel has only 8 measured samples within the observation window, which is less than the threshold, the timeliness of a single payment will be rolled back to the completion time declared in the document.

[0073] The reduction rate increases with the observation age, and its specific form can be varied. In some embodiments, the reduction rate increases linearly with the observation age; or, the reduction rate is tiered according to the observation age, with the higher the tier, the greater the reduction. In the linear form, the reduction rate changes continuously with the observation age. For example, the reduction rate increases by 5% for every hour increase in the observation age, so the reduction rate is 10% when the observation age is 2 hours, and the time window based on 30 minutes is reduced to 27 minutes. In the tiered form, the tier range of the observation age is predefined, and a reduction rate is set for each tier. For example, no reduction is applied when the observation age is zero, 10% is applied when the observation age falls within 24 hours, 30% is applied when the observation age falls between 24 hours and 7 days, and 50% is applied when the observation age exceeds 7 days.

[0074] The choice between the two formats depends on the data refresh rhythm. The linear format has no tier jumps and is suitable for data with continuously distributed observation periods and uniform refresh rhythms, such as the timeliness of a single payment continuously measured using a sliding window. Its side effect is that even small differences in the observation period can cause slight changes in the upper bound of the time window; the effective time window lengths obtained from two adjacent issuances of the same order are not entirely consistent; and the time window values ​​in reconciliation and caching should not be reused across transactions. The tiered format has stable values ​​within each tier, and the tier boundaries are explicit declarations of the reduction strategy, facilitating operational configuration and audit verification. It is suitable for data with a discrete distribution of observation periods based on a synchronization cycle, such as daily synchronized business qualifications. Its side effect is that the reduction magnitude jumps when the observation period crosses tier boundaries, and the effective time window lengths of two adjacent payments at the critical point show a step-like difference. In some embodiments, the two formats are used interchangeably based on the source of the data. The tiered format is used for externally synchronized data, while the linear format is used for high-frequency measured data. Each time window data quantity applies its respective reduction format according to its source.

[0075] Reference Figure 2 The implementation of the reduction is illustrated through examples and in a tiered format. For whitelist entries, the observation age is zero, the reduction is zero, and the time window remains at 30 minutes after reduction. For business qualifications, the observation age is 12 hours, falling within the 24-hour tier, with a 10% reduction, reducing the approximately 180-day time window to approximately 162 days. For single payment timeliness of Channel 1, the observation age is 30 minutes, also falling within the 24-hour tier, with a 10% reduction, reducing the 10-minute time window to 9 minutes. The minimum of the three reduced time window values ​​is 9 minutes, taken from the single payment timeliness on the payment capability side. This minimum value is used in S3 to determine the upper bound of the effective time window. The attribution of the item with the minimum value is discussed in the S3 explanation in conjunction with the tight constraint source.

[0076] The scope of the time window basis quantity for payment capability is further explained. The irreversible point duration dimension and the cancellation link delay dimension in the capability supply vector are both duration attributes, representing the time structure within the execution period of a payment. They do not have independent expiration times and therefore are not included in the time window basis quantity. Their effect is unfolded in the sub-step of step S4. The quantity of the completion time commitment carried by the payment capability side is only the timeliness of a single payment; therefore, only this item participates in the reduction and selection of the minimum value. This approach also reserves a basis for the expansion of the capability side. If a payment channel registers a new capability item with an expiration time, such as a time-limited settlement channel available only before a set deadline, the difference between the expiration time and the current time of this capability item can be included in the time window basis quantity for reduction according to the same caliber. This method does not limit the number of items in the time window basis quantity for reduction and minimum value processing.

[0077] S3. Based on the minimum value among the reduced time windows, execute token issuance to obtain a payment authorization token that binds the drug transaction order and the target payment channel. The effective time window of the payment authorization token starts from the execution time of token issuance, and the upper bound of the effective time window is the execution time plus the minimum value.

[0078] In the specific implementation, the issuing service executes token issuance immediately after completing the S2 reduction. The issued payment authorization token carries the order identifier, the target payment channel identifier, and the valid time window. The token data is held by the issuing side and the token identifier is returned to the initiating side. For example, if counterparty A's three reduced time windows are 30 minutes, approximately 162 days, and 9 minutes, with the minimum value being 9 minutes, the token issuance execution time is 17:30, and the valid time window starts from 17:30 with an upper limit of 17:39.

[0079] The reason for using the above-described structure for the effective time window is that in the execution environment of this method, post-issuance credential control measures are unavailable. In conventional systems, credentials with expiration dates are usually accompanied by a revocation mechanism. When the basis of a credential changes, the issuer registers it as revoked. For the revocation to take effect, the user of the credential must check the revocation status at the time of use. In this method, the usage stage corresponding to the payment authorization token is the execution of channel payment. The executor is a third-party payment channel. The payment channel does not verify platform-defined credentials, nor does it check the platform's revocation list. Once a payment request is sent to the channel, any credential-side control of the platform for that payment is ineffective throughout the entire execution period. Therefore, the issuance time becomes the last point in time when the platform can impose permission constraints. The semantics carried by the effective time window are not the latest time when each basis expires, but rather a commitment interval. That is, at any time within this interval, none of the authorized credentials have reached their reduced and confirmed existence boundary. Therefore, payments initiated within this interval do not require re-verification of each basis at the time of initiation. The method of constructing the commitment is to first reduce the data based on the observation age and then take the minimum value for each time window. The reduction absorbs the uncertainty of the outdated data on the platform side, and taking the minimum value makes the commitment valid for each data point simultaneously.

[0080] It is necessary to explain the objects constrained by this commitment interval and its boundaries. First, the effective time window constrains the initiating side of the payment, that is, it constrains when the payment can be issued, rather than directly constraining the completion time of the fund transfer. When the time window that takes the minimum value comes from the compliance qualification side, and the single payment time of the target payment channel is longer than the remaining duration of the qualification after reduction, the completion time of the payment initiated within the window may still be later than the expiration time of the qualification. Second, this method uses the irreversible point as the criterion for determining whether to release the payment. Once a payment crosses the irreversible point, it cannot be stopped. Therefore, this time must fall within the commitment interval, and the corresponding determination is carried out in the sub-step of step S4. In the case where the completion time is later than the upper limit of the effective time window but the payment has already been completed, the cross-window collection and diversion will be handled afterward according to the actual completion status. Third, the effective time window guarantees that the platform will not exceed its authority due to the natural expiration of the basis. Non-natural invalidation of the basis, such as the revocation of licenses or the cancellation of qualifications by the competent authority before the expiration time, will not actively reach the platform and are not within the scope of the effective time window guarantee. This is addressed by a three-pronged mechanism: bypassing the perception of invalidation signals by qualification validity observation operation, re-judging compliance review before the irreversible point, and collecting and diverting transactions outside the window to provide a safety net for reconciliation of completed transactions.

[0081] The upper bound is taken as the minimum value among the reduced time window criteria, rather than a weighted average of the values, because the commitment interval must be valid for each criterion simultaneously. The duration obtained by weighting or averaging may be longer than one of the reduced time window criteria, which would naturally expire before the time window expires, and the commitment would be breached. However, when taking the minimum value, none of the criteria have reached their reduced validity boundary at any time within the time window. Therefore, the minimum value is the longest duration that makes the commitment valid for all criteria. Taking a shorter value would only narrow the available time window, and taking any longer value would destroy the commitment.

[0082] In some embodiments, if the reduced time window basis quantity is not less than zero, the payment is rejected in response to the minimum value among all reduced time window basis quantities being not greater than zero. The reduction amount does not exceed the quantity being reduced, and the reduction result is bounded to zero. If a basis has expired at the current time, its time window basis quantity is not positive, is reduced to zero, and the minimum value is therefore not greater than zero, and the issuance is rejected. For example, if counterparty A initiates payment again at 18:10, the whitelist entry has expired at 18:00, the corresponding reduced time window basis quantity is zero, and the minimum value is zero. This payment is rejected at the issuance stage and does not proceed to the channel payment initiation. Payments with expired basis are thus truncated at the issuance stage, rather than being left for pre-initiation verification.

[0083] In some embodiments, an absolute capping duration is set for the upper limit of the effective time window. The upper limit of the effective time window is the earlier of the execution time plus the minimum value among the various reduced time window base values ​​and the execution time plus the absolute capping duration. For example, if the absolute capping duration is 24 hours and the minimum value of this payment is 9 minutes, the upper limit determined by the minimum value is earlier than the upper limit determined by the capping duration, so the capping is ineffective. However, when the various reduced time window base values ​​of a payment are all tens of days, the upper limit determined by the minimum value is much later than the execution time plus 24 hours, so the upper limit is the time obtained by the capping duration. The absolute capping means that even when individual base data is abnormally large or the base items are extremely few, the token exposure time is still constrained by a defined upper limit.

[0084] In some embodiments, S3 further defines the compliance qualification or payment capability corresponding to the minimum value among the reduced time window criteria as the tight constraint source, and binds the identifier of the tight constraint source to the payment authorization token. In response to two or more reduced time window criteria simultaneously reaching their minimum values, the tight constraint source is determined according to a preset order prioritizing compliance qualification over payment capability. The tight constraint source records the constraint source that truly determines the upper bound of the time window for this token. Subsequent handling of token expiration and out-of-window transactions follows this source. For example, if the minimum value of 9 minutes for this token is taken from the single payment time limit of Channel 1, the tight constraint source is payment capability, and its identifier is bound to the token. When both reach their minimum values, they are categorized under the compliance qualification side because out-of-window transactions on the qualification side directly affect filing compliance, and their handling path is stricter. When the source cannot be uniquely attributed, it is handled according to the stricter side.

[0085] In some embodiments, the tight constraint source is refined to the specific qualification or capability item that reaches the minimum value. In response to two or more items within the same category simultaneously reaching the minimum value, the tight constraint source is determined according to a preset order prioritizing whitelist entries over business qualifications. The refined tight constraint source directly indicates which criterion tightened the time window, allowing subsequent processing and operational attribution to pinpoint the item. This refinement method also achieves the purpose of binding the constraint source to the token.

[0086] In some embodiments, the payment request also carries the version number of the available channel list cached locally on the initiating end. During token issuance, the version number carried in the payment request is compared with the version number of the candidate channel set currently corresponding to the list version number. If the version number carried in the payment request is earlier than the version number of the candidate channel set currently corresponding to the list version number, the difference in the available channel list between the two is sent to the initiating end along with the payment authorization token. For example, if the channel set shrinkage update updates the list version number after removing channel three, the version number carried by the initiating end remains the version before the shrinkage. The issuing side sends the difference due to the removal of channel three along with the token, and the initiating end updates its local cache accordingly. Changes in the channel list are thus converged to the end side via the existing link of token issuance, without the need for independent list push.

[0087] In some embodiments, the payment amount for this payment is pre-allocated from the counterparty's available payment limit at the same time as the token is issued, resulting in a pre-allocated limit. When the payment authorization token expires, the return destination of the pre-allocated limit is determined according to the value of the tight constraint source. The separation of the return destination corresponds semantically to the tight constraint source: when the tight constraint source is payment capability, the token expires due to the completion time constraint on the channel side, the counterparty's qualification is not in doubt, and the pre-allocated limit is returned to the available payment limit, which can be reused for other payments immediately; when the tight constraint source is compliance qualification, the tightening time window is the existence boundary of the filing or qualification side. The expiration triggered by this constraint means that the qualification is approaching the boundary, and the pre-allocated limit is returned to the counterparty's frozen limit, which is not released as available until the qualification side confirms it. After the pre-allocated limit is returned, when a payment result callback indicating that this payment has been completed is received, the amount is deducted from the return destination according to the payment amount, so that the limit ledger is aligned with the actual fund flow. For example, if the payment amount for this order is 50,000 yuan, and the token is issued at 17:30, 50,000 yuan is pre-allocated from the available payment limit of counterparty A. If the token expires at 17:39 before the payment is completed, the tight constraint source for this transaction is payment capacity, and the pre-allocated 50,000 yuan is returned to the available payment limit. Subsequently, when a payment result callback indicating that this payment has been completed is received, 50,000 yuan is deducted from the available payment limit. Multiple concurrent payments each pre-allocate their own limits, and changes in the token lifecycle of any one payment only affect its own pre-allocated limit, thus keeping the limit occupancy consistent with the token status.

[0088] In other embodiments, the release target of the pre-allocated quota is determined based on the state of the whitelist entry at the time the payment authorization token expires. If the whitelist entry is in a normal state, it is returned to the available payment quota; if it is in a pending review state, it is returned to the frozen quota. Unlike the method of tightening constraint source routing, this method uses the immediate state of the eligibility side at the time of expiration as the release basis. When a whitelist entry is set to a pending review state, it is frozen regardless of the source of the tightening window. This method also achieves controlled release of the pre-allocated quota when the token expires.

[0089] S4. Before initiating channel payment, verify that the current time falls within the valid time window, and after the verification is passed, execute channel payment initiation to allow the payment. Channel payment initiation is to send a channel payment instruction to the target payment channel.

[0090] In practice, the initiating party sends a request with a token identifier after the purchaser confirms payment. The issuing side verifies that the current time falls within the token's valid time window. If the verification is successful, a channel payment instruction is sent to the target payment channel. For example, if the purchaser confirms payment at 17:32, the current time falls within the valid time window starting from 17:30 and with an upper limit of 17:39, and the verification is successful.

[0091] In some embodiments, the payment authorization token is also bound to the payment amount of the drug transaction order and the identifiers of the payer and payee. During the verification in S4, if the payment amount or the identifiers of the payer and payee are inconsistent with the value bound to the payment authorization token, the payment is blocked. For example, if the payment amount bound to the token is 50,000 yuan, but the payment amount in the request is changed to 60,000 yuan, the two are inconsistent, and the payment is blocked. In addition to the time window verification, an element consistency verification is superimposed, ensuring that the token is only valid for the transaction content locked at the time of issuance.

[0092] The number of times a payment authorization token can be used is also limited. In some embodiments, the payment authorization token is a one-time token, which becomes invalid after the payment is initiated and approved by the payment channel. The same token cannot be reused for multiple initiations, and duplicate initiation requests will be rejected because the token has expired.

[0093] If the current time during verification falls outside the valid time window, the current initiation will not be approved, but the transaction can be restarted in a controlled manner. In some embodiments, during the verification of S4, if the current time falls outside the valid time window, a re-issuance flag is returned to the initiator, allowing the initiator to re-execute S1 to S3 under the same drug transaction order. For example, if the purchaser confirms payment at 17:41, and the current time is later than the upper limit of 17:39, the issuing side returns a re-issuance flag to the initiator, prompting the purchaser to re-initiate. The re-executed S1 to S3 will re-contract and re-reduce the channels based on the status and observation age at the re-signing time, and any changes in the basis that occur during this period will be reintroduced in the new token.

[0094] The execution location of each verification point remains consistent. In some embodiments, the verification of S4, the verification upon arrival of the payment result callback, and the verification in the window reconciliation queue are all performed on the issuing side of the payment authorization token. The window data and each basis status are held by the issuing side, and the verification is performed on the same data benchmark at the three points in time to avoid inconsistent judgments caused by deviations in the initiating end's local clock or the data copy on the channel side. The verification upon arrival of the payment result callback and the verification in the window reconciliation queue will be discussed in detail in the following description of window collection and distribution.

[0095] In some embodiments, the capability supply vector of each payment channel further includes an irreversible point duration dimension and a revocation link delay dimension. The irreversible point duration dimension represents the time from when the payment is initiated by the channel to when the payment enters an irrevocable state, and the revocation link delay dimension represents the time from when a revocation instruction is issued to the payment channel to when the payment channel completes the revocation. S4 sequentially includes the following sub-steps S41 to S44: S41. The irreversible point of this payment is obtained by adding the irreversible point duration of the target payment channel to the scheduled initiation time of the channel payment. The scheduled initiation time of the channel payment is the execution time of S41. The latest revocable time is obtained by subtracting the cancellation link delay of the target payment channel from the irreversible point. Combined with... Figure 2 The irreversible point defines the time boundary within which the payment can still be prevented, while the latest revocable time is the latest time that a revocation instruction must be issued to take effect before the irreversible point. Together, they form the basis for determining subsequent sub-steps. For example, if the irreversible point duration of channel one is 3 minutes and the revocation link delay is 5 minutes, the execution time of S41 is 17:31, the irreversible point is 17:34, and the latest revocable time is 17:29. The latest revocable time is earlier than the scheduled time of channel payment initiation, meaning that once the payment is initiated, there is no opportunity for effective revocation.

[0096] There may be a discrepancy between the scheduled initiation time and the actual initiation time of channel payment. The period from S41 to the actual issuance of the channel payment instruction comprises the judgment execution and network transmission of S42 to S44. Since the actual initiation time is later than the scheduled initiation time, the irreversible point time calculated from the scheduled time is therefore earlier than the actual irreversible point time. S43 uses the earliest of the various expiration times being earlier than the irreversible point time as the interception condition, and S44 uses the irreversible point time not being earlier than the upper limit of the effective time window as the interception condition. Both conditions become easier to pass as the irreversible point time moves forward. The calculated value being earlier biased towards the release side rather than the interception side, and this deviation must be controlled. In practical implementation, the judgment execution and transmission time of S42 to S44 is typically in the second range, far less than the minute-level irreversible point duration, and also less than the conservative margin reserved at the upper limit of the effective time window. Under normal circumstances, this is insufficient to prevent payments that have exceeded the window from being mistakenly released. In some embodiments, an initiation time limit is also set. In response to the actual initiation time being later than the channel payment initiation time limit, the calculation of S41 is re-executed and the subsequent comparison is re-executed at the actual initiation time, so that the long deviation caused by abnormal blocking does not use the outdated judgment benchmark.

[0097] S42. Compare the revocation link delay dimension of the target payment channel with the irreversible point duration dimension. If the revocation link delay dimension is shorter than the irreversible point duration dimension, the compliance review for this payment is determined as a post-review; if the revocation link delay dimension is not shorter than the irreversible point duration dimension, the compliance review for this payment is determined as a pre-review. This comparison answers whether there is still a valid revocation window after the channel accepts the payment. When the revocation link delay dimension is shorter than the irreversible point duration dimension, the time leeway for the revocation instruction to be issued and completed before the irreversible point, calculated from the time the channel payment is initiated, is positive. There is still a window for revocation after acceptance, and the compliance review can be postponed to be executed within this window, so the channel payment initiation is not blocked by the review time consumption. When the revocation link delay dimension is not shorter than the irreversible point duration dimension, even if the revocation instruction is issued at the same time as the initiation, the payment has already passed the irreversible point when the revocation is completed. The revocation after acceptance cannot be physically effective, and the compliance review must be completed before the initiation. The comparison between the two directly corresponds to the existence or absence of the cancellation window and is the correct criterion for determining the review sequence. For example, if the cancellation link delay of Channel 1 is 5 minutes, which is not shorter than the irreversible point duration of 3 minutes, the compliance review of this payment is determined to be a pre-review; if the cancellation link delay of Channel 3 is 20 minutes, which is shorter than the irreversible point duration of 90 minutes, the payment using Channel 3 is determined to be a post-review.

[0098] The value of the cancellation link delay dimension itself affects the reliability of the above determination. In some embodiments, the value of the cancellation link delay dimension is the larger of the cancellation completion period declared in the payment channel document and the high quantile of the actual cancellation completion time of the payment channel. This dimension is used to deduce the latest revocable time from the irreversible point. If its value is less than the actual cancellation completion time, the latest revocable time is postponed. The cancellation instruction issued at that time will be completed after the irreversible point, the cancellation fails, and the funds have already been transferred. Conversely, a larger value only moves the latest revocable time forward, at most making a payment that could have been reviewed later judged as requiring prior review, at the cost of an extra review time before initiation. The two types of costs are not symmetrical, so this dimension takes the conservative side. The cancellation completion period declared in the document is the cancellation processing period promised by the channel. The high quantile of the actual cancellation completion time reflects the actual time of most cancellations rather than its maximum value. Taking the larger of the two can simultaneously cover the two situations where the channel fails to fulfill its promised period and the actual sample does not cover the long tail. For example, the cancellation completion deadline stated in the Channel 3 document is 30 minutes, the actual cancellation completion time is 20 minutes (the 90ths place), and the cancellation link delay is 30 minutes.

[0099] S43. A pre-payment review is performed before the payment is initiated. During the pre-payment review, if the earliest expiration time of the counterparty's response is earlier than the irreversible point, it is deemed non-compliant and the payment is blocked. The pre-payment review is based on the latest status of each supporting document read before initiation. If a supporting document will expire before the payment enters the irreversible state, the payment is blocked before initiation. For example, if the compliance review for this payment is a pre-payment review, and the earliest expiration time of counterparty A is 18:00 on the same day as the whitelist entry, which is later than the irreversible point of 17:34, it is deemed compliant and not blocked.

[0100] S44. The irreversible point time is compared with the upper bound of the valid time window. If the irreversible point time is not earlier than the upper bound of the valid time window, the payment is intercepted and an alternative channel set is returned to the initiator. If the irreversible point time is earlier than the upper bound of the valid time window, the payment is allowed. The alternative channel set is a set of payment channels in the candidate channel set whose candidate irreversible point times are earlier than the upper bound of the valid time window. The candidate irreversible point time for each payment channel in the candidate channel set is the time obtained by adding the irreversible point duration dimension of each payment channel to the channel payment initiation time. This comparison ensures that the time when the payment enters an irreversible state is constrained within the promised interval. When the payment is allowed, the point at which it loses the possibility of reversal is still within the validity boundary confirmed by the reduced basis. For example, if the irreversible point time of this payment, 17:34, is earlier than the upper bound of the valid time window, 17:39, the payment is allowed, and the issuing side issues a channel payment instruction to channel one after the comparison is passed. For example, if the target payment channel is Channel 2, its irreversible point duration is 15 minutes, and the irreversible point time is 17:46, which is no earlier than the upper limit of 17:39, the payment is blocked. In the candidate channel set, the candidate irreversible point time of Channel 1, 17:34, is earlier than the upper limit, while the candidate irreversible point time of Channel 2, 17:46, is no earlier than the upper limit. The alternative channel set is Channel 1. After receiving the alternative channel set, the initiating party presents Channel 1 to the purchaser for reselection. After reselection, the payment is re-initiated under the same order.

[0101] When the irreversible point is equal to the upper bound of the effective time window, it is included in the interception side. Equality means that the payment enters an irrevocable state exactly at the boundary of the commitment interval. The irreversible point is calculated from the predetermined time. Clock deviation and transmission delay may cause the actual value to shift to a later time. Once the boundary equality case shifts, it constitutes a window crossing. Therefore, the comparison condition is no earlier than the threshold, and the payment is intercepted, thus absorbing the judgment error on the interception side.

[0102] Following S4, for payments where compliance review is determined to be subject to subsequent review, the following subsequent review operations are performed: The subsequent review is conducted no later than the latest revocable time, using the same judgment method as the initial review. If the subsequent review determines non-compliance, a revocation is initiated to the target payment channel no later than the latest revocable time. After the channel accepts the payment but before the revocation window closes, the latest status of each supporting document is reread during the subsequent review. New invalidation signals arriving after the initiation time are captured here; for example, probe observation may set whitelist entries to a pending review state, or synchronous updates may advance the expiration time of a supporting document. The review is then re-performed according to the updated expiration time. If non-compliance is determined, a revocation is initiated to the target payment channel within the time limit during which the revocation is still effective. For example, a payment initiated at 10:00 AM using Channel 3 has an execution time of 10:01 AM, an irreversible point time of 11:31 AM, and a latest revocable time of 11:11 AM. The revocation link delay of 20 minutes is shorter than the irreversible point time of 90 minutes. The compliance review is determined to be a post-review, and the channel payment instruction is issued without prior review. The issuing side performs the post-review at 11:05 AM. The earliest expiration time among the counterparty A's various expiration times is 6:00 PM that day, which is later than the irreversible point time of 11:31 AM. Therefore, it is deemed compliant, and no revocation is initiated. Conversely, if the post-review reads that a whitelist entry has been set to a pending review state and its basis has been confirmed invalid, it is deemed non-compliant. The issuing side initiates a revocation to Channel 3 no later than 11:11 AM. The revocation is completed before the irreversible point time of 11:31 AM, and the fund transfer is blocked. Therefore, pre-review and post-review are handled according to the presence or absence of a cancellation window. Payments with a cancellation window are processed without being blocked in exchange for post-review, while payments without a cancellation window are processed to initiate pre-review and secure the last opportunity.

[0103] Reference Figure 3 The following is a detailed explanation of the qualification timeliness observation operation. The pending review status in the channel set contraction mentioned above and the updated basis status in the post-review both originate from this operation, which also provides the basis for updating the business qualification observation period.

[0104] In some embodiments, after S4, the following qualification timeliness observation operations are performed sequentially on the channel receipts returned by each payment channel: subject status type receipt codes are filtered out from the channel receipts; the ratio of the number of subject status type receipt codes appearing to the number of normally processed receipts within a set observation window is used to calculate the qualification doubt ratio; payment channels whose qualification doubt ratio reaches a preset doubt threshold are included in the doubt channel set; and status processing is performed on whitelist entries based on the number of payment channels in the doubt channel set. The above operations are explained below.

[0105] The system filters out entity status-related receipt codes from channel receipts. These codes are returned by the payment channel when the counterparty's account status, real-name information, and business qualifications verification fails. While qualification and registration failures don't proactively reach the platform, the payment channel verifies the counterparty using its own data source before processing each payment. If verification fails, a receipt code is returned explaining the reason. Therefore, the channel receipts serve as a bypass observation signal for the counterparty's eligibility, and this operation indirectly detects failures using this signal. Receipt codes are categorized semantically during filtering. For example, account status receipt codes (e.g., accounts that have been frozen or cancelled), real-name information discrepancies with registration, and qualification receipt codes (e.g., business qualification verification failures) are included. Receipt codes unrelated to entity eligibility, such as those due to channel malfunctions, limits, or insufficient balances, are excluded.

[0106] The ratio of the number of occurrences of status-based receipt codes within a set observation window to the number of normal acceptances from the same counterparty within the same observation window is used as the qualification doubt ratio. The number of normal acceptances is the number of payment transactions in the set observation window where the payment channel returns a successful acceptance receipt to the counterparty. The qualification doubt ratio is calculated for each payment channel with a normal acceptance count greater than zero. Using the ratio rather than the absolute number of transactions as the criterion ensures that counterparties with different transaction frequencies are comparable under the same threshold, and that occasional verification failures by high-frequency customers are not misinterpreted as failure signals. In some embodiments, the set observation window is a time window obtained by looking back a set duration from the current moment. The statistics scroll with the current moment, always reflecting the observation results of the most recent period. For example, if the set duration is 72 hours, each statistical analysis covers channel receipts from the 72 hours prior to the current moment.

[0107] Payment channels with a qualification doubt ratio reaching a preset doubt threshold are categorized into a doubt channel set. Payment channels with zero normally processed transactions and a number of entity status acknowledgment codes reaching a preset minimum occurrence threshold are also categorized into the doubt channel set. Based on the number of payment channels in the doubt channel set, whitelist entries are subject to status adjustments, including setting them to a pending review state or maintaining them in a normal state. Payment channels with zero normally processed transactions cannot have their ratios calculated, but their continuous return of entity status acknowledgment codes within the observation window is itself a strong failure signal. Categorizing them according to the absolute threshold of occurrence ensures that the extreme case where all payments from a counterparty on a certain channel are rejected does not escape observation due to a zero denominator. For example, the preset threshold for doubt is 5%, and the preset minimum number of occurrences is 3. If, within the set observation window, the counterparty B has 60 normal acceptances and 4 entity status receipt codes in Channel 1, and the qualification doubt ratio is about 6.7%, reaching the preset threshold for doubt, Channel 1 is included in the doubt channel set. If the counterparty B has zero normal acceptances in Channel 3 and 3 entity status receipt codes, reaching the preset minimum number of occurrences, Channel 3 is also included in the doubt channel set.

[0108] Status handling is performed separately based on the number of payment channels in the suspicious channel set. In some embodiments, status handling is performed separately based on the number of payment channels in the suspicious channel set: In response to the fact that the set of questionable channels is empty, the whitelist entries are kept in a normal state.

[0109] If the suspicious channel set contains only a single payment channel, it is determined that the payment channel in the suspicious channel set has an verification anomaly. The whitelist entry is kept in a normal state, and the payment channel in the suspicious channel set is removed from the counterparty's candidate channel set within the set isolation period.

[0110] In response to the fact that the questionable channel set includes multiple payment channels, it is determined that the business qualifications of the counterparty have expired, and the whitelist entries are set to a pending review status.

[0111] The basis for separate determination lies in the source of the signal. If a single payment channel fails to detect a failure while other channels process the same transaction normally, the failure signal only exists on that channel's side. This is more likely due to data anomalies or changes in verification strategies within that channel itself, resulting in a verification failure. The transaction counterparty is not affected; the channel is only temporarily removed from its candidate list. If multiple payment channels fail to detect a failure independently, the same cause on the entity side appears simultaneously on multiple unconnected observation sources, pointing to the failure of the transaction counterparty's own qualifications. The whitelist entry is placed in a pending review state and enters the tightening path S1c of the channel set contraction mentioned earlier, involving manual review. In some embodiments, the isolation period is set from the time of the verification failure determination, for example, setting the isolation period to 24 hours. The channel determined to have a verification failure will not enter the candidate channel set of that transaction counterparty for 24 hours from the time of determination, and will automatically resume participation in the comparison after the expiration. For example, if the questionable channel set of competitor B only contains channel one, it is determined that channel one has an abnormality in verification, and B's whitelist entry remains in a normal state. Channel one is removed within 24 hours from the time of determination. In another observation window, if B's ​​qualification doubt ratio in channel one is 10% and the qualification doubt ratio in channel two is 10%, both of which reach the threshold, the questionable channel set includes channel one and channel two. It is determined that B's business qualification has expired, and B's whitelist entry is set to a pending review state.

[0112] In some embodiments, the capability supply vector of each payment channel also includes a verification strength dimension. This dimension represents the depth of verification of the counterparty's business qualifications by the payment channel. The number of payment channels in the questionable channel set is weighted according to the value of the verification strength dimension. When the weighted count reaches a preset weighted threshold, the business qualification is deemed invalid. Payment channels with different verification depths have different strengths of evidence for their hit signals. Channels that perform in-depth verification of merchant qualifications have main status-type receipt codes that directly point to the qualification itself, and the weighting gives them greater weight in the judgment. For example, the weight of a deep verification is two, and the weight of a shallow verification is one, with a preset weighted threshold of three. If channel one is a deep verification channel and channel two is a shallow verification channel, and only channel one (deep verification) hits, the weighted count is two, which is below the threshold and is treated as a verification anomaly. If both channel one and channel two hit, the weighted count is three, reaching the threshold, and the business qualification is deemed invalid.

[0113] In contrast to a hit, a zero hit of the subject status receipt code carries a positive signal. In some embodiments, during the qualification validity observation operation, the following positive renewal operations are performed sequentially for zero hits of the subject status receipt code: the number of normal transactions processed by the counterparty on each payment channel within a set observation window is counted and the set of independent verification channels is determined accordingly; and when the set of independent verification channels includes multiple independent payment channels and the subject status receipt code has a zero hit, the observation is determined as a renewal verification for the expiration of the business qualification. The above operations are explained below.

[0114] The system statistically analyzes the number of normal transactions processed by counterparties on various payment channels within a set observation window. Payment channels that reach a preset threshold for normal transactions are then grouped into a set of independently verified channels. This threshold ensures that renewals are based solely on statistically significant observations; a few successful transactions are insufficient to support a judgment on the continued validity of the qualification.

[0115] In response to the independent verification channel set containing multiple independent payment channels and setting the number of occurrences of the entity status type receipt code of the counterparty within the observation window to zero, the observation corresponding to the zero hit is determined as the renewal verification of the expiration time of the business qualification. The observation age corresponding to the expiration time of the business qualification is recalculated from the time of the renewal verification. Among them, the multiple independent payment channels are multiple payment channels belonging to different operating entities.

[0116] The technical meaning of renewal verification is that before accepting each payment, each payment channel verifies the counterparty's legal status using its own data source. Successful acceptance means that the channel has completed a verification of the entity using its data source and the conclusion is "passed." Multiple payment channels continuously accept payments successfully within the observation window without any returning entity status confirmation codes, meaning that multiple independent data sources consistently confirm the entity's continued eligibility in a recent period. This consistent observation provides concurrent corroborating evidence from multiple independent data sources, and its confirmation strength is weaker than a proactive synchronization initiated by the platform to the filing data source. Therefore, it is only considered as a verification of the expiration date of the business qualification in the sense of refreshing the observation age. Its boundaries are also clearly defined: renewal verification refreshes the observation age, i.e., the confirmation point of the platform-side copy freshness, and does not extend the expiration date itself; the expiration date is still based on the filing data. Furthermore, renewal only occurs when three conditions are met simultaneously: zero hits, independent channels, and the number of accepted transactions reaching a threshold. Observations where any one of these conditions is not met do not constitute renewal verification.

[0117] The principle of mutual independence is defined as belonging to different operating entities because the independence of verification conclusions depends on the independence of data sources. Multiple payment channels under the same operating entity typically share the same set of merchant risk control and real-name data. Their respective acceptance and approval are essentially repeated readings of the same data source, and cross-verification is not valuable in a multi-channel format. Payment channels belonging to different operating entities independently access regulatory and filing data and independently maintain risk control databases. Their consistent approval at the same time constitutes a convergence of mutually independent evidence. The lower limit for multiple is two, which is the minimum complex number for mutual corroboration: approval from a single channel only excludes anomalies in the channel's own data source and cannot distinguish between the existence of the entity's qualification and the failure of the channel's data to be outdated and captured. The simultaneous omission of the same failure event by two independent data sources requires the failure signal to be missing on two independent synchronous links simultaneously. The conditions for this are much more difficult to meet than the single-source omission. Therefore, consistent approval from two independent channels is sufficient to support renewal, and this lower limit cannot be lowered further.

[0118] Renewal verification is adjusted based on the observed age. For example, if counterparty A has 60 normal transactions processed through Channel 1 and 25 through Channel 2 within the set observation window, both reaching the preset threshold of 20 transactions, and Channel 1 and Channel 2 belong to different operating entities, and A's entity status receipt code has zero occurrences, this observation is determined as a renewal verification for A's business qualification upon expiration. The observation age for this expiration date is recalculated from the time of renewal verification. Subsequently, when A initiates payment, the observation age corresponding to the business qualification in S2 approaches zero, and the reduction rate is correspondingly lowered. The time window for the business qualification is no longer further tightened due to outdated data. The hit and zero hit of the bypass probe thus form a two-way observation loop: a hit tightens the status and time window, while a zero hit refreshes the age and relaxes the reduction.

[0119] The requirements for evidence independence differ between the hit side and the zero-hit side, which is an intentional design. The hit side's approach involves placing whitelist entries in a pending review state and tightening the channel set—a tightening approach. Even if multiple hit channels belong to the same operating entity and their signals are duplicates from the same data source, the cost of misjudgment is only an additional manual review and a more stringent channel contraction. The zero-hit side's approach involves refreshing the observation period and reducing the reduction rate—a lenient approach. Misjudgment would allow expired qualifications to continue to be issued with longer validity windows. Due to the asymmetrical costs on both sides, the zero-hit side requires payment channels to belong to different operating entities to constitute cross-validation, while the hit side does not have this requirement to prevent genuine qualification failures from being missed due to unmet channel affiliation conditions.

[0120] In some embodiments, the advance notice period for each whitelist entry in the whitelist is determined based on the historical transaction frequency and the distribution of in-transit payment completion times of the corresponding counterparty. For counterparties with high transaction frequency and a preference for longer completion times, their entries are more likely to have long-term in-transit payments before expiry, thus requiring a longer advance notice period, for example, by taking the higher value of their in-transit payment completion time distribution and advancing it by several days. For counterparties with sparse transactions and a preference for instant channels, the advance notice period is correspondingly shortened. The timing of the reminder is thus matched to the actual in-transit situation of the counterparty, ensuring that renewal registration can be completed before the last long-term in-transit payment is initiated.

[0121] The following is a detailed explanation of the window-crossing collection and distribution operations. Of the three mechanisms mentioned above, qualification timeliness observation serves as a bypass for detecting failure signals, post-review handles the re-determination before the irreversible point, and this operation is the third, providing a safety net for compliant reconciliation after the completion of completed payments. The comparison constraint of S44 is the moment when the payment enters an irrevocable state. The moment the channel completes the fund transfer and the moment the payment result callback arrives can still be later than the upper limit of the effective time window. For example, if the channel's completion time falls at the tail end of its single payment timeframe, or if the callback is delayed after a channel retry, window-crossing transactions can still occur. This operation ensures that such transactions are collected and distributed without omission.

[0122] In some embodiments, after S4, the following windowless collection and distribution operations are performed on the payment result callbacks returned by the target payment channel: payment result callbacks whose arrival time is later than the upper limit of the effective time window and indicate that the payment has been completed are registered as windowless transaction records and sent to the windowless reconciliation queue; and windowless transaction records are transferred to the automatic posting channel and the manual compliance supplementation channel respectively according to the category of the tight constraint source carried by the windowless transaction record and the expiration time corresponding to the single payment validity period. The above operations are described below.

[0123] The arrival time of the payment result callback is compared with the upper limit of the effective time window. If the arrival time of the payment result callback is later than the upper limit of the effective time window and the payment result callback indicates that the payment has been completed, the payment is registered as a window-crossing transaction record with the identifier of the tight constraint source and sent to the window-crossing reconciliation queue. Callbacks whose arrival time falls within the effective time window are recorded as normal transactions and are not included in this operation; if the arrival time is later than the upper limit and the callback indicates that the payment has not been completed, it is treated as a payment failure and does not constitute a window-crossing transaction. The tight constraint source identifier is carried with the record during aggregation, so that subsequent routing can be directly routed according to the constraint source without having to re-trace the reduction details at the time of issuance during reconciliation.

[0124] In response to the fact that the tight constraint source of the out-of-window transaction record is payment ability, and the expiration time corresponding to the single payment validity period is later than the arrival time of the payment result callback, the out-of-window transaction record is judged as a compliant transaction and transferred to the automatic posting channel. The mechanism of this branch is based on the conservative margin created by the reduction. The upper limit of the effective time window is determined by the minimum value after reduction, while the expiration time corresponding to the single payment validity period is calculated based on the value before reduction. The upper limit is earlier than the expiration time due to the reduction, forming a gap between the two. When the tight constraint source is payment ability, the tightening of the time window is the single payment validity period. Although the arrival time of the transaction callback is later than the upper limit, it is still earlier than the actual expiration time of this item. This payment has not actually exceeded the existence boundary of any basis. The out-of-window transaction has only exceeded the conservative boundary created by the reduction, and is judged as a compliant transaction and automatically posted. The conservatism created by the reduction on the issuing side is thus identified and recovered on the reconciliation side and does not translate into manual processing volume. For example, if counterparty A makes a payment through channel 1, the upper limit of the token's validity window is 17:39, the expiration time corresponding to the single payment validity period is 17:40, and the payment result callback arrives at 17:39:30, indicating that the payment has been completed. Since the arrival time is later than the upper limit, this transaction is registered as a window-crossing transaction record with a payment capability identifier. Since the expiration time of 17:40 is later than the arrival time, it is determined to be a compliant transaction and transferred to the automatic posting channel.

[0125] In response to the fact that the tight constraint source of out-of-window transaction records is payment capability, and the expiration time corresponding to a single payment's validity period is not later than the arrival time of the payment result callback, out-of-window transaction records will be transferred to the manual compliance supplementary registration channel. For transactions whose arrival time has exceeded the actual expiration time, whether their completion falls within the validity period can no longer be verified by the issuing side data, and will be transferred to manual verification. The comparison condition is "not later than," that is, the boundary case where the expiration time equals the arrival time is also included in the manual side. The arrival time is determined by the timing of the callback issued by the channel side and the transmission link, and belongs to two different timing sources from the expiration time calculation by the issuing side. The actual order at the boundary of equality cannot be proven by the arrival time alone, and for the sake of conservatism, it will not be automatically judged as compliant. For example, if the callback of the same payment arrives late at 17:42, and the expiration time of 17:40 is not later than the arrival time, this transaction will be transferred to the manual compliance supplementary registration channel, and the operations personnel will supplement it after verifying the actual completion time and filing status on the channel side.

[0126] In response to the fact that the source of compliance for transactions exceeding the time window is a tight constraint, these transactions will be transferred to the manual compliance registration channel. When the source of compliance is a tight constraint, exceeding the upper limit of the time window means that the transaction is approaching or has even exceeded the validity boundary of the filing or qualification side. The qualification side boundary directly touches on the filing compliance of drug operation, and there is also the possibility of non-natural invalidation such as the revocation of licenses. Such transactions will not be automatically verified for compliance by the machine and will be transferred to the manual compliance registration channel for verification. For example, if competitor C's business license expires at 19:20 on the same day, and its whitelist entries expire the following month, and at 17:30, C initiates payment for a drug transaction order and selects Channel 3 as the target payment channel, the remaining validity period of the whitelist entries in the channel set contraction is longer than the preset contraction threshold, thus hitting S1a, and the candidate channel set is maintained; in S2, the time window basis quantity corresponding to the business license is 110 minutes, the observation age is 12 hours, falling into the 24-hour range, which is reduced to 99 minutes; the time window basis quantity corresponding to the single payment time of Channel 3 is 120 minutes, the observation age is 30 minutes, also falling into the 24-hour range, which is reduced to 108 minutes; the reduced time window basis quantity corresponding to the whitelist entries is much longer than both, with a minimum of 99 minutes. Based on the business qualification, with compliance qualification as the primary constraint, the upper limit of the effective time window is 19:09. S41's execution time is 17:31, and the irreversible point time is 19:01, earlier than the upper limit. Therefore, it is allowed. The cancellation link delay of 20 minutes is shorter than the irreversible point duration of 90 minutes. The compliance review is determined to be a post-review and executed before the latest revocable time of 18:41. During the review, the expiration time of the business qualification at 19:20 is later than the irreversible point time, thus it is deemed compliant. Channel 3 delivers a payment result callback indicating that this payment has been completed at 19:31, arriving later than the upper limit of 19:09. This transaction is registered as a cross-window transaction record carrying a compliance qualification identifier and transferred to the manual compliance supplementary registration channel for manual verification of C's qualification renewal filing status before processing. This example also shows that the completion time of a payment initiated within the window can be later than the expiration time of the basis that yielded the minimum value; such residual situations are handled by this operation afterward.

[0127] The comparison upon callback arrival and the verification in the cross-window reconciliation queue are both performed on the issuing side of the payment authorization token. They share the same time window data and the basis state benchmark with the verification of S4, thus the determination of the three time points is based on consistent data.

[0128] Reference Figure 4 The following describes the payment authorization management system for multiple payment channels that implements the above method. This system includes a request access module, a token issuance module, and a time window verification module.

[0129] The access request module is configured to receive payment requests for drug transaction orders, extract the counterparty's identifier from the payment request, and determine a set of candidate channels.

[0130] The token issuance module communicates with the request access module and is configured to determine the target payment channel from the candidate channel set. It performs reduction according to the observation age corresponding to each time window basis quantity to obtain each reduced time window basis quantity, and executes token issuance based on the minimum value among the reduced time window basis quantities. The resulting payment authorization token is bound to the drug transaction order and the target payment channel. The effective time window of the payment authorization token is calculated from the execution time of token issuance and is bounded to the time obtained by adding the minimum value to the execution time. Among them, the time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero.

[0131] The time window verification module communicates with the token issuance module and is configured to verify that the current time falls within a valid time window before executing the channel payment initiation, and execute the channel payment initiation after the verification is successful. The channel payment initiation is to issue a channel payment instruction to the target payment channel.

[0132] The specific implementation of each module corresponds to the description of each step in the method above. The request access module corresponds to S1 and the description of the candidate channel set determination and channel set shrinking. The token issuance module corresponds to S2, S3 and the description of the tight constraint source determination. The time window verification module corresponds to S4 and its sub-steps and the description of the post-review operation. The qualification timeliness observation operation and the window-crossing collection and diversion operation can be executed by the token issuance module and the time window verification module in collaboration, or by the independently deployed observation component and reconciliation component. There are no restrictions here.

[0133] In some embodiments, the system further includes a quota control module communicatively connected to the token issuance module. The token issuance module is further configured to determine the compliance qualification or payment capability corresponding to the minimum value of the discounted time window basis quantity among the discounted time window basis quantities as the tight constraint source and bind it to the payment authorization token. The quota control module is configured to pre-allocate the payment amount of this payment from the available payment quota of the counterparty at the same time as the token is issued. In response to the completion of this payment within the effective time window, the pre-allocated quota is cancelled. In response to the payment authorization token becoming invalid before the completion of this payment and the bound tight constraint source being payment capability, the pre-allocated quota is returned to the available payment quota. In response to the payment authorization token becoming invalid before the completion of this payment and the bound tight constraint source being compliance qualification, the pre-allocated quota is returned to the frozen quota of the counterparty. After the pre-allocated quota is returned, when a payment result callback indicating that this payment has been completed is received, the pre-allocated quota is deducted from the payment amount according to the return destination. The pre-allocation, cancellation, and return processing of the quota control module corresponds to the explanation of quota pre-allocation in the previous token issuance section, and the basis for separating the return destination according to the tight constraint source is also the same.

[0134] The same or similar parts in the various embodiments of this application can be referenced to each other, and the technical features of each embodiment can be combined with each other to form new embodiments without conflict.

[0135] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0136] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for managing payment permissions across multiple payment channels, characterized in that, The steps are as follows: S1. Receive a payment request for a drug transaction order, extract the identifier of the counterparty from the payment request, and determine a set of candidate channels; S2. Determine the target payment channel from the candidate channel set, and reduce each time window basis quantity according to the observation age corresponding to each time window basis quantity to obtain the reduced time window basis quantity. The time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero. S3. Execute token issuance based on the minimum value among the reduced time windows to obtain a payment authorization token that binds the drug transaction order and the target payment channel. The effective time window of the payment authorization token starts from the execution time of token issuance, and the upper bound of the effective time window is the execution time plus the minimum value. S4. Before initiating channel payment, verify that the current time falls within the valid time window, and after the verification is successful, execute the channel payment initiation to allow the payment. The channel payment initiation is to issue a channel payment instruction to the target payment channel.

2. The payment authorization management method for multiple payment channels according to claim 1, characterized in that, The compliance qualifications include the counterparty's whitelist entries in the filing whitelist and the counterparty's business qualifications. The payment capabilities include the single payment timeliness of the target payment channel. In S1, a compliance payment strategy is matched based on the compliance dimension group consisting of the counterparty's customer type and the drug compliance category of the transaction target. The compliance payment strategy outputs a capability demand vector. The capability demand vector is compared with the capability supply vector pre-registered by each payment channel in a dimension-by-dimensional coverage manner. The payment channels with dimension-by-dimensional coverage in the comparison result are included in the candidate channel set.

3. The payment authorization management method for multiple payment channels according to claim 2, characterized in that, Following step S4, the following qualification timeliness observation operations are performed sequentially on the channel receipts returned by each payment channel: The entity status type receipt code is selected from the channel receipts. The entity status type receipt code is the receipt code returned by the payment channel when the account status, real name information and business qualification of the counterparty fail to pass the verification. The ratio of the number of occurrences of the subject status type receipt code within the set observation window to the number of normal acceptances of the counterparty within the same set observation window is used as the qualification doubt ratio. The number of normal acceptances is the number of payment transactions in the set observation window in which the payment channel returns a successful acceptance receipt to the counterparty. The qualification doubt ratio is calculated one by one for each payment channel whose number of normal acceptances is greater than zero. Payment channels whose qualification doubt ratio reaches a preset doubt threshold are included in the doubt channel set. Payment channels whose normal acceptance count is zero and whose main entity status type receipt code occurrence count reaches a preset minimum occurrence count threshold are also included in the doubt channel set. The whitelist entries are then processed according to the number of payment channels in the doubt channel set. The status processing includes setting the whitelist entries to a pending review state and maintaining the whitelist entries in a normal state.

4. The payment authorization management method for multiple payment channels according to claim 3, characterized in that, In the qualification validity observation operation, the following positive renewal operations are also performed sequentially for zero hits of the subject status type receipt code: The number of normal transactions accepted by the counterparty on each payment channel within the set observation window is counted, and the payment channel whose number of normal transactions reaches the preset acceptance threshold is included in the independent verification channel set. In response to the fact that the set of independent verification channels includes multiple independent payment channels and the number of occurrences of the entity status type receipt code of the counterparty within the set observation window is zero, the observation corresponding to the zero hit is determined as the renewal verification of the expiration time of the business qualification. The observation age corresponding to the expiration time of the business qualification is recalculated from the time of the renewal verification. The multiple independent payment channels are multiple payment channels belonging to different operating entities.

5. The payment authorization management method for multiple payment channels according to claim 3, characterized in that, The status handling is categorized according to the number of payment channels in the set of questionable channels: In response to the set of suspicious channels being empty, the whitelist entries are maintained in the normal state. In response to the fact that the suspicious channel set contains only a single payment channel, it is determined that the payment channel in the suspicious channel set has a verification abnormality, the whitelist entry is kept in the normal state, and the payment channel in the suspicious channel set is removed from the candidate channel set of the counterparty within the set isolation time. In response to the fact that the set of questionable channels includes multiple payment channels, if it is determined that the business qualification of the counterparty has expired, the whitelist entry is set to the pending review status.

6. The payment authorization management method for multiple payment channels according to claim 3, characterized in that, In step S1, based on the remaining validity period of the whitelist entry at the execution time of S1 and the status of the whitelist entry at the execution time of S1, one execution channel set is selected from the parallel S1a, S1b, and S1c for contraction. The remaining validity period of the whitelist entry is the difference between the expiration time of the whitelist entry and the execution time of S1. S1a. In response to the whitelist entry being in the normal state and the remaining validity period of the whitelist entry being longer than a preset shrinkage threshold, maintain the candidate channel set; S1b. In response to the whitelist entry being in the normal state and the remaining validity period of the whitelist entry falling within the preset shrinkage threshold, the payment channel with a single payment timeout longer than the remaining validity period of the whitelist entry is removed from the candidate channel set; S1c. In response to the whitelist entry being in the pending review state, the candidate channel set is narrowed down to payment channels whose single payment time falls within the preset review period window.

7. The payment authorization management method for multiple payment channels according to claim 2, characterized in that, The capability supply vector of each payment channel further includes an irreversible point duration dimension and a revocation link delay dimension. The irreversible point duration dimension represents the time from when the payment is initiated by the channel to when the payment enters an irrevocable state. The revocation link delay dimension represents the time from when a revocation instruction is issued to the payment channel to when the payment channel completes the revocation. S4 sequentially includes the following sub-steps: S41. The irreversible point time of this payment is obtained by adding the irreversible point duration dimension of the target payment channel to the channel payment initiation scheduled time. The channel payment initiation scheduled time is the execution time of S41. The latest revocable time is obtained by subtracting the cancellation link delay dimension of the target payment channel from the irreversible point time. S42. Compare the cancellation link delay dimension and the irreversible point duration dimension of the target payment channel. If the cancellation link delay dimension is shorter than the irreversible point duration dimension, determine the compliance review of this payment as a post-review. If the cancellation link delay dimension is not shorter than the irreversible point duration dimension, determine the compliance review of this payment as a pre-review. S43. Before the channel payment is initiated, the pre-review is performed. In the pre-review, if the earliest of the expiration times of the counterparty is earlier than the irreversible point time, it is determined to be non-compliant and the payment is blocked. S44. Compare the irreversible point time with the upper bound of the effective time window. If the irreversible point time is not earlier than the upper bound of the effective time window, intercept the payment and return the alternative channel set to the initiator. If the irreversible point time is earlier than the upper bound of the effective time window, allow the payment. The alternative channel set is a set of payment channels in the candidate channel set whose candidate irreversible point times are earlier than the upper bound of the effective time window. The candidate irreversible point time of each payment channel in the candidate channel set is the time obtained by adding the irreversible point duration dimension of each payment channel to the predetermined time of payment initiation. Following S4, the following post-review operation is performed on the payment for which compliance review is determined to be post-review: the post-review is performed no later than the latest revocable time in accordance with the determination method of the pre-review, and if the post-review is determined to be non-compliant, the revocation is initiated to the target payment channel no later than the latest revocable time.

8. The payment authorization management method for multiple payment channels according to claim 2, characterized in that, In step S3, the compliance qualification or payment capability corresponding to the minimum value of the reduced time window basis quantity is also determined as a tight constraint source, and the identifier of the tight constraint source is bound to the payment authorization token. In response to two or more reduced time window basis quantities simultaneously reaching the minimum value, the tight constraint source is determined according to a preset order in which the compliance qualification takes precedence over the payment capability.

9. The payment authorization management method for multiple payment channels according to claim 8, characterized in that, Following step S4, the following windowing aggregation and distribution operations are also performed on the payment result callback returned by the target payment channel: The arrival time of the payment result callback is compared with the upper bound of the effective time window. If the arrival time of the payment result callback is later than the upper bound of the effective time window and the payment result callback indicates that the payment has been completed, the payment is registered as a window-crossing transaction record carrying the identifier of the tight constraint source and sent to the window-crossing reconciliation queue. In response to the fact that the tight constraint source carried by the over-the-window transaction record is the payment capability, and the expiration time corresponding to the single payment validity period is later than the arrival time of the payment result callback, the over-the-window transaction record is determined to be a compliant transaction and transferred to the automatic posting channel. In response to the fact that the tight constraint source carried by the over-the-window transaction record is the payment capability, and the expiration time corresponding to the single payment validity period is not later than the arrival time of the payment result callback, the over-the-window transaction record is transferred to the manual compliance supplementary registration channel. In response to the fact that the tight constraint source carried by the window-over transaction record is the compliance qualification, the window-over transaction record is transferred to the manual compliance supplementation channel.

10. A payment authorization management system for multiple payment channels, characterized in that, include: The access request module is configured to receive payment requests for drug transaction orders, extract the identifier of the counterparty from the payment request, and determine a set of candidate channels. The token issuance module, which is communicatively connected to the request access module, is configured to determine the target payment channel from the candidate channel set, perform reduction according to the observation age corresponding to each time window basis quantity to obtain each reduced time window basis quantity, and execute token issuance according to the minimum value among the reduced time window basis quantities. The resulting payment authorization token is bound to the drug transaction order and the target payment channel. The effective time window of the payment authorization token is calculated from the execution time of the token issuance and the time obtained by adding the minimum value to the execution time is the upper bound. The time window basis quantity is the difference between the expiration time of each qualification item included in the compliance qualification of the counterparty and the expiration time of each capability item included in the payment capability of the target payment channel and the current time. The observation age is the duration from the most recent verification time of each expiration time to the current time. The reduction range increases with the increase of the observation age and is zero when the observation age is zero. The time window verification module is communicatively connected to the token issuance module. It is configured to verify that the current time falls within the valid time window before executing the channel payment initiation, and to execute the channel payment initiation after the verification is passed. The channel payment initiation is to issue a channel payment instruction to the target payment channel.

Images