Payment method, system and architecture

Abstract

Provided in the present disclosure are a payment method, system and architecture. The method comprises: acquiring a payment request from a payment client; on the basis of the payment request and channel information of payment channels, determining the current payment channel; and controlling the current payment channel to make a transaction with the payment client, the current payment channel being any payment channel among a plurality of payment channels of a payment system, the plurality of payment channels being mutually independent of each other, the plurality of payment channels all being connected to a route interface and a payment interface of the payment system, the route interface being configured to connect to a plurality of payment routes by means of an access protocol of each payment route, the payment interface being configured to connect to the payment client, and the payment channels being configured to transmit to the route interface information acquired by the payment interface. The route interface in the present disclosure connects to the plurality of payment routes by means of the access protocol of each payment route, and the payment client only needs to meet an interface protocol of the payment system but does not need to individually connect to each payment route, improving payment access efficiency and convenience.

Description

Payment methods, systems and architectures

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This disclosure claims priority to Chinese patent application number 2024101149233, entitled “Payment Method, System and Architecture,” filed with the Chinese Patent Office on January 26, 2024, the entire contents of which are incorporated by reference into this disclosure. Technical Field

[0003] The present disclosure relates to the field of online payment, and more specifically, to a payment method, system, and architecture. Background Art

[0004] Currently, online payments support multiple payment channels, such as banks, third-party financial platforms, and e-wallets. Each payment channel has its own corresponding interface and protocol. Users need to understand and adapt to the technical requirements of each channel to complete transactions, which affects the efficiency and convenience of payment access.

[0005] Application Contents

[0006] In view of this, the purpose of the embodiments of the present disclosure is to provide a payment method, system and architecture that can improve the efficiency and convenience of payment access.

[0007] An embodiment of the present disclosure provides a payment method, which includes: obtaining a payment request from the payment terminal; determining a current payment channel based on the payment request and channel information of the payment channel; controlling the current payment channel to conduct transactions with the payment terminal; wherein the current payment channel is any one of multiple payment channels of a payment system, and the multiple payment channels are independent of each other; the multiple payment channels are all connected to a channel interface and a payment interface of the payment system; the channel interface is configured to access multiple payment channels through an access protocol of each payment channel, the payment interface is configured to access the payment terminal, and the payment channel is configured to transmit information obtained by the payment interface to the channel interface.

[0008] In the above implementation process, multiple payment channels are connected to the channel interface and payment interface of the payment system, and the channel interface is connected to multiple payment channels through the access protocol of each payment channel. When payment is required, the payment terminal only needs to establish a connection with the payment interface. That is, the payment terminal only needs to meet the interface protocol of the payment system, and there is no need to connect to each payment channel separately. This can greatly reduce the user's development and maintenance costs and improve the efficiency and convenience of payment access. In addition, after obtaining a payment request, the current payment channel is determined based on both the payment request and the channel information, which can improve the accuracy of the current payment channel determination.

[0009] In one embodiment, each payment channel is provided with a corresponding abnormality threshold, and determining the current payment channel based on the payment request and the channel information of the payment channel includes: judging whether the abnormality of the payment channel in the payment system exceeds the corresponding abnormality threshold; fusing the payment channel whose abnormality exceeds the corresponding abnormality threshold; and determining the current payment channel based on the payment request and the payment channel that has not been blown.

[0010] In the above implementation, when determining the current payment channel, the abnormal payment channel is first identified based on the relationship between the abnormality of the payment channel and the abnormality threshold, and the abnormal payment channel is then disconnected. Determining the current payment channel from the unconnected payment channels can reduce the occurrence of payment anomalies caused by payment channels, improve payment success rate, and enhance payment stability.

[0011] In one embodiment, each payment channel is provided with a corresponding circuit breaker period, and the method further includes: determining whether the circuit breaker period of the circuit breaker payment channel has ended; if the circuit breaker period of the circuit breaker payment channel has ended, selecting a low-risk order to trade with the circuit breaker payment channel; and determining whether the corresponding circuit breaker payment channel has returned to normal based on the transaction result of the low-risk order.

[0012] In the above implementation, by setting a circuit breaker period, the broken payment channel can be repaired within the period. After the circuit breaker period expires, the broken payment channel is verified through low-risk orders. Successful verification restores the verified payment channel to normal. This improves the timeliness of the broken payment channel and the accuracy of its restoration.

[0013] In one embodiment, at least one of the multiple payment channels is provided with a backup channel, and determining the current payment channel based on the payment request and the channel information of the payment channel includes: judging whether there is an abnormality in the payment channel corresponding to the payment request; if there is an abnormality in the payment channel corresponding to the payment request, judging whether the payment channel corresponding to the payment request is provided with the backup channel; if the payment channel corresponding to the payment request is provided with the backup channel, determining that the backup channel is the current payment channel.

[0014] In the above implementation process, when there is an abnormality in the payment channel corresponding to the payment request, if the payment channel is set with a backup payment channel, the backup payment channel is determined to be the current payment channel for transactions. Providing services through the backup payment channel can reduce the impact range of the payment channel failure, ensure the continuity and availability of the system, and improve the stability of payment.

[0015] In one embodiment, at least one of the multiple payment channels is provided with a backup channel, and determining the current payment channel based on the payment request and the channel information of the payment channel includes: judging whether there is an abnormality in the payment channel corresponding to the payment request; if there is an abnormality in the payment channel corresponding to the payment request, judging whether the payment channel corresponding to the payment request is an available channel; if the payment channel corresponding to the payment request is an unavailable channel, judging whether the payment channel corresponding to the payment request is provided with the backup channel; if the payment channel corresponding to the payment request is provided with the backup channel, determining that the backup channel is the current payment channel.

[0016] In the above implementation process, by further judging the abnormality of the payment channel, the transaction is completed through the backup channel only when it is determined that the payment channel is an unavailable channel, thereby improving the accuracy of the abnormality judgment of the payment channel and further improving the stability of payment.

[0017] In one embodiment, after controlling the current payment channel to conduct a transaction with the payment terminal, the method further includes: determining whether the transaction is successful; if the transaction fails, recording the failure in the failure statistics, and determining whether the current payment channel meets the circuit breaker standard; if the circuit breaker standard is met, marking the current payment channel as abnormal and performing a circuit breaker.

[0018] In the above implementation process, after each transaction, the transaction results are counted to update the status of the current payment channel according to the corresponding circuit breaker standard or recovery standard, thereby improving the accuracy of the current payment channel information.

[0019] In one embodiment, the multiple payment channels are set in a payment system, the payment systems are set in corresponding regions, and one or more payment systems are set in each region; after obtaining the payment request from the payment terminal, the method also includes: determining whether the payment system in the area corresponding to the payment request is available; if the payment system in the area corresponding to the payment request is not available, determining the domain name zone associated with the payment system in the area corresponding to the payment request; and forwarding the payment request to other payment systems corresponding to the domain name zone.

[0020] In the above implementation process, if the payment system of a certain area is unavailable, you can switch to the domain name area associated with the area, and forward the payment request to other payment systems corresponding to the domain name area, so that transactions can be conducted through other payment systems. You can get fast and stable service responses, enjoy a seamless system access experience, and be able to conduct transactions smoothly at all times and places, enhancing the user experience while improving payment stability.

[0021] An embodiment of the present disclosure also provides a payment system, comprising: multiple payment channels and a controller, wherein the multiple payment channels are independent of each other; the multiple payment channels are all connected to the channel interface and payment interface of the payment system, the channel interface is configured to access multiple payment channels through the access protocol of each payment channel, the payment interface is configured to access the payment end, and the payment channel is configured to transmit information obtained by the payment interface to the channel interface; the controller is respectively connected to the multiple payment channels; the controller is configured to obtain the payment request of the payment end, and determine the current payment channel based on the payment request and the channel information of the payment channel; the controller is also configured to control the current payment channel to conduct transactions with the payment end.

[0022] In the above implementation process, a channel interface is set up, and this channel interface accesses multiple payment channels through the access protocol of each payment channel. Multiple payment channels can then be connected to multiple payment channels through the channel interface. In addition, multiple payment channels are also connected to the payment interface, so that the payment system provides a unified payment access interface. When the payment end uses payment requests using different payment methods, the payment end only needs to connect to the payment system's payment interface, without having to connect to each payment channel separately. This can greatly reduce users' development and maintenance costs and improve the efficiency and convenience of payment access.

[0023] The disclosed embodiment also provides a payment architecture, comprising: a plurality of payment systems as described in claim 8; a plurality of said payment systems are arranged in a plurality of regions, and each region is provided with one or more said payment systems; wherein, if the said payment system in a certain region is unavailable, the transaction is switched to the said payment system in other regions.

[0024] In the above implementation process, by setting up corresponding payment systems in various regions, when the payment system in a certain region is unavailable, transactions can be switched to the payment systems in other regions, thereby improving the stability and security of the entire payment architecture and enhancing the user experience.

[0025] In one embodiment, the payment architecture manages the multiple payment systems through Kubernetes.

[0026] In the above implementation, Kubernetes is configured to manage multiple payment systems. When a node or container instance fails, the load is automatically transferred to other healthy nodes, enabling seamless service transfer and continuous payment service, improving payment stability. System resources are automatically adjusted based on the actual payment request volume and load, ensuring the payment system can efficiently handle a large number of concurrent requests, achieving high availability and optimized performance for the payment architecture. Furthermore, node or container instance failures can be quickly detected and automatically repaired, reducing system downtime and the risk of data loss.

[0027] An embodiment of the present disclosure further provides an electronic device, comprising: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method in the above-mentioned first aspect, or any possible implementation of the first aspect.

[0028] The disclosed embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the payment method according to the first aspect or any possible implementation of the first aspect are executed.

[0029] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, the following embodiments are given in conjunction with the accompanying drawings for detailed description as follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0031] FIG1 is a schematic diagram of a payment system provided by an embodiment of the present disclosure;

[0032] FIG2 is a block diagram of a controller provided in an embodiment of the present disclosure;

[0033] FIG3 is a flow chart of a payment method provided in an embodiment of the present disclosure;

[0034] FIG4 is a flow chart of determining the current payment channel according to an embodiment of the present disclosure;

[0035] FIG5 is a flowchart of transaction success determination according to an embodiment of the present disclosure;

[0036] FIG6 is a schematic diagram of a multi-region payment system interaction provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0037] The technical solutions in the embodiments of the present disclosure will be described below with reference to the accompanying drawings.

[0038] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of the present disclosure, the terms "first," "second," etc. are only configured to distinguish the description and should not be understood as indicating or implying relative importance.

[0039] A payment system is a combination of software and hardware configured to process financial transactions. It acts as a bridge between merchants, consumers, and financial institutions, enabling all parties to conduct payment and settlement operations securely and efficiently. A payment system includes the following components and functions: 1. Provides a standardized payment interface that enables merchants to receive payment requests from consumers. 2. Supports multiple payment channels, including banks, third-party payment platforms, and e-wallets. 3. Implements security measures such as data encryption, fraud detection, and identity verification. 4. Routes payment requests to the appropriate payment channel and provides payment results feedback to merchants and consumers. 5. Tracks and manages the status and information of payment orders. 6. Provides data statistics and reporting capabilities to help merchants analyze payment transactions and payment channel performance. 7. Handles the settlement and fund clearing of payment transactions.

[0040] However, after long-term research, the inventors of the present disclosure found that the payment system involves docking with banks, and docking with multiple bank channels involves technical complexity, access barriers, maintenance and updates, fund management, risk and security, data integration and reporting, and other pain points, which bring additional workload, time and cost to users. For example: Technical complexity: Each bank channel may use different interfaces and protocols, and merchants need to understand and adapt to the technical requirements of each channel. This may involve different API integration, data formats, encryption algorithms, etc., which require users to have corresponding technical capabilities and resources. Access barriers: Different bank channels may have different access processes and requirements, including compliance reviews, contract signing, testing and certification, etc. Users need to spend time and resources to meet these requirements in order to complete the docking process. Slow fault response capability: If a problem occurs in a bank channel and it is impossible to switch to other channels in time, some transactions may fail and financial losses may occur.

[0041] In view of this, the inventors of the present disclosure have proposed a payment method, which connects multiple payment channels to the channel interface and payment interface of the payment system, and the channel interface accesses multiple payment channels through the access protocol of each payment channel. When payment is required, the payment end only needs to establish a connection with the payment interface, that is, the payment end only needs to meet the interface protocol of the payment system, and there is no need to connect to each payment channel separately, which can greatly reduce the user's development and maintenance costs and improve the efficiency and convenience of payment access. In addition, after obtaining the payment request, since the current payment channel is determined based on both the payment request and the channel information, the accuracy of the current payment channel can be improved.

[0042] To facilitate understanding of this embodiment, a payment system for executing a payment method disclosed in an embodiment of the present disclosure is first introduced in detail.

[0043] FIG1 is a schematic diagram of a payment system according to an embodiment of the present disclosure, which includes a plurality of payment channels 200 ( FIG1 shows three payment channels, namely payment channel A, payment channel B, and payment channel C) and a controller 100 .

[0044] Among them, the multiple payment channels 200 are independent of each other; the multiple payment channels 200 are all connected to the channel interface and payment interface of the payment system.

[0045] The payment channel 200 here is configured to transmit the information obtained by the payment interface to the channel interface.

[0046] The channel interface is configured to access multiple payment channels through each payment channel's access protocol. For example, the payment channels may include Bank A, Bank B, Bank C, Bank D, a third-party payment platform, and an e-wallet. The payment channel type can be adjusted based on actual circumstances and is not specifically limited in this disclosure.

[0047] In one embodiment, the channel interface may be connected to multiple payment channels through a gateway interface or a payment interface according to the access protocol of each payment channel.

[0048] Each payment channel may correspond to one or more payment channels 200. The corresponding relationship between the payment channel and the payment channel 200 may be adjusted according to actual conditions, and this disclosure does not impose any specific restrictions.

[0049] The payment interface is configured to access the payment terminal, which is connected to the payment interface via the access protocol of the payment system.

[0050] It should be understood that since the payment system provides a unified payment access interface, when the payment end uses payment requests with different payment methods, the payment end only needs to connect with the payment interface of the payment system, and does not need to connect with each payment channel separately.

[0051] The controller 100 is respectively connected to a plurality of payment channels 200. The controller 100 is configured to obtain a payment request from a payment terminal and determine a current payment channel 200 according to the payment request and channel information of the payment channel 200.

[0052] In one embodiment, the controller 100 is further configured to control the current payment channel 200 to conduct transactions with the payment terminal.

[0053] As shown in FIG2 , the controller 100 may include a memory 111 and a processor 113. Those skilled in the art will appreciate that the structure shown in FIG1 is merely illustrative and does not limit the structure of the controller 100. For example, the controller 100 may include more or fewer components than shown in FIG1 , or may have a configuration different from that shown in FIG1 .

[0054] The memory 111 and processor 113 are electrically connected to each other, directly or indirectly, to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The processor 113 is configured to execute the executable modules stored in the memory.

[0055] The memory 111 may be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The memory 111 is configured to store a program, and the processor 113 executes the program after receiving an execution instruction. The method executed by the controller 100 defined by the process disclosed in any embodiment of the present disclosure may be configured in the processor 113 or implemented by the processor 113.

[0056] The processor 113 may be an integrated circuit chip with signal processing capabilities. The processor 113 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The various methods, steps and logic block diagrams disclosed in the embodiments of the present disclosure may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0057] The controller 100 in this embodiment can be configured to execute each step in each method provided in the embodiments of the present disclosure.

[0058] In the above implementation process, a channel interface is set up, and this channel interface accesses multiple payment channels through the access protocol of each payment channel. Multiple payment channels can then be connected to multiple payment channels through the channel interface. In addition, multiple payment channels are also connected to the payment interface, so that the payment system provides a unified payment access interface. When the payment end uses payment requests using different payment methods, the payment end only needs to connect to the payment system's payment interface, without having to connect to each payment channel separately. This can greatly reduce users' development and maintenance costs and improve the efficiency and convenience of payment access.

[0059] In a possible implementation, the embodiment of the present disclosure further provides a payment architecture, including: multiple payment systems as described above.

[0060] Multiple payment systems are set up in multiple regions, with each region having one or more payment systems. The number of payment systems set up in each region can be the same or different. The number of payment systems set up in each region can be selected based on actual circumstances and is not specifically limited in this disclosure.

[0061] The regions here can be divided according to city level, province, country, global level, etc. For example, the region can be divided into seven regions according to country: East China, Central China, North China, South China, Southwest China, Northwest China and Northeast China.

[0062] Among them, if the payment system in a certain region is unavailable, the transaction will be switched to the payment system in other regions.

[0063] It should be understood that the various payment systems in this payment architecture can serve as backups for each other. When the payment system in one region is unavailable, transactions can be conducted through the payment systems in other regions, thereby enhancing the stability and security of the entire payment architecture and the user experience.

[0064] In some embodiments, if multiple payment systems are set up in the same region, when a payment system in the same region is unavailable, transactions can be switched to other payment systems in the region.

[0065] It is understood that when switching to another payment system, the switching can be performed according to a set switching rule. For example, the switching rule may be switching to another payment system under the same domain name, switching to the nearest payment system, etc. The switching rule can be adjusted according to actual circumstances and is not specifically limited by this disclosure.

[0066] In the above implementation process, by setting up corresponding payment systems in various regions, when the payment system in a certain region is unavailable, transactions can be switched to the payment systems in other regions, thereby improving the stability and security of the entire payment architecture and enhancing the user experience.

[0067] In one possible implementation, the payment architecture manages multiple payment systems through Kubernetes.

[0068] Kubernetes is an open-source platform designed to automate and orchestrate the deployment, scaling, and management of containerized applications and workloads. Leveraging Kubernetes' high elasticity and automation, the payment system can automatically transfer workloads to healthy nodes when a node or container instance fails, ensuring seamless service transition and continuous payment service. Furthermore, system resources can be automatically adjusted based on actual payment request volume and load, ensuring the payment system can efficiently handle large numbers of concurrent requests while achieving high availability and optimized performance.

[0069] In addition, Kubernetes can also provide fault detection, self-healing capabilities and automatic recovery mechanisms, which can quickly detect and automatically repair node or container instance failures to reduce system downtime and data loss risks.

[0070] In the above implementation, Kubernetes is configured to manage multiple payment systems. When a node or container instance fails, the load is automatically transferred to other healthy nodes, enabling seamless service transfer and continuous payment service, improving payment stability. System resources are automatically adjusted based on the actual payment request volume and load, ensuring the payment system can efficiently handle a large number of concurrent requests, achieving high availability and optimized performance for the payment architecture. Furthermore, node or container instance failures can be quickly detected and automatically repaired, reducing system downtime and the risk of data loss.

[0071] Please refer to Figure 3, which is a flow chart of the payment method provided by the embodiment of the present disclosure. The specific process shown in Figure 3 will be described in detail below.

[0072] Step 201: Obtain a payment request from the payment terminal.

[0073] The payment terminal here refers to a terminal configured for payment, such as a mobile phone, tablet, computer, smartwatch, etc.

[0074] The above-mentioned payment requests include, but are not limited to, order requests, transfer requests, and collection requests. The type of payment request can be adjusted according to the actual application scenario. For example, if the payment method is configured for an online merchant, the payment request can be an order request. If the payment method is configured for an offline supermarket, the payment request can be a collection request. This disclosure does not limit the specific type of payment request.

[0075] Optionally, the payment request can be obtained after the payment request is generated, triggered by the payment request; it can also be obtained in real time, or it can be obtained at set intervals. The specific method of obtaining the payment request can be adjusted according to actual circumstances and is not specifically limited by this disclosure.

[0076] Step 202: Determine the current payment channel based on the payment request and the channel information of the payment channel.

[0077] The current payment channel is any one of the multiple payment channels of the payment system, and the multiple payment channels are independent of each other. The multiple payment channels are all connected to the channel interface and payment interface of the payment system.

[0078] The channel interface is configured to access multiple payment channels through the access protocol of each payment channel. The payment interface is configured to access the payment terminal, and the payment channel is configured to transmit the payment information of the payment interface to the channel interface.

[0079] At least one of the multiple payment channels is configured with a backup channel. Each payment channel may be configured with one or more backup channels. The configuration of the backup channels of the payment channels may be adjusted based on actual circumstances and is not specifically limited in this disclosure.

[0080] In one embodiment, each payment channel is assigned a corresponding abnormality threshold. When the abnormality in a payment channel exceeds the threshold, the payment channel is determined to be abnormal. When a payment channel is determined to be abnormal, the payment channel is disconnected and marked as abnormal.

[0081] Each payment channel can be set with a corresponding circuit breaker period, during which the payment channel can be repaired. When the circuit breaker period is reached, the payment channel can be verified to see if it has returned to normal. If it is verified that the payment channel has returned to normal, the payment channel will be restored and marked as normal.

[0082] The payment request may include various information such as payment information, payer information, payment type, and channel information. The information included in the payment request may be adjusted according to actual circumstances, and this disclosure does not impose specific limitations.

[0083] The channel information here may include the status of the channel, backup channel information, the payment channel corresponding to the channel, etc. The channel information can be adjusted according to actual conditions, and this disclosure does not impose specific restrictions.

[0084] It should be understood that since multiple payment channels are provided and these multiple payment channels correspond to multiple payment channels, different payment requests may correspond to different payment channels. Therefore, after receiving a payment request, one or more candidate payment channels corresponding to the current payment request can be determined based on the information in the payment request. Then, available payment channels can be determined based on the channel information of these candidate payment channels, and the current payment channel can be determined from among the available payment channels.

[0085] In one embodiment, the above-mentioned multiple payment channels are set in a payment system, that is, one payment system includes multiple payment channels.

[0086] The payment systems here are set up in the corresponding regions, and each region has one or more payment systems.

[0087] Step 203: Control the current payment channel to conduct transactions with the payment terminal.

[0088] It should be understood that after the current payment channel is determined, the payment request can be sent to the current payment channel to conduct the transaction according to the payment request through the current payment channel.

[0089] In the above implementation process, multiple payment channels are connected to the channel interface and payment interface of the payment system, and the channel interface is connected to multiple payment channels through the access protocol of each payment channel. When payment is required, the payment terminal only needs to establish a connection with the payment interface. That is, the payment terminal only needs to meet the interface protocol of the payment system, and there is no need to connect to each payment channel separately. This can greatly reduce the user's development and maintenance costs and improve the efficiency and convenience of payment access. In addition, after obtaining a payment request, the current payment channel is determined based on both the payment request and the channel information, which can improve the accuracy of the current payment channel determination.

[0090] In one possible implementation, step 202 includes: determining whether an abnormality of a payment channel in the payment system exceeds a corresponding abnormality threshold; tripping the payment channel whose abnormality exceeds the corresponding abnormality threshold; and determining the current payment channel based on the payment request and the untripped payment channels.

[0091] The abnormal situations here include channel exception processing requests, failed order ratio, etc.

[0092] The above-mentioned abnormality threshold is the maximum number of abnormalities allowed for each payment channel. For example, the abnormality threshold can be set to 2, 5, 10, etc. The abnormality threshold corresponding to each payment channel can be the same or different. The determination of the abnormality threshold can be adjusted according to actual circumstances and is not specifically limited in this disclosure.

[0093] In one embodiment, determining whether the abnormality of a payment channel in the payment system exceeds a corresponding abnormality threshold may be achieved by separately determining whether the abnormality of each payment channel in the payment system exceeds a corresponding abnormality threshold.

[0094] In another embodiment, determining whether the abnormality of a payment channel in a payment system exceeds a corresponding abnormality threshold may also be achieved in the following manner: determining a candidate payment channel based on the payment channel in the payment request, and determining whether the abnormality of each candidate payment channel exceeds a corresponding abnormality threshold.

[0095] It should be understood that when determining whether anomalies in payment channels within a payment system exceed corresponding anomaly thresholds, payment channels in the circuit-breaker period may not be evaluated. For example, if, after obtaining channel information for a payment connection, the corresponding channel status in the information is circuit-breaker, further evaluation of whether the anomaly exceeds the corresponding anomaly threshold may be omitted, and the payment channel may be directly filtered out.

[0096] Exemplarily, the above-mentioned determination of the current payment channel based on the payment request and the unblown payment channels can be achieved in the following manner: determining the payment channel corresponding to the payment channel in the payment request (i.e., the selected payment channel) based on the payment request, and determining the unblown payment channel among the selected payment channels as the current payment channel.

[0097] The above-mentioned determination of the current payment channel based on the payment request and the unblown payment channel can also be achieved in the following way: determine the unblown payment channel in the payment system based on the abnormal situation and the abnormal threshold, and then determine, based on the payment request, the payment channel corresponding to the payment channel in the payment request among the unblown payment channels as the current payment channel.

[0098] In the above implementation, when determining the current payment channel, the abnormal payment channel is first identified based on the relationship between the abnormality of the payment channel and the abnormality threshold, and the abnormal payment channel is then disconnected. Determining the current payment channel from the unconnected payment channels can reduce the occurrence of payment anomalies caused by payment channels, improve payment success rate, and enhance payment stability.

[0099] In one possible implementation, the method further includes: determining whether the circuit breaker period of the circuit breaker payment channel has ended; if the circuit breaker period of the circuit breaker payment channel has ended, selecting a low-risk order to trade with the circuit breaker payment channel; and determining whether the corresponding circuit breaker payment channel has returned to normal based on the transaction result of the low-risk order.

[0100] The circuit breaker periods corresponding to the various payment channels may be the same or different. The circuit breaker settings may be adjusted based on actual conditions and are not specifically limited in this disclosure.

[0101] In one embodiment, each payment request is provided with a risk level for the order corresponding to the payment request. The order risk level is automatically determined based on information such as the order amount and purpose. This risk level may include, but is not limited to, low risk, high risk, and medium risk. The order risk level may be adjusted based on actual circumstances and is not specifically limited in this disclosure.

[0102] It should be understood that before determining whether anomalies in a payment channel within a payment system exceed corresponding anomaly thresholds, it is necessary to first obtain channel information for the payment channel, which may include channel status. Based on the channel information of each payment channel, payment channels in the circuit breaker period can be identified. For payment channels in the circuit breaker period, it can be determined whether the circuit breaker period has ended. If the circuit breaker period has not ended, the circuit breaker status will remain. If the circuit breaker period has ended, the payment channel can be marked as a pending verification channel. When a low-risk order is obtained, transactions can be conducted through the pending verification channel. If the low-risk order transaction is successful, it indicates that the pending verification channel has returned to normal, and the pending verification channel is marked as normal. If the low-risk order transaction fails, it indicates that the pending verification channel has not yet returned to normal, and the pending verification channel remains circuit breaker.

[0103] In the above implementation, by setting a circuit breaker period, the broken payment channel can be repaired within the period. After the circuit breaker period expires, the broken payment channel is verified through low-risk orders. Successful verification restores the verified payment channel to normal. This improves the timeliness of the broken payment channel and the accuracy of its restoration.

[0104] In one possible implementation, step 202 includes: determining whether there is an abnormality in the payment channel corresponding to the payment request; if there is an abnormality in the payment channel corresponding to the payment request, determining whether a backup channel is set for the payment channel corresponding to the payment request; if a backup channel is set for the payment channel corresponding to the payment request, determining that the backup channel is the current payment channel.

[0105] The exceptions here may include payment channel circuit breaking, payment access traffic exceeding the threshold, and many other situations.

[0106] In one embodiment, each payment channel is provided with a corresponding payment channel. The payment request includes the payment channel required for the transaction. After obtaining the payment request, the corresponding payment channel can be determined based on the payment channel in the payment request.

[0107] After determining the corresponding payment channel, the corresponding channel information is obtained and the channel status in the channel information is used to determine whether the payment channel has any abnormalities. If the payment channel is normal, the transaction is directly processed through the payment channel. If the payment channel is abnormal, the system first determines whether the payment channel has a backup payment channel. If so, the backup channel is determined to be the current payment channel.

[0108] In the above implementation process, when there is an abnormality in the payment channel corresponding to the payment request, if the payment channel is set with a backup payment channel, the backup payment channel is determined to be the current payment channel for transactions. Providing services through the backup payment channel can reduce the impact range of the payment channel failure, ensure the continuity and availability of the system, and improve the stability of payment.

[0109] In one possible implementation, as shown in FIG4 , step 202 includes: determining whether there is an abnormality in the payment channel corresponding to the payment request; if there is an abnormality in the payment channel corresponding to the payment request, determining whether the payment channel corresponding to the payment request is an available channel; if the payment channel corresponding to the payment request is an unavailable channel, determining whether a backup channel is set for the payment channel corresponding to the payment request; if a backup channel is set for the payment channel corresponding to the payment request, determining that the backup channel is the current payment channel.

[0110] It should be understood that since the payment channel anomaly may not be due to a circuit breaker, in this case, the payment channel can usually continue to process transactions. If the payment channel anomaly is due to a circuit breaker, the payment channel cannot continue to process transactions and it is necessary to switch to another payment channel to conduct transactions.

[0111] Whether the payment channel is available can be determined by checking whether it is in a circuit-breaker state. If the payment channel is in a circuit-breaker state, the payment channel is unavailable; if the payment channel is not in a circuit-breaker state, the payment channel is available.

[0112] In some embodiments, if the payment channel corresponding to the payment request does not have a backup channel, the payment fails and a failure result is returned.

[0113] In the above implementation process, by further judging the abnormality of the payment channel, the transaction is completed through the backup channel only when it is determined that the payment channel is an unavailable channel, thereby improving the accuracy of the abnormality judgment of the payment channel and further improving the stability of payment.

[0114] In one possible implementation, as shown in FIG5 , after step 203 , the method further includes: determining whether the transaction is successful; if the transaction fails, recording the failure in the failure statistics, and determining whether the current payment channel meets the circuit breaker criteria; if the circuit breaker criteria is met, marking the current payment channel as abnormal and performing a circuit breaker.

[0115] It should be understood that after each failure is recorded in the statistics, the current abnormality of the current payment channel in the failure statistics can be counted and a determination can be made as to whether the current abnormality exceeds a corresponding abnormality threshold. If the current abnormality exceeds the corresponding abnormality threshold, it is determined that the current payment channel has reached the circuit breaker standard. If the current abnormality does not exceed the corresponding abnormality threshold, it is determined that the current payment channel has not reached the circuit breaker standard.

[0116] In one embodiment, if the transaction is successful, it is recorded in the success statistics. If the current channel status of the current payment channel is abnormal, it can be further determined whether the current payment channel has met the recovery standard; if it has met the recovery standard, the current payment channel is marked as normal.

[0117] The recovery criteria here may include access traffic within a threshold range, the end of the payment channel circuit breaker period, etc. The recovery criteria can be adjusted according to actual conditions, and this disclosure does not impose specific limitations.

[0118] In the above embodiment, if the current payment channel does not meet the recovery criteria, a success result is directly returned.

[0119] In the above implementation process, after each transaction, the transaction results are counted to update the status of the current payment channel according to the corresponding circuit breaker standard or recovery standard, thereby improving the accuracy of the current payment channel information.

[0120] In one possible implementation, after step 201, the method further includes: determining whether the payment system of the area corresponding to the payment request is available; if the payment system of the area corresponding to the payment request is not available, determining the domain name zone associated with the payment system of the area corresponding to the payment request; and forwarding the payment request to other payment systems corresponding to the domain name zone.

[0121] Whether the payment system is available can be determined by the system information of the payment system or by the result of the payment request. The availability of the payment system can be adjusted according to the actual situation and is not specifically limited in this disclosure.

[0122] In one embodiment, each domain name may include one or more payment systems, and payment systems in the same domain name are associated with each other.

[0123] For example, as shown in Figure 6, if the domain name of region A is associated with the domain name of region B. When a payment request is received, if the region corresponding to the payment request is region A, then the availability of the payment system in region A is determined. If the payment system in region A is not available, the transaction is switched to region B and completed through the payment system in region B. If the region corresponding to the payment request is region B, then the availability of the payment system in region B is determined. If the payment system in region B is not available, the transaction is switched to region A and completed through the payment system in region A.

[0124] In the above implementation process, if the payment system of a certain area is unavailable, you can switch to the domain name area associated with the area, and forward the payment request to other payment systems corresponding to the domain name area, so that transactions can be conducted through other payment systems. You can get fast and stable service responses, enjoy a seamless system access experience, and be able to conduct transactions smoothly at all times and places, enhancing the user experience while improving payment stability.

[0125] In addition, an embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the payment method in the above method embodiment are executed.

[0126] The computer program product of the payment method provided in the embodiment of the present disclosure includes a computer-readable storage medium storing program code. The instructions included in the program code can be configured to execute the steps of the payment method in the above method embodiment. For details, please refer to the above method embodiment and will not be repeated here.

[0127] In the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a portion of code, and the module, program segment or a portion of code contains one or more executable instructions configured to implement the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0128] In addition, the functional modules in the various embodiments of the present disclosure may be integrated together to form an independent part, or each module may exist independently, or two or more modules may be integrated to form an independent part.

[0129] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0130] The above are merely preferred embodiments of the present disclosure and are not intended to limit the present disclosure. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure shall be included within the scope of protection of the present disclosure. It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0131] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims. Industrial Applicability

[0132] The embodiments of the present disclosure provide a payment method, system, and architecture that can greatly reduce the development and maintenance costs of users, improve the efficiency and convenience of payment access, and improve the accuracy of current payment channel determination.

Claims

1. A payment method, characterized in that, The method includes: Obtaining a payment request of the payment terminal; Determining a current payment channel according to the payment request and channel information of the payment channel; Controlling the current payment channel to conduct a transaction with the payment terminal; Wherein, the current payment channel is any one of multiple payment channels of the payment system, and the multiple payment channels are independent of each other; the multiple payment channels are all connected to the channel interface and payment interface of the payment system; the channel interface is configured to access multiple payment channels through the access protocol of each payment channel, and each payment channel is provided with a corresponding payment channel; the payment interface accesses the payment terminal through the access protocol of the payment system, and the payment channel is configured to transmit the information obtained by the payment interface to the channel interface; the payment system provides a unified payment interface, and the payment system is configured such that when the payment terminal has payment requests for different payment methods, the payment terminal docks with the payment interface.

2. The payment method according to claim 1, wherein Each payment channel is provided with a corresponding exception threshold. The determining of the current payment channel according to the payment request and the channel information of the payment channel includes: Judging whether the exception situation of the payment channels in the payment system exceeds the corresponding exception threshold; Fusing the payment channels whose exception situation exceeds the corresponding exception threshold; Determining the current payment channel according to the payment request and the unfused payment channels.

3. The payment method according to claim 2, wherein Each payment channel is provided with a corresponding fusing period. The method further includes: Judging whether the fusing period of the fused payment channel ends; If the fusing period of the fused payment channel ends, selecting a low-risk order to conduct a transaction with the fused payment channel; Determining whether the corresponding fused payment channel returns to normal according to the transaction result of the low-risk order.

4. The payment method according to any one of claims 1 to 3, characterized in that, At least one of the multiple payment channels is provided with a backup channel. The determining of the current payment channel according to the payment request and the channel information of the payment channel includes: Judging whether the payment channel corresponding to the payment request has an exception; If the payment channel corresponding to the payment request has an exception, judging whether the payment channel corresponding to the payment request is provided with the backup channel; If the payment channel corresponding to the payment request is provided with the backup channel, determining the backup channel as the current payment channel.

5. The payment method according to any one of claims 1-4, characterized in that At least one of the multiple payment channels is provided with a backup channel. The determining of the current payment channel according to the payment request and the channel information of the payment channel includes: Judging whether the payment channel corresponding to the payment request has an exception; If the payment channel corresponding to the payment request has an exception, judging whether the payment channel corresponding to the payment request is an available channel; If the payment channel corresponding to the payment request is an unavailable channel, judging whether the payment channel corresponding to the payment request is provided with the backup channel; If the payment channel corresponding to the payment request is provided with the backup channel, determining the backup channel as the current payment channel.

6. The payment method according to claim 4 or 5, characterized in that After controlling the current payment channel to conduct a transaction with the payment terminal, the method further includes: Judging whether the transaction is successful; If the transaction fails, record it in the failure statistics and determine whether the current payment channel reaches the fuse standard; If it reaches the fuse standard, mark the current payment channel as abnormal and perform fusing.

7. The payment method according to any one of claims 1-6, characterized in that, The multiple payment channels are set in the payment system, the payment system is set in the corresponding region, and one or more of the payment systems are set in each region; after obtaining the payment request of the payment terminal, the method further includes: Determine whether the payment system in the area corresponding to the payment request is available; If the payment system in the area corresponding to the payment request is unavailable, determine the domain name area associated with the payment system in the area corresponding to the payment request; Forward the payment request to other payment systems corresponding to the domain name area.

8. A payment system, characterized in that, Includes: Multiple payment channels and a controller, and the multiple payment channels are independent of each other; The multiple payment channels are all connected to the channel interface and the payment interface of the payment system. The channel interface is configured to access multiple payment channels through the access protocol of each payment channel, and each payment channel is provided with a corresponding payment channel; the payment interface accesses the payment terminal through the access protocol of the payment system, and the payment channel is configured to transmit the information obtained by the payment interface to the channel interface; the payment system provides a unified payment interface, and the payment system is configured such that when the payment terminal makes a payment request in different payment methods, the payment terminal docks with the payment interface; The controller is respectively connected to the multiple payment channels; The controller is configured to obtain the payment request of the payment terminal and determine the current payment channel according to the payment request and the channel information of the payment channel; The controller is further configured to control the current payment channel to conduct a transaction with the payment terminal.

9. A payment architecture, characterized in that, Includes: Multiple payment systems as described in claim 8; The multiple payment systems are set in multiple regions, and one or more of the payment systems are set in each region; Wherein, if the payment system in a certain region is unavailable, switch to the payment system in other regions for transactions.

10. The payment architecture according to claim 9, wherein The payment architecture manages the multiple payment systems through Kubernetes.

Images