Two-way activity detection method, device, equipment, system and medium in cross-regional payment

Abstract

The invention discloses a bidirectional detection method, device, equipment and system in cross-regional payment and a medium, and belongs to the field of data processing. The method comprises the following steps: receiving a request message periodically sent by a business center of a payment institution by calling a bidirectional probe interface, wherein the request message comprises a business center identifier and an availability state of at least one business center of the payment institution; synchronizing a service center identifier and an availability state of the service center to other cross-regional gateway centers of the plurality of cross-regional gateway centers according to the request message; and in response to the request message, a response message is fed back to the service center sending the request message through the bidirectional probe interface, and the response message comprises gateway center identifiers and availability states of the plurality of cross-regional gateway centers. According to the embodiment of the invention, the efficiency of bidirectional detection is improved.

Description

Technical Field

[0001] This application belongs to the field of data processing, and in particular relates to a two-way activation method, apparatus, equipment, system and medium for cross-regional payment. Background Technology

[0002] In cross-regional payment scenarios, payment transactions from a payment institution in one region need to be routed through a cross-regional gateway to the business center of a payment institution in another region for processing. To meet the ever-increasing demands of users and payment data volume, payment institutions typically have multiple business centers, and cross-regional gateways also have multiple cross-regional gateway centers. Each cross-regional gateway center needs to probe the availability of the payment institution's business centers, and similarly, the payment institution's business centers need to probe the availability of the cross-regional gateway centers. For each cross-regional gateway center and business center, at least one active probe and one passive probe are required to complete one round of probing. For example, a cross-regional gateway center needs to probe each business center individually and receive a response from each business center, and each business center also needs to probe each cross-regional gateway center individually and receive a response from each cross-regional gateway center to complete one round of probing. With multiple business centers for both payment institutions and cross-regional gateways, numerous interactions are required to complete a single round of probing, resulting in high complexity and low efficiency in the bidirectional probing between cross-regional gateway centers and business centers in cross-regional payment scenarios. Summary of the Invention

[0003] This application provides a method, apparatus, device, system, and medium for two-way activation detection in cross-regional payments, which can improve the efficiency of two-way activation detection between cross-regional gateway centers and business centers.

[0004] In a first aspect, embodiments of this application provide a two-way activation method for cross-regional payments, comprising: a cross-regional gateway center receiving a request message periodically sent by a business center of a payment institution via a two-way activation interface, the request message including the business center identifier and availability status of at least one business center of the payment institution; the cross-regional gateway center synchronizing the business center identifier and availability status of the business center to other cross-regional gateway centers according to the request message; and in response to the request message, the cross-regional gateway center sending a response message to the business center that sent the request message via the two-way activation interface, the response message including the gateway center identifier and availability status of the multiple cross-regional gateway centers.

[0005] Secondly, embodiments of this application provide a two-way activation detection device for cross-regional payments, comprising: a receiving module, configured to receive request messages periodically sent by the business center of a payment institution via a two-way activation detection interface, the request messages including the business center identifier and availability status of at least one business center of the payment institution; a synchronization module, configured to synchronize the business center identifier and availability status of the business center to other cross-regional gateway centers according to the request messages; and a sending module, configured to respond to the request messages by sending a response message from the cross-regional gateway center to the business center that sent the request messages via the two-way activation detection interface, the response message including the gateway center identifier and availability status of the multiple cross-regional gateway centers.

[0006] Thirdly, embodiments of this application provide a two-way activation system for cross-regional payments, comprising: a business center, configured to periodically call a two-way activation interface to send request messages to a cross-regional gateway center, the request message including the business center identifier and availability status of at least one business center of the payment institution; a cross-regional gateway center, communicatively connected to the business center, configured to synchronize the business center identifier and availability status of the business center to other cross-regional gateway centers according to the request message; and a response message, configured to respond to the request message by sending a response message to the business center that sent the request message through the two-way activation interface, the response message including the gateway center identifier and availability status of the multiple cross-regional gateway centers.

[0007] Fourthly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the bidirectional detection method in cross-regional payment in the first aspect.

[0008] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the bidirectional liveness detection method in cross-regional payment as described in the first aspect.

[0009] In a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the bidirectional liveness detection method in cross-regional payment as described in the first aspect.

[0010] This application provides a method, apparatus, device, system, and medium for two-way activity detection in cross-regional payments. The payment institution's business center periodically calls a two-way activity detection interface to send request messages to a cross-regional gateway center. The request message includes the business center identifier and availability status of at least one business center of the payment institution. The cross-regional gateway center synchronizes the business center identifier and availability status from the request message to other cross-regional gateway centers. Responding to the request message, the cross-regional gateway center sends a response message back to the business center through the two-way activity detection interface. The response message includes the gateway center identifier and availability identifier of multiple cross-regional gateway centers. For both the business center and the cross-regional gateway center, only one request message and one response message are needed for a single probe to achieve two-way activity detection, eliminating the need for two probes. This reduces the number of interactions between the business center and the cross-regional gateway center in two-way activity detection, thereby reducing the complexity of two-way activity detection between business centers and cross-regional gateway centers in cross-regional payment scenarios and improving the efficiency of two-way activity detection between business centers and cross-regional gateway centers. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating an example of probing between multiple business centers and multiple cross-regional gateway centers; Figure 2 This is a schematic diagram of the structure of a two-way activity detection system in cross-regional payment provided in an embodiment of this application; Figure 3 A flowchart illustrating a two-way liveness detection method in cross-regional payments provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating an example of a service center sending a request message to a cross-regional gateway center, as provided in an embodiment of this application. Figure 5 This is a schematic diagram illustrating another example of a service center sending a request message to a cross-regional gateway center, as provided in the embodiments of this application. Figure 6 A schematic diagram illustrating an example of the dual-write mechanism for a cross-regional gateway center provided in an embodiment of this application; Figure 7 A schematic diagram illustrating an example of cross-regional transaction request transmission between a cross-regional gateway center and a business center before adjustment, provided in an embodiment of this application; Figure 8A schematic diagram illustrating an example of the adjusted cross-regional transaction request transmission between a cross-regional gateway center and a business center, provided in an embodiment of this application. Figure 9 A schematic diagram illustrating an example of a cross-regional payment process provided in an embodiment of this application; Figure 10 A schematic diagram of the structure of a two-way activity detection device in cross-regional payment provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the purpose, technical solution, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of the details in these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application. It should be noted that the acquisition, storage, use, and processing of information and data in the embodiments of this application are all authorized by users or relevant organizations and comply with the relevant provisions of national laws and regulations. In the embodiments of this application, certain software, components, models, and other existing solutions in the industry may be mentioned. These should be considered as exemplary, and their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or necessarily used such a solution.

[0014] In cross-regional payment scenarios, payment transactions from a payment institution in one region need to be routed through a cross-regional gateway to the business center of a payment institution in another region for processing. To meet the ever-increasing demands of users and payment data volume, payment institutions typically have multiple business centers, and cross-regional gateways also have multiple cross-regional gateway centers. Each cross-regional gateway center needs to probe the availability of the payment institution's business centers, and similarly, the payment institution's business centers need to probe the availability of the cross-regional gateway centers. For each cross-regional gateway center and business center, at least one active probe and one passive probe are required to complete one round of probing. An active probe includes a request and a response, and a passive probe also includes a request and a response. A cross-regional gateway center needs to probe each business center individually and receive a response from each business center, and each business center also needs to probe each cross-regional gateway center individually and receive a response from each cross-regional gateway center to complete one round of probing. With multiple business centers for both payment institutions and cross-regional gateways, numerous interactions are required to complete one round of probing, resulting in high complexity and low efficiency in the bidirectional probing between cross-regional gateway centers and business centers in cross-regional payment scenarios. For example, Figure 1 A schematic diagram illustrating an example of probing between multiple business centers and multiple cross-regional gateway centers, as shown below. Figure 1 As shown, the payment institution has Business Center 1, Business Center 2, and Business Center 3, while the cross-regional gateway has Cross-Regional Gateway Center 1 and Cross-Regional Gateway Center 2. Business Center 1 probes both Cross-Regional Gateway Center 1 and Cross-Regional Gateway Center 2 and receives their responses. Business Center 2 probes both Cross-Regional Gateway Center 1 and Cross-Regional Gateway Center 2 and receives their responses. Business Center 3 probes both Cross-Regional Gateway Center 1 and Cross-Regional Gateway Center 2 and receives their responses. Cross-Regional Gateway Center 1 probes all three business centers and receives their responses. Similarly, Cross-Regional Gateway Center 2 probes all three business centers and receives their responses. Therefore, a significant amount of interaction is required between the business centers and the cross-regional gateway centers to complete one round of probing. In order to synchronize state information with the cross-regional gateway center of the payment structure, the business center also needs to provide a probe server for the other party to call, and also needs to develop a probe client to probe the other party. This makes the design of the cross-regional gateway center and the business center in the cross-regional payment scenario more complex.

[0015] This application provides a method, apparatus, device, system, and medium for two-way liveness detection in cross-regional payments. For a business center or a cross-regional gateway center, two-way liveness detection between the business center and the cross-regional gateway center can be achieved through a single request and response, eliminating the need for two probes. The business center does not need to probe each cross-regional gateway center; it can obtain the availability status of multiple cross-regional gateway centers by randomly or in round-robin polling. Similarly, the cross-regional gateway center does not need to probe each business center; it can passively receive the availability status of the business centers. This reduces the number of interactions between the business center and the cross-regional gateway center in a single probe round, simplifies the two-way liveness detection process between the business center and the cross-regional gateway center, reduces the complexity of two-way liveness detection between business and cross-regional gateway centers in cross-regional payment scenarios, and improves the efficiency of two-way liveness detection between business and cross-regional gateway centers.

[0016] To facilitate understanding, the two-way activation system for cross-regional payments in this application embodiment will be briefly described below. The two-way activation system for cross-regional payments can be used in scenarios involving two-way activation between the payment institution's business center and the cross-regional gateway center in cross-regional payments. Cross-regional payments may involve a business center in one region, a cross-regional gateway center, and a business center in another region. The cross-regional gateway center can act as a relay station for cross-regional payment information. The regions crossed in cross-regional payments may include, but are not limited to, cities, countries, or regions defined according to other requirements. Payment methods for cross-regional payments may include QR code payments; other payment methods that can use the two-way activation method for cross-regional payments in this application embodiment are also within the scope of protection of this application embodiment. Figure 2 This is a schematic diagram of the structure of a two-way activation system in cross-regional payment provided in an embodiment of this application, as shown below. Figure 2As shown, the two-way activation system in this cross-regional payment system may include a business center 11 of the payment structure and a cross-regional gateway center 12. The number of business centers 11 and cross-regional gateway centers 12 in the two-way activation system can be multiple. Business centers 11 can communicate and interact with cross-regional gateway centers 12. The business center 11 of the payment institution can be used to interact with users, merchants, etc., execute payment transactions, and store relevant payment data. The cross-regional gateway center is the hub for traffic scheduling and unified access. It can interface with multiple business centers of multiple payment institutions and can be used to determine the business center in cross-regional payments, perform format conversion of cross-regional transaction requests, and manage cross-regional payment traffic. During a cross-regional payment process, a business center 11 initiates a cross-regional transaction request, sending the payment request to an available cross-regional gateway center 12. The cross-regional gateway center 12 then sends the payment request to another available business center 11, thus realizing cross-regional payment. The specific steps of the two-way liveness detection method in cross-regional payments executed by Business Center 11 and Cross-Regional Gateway Center 12 will be explained in detail below, and will not be repeated here.

[0017] The following describes the two-way activity detection method, device, equipment, system, and medium for cross-regional payments provided in this application.

[0018] This application provides a two-way activation method for cross-regional payments, which can be applied to perform two-way activation between the business center and the cross-regional gateway center in cross-regional payment scenarios. This two-way activation method for cross-regional payments can be executed by a two-way activation device or a two-way activation system for cross-regional payments. The two-way activation device can be located in the cross-regional gateway center, and the steps performed by the two-way activation device can also be considered as steps performed by the cross-regional gateway center. Figure 3 A flowchart of a two-way liveness detection method in cross-regional payment provided in an embodiment of this application is shown below. Figure 3 As shown, the two-way activation method in cross-regional payment may include steps S201 to S203.

[0019] In step S201, the cross-regional gateway center receives request messages periodically sent by the payment institution's business center through the bidirectional probe interface.

[0020] This bidirectional liveness detection interface is a dedicated interface for bidirectional liveness detection between the business center and the cross-regional gateway center. It is only used by the business center to call the cross-regional gateway center. That is, the business center actively sends a request to the cross-regional gateway center through this bidirectional liveness detection interface, and receives the response from the cross-regional gateway center through this bidirectional liveness detection interface.

[0021] The payment institution's business center can periodically call the two-way activity detection interface to send request messages to the cross-regional gateway center. The period for the business center to send request messages to the cross-regional gateway center can be set according to the scenario, requirements, experience, etc., and is not limited here. For example, the period for the business center to send request messages to the cross-regional gateway center can be 5 seconds, that is, the business center calls the two-way activity detection interface to send request messages to the cross-regional gateway center every 5 seconds.

[0022] The request message includes a business center identifier and availability status for at least one business center of the payment institution. The business center identifier represents the business center; for example, it can be implemented as a business center number. The availability status of the business center indicates whether the business center is available. In some examples, if the availability status is the first character, it indicates that the business center is available; if the availability status is the second character, it indicates that the business center is unavailable. For example, if the availability status is 1, it indicates that the business center is available; if the availability status is 0, it indicates that the business center is unavailable.

[0023] In some examples, the request message also includes the configuration mapping between cross-regional gateway centers and service centers. This mapping represents the service centers that the cross-regional gateway center can support; that is, the cross-regional gateway center interacts only with service centers it has a configuration mapping with, and not with service centers it does not. By configuring the cross-regional gateway center mapping in the service center's request message, dynamic traffic adjustment for the cross-regional gateway center can be achieved.

[0024] In some examples, the structure of the request message transmitted through the bidirectional liveness detection interface can be, but is not limited to, JSON or XML formats. A request message conforming to the bidirectional liveness detection interface format can include first-level information and second-level information. First-level information includes the payment institution's identifier, used to identify the payment institution. Second-level information includes a list of business center statuses. The business center status list includes at least one set of first-center information, which consists of information related to the business centers in the request message. Each set of first-center information includes the gateway center identifier of a cross-regional gateway center and the business center identifiers and availability status of business centers with configured correspondence across cross-regional gateway centers. The business center status list can be a composite field, represented in array form, but is not limited to this. For example, a request message might look like this: { "acqNtwkIdCd": "00000001", "ntDataInfList": [ {"accessNet": "SH01", "tradeUrlInfoList": [ {"tradeUrlNo": "1","status": "1"}, {"tradeUrlNo": "2","status": "0"} ]}, {"accessNet": "BJ01", "tradeUrlInfoList": [ {"tradeUrlNo": "3","status": "1"}, {"tradeUrlNo": "4","status": "1"} ]} ] }” In this example, the payment institution deployed four business centers, and the cross-regional gateway deployed two cross-regional gateway centers. Here, "acqNtwkIdCd" represents the payment institution's identifier; "ntDataInfList" represents the business center status list; "accessNet": "SH01" indicates that the cross-regional gateway center identifier is SH01; the first occurrence of "tradeUrlInfoList" represents the list of business centers with a configuration correspondence to the cross-regional gateway center identifier SH01; "tradeUrlNo": "1", "status": "1" indicates that the availability status of the business center with business center identifier "tradeUrlNo" of 1 is 1, i.e., the business center with business center identifier "tradeUrlNo" of 1 is available; "tradeUrlNo": "2", "status": "0" indicates that the availability status (status) of the business center with the business center identifier "tradeUrlNo" 2 is 0, meaning the business center with the business center identifier "tradeUrlNo" 2 is unavailable; business centers with a configuration correspondence with the cross-regional gateway center with the cross-regional gateway center identifier SH01 include the business center with the business center identifier 1 and the business center with the business center identifier 2; "accessNet": "BJ01" indicates that the cross-regional gateway center identifier is BJ01; the second occurrence of "tradeUrlInfoList" indicates a list of business centers with a configuration correspondence with the cross-regional gateway center with the cross-regional gateway center identifier BJ01; "tradeUrlNo": "3", "status": "1" indicates that the availability status (status) of the business center with the business center identifier "tradeUrlNo" 3 is 1, meaning the business center with the business center identifier "tradeUrlNo" 3 is available; "tradeUrlNo": "4", "status": "1" indicates that the availability status (status) of the business center with the business center identifier "tradeUrlNo" 4 is 1, meaning that the business center with the business center identifier "tradeUrlNo" 4 is available. Business centers with a configuration correspondence to the cross-regional gateway center with the cross-regional gateway center identifier BJ01 include the business centers with business center identifiers 3 and 4. The payment institution's business centers inform the cross-regional gateway center via request messages that: cross-regional gateway center SH01 can call business centers 1 and 2, business center 1 is available, and business center 2 is unavailable; cross-regional gateway center BJ01 can call business centers 3 and 4, and both business centers 3 and 4 are available.Cross-region gateway centers will not send cross-region transaction requests to unavailable business centers.

[0025] In step S202, the cross-regional gateway center synchronizes the business center identifier and availability status of the business center to other cross-regional gateway centers according to the request message.

[0026] Cross-regional gateway centers passively receive request messages and synchronize the business center identifiers and availability statuses of the service centers in the request messages with other cross-regional gateway centers to ensure consistency in the recorded business center identifiers and availability statuses across multiple cross-regional gateway centers. The business center identifiers and availability statuses recorded by each cross-regional gateway center are the same as those in the most recently received request message. In some examples, the request message may include the business center identifiers and availability statuses of all service centers. In this case, the cross-regional gateway center receiving the request message can synchronize the business center identifiers and availability statuses of all service centers in the request message to other cross-regional gateway centers, ensuring that all cross-regional gateway centers have access to the business center identifiers and availability statuses of all service centers. In other examples, the request message includes the business center identifiers and availability statuses of the service center that sent the request message. In this case, multiple cross-regional gateway centers can synchronize with each other, merging the business center identifiers and availability statuses of all service centers, ensuring that all cross-regional gateway centers have access to the business center identifiers and availability statuses of all service centers.

[0027] In step S203, in response to the request message, the cross-regional gateway center sends a response message back to the service center that sent the request message through the bidirectional probe interface.

[0028] The response message is a message sent by a cross-region gateway center in response to a request message. The response message includes gateway center identifiers and availability statuses for multiple cross-region gateway centers; specifically, it includes the gateway center identifiers and availability statuses for all cross-region gateway centers. The gateway center identifier identifies the cross-region gateway center; for example, it can be implemented as a number for the cross-region gateway center. The availability status of a cross-region gateway center indicates whether it is available. In some examples, if the availability status is the third character, it indicates that the cross-region gateway center is available; if the availability status is the fourth character, it indicates that the cross-region gateway center is unavailable. For example, if the availability status is 1, it indicates that the cross-region gateway center is available; if the availability status is 0, it indicates that the cross-region gateway center is unavailable.

[0029] In some examples, the structure of the response message transmitted through the bidirectional probe interface can be, but is not limited to, JSON or XML formats. A response message conforming to the bidirectional probe interface format includes primary and secondary information. Primary information includes a response code, which identifies the message as a response. Secondary information includes a cross-regional gateway center status list, which includes at least one set of secondary center information, representing information related to the cross-regional gateway center in the response message. Each set of secondary center information includes the gateway center identifier and availability status of a cross-regional gateway center. The cross-regional gateway center status list can be a composite field, represented as an array, but is not limited to this. For example, a response message might look like this: { "respCd": "0000000000", "ntStatusList": [ { "accessNet": "SH01", "status": "1" }, { "accessNet": "BJ01", "status": "0" } ] }” In this example, two cross-region gateway centers are deployed. "respCd" represents the response code; "ntStatusList" represents the cross-region gateway center status list; "accessNet": "SH01" indicates that the cross-region gateway center identifier is SH01; "status": "1" indicates the availability status of the cross-region gateway center with identifier SH01, i.e., "status" is 1, meaning the cross-region gateway center with identifier SH01 is available; "status": "0" indicates the availability status of the cross-region gateway center with identifier BJ01, i.e., "status" is 0, meaning the cross-region gateway center with identifier BJ01 is unavailable. The cross-region gateway center informs the service center via a response message that cross-region gateway center SH01 is available and cross-region gateway center BJ01 is unavailable. The service center will not send cross-region transaction requests to the unavailable cross-region gateway center.

[0030] In this embodiment, the payment institution's business center periodically calls the bidirectional probe interface to send request messages to the cross-regional gateway center. The request message includes the business center identifier and availability status of at least one of the payment institution's business centers. The cross-regional gateway center synchronizes the business center identifier and availability status from the request message to other cross-regional gateway centers. Responding to the request message, the cross-regional gateway center sends a response message back to the business center through the bidirectional probe interface. The response message includes the gateway center identifier and availability identifier of multiple cross-regional gateway centers. For both the business center and the cross-regional gateway center, only one probe consisting of a request message and a response message is needed to achieve bidirectional probe between the business center and the cross-regional gateway center, eliminating the need for two probes. This reduces the number of interactions between the business center and the cross-regional gateway center during bidirectional probe, thereby reducing the complexity of bidirectional probe between business centers and cross-regional gateway centers in cross-regional payment scenarios and improving the efficiency of bidirectional probe between business centers and cross-regional gateway centers. Moreover, the business center does not need to probe each cross-regional gateway center. The business center can obtain the availability status of multiple cross-regional gateway centers by randomly or in round-robin. The cross-regional gateway centers also do not need to probe each business center. They can passively receive the availability status of the business centers. This can reduce the number of interactions between the business center and the cross-regional gateway center in a round of probing, simplify the two-way probing process between the business center and the cross-regional gateway center, thereby reducing the complexity of two-way probing between the business cross-regional gateway center and the business center in cross-regional payment scenarios and improving the efficiency of two-way probing between the business cross-regional gateway center and the business center.

[0031] In some embodiments, if a payment institution's business center can perceive the availability status of other business centers within the payment institution, it can send the availability status of all business centers to the cross-regional gateway center at once. Specifically, when a business center can perceive the availability status of other business centers within the payment institution, a request message sent by one business center includes the availability status of all business centers within the payment institution. The business center may have a central status management node, which perceives the availability status of all business centers within the payment institution and aggregates it to generate a request message, which is then used to invoke the bidirectional liveness detection interface to send this request message to the cross-regional gateway center. For example, Figure 4 This is a schematic diagram illustrating an example of a service center sending a request message to a cross-regional gateway center, as provided in an embodiment of this application. Figure 4As shown, the central status management node 31 can perceive the availability status of business center 1, business center 2, and business center 3. All three business centers are available. The central status management node 31 can transmit the information "Business center 1 - Available, Business center 2 - Available, Business center 3 - Available" to the cross-regional gateway center 1 via a request message. A business center can send this request message to any cross-regional gateway center through the central status management node. Upon receiving the request message, the cross-regional gateway center synchronizes the availability status of each business center in the request message with other cross-regional gateway centers through a synchronization mechanism.

[0032] In some embodiments, if a business center is unaware of the availability status of other business centers, each business center may only send its own availability status to the cross-regional gateway center. Multiple cross-regional gateway centers can then merge the availability statuses of all business centers. Specifically, when a business center is unaware of the availability status of other business centers within the payment institution, each business center sends a request message including its own availability status. Multiple cross-regional gateway centers synchronize with each other to merge the availability statuses of the business centers in the received request messages, ensuring that each cross-regional gateway center obtains the availability status of all business centers within the payment institution. For example... Figure 5 This is a schematic diagram illustrating another example of a service center sending a request message to a cross-regional gateway center, as provided in the embodiments of this application. Figure 5 As shown, Business Center 1 sends a request message containing "Business Center 1 - Available" to Cross-Region Gateway Center 1, Business Center 2 sends a request message containing "Business Center 2 - Available" to Cross-Region Gateway Center 1, and Business Center 3 sends a request message containing "Business Center 3 - Available" to Cross-Region Gateway Center 2. Cross-Region Gateway Center 1 and Cross-Region Gateway Center 2 can merge "Business Center 1 - Available", "Business Center 2 - Available", and "Business Center 3 - Available" through a synchronization mechanism so that both Cross-Region Gateway Center 1 and Cross-Region Gateway Center 2 can obtain the availability status of Business Center 1, Business Center 2, and Business Center 3.

[0033] In some embodiments, each cross-regional gateway center may be configured with a storage node, which stores the business center identifier and availability status of the business center. The storage node may include, but is not limited to, a single node with storage capabilities such as Redis. Cross-regional gateway centers may employ a dual-write approach to ensure the consistency of the availability status of business centers across multiple cross-regional gateway centers. Specifically, each cross-regional gateway center first writes the business center identifier and availability status from the request message to its own configured storage node; then, it writes the same information to the storage nodes configured in other cross-regional gateway centers. That is, the cross-regional gateway center first writes to its local storage node and then to a remote storage node. Cross-regional gateway centers may be configured with a management device or module for managing the availability status of business centers, which can execute the dual-write mechanism. In some examples, the two-way activation device in cross-regional payments may include this management device or module. For example, Figure 6 A schematic diagram illustrating an example of the dual-write mechanism for a cross-regional gateway center provided in this application embodiment is shown below. Figure 6 As shown, cross-region gateway center 1 is configured with management device 1 and Redis 1, and cross-region gateway center 2 is configured with management device 2 and Redis 2. After cross-region gateway center 1 receives a request message, management device 1 writes the availability status of the business center in the request message to Redis 1 first, and then to Redis 2. Similarly, after cross-region gateway center 2 receives a request message, management device 2 writes the availability status of the business center in the request message to Redis 2 first, and then to Redis 1. This dual-write method ensures that the failure of a write operation on any one storage node will not affect the use of the cross-region gateway center cluster.

[0034] In some embodiments, each cross-regional gateway center is configured with a storage node. The storage node stores the configuration mapping between the cross-regional gateway center and the business center, the business center identifier, and the availability status of the business center. The cross-regional gateway center can read the information in the storage node to determine which business center to transmit the cross-regional transaction request to. Specifically, the cross-regional gateway center receives the cross-regional transaction request sent by the business center; the cross-regional gateway center reads the business center identifier and availability status of the business center with which it has a configuration mapping with the cross-regional gateway center from the storage node; the cross-regional gateway center sends the cross-regional transaction request to the business center with which it has a configuration mapping and whose availability status indicates availability. The cross-regional transaction request is a transaction request in a cross-regional payment scenario. When the cross-regional gateway center receives a cross-regional transaction request, it needs to query the configuration mapping between the business center and the cross-regional gateway center from the storage node and send the cross-regional transaction request to the business center supported by the cross-regional gateway center, i.e., the business center with which it has a configuration mapping with the cross-regional gateway center. For example, if cross-regional gateway center 1 has a configuration correspondence with business center 1 and business center 2, and cross-regional gateway center 2 has a configuration correspondence with business center 3; if cross-regional gateway center 1 receives a cross-regional transaction request, then cross-regional gateway center 1 will only send the cross-regional transaction request to business center 1 or business center 2; if cross-regional gateway center 2 receives a cross-regional transaction request, then cross-regional gateway center 2 will only send the cross-regional transaction request to business center 3.

[0035] In some examples, the traffic allocation of transaction requests to cross-regional gateway centers can also be controlled by dynamically adjusting the configuration mapping between cross-regional gateway centers and business centers. Specifically, the business center receives a parameter adjustment instruction to adjust the configuration mapping between the cross-regional gateway center and the business center in the request message. The parameter adjustment instruction is used to indicate the adjustment of the configuration mapping, specifically indicating the adjusted configuration mapping between the cross-regional gateway center and the business center. The business center can generate or update the request message according to the parameter adjustment instruction, configuring the configuration mapping between the cross-regional gateway center and the business center in the request message to match the configuration mapping between the cross-regional gateway center and the business center in the parameter adjustment instruction. For example, Figure 7 This is a schematic diagram illustrating an example of cross-regional transaction request transmission between a cross-regional gateway center and a business center before adjustments, as provided in an embodiment of this application. Figure 7 As shown, Business Center 1, Business Center 2, and Business Center 3 transmit the configuration mapping relationship between the cross-regional gateway center and the business centers to the cross-regional gateway center 1 through request messages. Figure 7The terms “Cross-region Gateway Center 1 - Business Center 1”, “Cross-region Gateway Center 1 - Business Center 2”, and “Cross-region Gateway Center 2 - Business Center 3” indicate that Cross-region Gateway Center 1 has a configuration correspondence with Business Center 1 and Business Center 2, and Cross-region Gateway Center 2 has a configuration correspondence with Business Center 3. Correspondingly, Cross-region Gateway Center 1 can send cross-region transaction requests to Business Center 1 and Business Center 2, and Cross-region Gateway Center 2 can send cross-region transaction requests to Business Center 3. Figure 8 This is a schematic diagram illustrating an example of the adjusted cross-regional transaction request transmission between a cross-regional gateway center and a business center provided in this application embodiment. After adjusting the configuration correspondence through parameter adjustment instructions, cross-regional gateway center 1 has a configuration correspondence with business center 1, and cross-regional gateway center 2 has a configuration correspondence with business centers 2 and 3, which can be represented as follows: Figure 8 The configurations "Cross-Region Gateway Center 1 - Business Center 1", "Cross-Region Gateway Center 2 - Business Center 2", and "Cross-Region Gateway Center 2 - Business Center 3" correspond to this. Cross-Region Gateway Center 1 can send cross-regional transaction requests to Business Center 1, and Cross-Region Gateway Center 2 can send cross-regional transaction requests to both Business Center 2 and Business Center 3. By adjusting the configuration mapping between the cross-regional gateway centers and business centers, the cross-regional payment traffic of the cross-regional gateway centers can be dynamically adjusted, making cross-regional payment traffic control more flexible.

[0036] In some examples, during the transmission of cross-regional transaction requests by cross-regional gateway centers, a dual-read approach can be used to ensure the reliability of the availability status reads from the business centers. Specifically, the cross-regional gateway center first reads its own configured storage nodes; if its own configured storage nodes are abnormal, the cross-regional gateway center reads the storage nodes configured by other cross-regional gateway centers. That is, for each cross-regional gateway center, it will first read the local storage nodes and then read the remote storage nodes. The cross-regional gateway center can be configured with a management device or management node for managing the availability status of the business centers, and this management device or management node can perform a dual-write mechanism. For example, such as... Figure 6 As shown, after the cross-regional gateway center 1 receives a cross-regional transaction request, management device 1 first reads Redis 1. If Redis 1 is faulty and the configuration mapping cannot be retrieved from Redis 1, it then reads the configuration mapping from Redis 2. Similarly, after the cross-regional gateway center 2 receives a cross-regional transaction request, management device 2 first reads Redis 2. If Redis 2 is faulty and the configuration mapping cannot be retrieved from Redis 2, it then reads the configuration mapping from Redis 2. This dual-read approach ensures the reliability of the configuration mapping retrieval.

[0037] In some examples, it's possible that all storage nodes configured in the cross-regional gateway center may malfunction. In this case, a preset rule can be triggered to send a cross-regional transaction request to a specific business center. Specifically, if multiple storage nodes configured in the cross-regional gateway center malfunction, the cross-regional gateway center reads the configuration database, retrieves the address of one of the payment institution's business centers from the configuration database, and sends a cross-regional transaction request to that business center. The configuration database is a preset database that stores the business center identifier and address of the payment institution's business centers. The business center address is the communication address. The address of a payment institution's business center retrieved from the configuration database can be any address in the configuration database, or it can be the address of the first business center in the configuration database, or a predetermined business center address can be pre-set in the configuration database. In the event of all storage nodes malfunctioning, the address of the payment institution's business center retrieved from the configuration database can be this predetermined business center address; this is not limited here.

[0038] In some embodiments, the cross-regional gateway center can periodically monitor the availability status updates of the service centers it stores to dynamically detect whether a service center is abnormal. Specifically, the cross-regional gateway center periodically monitors the update time of the service center identifier and availability status of the stored service centers; if the interval between the latest update time and the current monitoring time is longer than an abnormal duration threshold, an alarm message is issued. The alarm message indicates that a service center with an interval longer than the abnormal duration threshold has experienced an anomaly. The update time of the service center identifier and availability status of the service centers stored by the cross-regional gateway center is the time when the cross-regional gateway center receives the request message. The duration of the monitoring period for the service center identifier and availability status of the stored service centers can be determined based on the scenario, requirements, experience, etc., and is not limited here. For example, the duration of the monitoring period for the service center identifier and availability status of the stored service centers can be shorter than the duration of the service center sending the request message; for example, the duration of the monitoring period for the service center identifier and availability status of the stored service centers can be 1 second. The anomaly duration threshold is a time limit used to determine whether an anomaly has occurred. It can be set according to the scenario, requirements, experience, etc., and is not limited here. For example, the anomaly duration threshold could be 30 seconds. If the interval between the latest update event and the current detection time is longer than the anomaly duration threshold, it indicates that the business center has not reported the request message for longer than the anomaly duration threshold, and it is highly likely that an anomaly has occurred in the business center. Alarm messages can be sent to alert operations personnel so that they can handle the anomaly in the business center. In some examples, if the interval between the latest update time and the current monitoring time is longer than the anomaly duration threshold, the business center with an interval longer than the anomaly duration threshold can also be isolated. Update time monitoring can be implemented by the management node or management device in the above embodiments, and is not limited here.

[0039] In some embodiments, the cross-regional gateway center may also be configured with a gateway status management device or a gateway status management module, and the two-way activation device in cross-regional payment may include the gateway status management device or the gateway status management module. The gateway status management device or the gateway status management module can receive operation and maintenance setting instructions, which may include the availability status of each cross-regional gateway center. The gateway status management device or the gateway status management module stores the availability status of each cross-regional gateway center according to the operation and maintenance setting instructions, thereby facilitating the cross-regional gateway center to generate a response message to return to the business center based on the stored availability status of each cross-regional gateway center.

[0040] For ease of understanding, the cross-regional payment process in the embodiments of this application is described below. Figure 9 A schematic diagram illustrating an example of a cross-regional payment process provided in an embodiment of this application, such as... Figure 9 As shown, the cross-regional payment process may include steps a1 to a6.

[0041] In step a1, the business center sends a request message to the cross-regional gateway center. This request message is used to request bidirectional liveness detection.

[0042] In step a2, the cross-regional gateway center stores the availability status of the service center in the request message in the management module.

[0043] In step a3, the cross-regional gateway center obtains the availability status of the cross-regional gateway center from the gateway status management module.

[0044] In step a4, the cross-regional gateway center sends a response message to the business center.

[0045] In step a5, the cross-regional gateway center determines the available service centers from the management module.

[0046] In step a6, the cross-regional gateway center sends a cross-regional transaction request to the available business center.

[0047] The specific details of steps a1 to a6 above can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0048] This application also provides a two-way activity detection device for cross-regional payments, which can be set at the cross-regional gateway center. Figure 10 This is a schematic diagram of the structure of a two-way activity detection device in cross-regional payment provided in an embodiment of this application, as shown below. Figure 10 As shown, the two-way detection device 400 in the cross-regional payment may include a receiving module 401, a synchronization module 402, and a sending module 403.

[0049] The receiving module 401 can be used to receive request messages periodically sent by the payment institution's business center calling the bidirectional activation interface. The request message includes the business center identifier and availability status of at least one business center of the payment institution.

[0050] The synchronization module 402 can be used by a cross-regional gateway center to synchronize the business center identifier and availability status of a business center to other cross-regional gateway centers based on a request message.

[0051] The sending module 403 can be used to respond to request messages. The cross-regional gateway center sends a response message to the service center that sent the request message through a bidirectional liveness detection interface. The response message includes the gateway center identifier and availability status of multiple cross-regional gateway centers.

[0052] In some embodiments, the request message may also include the configuration mapping between cross-regional gateway centers and business centers.

[0053] In some embodiments, a request message conforming to the two-way activation detection interface format includes primary information and secondary information. The primary information includes the payment institution's identifier, and the secondary information includes a business center status list. The business center status list includes at least one set of first center information, each set including the gateway center identifier of a cross-regional gateway center and the business center identifiers and availability status of business centers with configured correspondences across cross-regional gateway centers. A response message conforming to the two-way activation detection interface format includes primary information and secondary information. The primary information includes a response code, and the secondary information includes a cross-regional gateway center status list. The cross-regional gateway center status list includes at least one set of second center information, each set including the gateway center identifier and availability status of a cross-regional gateway center.

[0054] In some embodiments, when a business center is aware of the availability status of other business centers of the payment institution, a request message sent by one business center includes the availability status of all business centers of the payment institution. When a business center is not aware of the availability status of other business centers of the payment institution, each business center sends a request message including its own availability status. Multiple cross-regional gateway centers synchronize with each other to merge the availability status of business centers in the received request messages, so that each cross-regional gateway center obtains the availability status of all business centers of the payment institution.

[0055] In some embodiments, each cross-regional gateway center is configured with a storage node. The synchronization module 402 may be specifically configured to: first, write the service center identifier and availability status in the request message to its own configured storage node; then, write the service center identifier and availability status in the request message to the storage nodes configured by other cross-regional gateway centers.

[0056] In some embodiments, each cross-regional gateway center is configured with a storage node, which stores the configuration mapping between the cross-regional gateway center and the service center, the service center identifier, and the availability status of the service center. The receiving module 401 can be used to receive cross-regional transaction requests sent by the service center. The receiving module 401 and the sending module 403 can be used to read the service center identifier and availability status of the service center that has a configuration mapping with the cross-regional gateway center from the storage node. The sending module 403 can be used to send the cross-regional transaction request to the service center that has a configuration mapping with the cross-regional gateway center and whose availability status indicates availability.

[0057] In some embodiments, the receiving module 401 and the sending module 403 can be used to: first read the storage nodes configured by themselves; if the storage nodes configured by themselves are abnormal, then read the storage nodes configured by other cross-regional gateway centers among the multiple cross-regional gateway centers. The receiving module 401 and the sending module 403 can also be used to: if the storage nodes configured by multiple cross-regional gateway centers are all abnormal, then read the configuration database, obtain the address of a business center of the payment institution from the configuration database, and send a cross-regional transaction request to the obtained business center of the payment institution.

[0058] In some embodiments, the two-way activity detection device 400 in cross-regional payments may further include a monitoring module and an alarm module. The monitoring module is used to periodically monitor the update time of the business center identifier and availability status of the stored business centers. The alarm module is used to issue an alarm message if the interval between the latest update time and the current monitoring time exceeds an abnormal duration threshold, indicating that an anomaly has occurred in the business center where the interval exceeds the abnormal duration threshold.

[0059] It should be noted that the two-way activity detection device 400 in the cross-regional payment is a device corresponding to the two-way activity detection method in the cross-regional payment described above. All implementation methods in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effect. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0060] This application also provides an electronic device. Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, as shown below. Figure 11 As shown, the electronic device 500 includes a memory 501, a processor 502, and a computer program stored in the memory 501 and executable on the processor 502.

[0061] In some examples, the processor 502 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that may be configured to implement the embodiments of this application.

[0062] Memory 501 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the bidirectional probe method in cross-regional payments according to embodiments of this application.

[0063] The processor 502 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 501, so as to implement the two-way detection method in cross-regional payment in the above embodiment.

[0064] In some examples, the electronic device 500 may also include a communication interface 503 and a bus 504. For example, Figure 11 As shown, the memory 501, processor 502, and communication interface 503 are connected through bus 504 and complete communication with each other.

[0065] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 503.

[0066] Bus 504 includes hardware, software, or both, that couples the components of electronic device 500 together. For example, and not as a limitation, bus 504 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 504 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0067] This application also provides a computer-readable storage medium storing computer program instructions. When executed by a processor, these computer program instructions can implement the two-way activation method in cross-regional payment described in the above embodiments, achieving the same technical effect. To avoid repetition, further details are omitted here. The aforementioned computer-readable storage medium may include non-transitory computer-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, etc., and is not limited thereto.

[0068] This application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the two-way activation method in cross-regional payment in the above embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0069] It should be clarified that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. For the device embodiments, equipment embodiments, system embodiments, computer-readable storage medium embodiments, and computer program product embodiments, the relevant parts can be referred to the description section of the method embodiments. This application is not limited to the specific steps and structures described above and shown in the figures. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application. Furthermore, for the sake of brevity, detailed descriptions of known methods and techniques are omitted here.

[0070] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0071] Those skilled in the art will understand that the above embodiments are exemplary and not restrictive. Different technical features appearing in different embodiments can be combined to achieve beneficial effects. Based on a study of the drawings, specification, and claims, those skilled in the art should be able to understand and implement other variations of the disclosed embodiments. In the claims, the term "comprising" does not exclude other means or steps; the quantifier "a" does not exclude a plurality; the terms "first" and "second" are used to identify names and not to indicate any particular order. No reference numerals in the claims should be construed as limiting the scope of protection. The functionality of multiple parts appearing in the claims can be implemented by a single hardware or software module. The appearance of certain technical features in different dependent claims does not mean that these technical features cannot be combined to achieve beneficial effects.

Claims

1. A two-way activation method for cross-regional payments, characterized in that, include: The cross-regional gateway center receives request messages periodically sent by the payment institution's business center through the bidirectional activation interface. The request messages include the business center identifier and availability status of at least one of the payment institution's business centers. Based on the request message, the cross-regional gateway center synchronizes the business center identifier and availability status of the business center to other cross-regional gateway centers. In response to the request message, the cross-regional gateway center sends a response message to the service center that sent the request message through the bidirectional liveness detection interface. The response message includes gateway center identifiers and availability status of multiple cross-regional gateway centers.

2. The method according to claim 1, characterized in that, The request message also includes the configuration correspondence between the cross-regional gateway center and the business center.

3. The method according to claim 1, characterized in that, The request message conforming to the bidirectional liveness detection interface format includes first-level information and second-level information. The first-level information includes the institution identifier of the payment institution, and the second-level information includes a business center status list. The business center status list includes at least one set of first-center information. Each set of first-center information includes the gateway center identifier of a cross-regional gateway center and the business center identifier and availability status of a business center with a configuration correspondence between the cross-regional gateway centers. The response message conforming to the bidirectional liveness detection interface format includes primary information and secondary information. The primary information includes a response code, and the secondary information includes a cross-regional gateway center status list. The cross-regional gateway center status list includes at least one set of secondary center information, and each set of secondary center information includes the gateway center identifier and availability status of a cross-regional gateway center.

4. The method according to claim 1, characterized in that, If a business center is able to perceive the availability status of other business centers of the payment institution, the request message sent by one business center includes the availability status of all business centers of the payment institution. In the absence of a business center being aware of the availability status of other business centers of the payment institution, each business center sends a request message that includes its own availability status. Multiple cross-regional gateway centers synchronize with each other to merge the availability status of the business centers in the received request messages, so that each cross-regional gateway center obtains the availability status of all business centers of the payment institution.

5. The method according to claim 2, characterized in that, Also includes: The business center receives a parameter adjustment instruction and adjusts the configuration correspondence between the cross-regional gateway center and the business center in the request message.

6. The method according to claim 1, characterized in that, Each cross-regional gateway center is configured with one storage node; Based on the request message, the cross-regional gateway center synchronizes the business center identifier and availability status of the business center to other cross-regional gateway centers, including: The cross-regional gateway center first writes the business center identifier and availability status in the request message into its own configured storage node; The cross-regional gateway center then writes the service center identifier and availability status from the request message into the storage nodes configured by other cross-regional gateway centers.

7. The method according to claim 1, characterized in that, Each cross-regional gateway center is configured with a storage node, which stores the configuration mapping between the cross-regional gateway center and the business center, the business center identifier of the business center, and the availability status. The method further includes: The cross-regional gateway center receives cross-regional transaction requests sent by the business center; The cross-regional gateway center reads the business center identifier and availability status of the business center in the storage node that has a configuration correspondence with the cross-regional gateway center; The cross-regional gateway center sends cross-regional transaction requests to the business center that has a configuration correspondence with the cross-regional gateway center and whose availability status indicates availability.

8. The method according to claim 7, characterized in that, The cross-region gateway center reads the business center identifier and availability status from the storage nodes of the business centers that have a configuration correspondence with the cross-region gateway center, including: The cross-regional gateway center first reads its own configured storage nodes; If its own configured storage node is abnormal, the cross-regional gateway center will read the storage nodes configured by other cross-regional gateway centers. The method further includes: If the storage nodes configured in multiple cross-regional gateway centers are all abnormal, the cross-regional gateway center reads the configuration database, obtains the address of one of the payment institution's business centers from the configuration database, and sends a cross-regional transaction request to the obtained business center of the payment institution.

9. The method according to claim 1, characterized in that, Also includes: The cross-regional gateway center periodically monitors the update time of the business center identifier and availability status of the stored business centers; If the interval between the latest update time and the current monitoring time is longer than the abnormal duration threshold, the cross-regional gateway center will issue an alarm message, indicating that an anomaly has occurred in the service center where the interval is longer than the abnormal duration threshold.

10. A two-way activity detection device for cross-regional payments, characterized in that, include: The receiving module is used to receive request messages periodically sent by the business center of the payment institution through the bidirectional activation interface. The request message includes the business center identifier and availability status of at least one business center of the payment institution. The synchronization module is used by the cross-regional gateway center to synchronize the business center identifier and availability status of the business center to other cross-regional gateway centers based on the request message. The sending module is used to respond to the request message. The cross-regional gateway center sends a response message to the service center that sent the request message through the bidirectional liveness detection interface. The response message includes gateway center identifiers and availability status of multiple cross-regional gateway centers.

11. A two-way activation system for cross-regional payments, characterized in that, include: The business center is used to periodically call the bidirectional liveness detection interface to send request messages to the cross-regional gateway center. The request message includes the business center identifier and availability status of at least one business center of the payment institution. A cross-regional gateway center, communicating with a business center, is used to synchronize the business center identifier and availability status of the business center to other cross-regional gateway centers according to the request message; and is used to respond to the request message by sending a response message to the business center that sent the request message through the bidirectional liveness detection interface, the response message including the gateway center identifier and availability status of the multiple cross-regional gateway centers.

12. An electronic device, characterized in that, include: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the two-way activation method in cross-regional payment as described in any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the two-way liveness detection method in cross-regional payments as described in any one of claims 1 to 9.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the bidirectional liveness detection method in cross-regional payments as described in any one of claims 1 to 9.

Images