CN113924590A - System and method for electronic payment and gateway routing - Google Patents

Abstract

According to an example, a system for electronic payment and gateway selection and routing may include a processor and a memory storing instructions. When executing the instructions, the processor may cause the system to receive data associated with the transaction. The system may also determine the predictive performance capability of each of the plurality of gateways based on one or more transaction parameters associated with the data. The system can select a target gateway from a plurality of gateways based on the predicted performance capabilities of the target gateway. The system can transmit data associated with the transaction to the target gateway to process the transaction over the network.

Description

System and method for electronic payment and gateway routing

Cross Reference to Related Applications

This application claims priority from us application No. 16/422,259 filed on 24/5/2019, the contents of which are incorporated by reference in their entirety for all purposes.

Technical Field

The present patent application relates generally to electronic payment and routing systems and, more particularly, to systems and methods for electronic payment and gateway routing using Artificial Intelligence (AI) -based machine learning techniques.

Background

Advances in mobile communications are changing the way people communicate with each other and the way people purchase goods and services. For example, the retail and commercial industries have witnessed an unprecedented digital growth in recent years. For example, as the degree of globalization increases, ensuring successful payment transactions becomes increasingly challenging in large data and digital transactions.

Summary of The Invention

According to a first aspect of the invention, there is provided a system comprising: a processor; a memory storing instructions that, when executed by the processor, cause the processor to: receiving data associated with a transaction; determining a predicted performance capability for each of the plurality of gateways based on one or more transaction parameters associated with the data; selecting a target gateway from the plurality of gateways based on the predicted performance capabilities of the target gateway; and transmitting data associated with the transaction to the target gateway to process the transaction over the network.

The transaction may be a payment transaction.

The predicted performance capability of each of the plurality of gateways may include at least one of: a probability that the target gateway will successfully process the transaction, a speed at which the target gateway will process the transaction, or a cost associated with the target gateway processing the transaction.

The instructions may also cause the system to use an Artificial Intelligence (AI) -based machine learning technique that analyzes data associated with the transaction and data associated with the plurality of gateways to determine a predicted performance capability of each of the plurality of gateways.

The artificial intelligence AI based machine learning technique may include at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis.

Artificial intelligence AI-based machine learning techniques may include calculating, for each of a plurality of gateways, a value representing a predicted performance capability of the gateway.

The instructions may also cause the system to weight a value of each of the plurality of gateways based on at least one of the one or more transaction parameters or data associated with the transaction to create a weighted value.

A target gateway may be selected from the plurality of gateways based on a weighted value of the predicted performance capabilities.

The one or more transaction parameters may include at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier (acquirer identifier), issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity mode.

According to a second aspect of the invention, there is provided a method comprising: receiving, by a processor of a payment system operating in a network, data associated with a transaction; determining, by the payment system processor, a predicted performance capability for each of the plurality of gateways based on the one or more transaction parameters associated with the data; selecting, by the processor, a target gateway from the plurality of gateways based on the predicted performance capabilities of the target gateway; and transmitting, by the processor, data associated with the transaction to the target gateway to process the transaction over the network.

Determining the predicted performance capabilities may also include determining the predicted performance capabilities of each of the plurality of gateways using an Artificial Intelligence (AI) -based machine learning technique that analyzes data associated with the transaction and data associated with the plurality of gateways.

The AI-based machine learning techniques may include at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis.

Using AI-based machine learning techniques may also include calculating, for each of a plurality of gateways, a value representing a predicted performance capability of the gateway.

The method may further comprise: the value of each of the plurality of gateways is weighted based on at least one of one or more transaction parameters or data associated with the transaction, thereby creating a weighted value for each of the plurality of gateways.

Selecting the target gateway may include selecting the target gateway from the plurality of gateways based on the weighted value of each of the plurality of gateways.

The one or more transaction parameters may include at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity pattern.

According to a third aspect of the invention, there is provided a non-transitory computer readable storage medium having stored thereon an executable file that, when executed, instructs a processor to: receiving data associated with a transaction; associating one or more transaction parameters with data associated with the transaction, wherein the one or more transaction parameters are associated with performance capabilities of the plurality of gateways; applying an Artificial Intelligence (AI) -based machine learning technique to the one or more transaction parameters, wherein the AI-based machine learning technique includes at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis; calculating a value for each of the plurality of gateways based on the AI-based machine learning technique, wherein the value represents a performance capability of each of the plurality of gateways; and selecting a target gateway from the plurality of gateways based on the value of each of the plurality of gateways.

The transaction may be a payment transaction.

Calculating the value may include weighting each respective value based on at least one of one or more transaction parameters or data associated with the transaction to create a weighted value for each of the plurality of gateways, wherein selecting the target gateway from the plurality of gateways is based on the weighted value for each of the plurality of gateways.

The one or more transaction parameters may include at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity pattern.

Brief Description of Drawings

Features of the present disclosure are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. One skilled in the art will readily recognize from the following that alternative examples of the structures and methods illustrated in the accompanying drawings may be employed without departing from the principles described herein.

Fig. 1 illustrates a block diagram of a system environment for a system that facilitates transaction processing related to electronic payments and gateway routing for transaction processing, according to an example.

FIG. 2 illustrates a block diagram of a system for electronic payment and gateway routing in the electronic transaction processing environment shown in FIG. 1, according to one example.

Fig. 3 shows a block diagram of the system for electronic payment and gateway routing depicted in fig. 1 and 2, according to one example.

Fig. 4 shows a block diagram of a computer system for electronic payment and gateway routing, according to an example.

Fig. 5 illustrates a method for electronic payment and gateway routing according to one example.

Detailed Description

For simplicity and illustrative purposes, the present disclosure is described by referring mainly to examples thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures readily apparent to those of ordinary skill in the art have not been described in detail so as not to unnecessarily obscure the present disclosure. As used herein, the terms "a" and "an" are intended to mean at least one of a particular element, the term "including" means including, but not limited to, and the term "based on" means at least partially based on.

The payment gateway facilitates payment transactions by transmitting information between the payment portal and the front-end processor or acquiring bank. The payment transaction facilitated by the payment gateway may include any transaction associated with an electronic payment, where the transaction may be conducted between a payment system, a payer, and/or a payee. The payment transaction may also be associated with a transaction type, such as a sales transaction, a post-authorization transaction, or a refund. The payment gateway may include any node or network element that provides routing functionality to facilitate payment transactions. In some cases, a bank or professional financial service provider may provide a payment gateway for its customers. Existing payment systems may not typically have the capability to provide guidance for gateway selection or routing. In contrast, some conventional payment systems simply use a random or manual process to select a payment gateway. Further, once the payment gateway is selected, the payment gateway may perform various tasks to process the transaction with little, if any, input from the payment system, the payer, or the payee.

However, successful payment transactions tend to depend on the capabilities of the payment gateway. The payment gateway performance is in turn based on a number of variables, such as transaction type, date, time, amount, currency, etc. One technical problem with conventional approaches is that these or other variables are typically not considered for selection of a payment gateway. Existing payment systems most likely rely on rule-based techniques, guided primarily by manual processes, to select and route payment transactions to a particular payment gateway. This static approach typically results in many failed and unsuccessful transactions for payment, which in turn may result in wasted and inefficient utilization of processing and network resources.

According to examples described herein, a dynamic approach may be provided for payment gateway selection and payment transaction processing. Rather than relying on traditional rule-based techniques, dynamic methods can reduce or eliminate payment failures and unsuccessful transactions, and can also improve performance and speed of transaction completion. As a result, a technical improvement over the technical problem discussed above may be that by implementing the dynamic approach disclosed herein, processing resources and network resources may be utilized in a more efficient and energy efficient manner.

Dynamic methods of payment gateway selection and payment transaction processing may use decision making and machine learning. The dynamic approach may also take into account various transaction processing variables to help reduce or eliminate payment failures and unsuccessful transactions. For example, the dynamic methods disclosed herein may further help balance and/or reduce the load on the payment gateway, which may help facilitate successful payment transactions. Further, the dynamic methods disclosed herein may enable payment transactions to be completed faster, e.g., in real time or near real time. This may be particularly advantageous for advertising, online shopping, or other scenarios that may require real-time or near real-time transaction processing. These and other benefits will be apparent from the description provided herein.

Fig. 1 illustrates a block diagram of a system environment 100 of a system 300 according to an example, the system 300 for facilitating transaction processing related to electronic payments and gateway routing for transaction processing. As shown, the system environment 100 may include any number of client devices 110, with the client devices 110 shown as client devices 110A, 110B, and 110X, where the variable "X" may represent an integer greater than 1. System environment 100 may also include network 120, external systems 130, and any number of gateways 140, gateways 140 being shown as gateways 140A, 140B, and 140N, where the variable "N" may represent an integer greater than 1. The system 300 may select gateways 140A, 140B, and 140N for processing transactions via the transaction processing system 150. In some examples, system 300 may be a social networking system, a content sharing network, an electronic or online payment system, or any other system that facilitates any kind of transaction for and with a user in a personal, financial, or business environment.

In some examples, system 300 may be an electronic payment system. The system 300 may also include a machine learning subsystem 340, and the machine learning subsystem 340 may determine and automatically select gateways 140A, 140B, and 140N using Artificial Intelligence (AI) -based machine learning techniques for processing one or more payment transactions. As described herein, a payment transaction may be associated with any payment transaction type, such as a sales transaction, a post-authorization transaction, a refund, or other payment related transaction. The system 300 may select the gateways 140A, 140B, and 140N based on a probability that the selected gateway will successfully process the payment transaction. As described herein, a successful payment transaction may be a payment transaction that has not failed or been rejected during processing of the payment transaction, or if rejected, that does not significantly affect or cause undue delay during processing of the payment transaction. As described herein, the performance (e.g., speed) of processing transactions and the cost (e.g., exchange rate, chargeback, etc.) of processing transactions may also affect whether a payment transaction is deemed successful. For example, 200000 types of Bank Identification Numbers (BINs) for credit or debit cards may be used and stored in the system 300. However, it may be observed that certain credit cards may be processed at a faster speed and with greater throughput via one of the gateways 140 (e.g., gateway 140A) relative to the other gateways 140 (e.g., gateway 140B). When the transaction is routed through the gateway 140A, payment transactions may be more successfully processed at a faster collective rate and/or with minimal associated costs, fees, or charges.

In some examples, a successful payment transaction may be predicted based on a number of (a multiple of) variables, such as transaction type, date, time, amount, and/or currency, to name a few examples. For example, using these and/or other variables, the probability of a successful payment transaction may occur at a particular gateway, as described in more detail with reference to fig. 3.

Once the machine learning subsystem 340 identifies and determines the gateways 140A, 140B, and 140N based on the probability and/or performance capabilities that resulted in a successful payment transaction, the gateways 140A, 140B, and 140N may be selected to proceed with processing the payment transaction. It should be understood that in addition to processing transactions, the system 300 may also receive data or various instructions from the client device 110 and/or the external system 130.

Each client device 110 may be a computing device that may transmit and/or receive data via network 120. In this regard, each client device 110 may be any device having computer functionality, such as a smartphone, tablet, laptop, watch, desktop, server, or other computing device. Further, in some examples, client devices 110 may each be a cash register, a point of sale (POS) device, or other similar device for initiating or processing data for a payment transaction.

In some examples, client device 110 may execute an application that allows a user of client device 110 to interact with various elements on network 120. For example, client device 110 may receive data from user input, a database, a file, a web service, and/or via an Application Programming Interface (API). Further, client device 110 may execute a browser or application to enable interaction between client device 110 and system 300 via network 120. For example, a user may interact with a mobile application or web application executed via a browser to provide user input for a payment transaction. In one example, client device 110 may interact with system 300 through an Application Programming Interface (API) running on a local or remote operating system of client device 110. Various other examples may also be provided.

According to an example, the client device 110 may include software for facilitating transaction processing related to electronic payments and gateway routing for transaction processing. For example, the client device 110 may access or include data associated with the machine learning subsystem 340. As shown, one or more portions of the system 300 and the machine learning subsystem 340 may reside at a hub location. However, it should be understood that any data or functionality associated with the machine learning subsystem 340 may also be local to the client device 110, or at some other computing device between the client device 110 and the gateway 140.

Network 120 may be a Local Area Network (LAN), Wide Area Network (WAN), the internet, a cellular network, a cable network, a satellite network, or other network that facilitates communication between client device 110, external system 130, system 300, and/or any other system, component, or device connected to network 120. Network 120 may also include one or any number of the above-described exemplary types of networks operating as stand-alone networks or in cooperation with one another. For example, network 120 may utilize one or more protocols of one or more clients or servers to which they are communicatively coupled. Network 120 may facilitate the transmission of data according to a transmission protocol of any device and/or system in network 120. Although network 120 is depicted in fig. 1 as a single network, it should be understood that in some examples, network 120 may also include multiple (a complexity of) interconnected networks.

An external system 130 may be communicatively coupled to the network 120. In some examples, external system 130 may be a third-party website or any content or data source that provides content or data to client device 110 and/or system 300. The external system 130 may also provide content via the system 300 or other network elements (not shown).

In some examples, external systems 130 may include Enterprise Resource Planning (ERP) systems and applications, documents, web feeds, or online portals. The ERP system may include one or more application servers that host various ERP applications. These may include, for example, a Customer Relationship Management (CRM) platform, system, or application. An ERP system may collect, store, manage, and interpret data associated with various enterprise functions or activities. The ERP system may also provide a comprehensive and constantly updated view of the core business processes, for example, using a common database maintained by a database management system. The ERP system may also track enterprise resources (e.g., cash, raw materials, production capacity, etc.) as well as other information, such as company or business transactions (e.g., orders, purchase orders, payroll, etc.). The ERP system may also monitor and store data associated with various customer communications. Further, the applications that make up the ERP system may share data among various departments (e.g., manufacturing, procurement, sales, accounting, etc.) that provide relevant communication data. ERP systems may facilitate information flow between many enterprise functions and may manage communications with stakeholders (stakeyers), customers, or other parties. The ERP system may also contain a large amount of information that can be used to enhance the meaning of other data. In some examples, the external system 130 may include any number of payer/payee profiles, preferences, trends, policies, etc., all of which may facilitate successful transaction processing, as described herein.

Each of gateways 140A, 140B, and 140N may be any node or network element that provides routing functionality to transaction processing system 150. Each of gateways 140A, 140B, and 140N may be a stopping point or a routing point for data in system environment 100. In other words, gateways 140A, 140B, and 140N may facilitate routing data from one network element to another network element. In some examples, the gateway 140 may be a payment gateway that facilitates one or more payment transactions via any number of transaction processing systems 150. Each of the gateways 140A, 140B, and 140N may include a gateway processor 145 (which is shown as gateway processors 145A, 145B, and 145N). These gateway processors 145 may cause one or more payment transactions and cause successful payment transactions by routing payment transaction data to the downstream transaction processing systems 150. To route the payment transaction, the gateway processor 145 may communicate with the processor of the acquirer and/or the issuer, for example, to complete the transaction. It should be appreciated that this may include transmitting an authorization request to and receiving authorization from one or more acquirers or issuers for routing payment transactions for processing. Details regarding the authorization process will be apparent from the description of fig. 2 below.

The terms "payment gateway" and "gateway" may be used interchangeably throughout, unless explicitly stated otherwise. Such payment transactions may involve the transfer of information between a payment portal (e.g., a website, mobile phone, or interactive voice response service) and one or more transaction processing systems 150 (e.g., a front-end processor or acquiring bank, card network, issuer, or other network element for processing transactions), which transaction processing systems 150 may be downstream from the system 300 and gateway 140.

In a payment transaction scenario, for example, the gateway 140 may also screen transactions for fraud and/or calculate taxes in real-time before an authorization request is sent to the processor. The gateway 140 may also assist in detecting fraud by incorporating features such as geolocation, speed pattern analysis, foreign asset control Office (OFAC) list or blacklist (block-list) look-ups, delivery address verification, Address Verification System (AVS) checks, biometrics or other identity deformation detection, etc. For example, the gateway 140 may incorporate any number of these features to help mark fraudulent activity by identifying irregular purchasing activity, shortened time periods between transactions, increased transaction numbers, different geographic locations for multiple transactions, high dollar transactions, inaccurate password or PIN (personal identification number) attempts, high risk locations (e.g., cities, states, countries, etc.), or combinations thereof. It should also be understood that the gateway 140 may be used in a manner where a payment service provider, e-commerce platform, Independent Sales Organization (ISO), distributor, or acquiring bank, for example, is able to incorporate payment gateway technology and functionality entirely and as its own brand. This may provide a more seamless user experience and increase enterprise partnerships and collaboration. Fig. 1 shows a network 120 communicatively coupled to a client device 110, an external system 130, and a system 300. However, it will be apparent to one of ordinary skill in the art that network 120 may also communicatively couple system 300, gateway 140, transaction processing system 150, and/or any other computing device or network element in system environment 100.

FIG. 2 illustrates a block diagram of a system 300 for electronic payment and gateway routing in the electronic transaction processing environment 200 shown in FIG. 1, according to one example. Although FIG. 2 is directed to a card processing environment 200, it will be apparent to those of ordinary skill in the art that the principles described for card processing may be applied to other transaction processing environments, such as electronic funds transfers, mobile payments, debits, and/or other transactions. As shown, the client device 110 may communicate with the system 300 to process transactions via the gateway 140. In the card processing environment 200, the transaction may be a card-related payment transaction (e.g., a credit or debit card) and may involve a number of additional entities and/or systems. In particular, these entities and/or systems may include a vault (vault)225, an acquirer 250 (via an acquirer processor 255), a transaction or card network 260, an issuer 270 (via an issuer processor 275), and/or other systems and entities.

When a customer orders a product or service via one of client devices 110 (e.g., a POS device or computing device capable of supporting online purchases), data associated with the purchase may be generated or received at client device 110 and transmitted to system 300. The data associated with the purchase may include card payment data and/or profile information associated with the customer or purchaser. It should be appreciated that a web browser, mobile application, or other security-enabling feature at client device 110 or system 300 may encrypt data associated with the purchase. In some examples, this may be accomplished via SSL (secure socket layer) encryption or other encryption/security techniques. In some examples, when a customer places an order via client device 110, client device 110 may transmit a request for a transaction or card payment to system 300.

Once the system 300 receives a card payment request from one of the client devices 110, the system 300 may use machine learning or other AI-based techniques to select and route the transaction to one of the gateways 140 (e.g., payment gateway), which one of the gateways 140 is identified and determined to have, for example, the highest likelihood of success for processing the payment transaction. In some examples, success of the payment transaction may be based on a likelihood that the payment transaction will be processed without failure. The success of the payment transaction may also be based on performance such as speed. For example, it may be desirable to minimize the time taken to initiate and complete a payment transaction, as this may translate into more transactions being completed in any given period of time. The success of the payment transaction may also be based on the cost of processing the transaction (e.g., exchange rate, chargeback, etc.). In some examples, the performance or speed of the transaction may be affected by data loading (or predicted data loading) at gateway 140 or transaction processing system 150, network latency, or other factors that may affect transaction processing time. Transaction costs may be affected by exchange costs, exchange rates, chargebacks, or other fees associated with a location, distance, product, service, issuer, or acquirer. Again, the system 300 may determine these and other conditions based on various factors and/or parameters, as described in more detail with reference to fig. 3. Thus, the system 300 may identify and select one of the gateways 140 with the greatest likelihood of success, which may be referred to as the selected gateway or the target gateway, and the system may proceed to transmit data associated with the purchase (or any other relevant purchase or transaction details) to the target gateway. It should also be understood that another (SSL) encrypted connection may also be provided to any payment server hosted by the payment gateway 140 or other similar encrypted/secure connection.

In some examples, the system 300 may be in communication with the vault 225. The vault 225 may be a data vault or other repository or source of data and information associated with transactions, users, banks, financial institutions, businesses, and/or other entities associated with transactions. In some examples, the system 300 may rely on the vault 225 to collect and analyze information from multiple customers, merchants, banks, users, systems, historical transactions, etc. in order to determine patterns, behaviors, and trends of current or future transactions. In this manner, the system 300 may use the information included in the vault 225 to help facilitate processing of payment transactions (e.g., improved speed, cost, and/or success), as well as communicate with the client device 110, external systems, or other downstream elements for payment processing in the card processing environment 200. The system 300 may use these and other data in the vault 225 to analyze and select gateways 140 for transaction processing. As described in more detail with reference to fig. 3, the vault 225 may communicate with and share data with various components in the system 300 to help facilitate the selection of a gateway and routing of transactions to the gateway 140.

The gateway 140 selected by the system 300 may receive instructions from the system 300 to process the payment transaction. This may include receiving data associated with the purchase from the system 300. The gateway 140 may then communicate with the acquirer 250 via the acquirer processor 255. In some examples, gateway 140 may convert the received data into usable data. For example, data associated with the purchase may be formatted in any number of ways. In some examples, the data may be converted from XML to international organization for standardization (ISO)8583 or variant message formats (e.g., formats understood by Electronic Funds Transfer (EFT) clearinghouse). The gateway 140 may then transmit the transaction information to the acquirer processor 255 at the acquirer 250.

In some examples, it should be understood that the gateway 140 may bypass any other system (even system 300) and receive transaction data directly from the client device 110, which may include data associated with the purchase. As described herein, this may involve the client device 110 being able to access or support functions normally associated with the machine learning subsystem 340 of the system 300 in a remote or local manner. In some cases, this direct approach may reduce the merchant's payment card industry data security standard (PCI-DSS) compliance obligations without diverting the customer from any online portal or purchase channel.

The acquirer processor 255 of the acquirer 250 may transmit transaction information to the transaction or card network 260. Transaction or card network 260 may be any type of payment or transaction association, such as

American

And/or

And the like. In some examples, the transaction or card network 260 may act as and function as an issuer 270. For example, if American is used in card processing environment 200

Or

Card, then with American

Or

The card associated transaction or card network 260 may act as and serve as an issuer 270. In this case, the issuer 270 may provide an "approved" or "denied" response directly to the payment gateway 140 via the issuer processor 275. In some examples, transaction or card network 260 may allow another entity (e.g., an issuing bank or financial institution associated with transaction or card network 260) to act as and function as issuer 270. For example, if used

Or

The card, transaction or card network 260 may route the transaction to an issuing bank or financial institution associated with the transaction or card network 260. This is because

Or

The network may typically allow other entities to act as and act as issuers. Although the issuer 270 may differ depending on the transaction or card network 260 used, it should be understood that the system 300 may continue to analyze and select the gateway 140 for routing and electronic transaction processing in a similar manner, regardless of what entity acts or functions as an issuer 270, as described herein.

In some examples, an issuing bank or financial institution associated with the transaction or card network 260 may receive the authorization request and may proceed to verify any available credit or debit balances and/or transmit a response back to the issuer processor 275 (e.g., via a similar process or route as when the authorization request came in). The response may include a response code (e.g., "approved" or "rejected"). In addition, the response may also include the reason why any particular transaction may have failed. This may include, for example, reasons such as insufficient funds, unavailable bank links, or other reasons for the transaction to fail or be rejected. Meanwhile, the issuer 270 may suspend the transaction until the system 300, client device 110, or other entity may provide additional information to indicate that the transaction process is proceeding. Such suspension may result in delays that affect the consumer's ability to consume further (as it reduces the amount of credit available or suspends a portion of the funds in the debit account) and the merchant's ability to collect and deliver the purchased goods or services.

If authorization is received or there are no further authorization barriers to resolve, the issuer 270 may forward an authorization response to the gateway 140 via the issuer processor 275. The gateway 140 may receive the authorization response and forward the authorization response to the system 300 (or any interface for processing payment), where the authorization response is interpreted as a relevant response and then relayed back to the merchant and/or cardholder in the system 300. This is commonly referred to as "Authorization or Auth"). The entire process may take 2 to 3 seconds to complete. While this may be a relatively short process, it should be appreciated that overall processing time may increase when a large number of transactions occur, as a whole. In addition, any problems or issues encountered during this process may affect other queued transactions, which in turn may affect the performance capabilities of the gateway 140.

Once authorization is received, the merchant may then begin fulfilling the purchase, and the process described above may be repeated again to "Clear" the authorization by completing the transaction. In some examples, the "purge" may be initiated after the merchant has completed the transaction (e.g., shipping the order, or dispatching an agent to deliver the service). This may result in the issuer 270 "clearing" the "authorization" (e.g., transferring an authorization hold (auth-hold) to the borrower) via the issuer processor 275, and the issuer 270 may then be ready to settle (settle) with the acquirer 250 via the acquirer processor 255. In other words, the issuer 270 may Clear ("Clear") (e.g., approve the transaction or indicate that there are sufficient funds or balances) any authorized holds (e.g., authorized holds) that may have been established during the process of verifying the transaction so that the transaction may proceed to settlement with the acquirer 250.

It may not be uncommon for a merchant, via system 300 or other systems in card processing environment 200, to submit all of its approved authorizations to its acquirer 250 in bulk (e.g., at the end of the day) for settlement. This may help to "clear" any corresponding "grant" if it has not been explicitly "cleared" at that time.

The acquirer 250 may then issue a bulk settlement request to the issuer 270, and the issuer 270 may make a settlement payment to the acquirer 250, which will be completed within the next day in most cases. The acquirer 250 may then deposit the total approved funds into the merchant's designated account. The designated account may be the account of the acquirer 250 if the merchant transacts banking at the same bank, or the designated account may be the account of another bank or financial institution. The entire process from authorization to settlement to withdrawal may take 2 to 4 days.

As described herein, once the gateway 140 is selected, the various tasks of processing the transaction may be accomplished with little, if any, input from any system, payer, or payee. Thus, selecting a gateway as discussed herein may generally result in a greater likelihood of success in processing transactions, minimizing or eliminating transaction failures, increasing transaction speed, and/or reducing costs associated with processing transactions, among other things.

Fig. 3 shows a block diagram of the system 300 for electronic payment and gateway routing depicted in fig. 1 and 2, according to one example. In some examples, the system 300 may provide electronic payment and gateway routing for processing payment transactions. As shown, the system 300 may include a parameter data store 305, a transaction data store 310, and a transaction server 315.

The parameter data store 305 may store various variables or parameters for analyzing, evaluating, identifying, and selecting gateways, as discussed herein. Parameters that may be stored at parameter data store 305 may include, but are not limited to, transaction type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier, authorization code or requirement, response code or requirement, security code or requirement, card information, user profile, transaction profile, authentication code or requirement, operating environment, output capabilities, and the like. Other parameters may include card information (e.g., Issuer Identification Number (IIN), Bank Identification Number (BIN), etc.), cardholder information, cardholder authentication code or requirements, operating environment, terminal output capabilities, transaction and non-transaction activity patterns, Address Verification System (AVS), Merchant Category Code (MCC), tracking numbers, referral numbers, EMV (Europay,

and

) CorrelationInformation, etc.

Other information stored in the parameter data store 305 may include performance information and/or cost information related to processing transactions. For example, performance information may include data associated with the speed at which transactions are processed, such as performance capabilities that may be affected by hardware, software, or a network or other element. These may include network delays or other network-related characteristics for a given gateway 140A, 140B, and 140N, or other performance issues that the gateways 140A, 140B, and 140N are predicted (or observed) to encounter that may affect speed or other performance capabilities. Cost information may include the associated cost of processing any given transaction, such as exchange cost, exchange rate, chargeback, or other fees associated with a location, distance, product, service, issuer, or acquirer.

The transaction data store 310 may store content associated with one or more transactions. These transactions may include payment transactions, advertising transactions, online transactions, mobile transactions, merchant transactions, user-to-user transactions, charge-based transactions, card-based transactions, financial transactions, and digital transactions. The content may include an identification of the gateways 140A, 140B, and 140N used to process the transaction, a transaction request time, a transaction result time, and/or other data related to the transaction. As used herein, a transaction request time may be a desired time for transaction processing and a transaction result time may be a time actually spent by the transaction processing. For example, based on the transaction request time and transaction result time, the system 300 may determine the amount of time it takes for the gateways 140A, 140B, and 140N to return a response code or other result for a given transaction. The system 300 may use the amount of time on various transactions processed via the gateways 140A, 140B, and 140N to determine the network characteristics of the payment gateway. For example, multiple transactions may be tracked, and reasons for success, performance, cost, trends, and/or other network capabilities may be identified and determined. The transaction data store 310 may also store profile information for users, cardholders, payers, payees, or other profile data associated with one or more transactions. The transaction server 315 may provide or implement at least one transaction service associated with one or more transactions.

The system 300 may also include an action recorder 320, an action log 325, and a web server 330. In some examples, the action recorder 320 may receive communications regarding user actions performed on the system 300 or outside of the system 300 and may populate the action log 325 with information regarding various user actions. Such user actions may include, for example, adding to a connection of another user or entity, sending a message from another user or entity, viewing content associated with another user or entity, initiating a payment transaction, and so forth. In some examples, the action recorder 320 may receive content interaction activities associated with another user or entity according to one or more privacy settings or rules. Further, many of the actions described in conjunction with other objects may be specific to a particular user, and thus, the actions may also be associated with those users. Any or all of these user actions may be stored in action log 325.

The system 300 may use the action log 325 to track user actions on the system 300 or other external systems. The action log 325 may also include context information associated with the context of the user action. For example, such content information may include a date/time at which the action was performed, other actions recorded around a similar date/time period, or other associated actions. Other contextual information may include user action patterns, other similar user-presented patterns, or even various interactions that a user may have with any particular or similar object. These and other similar actions or other similar information may be stored in action log 325 and may be used for gateway routing and selection, as described herein.

web server 330 may link system 300 to one or more client devices (e.g., client device 110 of fig. 1) via a network (e.g., network 120 of fig. 1). web server 330 may provide web pages and other web related content such as Java, Flash, XML, or other similar content. web server 330 may communicate with various internal elements of system 300 or external network components to provide various functions, such as receiving, transmitting, and/or routing content between system 300, client devices, and other network components.

As described herein, the system 300 may also include a machine learning subsystem 340. The machine learning subsystem 340 may employ one or more AI-based techniques to help define, modify, track, schedule, execute, compare, analyze, evaluate, and/or deploy one or more workflows associated with one or more application services of the system 300. In some examples, machine learning subsystem 340 may include Artificial Intelligence (AI) router 342, model 344, training data store 346, and classifier 348.

In particular, AI router 342 of machine learning subsystem 340 may enable system 300 to identify gateways that may result in successful or desired transaction processing (e.g., payment transactions), as discussed herein. In particular, the machine learning subsystem 340 may train the model 344 based on training data included in the training data store 346. The machine learning subsystem 340 may also train the classifier 348 based on the training data. Classifier 348 may be used to evaluate gateway performance capabilities. Based on these evaluations, AI router 342 may identify and select gateway 140 to handle any particular transaction.

The machine learning subsystem 340 may use one or more AI-based machine learning techniques to generate the model 344 and the classifier 348. The model 344 generated by the machine learning subsystem 340 may provide a framework for evaluating, identifying, and selecting one or more gateways for successful transaction processing. In some examples, model 344 may include a set of weights associated with a set of features for generating output scores or values that are a weighted set of scores or values associated with various features. In other examples, model 344 may include a set of weights and instructions for aggregating the weights to generate an output score or value. In some examples, a vector or array generator (not shown) may use model 344 to generate a vector or array representing transactional characteristics that contribute to successful gateway performance. The machine learning subsystem 340 may also generate a classifier 348 that takes input from the model 344, such as a vector or array generated using the model 344, to return an identification of whether the content represented by the vector may be helpful in determining which gateway will result in successful transaction processing. To generate a vector or array, the training data may be provided in a matrix format. The classifier 348 generated by the machine learning subsystem 340 may be a single classifier or multiple classifiers, each of which may determine the performance capabilities of each gateway 140. These scores or values may assist the system 300 in analyzing and determining those gateways 140 that have the "highest" likelihood of successful transaction processing.

The machine learning subsystem 340 may ingest training data from the training data store 346 to generate the model 344 and any classifiers 348. The training data store 346 may include any previously analyzed content and data describing the content, such as data associated with one or more transactions to be processed, whether there are variables or parameters that may make processing challenging or successful, gateway capabilities and options based on these variables and parameters, and the likelihood of successful processing by various gateways. In some examples, the training data may not provide data specific to a particular transaction, but may simply indicate whether the particular transaction is more likely to succeed or fail at various gateways for downstream processing. Training data store 346 may include data obtained from action log 325, parameter data store 305, transaction data store 310, and/or other sources. For example, as described with reference to fig. 2, the vault 225 may also share data with the training data store 346, the action log 325, the parameter data store 305, the transaction data store 310, or any other data source to facilitate causing the machine learning subsystem 340 to perform any number of actions associated with gateway selection and routing, as described herein.

The machine learning subsystem 340 may generate the models 344 based on optimization of different types of content analysis models, including, but not limited to, algorithms that analyze transactions and gateway capabilities to process the transactions. For example, the generated model 344 may include a neural network, a tree-based model, a bayesian network, a support vector, a cluster, a kernel method, a spline (spline), a knowledge graph, or an integration of one or more of these and other techniques. The machine learning subsystem 340 may determine weights for the model 344, e.g., weights for edges of the neural network corresponding to the model 344. The machine learning subsystem 340 may also generate a classifier 348 that may use this technique. The machine learning subsystem 340 may periodically update the model 344 and/or the classifier 348 based on additional training or update data associated with the system 300. It should be appreciated that the machine learning subsystem 340 may vary depending on the type of input and output requirements and/or the type of task or problem that is intended to be solved. As described herein, the machine learning subsystem 340 may use supervised learning or semi-supervised learning to build the model 344 using data in the training data store 346. Supervised learning may include classification and/or regression, while semi-supervised learning may require iterative optimization using an objective function to fill in gaps when at least some of the output is missing. It should also be understood that the machine learning subsystem 340 may provide other types of machine learning methods, such as reinforcement learning, feature learning, anomaly detection, and the like.

It should be appreciated that the classification algorithm may provide for the assignment of instances to predefined classes to decide whether a match or correlation exists. Alternatively, a clustering scheme or technique may use groupings of related data points that are not tagged. The use of knowledge graphs can provide an organized graph that associates nodes and edges, where nodes can be related to semantic concepts, such as people, objects, entities, events, etc., and edges can be defined by relationships between semantic-based nodes. It should be understood that the term "node" may be used interchangeably with "entity" and "edge" may be used interchangeably with "relationship" as described herein. Furthermore, techniques involving simulation models and/or decision trees may provide a detailed and flexible approach to gateway selection and routing.

In some examples, the system 300 may associate one or more transaction parameters with data associated with a transaction. The transaction parameters may be associated with multiple gateways.

The system 300 may apply Artificial Intelligence (AI) -based machine learning techniques to one or more transaction parameters. AI-based machine learning techniques may include clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, knowledge graph analysis, and/or other techniques. For example, the transaction parameters may be associated with historical transaction results (e.g., failed or approved response codes), the amount of time it takes for the historical transaction to complete, and/or other performance capability data related to the gateway.

The system may calculate a value representing a predicted performance capability of each of the plurality of gateways according to Artificial Intelligence (AI) -based machine learning techniques. In some cases, the system may apply a weight to the value based on at least one of the one or more transaction parameters and data associated with the transaction. For example, the weighting values may be based on weighting individual transaction parameters to reflect the predicted relevance of each parameter to the observed outcome. In this way, certain parameters that are highly correlated with certain outcomes may be weighted higher, as they have been observed to be more highly correlated with these outcomes.

The system 300 may select a target gateway from the plurality of gateways based on a weighted value of the predicted performance capabilities of the target gateway. For example, the weighting value may reflect a probability that the target gateway will successfully process the transaction, will process the transaction more efficiently (e.g., faster) than another gateway, and/or otherwise exhibit better performance than another gateway. The weighting value may also or alternatively reflect the probability that the target gateway will process the transaction in a cost-effective manner based on considerations associated with processing costs, chargeback likelihood, or other applicable fees and rates. As discussed herein, system 300 may perform gateway selection by comparing weighted values to weighted values of other gateways.

As described herein, systems and methods for gateway/processor selection and routing may process variables (or other parameters) involved in a given transaction, and may apply at least one AI-based machine learning technique to evaluate gateways and select one or more gateways based on their one or more predicted performance capabilities. Machine learning techniques may analyze these or other parameters for a given transaction to determine the "best" or optimal gateway for successfully processing the transaction. However, simply because one gateway can successfully process one transaction at a particular time does not necessarily mean that the same gateway will successfully process another transaction at another time. Likewise, simply because a gateway may process one transaction at one speed or cost at a particular time does not necessarily mean that the gateway will process another transaction at the same speed or cost at another time.

Thus, as described herein, systems and methods for gateway selection and routing may provide a dynamic solution that may make various decisions based on analysis of constantly changing variables, with various weighting and/or scoring options to narrow the number of potential gateways to use, and ultimately select a gateway that will have the highest likelihood of success when processing a transaction (e.g., based on a score or value associated with the gateway relative to scores or values associated with other gateways), minimize the amount of time to process a transaction, and/or exhibit other performance capabilities compared to other gateways.

It should be understood that the systems and subsystems shown herein may include one or more servers or computing devices, as described herein. Each of these servers or computing devices may also include a platform and at least one application. The application may include software (e.g., machine-readable instructions) stored on a non-transitory computer-readable medium and executable by a processor. A platform may be an environment on which an application is designed to run. For example, a platform may include hardware to execute applications, an Operating System (OS), and a runtime library (runtime library). The application may be compiled to run on the platform. The runtime library may include low-level routines or subroutines that are called by the application to cause some behavior of the platform at runtime (e.g., exception handling, memory management, etc.). The subsystems may be similar to the platform and may include software and hardware running various software or applications.

While the gateways, systems, subsystems, and/or other computing devices may be shown as a single component or element (e.g., a server), one of ordinary skill in the art will recognize that such a single component or element may represent multiple components or elements, and that such components or elements may be connected via one or more networks. Furthermore, middleware (not shown) may be included with any element or component described herein. Middleware may include software hosted by one or more servers. Further, it is to be understood that some middleware or servers may or may not be required to implement the functionality. Other types of servers, middleware, systems, platforms, and applications not shown may also be provided at the front end or back end to facilitate the features and functionality of the system 300.

Fig. 4 shows a block diagram of a computer system 400 for electronic payment and gateway routing, according to an example. Computer system 400 may be part of or any of client device 110, external system 130, and/or system 300 to perform the functions and features described herein. Computer system 400 may include an interconnect (interconnect)410, a processor 412, a multimedia adapter 414, a network interface 416, a system memory 418, a storage adapter 420, and the like.

Interconnect 410 may interconnect various subsystems, elements, and/or components of computer system 400. As shown, the interconnect 410 may be an abstraction that may represent any one or more separate physical buses, point-to-point connections, or both, connected by appropriate bridges, adapters, or controllers. In some examples, interconnect 410 may include a system bus, a Peripheral Component Interconnect (PCI) bus or PCI-Express bus, a HyperTransport or Industry Standard Architecture (ISA) bus, a Small Computer System Interface (SCSI) bus, a Universal Serial Bus (USB), an IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus or "firewire" or other similar interconnect element.

In some examples, interconnect 410 may allow data communication between processor 412 and system memory 418, and system memory 418 may include Read Only Memory (ROM) or flash memory (neither shown) and Random Access Memory (RAM) (not shown). It should be appreciated that the RAM may be the main memory into which the operating system and various application programs may be loaded. The ROM or flash memory may contain code such as a Basic Input Output System (BIOS) that controls basic hardware operations such as interaction with one or more peripheral components.

The processor 412 may be a Central Processing Unit (CPU) of the computing device and may control the overall operation of the computing device. In some examples, processor 412 may accomplish this by executing software or firmware or other data stored in system memory 418 via storage adapter 420. The processor 412 may be or include one or more programmable general or special purpose microprocessors, Digital Signal Processors (DSPs), programmable controllers, Application Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), Trusted Platform Modules (TPMs), Field Programmable Gate Arrays (FPGAs), other processing circuitry, or a combination of these and other devices.

The multimedia adapter 414 may connect to various multimedia components or peripherals. These may include devices associated with visual (e.g., video card or display), audio (e.g., sound card or speaker), and/or various input/output interfaces (e.g., mouse, keyboard, touch screen).

Network interface 416 may provide the computing device with the ability to communicate with various removal devices over a network (e.g., network 120 of FIG. 1), and may include, for example, an Ethernet adapter, a fibre channel adapter, and/or other supporting wired or wireless adapters. Network interface 416 may provide a direct or indirect connection from one network element to another network element and facilitate communication as well as communication between the various network elements.

The storage adapter 420 may be connected to a standard computer readable medium, such as a fixed disk drive (internal or external), for storing and/or retrieving information.

Many other devices, components, elements, or subsystems (not shown) may be connected to interconnect 410 or via a network (e.g., network 120 of fig. 1) in a similar manner. In contrast, all of the devices shown in FIG. 4 need not be present to practice the present disclosure. The devices and subsystems may be interconnected in different ways from that shown in fig. 4. Code implementing the dynamic methods of payment gateway selection and payment transaction processing of the present disclosure may be stored in a computer-readable storage medium, such as one or more system memories 418 or other storage devices. Fruit of Chinese wolfberryThe code for the payment gateway selection and dynamic method of payment transaction processing of the present disclosure may also be received via one or more interfaces and stored in memory. The operating system provided on computer system 400 may be an MS-

MS-

OS

Or another operating system.

By providing the gateway selection and routing system with AI and machine learning based analysis as described herein, the system 300 may enable the identification and selection of gateways to more successfully process a wide variety of transactions. At the same time, the system 300 may provide improved load balancing of network components, maximize resource utilization, increase processing speed, and minimize energy consumption. Further, the system 300 may minimize failed or unsuccessful transactions that may harm the user, consumer, merchant, or other entity involved in the various data-based transactions. The system 300 may incorporate multiple variables or parameters to analyze the likelihood that gateway performance at any given time results in a more efficient gateway selection and routing approach in a heterogeneous manner. It should be appreciated that the examples described herein may have a flexible structure and provide many advantages over other conventional or custom solutions.

Fig. 5 illustrates a method for electronic payment and gateway routing according to one example. The method 500 is provided as an example, as there are a variety of ways to perform the methods described herein. Although method 500 is primarily described as being performed by system 300 as shown in fig. 1, 2, and 3, or computer system 400 of fig. 4, method 500 may be performed by or otherwise performed by other systems or combinations of systems. Each block shown in fig. 5 may also represent one or more processes, methods, or subroutines, and one or more blocks may comprise machine-readable instructions stored on a non-transitory computer-readable medium and executed by a processor or other type of processing circuitry to perform one or more operations described herein.

At 510, the system 300 may receive data associated with a transaction. As described herein, the transaction may be a payment transaction. In some examples, the system 300 may also format data associated with the transaction as usable data. At least some of the data may be received based on data from the transaction, such as a payment for an amount of the transaction. At least some data may be received from a system clock, such as the current time that the payment transaction is being processed.

In 520, the system 300 may determine predicted performance capabilities of the plurality of gateways based on one or more transaction parameters associated with the transaction data. As described herein, the one or more transaction parameters may include, but are not limited to, a transaction type, an amount, a transaction currency, a time, a date, a location, a payer identifier, a payee identifier, an acquirer identifier, an issuer identifier authorization requirement, a response requirement, a security requirement, card information, a user profile, a transaction profile, an authentication requirement, an operating environment, an output capability, and/or an activity pattern.

In some examples, Artificial Intelligence (AI) -based machine learning techniques may be used to determine the predicted performance capabilities of each of the plurality of gateways. As described herein, Artificial Intelligence (AI) -based machine learning techniques may include, but are not limited to, clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, knowledge graph analysis, and/or other techniques.

To facilitate determining the predicted performance capabilities, the system 300 may use AI-based machine learning techniques to calculate a value representing the predicted performance capabilities of each of the plurality of gateways. In some examples, the value may be further weighted based on one or more transaction parameters and/or data associated with the transaction.

At 530, the system 300 may select a target gateway from the plurality of gateways based on the predicted performance capabilities. In some examples, the target gateway may be selected from the plurality of gateways based on a weighted value of the predicted performance capabilities. As described above, each of the plurality of gateways may be associated with a value or weighted value indicative of a predicted performance capability. In some examples, the gateway having the highest value or highest weighted value may be determined to have the highest likelihood of success in processing the electronic transaction and therefore be selected as the target gateway.

In 540, the system 300 may transmit data associated with the transaction to the target gateway to process the transaction through the transaction or card network 260, as described with reference to fig. 2.

Although the selection and routing methods and systems described herein may be primarily directed to payment transactions, it should be understood that the system 300 may provide processor/network routing, which may or may not involve a gateway. Further, the system 300 may use routing or decision making in transactions or scenarios that do not involve payment. For example, the system 300 may also use the AI-based machine learning techniques disclosed herein in other various environments, such as in advertising transactions, online transactions, mobile transactions, merchant transactions, user-to-user transactions, charge-based transactions, card-based transactions, financial transactions, and/or digital transactions. Other applications or uses of the system 300 may also include social networking, competition, marketing, performance analysis, risk analysis, data management, content-based recommendation engines, and/or other types of knowledge or data driven systems.

It should be noted that the functionality described herein may be constrained by one or more privacy policies implemented by the system 300 that may prohibit the use of images for concept detection, recommendation, generation, and analysis.

In particular examples, one or more objects (e.g., content or other types of objects) of a computing system may be associated with one or more privacy settings. The one or more objects may be stored on or otherwise associated with any suitable computing system or application, such as, for example, system 300, client device 110, gateway 140, external system 130, a social networking application, a messaging application, a photo sharing application, or any other suitable computing system or application. Although the examples discussed herein are in the context of an online social network, these privacy settings may apply to any other suitable computing system. The privacy settings (or "access settings") of the object may be stored in any suitable manner, such as, for example, in association with the object, in an index on an authorization server, in another suitable manner, or any suitable combination thereof. The privacy settings of an object may specify how the object (or particular information associated with the object) may be accessed, stored, or otherwise used (e.g., viewed, shared, modified, copied, executed, surfaced, or identified) in an online social network. An object may be described as "visible" with respect to a particular user or other entity when the privacy settings of the object allow the user or other entity to access the object. By way of example and not limitation, a user of an online social network may specify privacy settings for a user profile page that identify a group of users that may access work experience information on the user profile page, thus excluding other users from accessing the information.

In a particular example, the privacy settings of an object may specify a "blocked list" of users or other entities that should not be allowed to access certain information associated with the object. In a particular example, the blocklist may include third party entities. The blocklist may specify one or more users or entities to which the object is not visible. By way of example and not limitation, a user may specify a group of users who may not have access to an album associated with the user, thereby precluding those users from accessing the album (while certain users who may not be within the specified group of users may also be permitted access to the album). In a particular example, the privacy settings may be associated with particular social graph elements. Privacy settings of a social graph element (e.g., a node or an edge) may specify how the social graph element, information associated with the social graph element, or objects associated with the social graph element may be accessed using an online social network. By way of example and not limitation, a particular concept node corresponding to a particular photo may have a privacy setting that specifies that the photo is only accessible to the user tagged in the photo and friends of the user tagged in the photo. In particular examples, privacy settings may allow users to opt-in or opt-out to have their content, information, or actions stored/recorded by system 300 or shared with other systems (e.g., external system 130). Although this disclosure describes using particular privacy settings in a particular manner, this disclosure contemplates using any suitable privacy settings in any suitable manner.

In a particular example, the system 300 may present a "privacy wizard" to the first user (e.g., within a web page, module, one or more dialog boxes, or any other suitable interface) to help the first user specify one or more privacy settings. The privacy wizard may display instructions, suitable privacy-related information, current privacy settings, one or more input fields for accepting one or more inputs from the first user specifying a change or confirmation of the privacy settings, or any suitable combination thereof. In a particular example, the system 300 may provide a "dashboard" functionality to the first user that may display the first user's current privacy settings to the first user. The dashboard function may be displayed to the first user at any suitable time (e.g., after an input from the first user invoking the dashboard function, after a particular event or trigger action occurs). The dashboard functionality may allow the first user to modify one or more current privacy settings of the first user at any time in any suitable manner (e.g., redirect the first user to a privacy wizard).

The privacy settings associated with the object may specify any suitable granularity at which access is allowed or denied. By way of example and not limitation, access or denial of access may be specified for a particular user (e.g., only me, my roommates, my boss), users within a particular degree of separation (e.g., friends of friends), groups of users (e.g., gaming clubs, my family), networks of users (e.g., employees of a particular employer, students or alumni of a particular university), all users ("public"), no users ("private"), users of a third-party system, a particular application (e.g., a third-party application, an external website), other suitable entity, or any suitable combination thereof. Although this disclosure describes a particular granularity of allowing or denying access, this disclosure contemplates any suitable granularity of allowing or denying access.

In a particular example, different objects of the same type associated with a user may have different privacy settings. Different types of objects associated with a user may have different types of privacy settings. By way of example and not limitation, the first user may specify that the status update of the first user is public, but that any image shared by the first user is only visible to friends of the first user on the online social network. As another example and not by way of limitation, a user may specify different privacy settings for different types of entities (e.g., an individual user, friends of friends, attendees, user groups, or corporate entities). As another example and not by way of limitation, the first user may specify a group of users that may view a video published by the first user while preventing the video from being visible to an employer of the first user. In particular examples, different privacy settings may be provided for different groups of users or user demographics. By way of example and not limitation, the first user may specify that other users of the same university as the first user may view photos of the first user, but that other users who are family members of the first user may not view those same photos.

In a particular example, the system 300 can provide one or more default privacy settings for each object of a particular object type. The privacy settings of an object set as a default may be changed by the user associated with the object. By way of example and not limitation, all images posted by the first user may have a default privacy setting that is visible only to friends of the first user, and for a particular image, the first user may change the privacy setting of the image to be visible to friends and friends of friends.

In a particular example, the privacy settings may allow the first user (e.g., by opt-out, by opt-in) to specify whether the system 300 may receive, collect, record, or store particular objects or information associated with the user for any purpose. In particular examples, the privacy settings may allow the first user to specify whether a particular application or process may access, store, or use a particular object or information associated with the user. The privacy settings may allow the first user to opt-in or opt-out of having objects or information accessed, stored, or used by a particular application or process. The system 300 may access such information to provide a particular function or service to the first user, while the system 300 may not access the information for any other purpose. Prior to accessing, storing, or using such objects or information, the system 300 may prompt the user to provide privacy settings that specify which applications or processes (if any) may access, store, or use the objects or information before allowing any such actions. By way of example and not limitation, a first user may transmit a message to a second user via an application (e.g., messaging app) related to an online social network, and may specify privacy settings at which such message should not be stored by system 300.

In a particular example, the user may specify whether the system 300 may access, store, or use a particular type of object or information associated with the first user. By way of example and not limitation, the first user may specify that images transmitted by the first user through the system 300 may not be stored by the system 300. As another example and not by way of limitation, a first user may specify that messages sent from the first user to a particular second user may not be stored by the system 300. As yet another example and not by way of limitation, the first user may specify that all objects sent via a particular application may be saved by the system 300.

In particular examples, the privacy settings may allow the first user to specify whether particular objects or information associated with the first user may be accessed from the client device 110 or the external system 130. The privacy settings may allow the first user to opt-in or opt-out of accessing objects or information from a particular device (e.g., a phone book on the user's smartphone), from a particular application (e.g., a messaging app), or from a particular system (e.g., an email server). The system 300 may provide default privacy settings for each device, system, or application, and/or may prompt the first user to specify particular privacy settings for each context. By way of example and not limitation, the first user may utilize the location service features of system 300 to provide recommendations regarding restaurants or other places near the user. The first user's default privacy settings may specify that the system 300 may use location information provided from one of the first user's client devices 110 to provide location-based services, but that the system 300 may not store or provide the first user's location information to any external system 130. The first user may then update the privacy settings to allow the third-party image sharing application to use the location information to geotag the photograph.

In particular examples, privacy settings may allow a user to specify whether current, past, or anticipated emotion, or sentiment information associated with the user may be determined, and whether a particular application or process may access, store, or use such information. Privacy settings may allow a user to opt-in or opt-out of having mood, emotion, or emotional information accessed, stored, or used by a particular application or process. The system 300 may predict or determine emotions, or emotions associated with a user based on, for example, user-provided input and interactions with particular objects (e.g., pages or content viewed by the user, posts uploaded by the user, or other content), as well as interactions with other content of the online social network. In a particular example, the system 300 may use the user's previous activities and the calculated emotion, or emotion to determine the current emotion, or emotion. A user wishing to enable this function may indicate in their privacy settings that they choose to join in having system 300 receive the input necessary to determine emotion, or emotion. By way of example and not limitation, system 300 may determine that the default privacy setting is not to receive any information needed to determine emotion, or emotion until there is an explicit indication from the user that system 300 may do so. Conversely, if the user does not opt-in to have the system 300 receive these inputs (or affirmatively opt-out to have the system 300 receive these inputs), the system 300 may be prevented from receiving, collecting, recording, or storing these inputs or any information associated with these inputs. In a particular example, the system 300 may use predicted emotions, or emotions to provide recommendations or advertisements to the user. In a particular example, if the user wishes to use the functionality for a particular purpose or application, the user may specify additional privacy settings to opt-in to having emotional, or emotional information for that particular purpose or application. By way of example and not limitation, system 300 may use a user's mood, emotion, or emotion to provide a dynamic message (news feed) item, page, friend, or advertisement to the user. The user may specify in his privacy settings that system 300 may determine the user's mood, emotion, or emotion. The user may then be asked to provide additional privacy settings to indicate the purpose for which the user's mood, emotion or emotion may be used. The user may indicate that system 300 may use his or her mood, emotion, or emotion to provide dynamic message content and a recommendation page, but not to recommend friends or advertisements. System 300 may then provide only dynamic message content or pages based on the user's mood, emotion, or emotion, and may not use this information for any other purpose, even if privacy settings are not explicitly prohibited.

In a particular example, the privacy settings may allow a user to participate in transient sharing of objects on an online social network. Ephemeral sharing refers to sharing objects (e.g., posts, photos) or information for a limited period of time. Access or denial of access to objects or information may be specified by time or date. By way of example and not limitation, a user may specify that a particular image uploaded by the user is visible to the user's friends in the next week, after which time the image may no longer be accessible to other users. As another example and not by way of limitation, a company may publish content related to the release of a product prior to formal release and specify that the content is not visible to other users until after the release of the product.

In certain examples, for certain objects or information having privacy settings that specify that they are time-limited, the system 300 may restrict its access, storage, or use of such objects or information. The system 300 may temporarily access, store, or use these particular objects or information to cause a particular action by a user associated with these objects or information, and may subsequently delete the objects or information, as specified by the corresponding privacy settings. By way of example and not limitation, a first user may transmit a message to a second user, and the system 300 may temporarily store the message in the content data store until the second user has viewed or downloaded the message, at which point the system 300 may delete the message from the data store. As another example and not by way of limitation, continuing with the previous example, a message may be stored for a specified period of time (e.g., 2 weeks), after which the system 300 may delete the message from the content data store.

In particular examples, the privacy settings may allow a user to specify one or more geographic locations from which an object may be accessed. Access or denial of access to the object may depend on the geographic location of the user attempting to access the object. By way of example and not limitation, users may share an object and specify that only users in the same city may access or view the object. As another example and not by way of limitation, a first user may share an object and specify that the object is visible to a second user only when the first user is at a particular location. If the first user leaves the particular location, the object may no longer be visible to the second user. As another example and not by way of limitation, a first user may specify that an object is only visible to a second user within a threshold distance from the first user. If the first user subsequently changes location, a second user who originally had access to the object may lose access, and a new group of second users may gain access when they reach within a threshold distance of the first user.

In a particular example, the system 300 may have the following functionality: personal or biometric information of the user may be used as input for user authentication or experience personalization purposes. Users may choose to utilize these functions to enhance their experience on the online social network. By way of example and not limitation, a user may provide personal or biometric information to the system 300. The user's privacy settings may specify that such information may be used only for certain processes, such as authentication, and further specify that such information may not be shared with any external systems 130 or used for other processes or applications associated with the system 300. As another example and not by way of limitation, system 300 may provide functionality for a user to provide voiceprint recordings to an online social network. By way of example and not by way of limitation, if a user wishes to take advantage of this functionality of an online social network, the user may provide a sound recording of his or her own voice to provide status updates on the online social network. The recording of the voice input may be compared to the user's voice print to determine what words the user speaks. The user's privacy settings may specify that such voice recordings may be used only for voice input purposes (e.g., authenticating the user, sending voice messages, improving voice recognition to use voice-operated features of the online social network), and further specify that such voice recordings may not be shared with any external system 130 or used by other processes or applications associated with the system 300. As another example and not by way of limitation, system 300 may provide functionality for a user to provide a reference image (e.g., facial contour, retinal scan) to an online social network. The online social network may compare the reference image to later received image input (e.g., to authenticate the user, mark the user in a photo). The user's privacy settings may specify that such voice recordings may be used for only limited purposes (e.g., authenticating, tagging the user in a photo), and further specify that such voice recordings may not be shared with any external system 130 or used by other processes or applications associated with system 300.

In certain examples, changes to the privacy settings may take effect retroactively, which may affect the visibility of objects and content shared before the change. By way of example and not limitation, a first user may share a first image and specify that the first image is to be disclosed to all other users. Later, the first user may specify that any images shared by the first user should only be visible to the first group of users. The system 300 may determine that the privacy settings also apply to the first image and make the first image visible only to the first group of users. In certain examples, changes to the privacy settings may only take effect in the future. Continuing with the example above, if the first user changes the privacy setting and then shares the second image, the second image may only be visible to the first group of users, but the first image may remain visible to all users. In a particular example, in response to a user action to change the privacy settings, the system 300 can further prompt the user to indicate whether the user wants to apply the change in privacy settings retrospectively. In a particular example, the user's changes to the privacy settings may be a one-time change specific to one object. In a particular example, the user's changes to privacy may be global changes to all objects associated with the user.

In a particular example, the system 300 may determine that the first user may want to change one or more privacy settings in response to a trigger action associated with the first user. The trigger action may be any suitable action on the online social network. By way of example and not limitation, the triggering action may be a change in a relationship between a first user and a second user of the online social network (e.g., a user "delete friends" changing a relationship state between the users). In a particular example, upon determining that the trigger action has occurred, the system 300 can prompt the first user to change a privacy setting regarding visibility of an object associated with the first user. The prompt may redirect the first user to a workflow process for editing privacy settings for one or more entities associated with the trigger action. The privacy settings associated with the first user may only be changed in response to explicit input from the first user and may not be changed without approval by the first user. By way of example and not limitation, the workflow process may include providing a current privacy setting for a second user or group of users to a first user (e.g., removing a tab of the first user or second user from a particular object, changing the visibility of a particular object for the second user or group of users), and receiving an indication from the first user to change the privacy setting based on any of the methods described herein, or to maintain an existing privacy setting.

In certain examples, a user may need to provide verification of privacy settings before allowing the user to perform a particular action on an online social network, or to provide verification before changing a particular privacy setting. When a particular action is performed or a particular privacy setting is changed, a prompt may be presented to the user to remind the user of his or her current privacy setting and ask the user to verify the privacy setting for the particular action. Further, a user may need to provide confirmation, double confirmation, authentication, or other suitable type of verification before a particular action is taken, and the action may not be completed before such verification is provided. By way of example and not limitation, a user's default privacy settings may indicate that one person's relationship status is visible (i.e., "public") to all users. However, if the user changes his or her relationship state, the system 300 may determine that such action may be sensitive and may prompt the user to confirm whether his or her relationship state should remain public before proceeding. As another example and not by way of limitation, a user's privacy settings may specify that the user's posts are visible only to the user's friends. However, if the user changes the privacy setting of his or her post to public, the system 300 may prompt the user for both: the user's current privacy setting for the posts is a reminder that is only visible to friends, and the change will make all of the user's past posts visible to the public. The user may then need to provide a second verification, enter authentication credentials, or provide other types of verification before proceeding to change the privacy settings. In certain examples, the user may need to provide verification of the privacy settings on a regular basis. A prompt or reminder may be sent to the user periodically, depending on the elapsed time or the number of user actions. By way of example and not limitation, the system 300 may send a reminder to the user to confirm his or her privacy settings every six months or every ten photo postings. In certain examples, the privacy settings may also allow the user to control access to objects or information on a per-request basis. By way of example and not limitation, the system 300 may notify the user whenever the external system 130 attempts to access information associated with the user and require the user to provide verification that access should be allowed before proceeding.

What has been described and illustrated herein are examples and some variations of the present disclosure. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the scope of the disclosure, which is intended to be defined by the following claims and their equivalents, in which all terms are meant in their broadest reasonable sense unless otherwise indicated.

Claims (15)

1. A system, comprising:

a processor;

a memory storing instructions that, when executed by the processor, cause the processor to:

receiving data associated with a transaction;

determining a predicted performance capability for each of a plurality of gateways based on one or more transaction parameters associated with the data;

selecting a target gateway from the plurality of gateways based on a predicted performance capability of the target gateway; and

transmitting data associated with the transaction to the target gateway to process the transaction over a network.

2. The system of claim 1, wherein the transaction is a payment transaction.

3. The system of claim 1 or claim 2, wherein the predicted performance capabilities of each of the plurality of gateways comprises at least one of: a probability that the target gateway will successfully process the transaction, a speed at which the target gateway will process the transaction, or a cost associated with the target gateway processing the transaction.

4. The system of any preceding claim, wherein the instructions further cause the system to use an Artificial Intelligence (AI) -based machine learning technique that analyzes data associated with the transaction and data associated with the plurality of gateways to determine a predicted performance capability of each of the plurality of gateways.

5. The system of claim 4, wherein the Artificial Intelligence (AI) -based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis.

6. The system according to claim 4 or claim 5, wherein the Artificial Intelligence (AI) -based machine learning technique comprises calculating, for each of the plurality of gateways, a value representing a predicted performance capability of the gateway;

optionally, wherein the instructions further cause the system to weight the value of each of the plurality of gateways based on at least one of the one or more transaction parameters or data associated with the transaction to create a weighted value; and is

Further optionally, wherein the target gateway is selected from the plurality of gateways based on weighted values of the predicted performance capabilities.

7. The system of any preceding claim, wherein the one or more transaction parameters comprise at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity pattern.

8. A method, comprising:

receiving, by a processor of a payment system operating in a network, data associated with a transaction;

determining, by a processor of the payment system, a predicted performance capability for each of a plurality of gateways based on one or more transaction parameters associated with the data;

selecting, by the processor, a target gateway from the plurality of gateways based on a predicted performance capability of the target gateway; and

transmitting, by the processor, data associated with the transaction to the target gateway to process the transaction over a network.

9. The method of claim 8, wherein determining the predicted performance capabilities further comprises determining the predicted performance capabilities of each of the plurality of gateways using Artificial Intelligence (AI) -based machine learning techniques that analyze data associated with transactions and data associated with the plurality of gateways; and is

Optionally, wherein the AI-based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis.

10. The method of claim 9, wherein using the AI-based machine learning technique further comprises calculating, for each of the plurality of gateways, a value representing a predicted performance capability of the gateway,

optionally, the method further comprises:

weighting the value for each of the plurality of gateways based on at least one of the one or more transaction parameters or data associated with the transaction, thereby creating a weighted value for each of the plurality of gateways.

11. The method of claim 10, wherein selecting the target gateway comprises selecting the target gateway from the plurality of gateways based on a weighted value for each of the plurality of gateways.

12. The method of any of claims 8 to 11, wherein the one or more transaction parameters comprise at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity pattern.

13. A non-transitory computer-readable storage medium having stored thereon an executable file that, when executed, instructs a processor to:

receiving data associated with a transaction;

associating one or more transaction parameters with data associated with the transaction, wherein the one or more transaction parameters are associated with performance capabilities of a plurality of gateways;

applying an Artificial Intelligence (AI) -based machine learning technique to the one or more transaction parameters, wherein the AI-based machine learning technique includes at least one of: clustering, classification, pattern mining, logistic regression, decision trees, random forests, semantics, simulation, or knowledge graph analysis;

calculating a value for each of the plurality of gateways based on the AI-based machine learning technique, wherein the value represents a performance capability of each of the plurality of gateways; and

selecting a target gateway from the plurality of gateways based on the value for each of the plurality of gateways.

14. The non-transitory computer-readable storage medium of claim 13, wherein the transaction is a payment transaction, and

optionally, wherein calculating the value comprises weighting each respective value based on at least one of the one or more transaction parameters or data associated with the transaction to create a weighted value for each of the plurality of gateways, wherein selecting the target gateway from the plurality of gateways is based on the weighted value for each of the plurality of gateways.

15. The non-transitory computer-readable storage medium of claim 13 or claim 14, wherein the one or more transaction parameters include at least one of: type, amount, transaction currency, time, date, location, payer identifier, payee identifier, acquirer identifier, issuer identifier authorization requirements, response requirements, security requirements, card information, user profile, transaction profile, authentication requirements, operating environment, output capabilities, or activity pattern.

Images