EP3977384A1

EP3977384A1 - Systems and methods for electronic payment and gateway routing

Info

Publication number: EP3977384A1
Application number: EP20731695.1A
Authority: EP
Inventors: Kasra NEJATIAN; Justin Mason Chace; Ankit Yatish MODI; Ritwik YADAV; Swathish Ram AYYAPPAN
Original assignee: Facebook Inc
Current assignee: Meta Platforms Inc
Priority date: 2019-05-24
Filing date: 2020-05-19
Publication date: 2022-04-06
Also published as: CN113924590A; WO2020242836A1

Abstract

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

Description

SYSTEMS AND METHODS FOR ELECTRONIC PAYMENT AND GATEWAY

ROUTING

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority from U.S. Application No. 16/422,259, filed on May 24, 2019, the contents of which are incorporated by reference in their entirety herein for all purposes.

TECHNICAL FIELD

[0002] This patent application relates generally to electronic payment and routing systems, and more specifically, to systems and methods for electronic payment and gateway routing using artificial intelligence (Al) based machine learning techniques.

BACKGROUND

[0003] Advances in mobile telecommunications are changing the way people communicate with one another and the way people purchase items and services. The retail and commercial industries, for example, have witnessed unprecedented digital growth in recent years. With increased globalization, ensuring successful payment transactions, for example, is becoming more challenging amidst larger volumes of data and digital transactions.

SUMMARY OF THE INVENTION [0004] According to a first aspect of the present invention, there is provided a system comprising: a processor; a memory storing instructions, which when executed by the processor, causes the processor to: receive data associated with a transaction; determine a predicted performance capability for each of a plurality of gateways based on one or more transaction parameters associated with the data; select a target gateway from the plurality of gateways based on the predicted performance capability of the target gateway; and transmit the data associated with the transaction to the target gateway to process the transaction over a network.

[0005] The transaction may be a payment transaction.

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

[0007] The instructions may further cause the system to use an artificial intelligence, Al, based machine learning technique that analyzes the data associated with transaction and data associated with the plurality of gateways to determine the predicted performance capability of each of the plurality of gateways. [0008] The artificial intelligence, Al, based machine learning technique may comprise at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis.

[0009] The artificial intelligence, Al, based machine learning technique may comprise calculating, for each of the plurality of gateways, a value that represents the predicted performance capability of the gateway.

[0010] The instructions may further cause the system to weight the values for each of the plurality of gateways to create weighted values based on at least one of: the one or more transaction parameters, or the data associated with the transaction.

[0011] The target gateway may be selected from the plurality of gateways based on the weighted value for the predicted performance capability.

[0012] The one or more transaction parameters may comprise at least one of: type, amount, transaction currency, time, date, location, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, or activity pattern. [0013] According to a second aspect of the present 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 of 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 the predicted performance capability of the target gateway; and transmit, by the processor, the data associated with the transaction to the target gateway to process the transaction over the network.

[0014] Determining the predicted performance capability may further comprise determining the predicted performance capability of each of the plurality of gateways using an artificial intelligence, Al, based machine learning technique that analyzes the data associated with transaction and data associated with the plurality of gateways.

[0015] The Al based machine learning technique may comprise at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis.

[0016] Using the Al based machine learning technique may further comprise calculating, for each of the plurality of a gateways, a value that represents the predicted performance capability of the gateway.

[0017] The method may further comprise: weighting the value for each of the plurality of gateways to create, for each of the plurality of gateways, a weighted value for the gateway based on at least one of: the one or more transaction parameters, or the data associated with the transaction.

[0018] Selecting the target gateway may comprise selecting the target gateway from the plurality of gateways based on the weighted value for each of the plurality of gateways.

[0019] The one or more transaction parameters may comprise at least one of: type, amount, transaction currency, time, date, location, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, or activity pattern.

[0020] According to a third aspect of the present invention, there is provided a non-transitory computer-readable storage medium having an executable stored thereon, which when executed instructs a processor to: receive data associated with a transaction; correlate one or more transaction parameters with the data associated with the transaction, wherein the one or more transaction parameters are associated with a performance capability of the plurality of gateways; apply an artificial intelligence (Al) based machine learning technique to the one or more transaction parameters, wherein the Al based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis; calculate a value for each of the plurality of gateways based on the Al based machine learning technique, wherein the value represents the performance capability of each of the plurality of gateways; and select a target gateway from the plurality of gateways based on the value for each of the plurality of gateways.

[0021] The transaction may be a payment transaction.

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

[0023] The one or more transaction parameters may comprise at least one of: type, amount, transaction currency, time, date, location, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, or activity pattern.

BRIEF DESCRIPTION OF DRAWINGS [0024] Features of the present disclosure are illustrated by way of example and not limited in the following figures, in which like numerals indicate like elements. One skilled in the art will readily recognize from the following that alternative examples of the structures and methods illustrated in the figures can be employed without departing from the principles described herein.

[0025] Figure 1 illustrates a block diagram of a system environment of a system for facilitating transaction processing related to electronic payments and for gateway routing for transaction processing, according to an example.

[0026] Figure 2 shows a block diagram of the system for electronic payment and gateway routing in an electronic transaction processing environment shown in Figure 1 , according to an example.

[0027] Figure 3 illustrates a block diagram of the system for electronic payment and gateway routing depicted in Figures 1 and 2, according to an example.

[0028] Figure 4 illustrates a block diagram of a computer system for electronic payment and gateway routing, according to an example.

[0029] Figure 5 illustrates a method for electronic payment and gateway routing, according to an example.

DETAILED DESCRIPTION

[0030] 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 readily apparent, however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures readily understood by one 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 denote at least one of a particular element, the term“includes” means includes but not limited to, the term“including” means including but not limited to, and the term“based on” means based at least in part on.

[0031] A payment gateway facilitates a payment transaction by transferring information between a payment portal and a front-end processor or acquiring bank. A payment transaction facilitated by a payment gateway may include any transaction associated with an electronic payment, where the transaction may be between a payment system, a payor, and/or a payee. A payment transaction may further be associated with a transaction type, such as a sale transaction, a post authorization transaction, or a refund. A payment gateway may include any node or network element that provides routing functionality to facilitate payment transactions. In some instances, a bank or a specialized financial service provider may provide the payment gateway for its customers. Existing payment systems generally may not have features that provide guidance on gateway selection or routing. Instead, some traditional payment systems simply select a payment gateway using a random or a manual process. In addition, once a payment gateway is selected, the payment gateway may perform a variety of tasks to process the transaction with very little, if any, input from the payment system, payor, or payee.

[0032] Successful payment transactions, however, are often predicated on payment gateway performance. Payment gateway performance, in turn, is based on a number of variables, such as transaction type, date, time, amount, currency, etc. A technical problem with traditional approaches is that selecting a payment gateway typically does not take these or other variables into account. At most, an existing payment system may rely on a rule-based technique, largely guided by a manual process, to select and route a payment transaction to a particular payment gateway. This static approach may often lead to many payment failures and unsuccessful transactions, which in turn may result in wasted and inefficient utilization of processing and networking resources.

[0033] According to examples described herein, dynamic approaches for payment gateway selection and payment transaction processing may be provided. Rather than rely on traditional rule-based techniques, the dynamic approaches may reduce or eliminate payment failures and unsuccessful transactions and may also increase the performance and speeds at which transactions are completed. As a result, a technical improvement to the technical problem discussed above may be that, through implementation of the dynamic approaches disclosed herein, processing resources and networking resources may be utilized in a more efficient and energy-conserving manner.

[0034] The dynamic approaches for payment gateway selection and payment transaction processing may use decisioning and machine learning. The dynamic approaches may also take various transaction processing variables into account to help reduce or eliminate payment failures and unsuccessful transactions. For example, the dynamic approaches disclosed herein may further aid in balancing and/or reducing load on payment gateways, which may help facilitate successful payment transactions. Additionally, the dynamic approaches disclosed herein may enable payment transactions to be completed faster, such as in real-time or near real-time. This may be particularly advantageous for advertising, online shopping, or other scenarios where real-time or near real-time transaction processing may be desired. These and other benefits will be apparent in the description provided herein.

[0035] Figure 1 illustrates a block diagram of a system environment 100 of a system 300 for facilitating transaction processing related to electronic payments and for gateway routing for transaction processing, according to an example. As shown, the system environment 100 may include any number of client devices 1 10, shown as client devices 1 10A, 1 10B, and 1 1 OX, in which the variable“X” may represent an integer greater than one. The system environment 100 may also include a network 120, an external system 130, and any number of gateways 140, shown as gateways 140A, 140B, and 140N, in which the variable“N” may represent an integer greater than one. The system 300 may select a gateway 140A, 140B, and 140N for processing a transaction via transaction processing systems 150. In some examples, the 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 variety of transactions for and with users in personal, financial, or enterprise environments. [0036] In some examples, the system 300 may be an electronic payment system. The system 300 may also include a machine learning subsystem 340, which may use an artificial intelligence (Al) based machine learning technique to determine and automatically select a gateway 140A, 140B, and 140N in order to process one or more payment transactions. The payment transaction, as described herein, 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 a gateway 140A, 140B, and 140N based on a probability that the selected gateway will successfully process a payment transaction. A successful payment transaction, as described herein, may be a payment transaction that does not fail or is not denied during the processing of the payment transaction, or if denied, does not significantly impact or cause undue delay during the processing of the payment transaction. As described here, performance (e.g., speed) of processing a transaction and cost of processing a transaction (e.g., interchange rate, chargebacks, etc.) may also affect whether a payment transaction is deemed successful or not. For example, there may be 200,000 types of bank identification numbers (BINs) for credit or debit cards used and stored at system 300. However, it may be observed that certain credit cards may process more swiftly and with more throughput via one of the gateways 140 (e.g., the gateway 140A) relative to other gateways 140 (e.g., the gateway 140B). When routing the transaction through this gateway 140A, the payment transaction may be processed more successfully, at a faster collective rate, and/or with minimum associated cost, charges, or fees. [0037] In some examples, a successful payment transaction may be predicted based on a multitude of variables, such as transaction type, date, time, amount, and/or currency, to name a few. For instance, the probability of a successful payment transaction may occur at a particular gateway using these and/or other variables as described in more detail with respect to Figure 3.

[0038] Once the machine learning subsystem 340 identifies and determines the gateway 140A, 140B, and 140N based on the probabilities of producing a successful payment transaction and/or the performance capabilities, the gateway 140A, 140B, and 140N may be selected to proceed with processing the payment transaction. It should be appreciated that the system 300 may also receive data or various instructions from the client devices 1 10 and/or the external system 130 beyond processing transactions.

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

[0040] In some examples, the client devices 1 10 may execute an application allowing a user of the client devices 1 10 to interact with various elements on the network 120. For instance, the client devices 1 10 may receive data from user input, a database, a file, a web service, and/or via an application programming interface (API). Additionally, the client devices 1 10 may execute a browser or application to enable interaction between the client devices 1 10 and the system 300 via the network 120. For example, a user may interact with a mobile application or a web application, executing via a browser, to provide user input for a payment transaction. In an example, the client devices 1 10 may interact with the system 300 through application programming interfaces (APIs) running on a native or remote operating systems of the client devices 1 10. Other various examples may also be provided.

[0041] According to examples, the client devices 1 10 may include software for facilitating transaction processing related to electronic payments and for gateway routing for transaction processing. For instance, the client devices 1 10 may have access to 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 network centric location. However, it should be appreciated that any data or functionality associated with the machine learning subsystem 340 may also be local to the client devices 1 10, or at some other computing device between the client devices 1 10 and the gateways 140.

[0042] The 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 the client devices 1 10, the external system 130, the system 300, and/or any other system, component, or device connected to the network 120. The network 120 may further include one, or any number, of the exemplary types of networks mentioned above operating as a stand-alone network or in cooperation with each other. For example, the network 120 may utilize one or more protocols of one or more clients or servers to which they are communicatively coupled. The network 120 may facilitate transmission of data according to a transmission protocol of any of the devices and/or systems in the network 120. Although the network 120 is depicted as a single network in Figure 1 , it should be appreciated that in some examples, the network 120 may include a plurality of interconnected networks as well.

[0043] The external system 130 may be communicatively coupled to the network 120. In some examples, the external system 130 may be a third-party website, or any content or data source, that provides content or data to the client devices 1 10 and/or the system 300. The external system 130 may also provide content via the system 300 or other network element (not shown).

[0044] In some examples, the external system 130 may include an enterprise resource planning (ERP) system and application, a document, a web feed or online portal. 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. The ERP system may collect, store, manage, and interpret data associated with various enterprise functions or activities. The ERP system may also provide an integrated and continuously updated view of core business processes, for example, using common databases 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 corporate or business transactions (e.g., orders, purchase orders, payroll, etc.). The ERP system may also monitor and store data associated with various customer communications. Furthermore, the applications that make up the ERP system may share data across various departments (e.g., manufacturing, purchasing, sales, accounting, etc.) that provide related communications data. The ERP system may facilitate information flow between many enterprise functions and may manage communications with stakeholders, customers, or other parties. The ERP system may also contain a large amount of information that could be used to enhance meaning of other data. In some examples, the external system 130 may include any number of payor/payee profiles, preferences, trends, policies, etc., all of which may facilitate successful transaction processing, as described herein.

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

[0046] The terms “payment gateway” and “gateway” may be used interchangeably throughout, unless otherwise expressly noted. Such payment transactions may involve transfer of information between a payment portal, such as a website, mobile phone, or interactive voice response service, and one or more transaction processing systems 150, such as a front-end processor or acquiring bank, card network, issuer, or other network element for processing transactions, which may be downstream of the system 300 and the gateways 140.

[0047] In a payment transaction scenario, the gateways 140, for example, may also screen transactions for fraud and/or calculate tax in real time prior to the authorization request being sent to the processor. The gateways 140 may also help detect fraud by Incorporating features, such as geolocation, velocity pattern analysis, Office of Foreign Assets Control (OFAC) list or black-list lookups, delivery address verification, address verification system (AVS) checks, biometrics or other identity morphing detection, etc. The gateways 140, for example, may incorporate any number of these features to help flag for fraudulent activities by identifying irregular purchasing activities, shortened time period between transactions, increased number of transactions, disparate geographic locations of multiple transactions, high-doMar transactions, inaccurate password or PIN (personal identification number) attempts, high-risk locations (e.g., cities, states, countries, etc.), or a combination thereof. It should also be appreciated that the gateways 140 may be used in such a way where payment service providers, e-commerce platforms, independent sales organizations (ISOs), resellers, or acquiring banks, for example, may be able to fully incorporate and brand the payment gateway technology and functionalities as their own. This may provide a more seamless user experience and increase enterprise partnerships and collaboration. Figure 1 shows the network 120 communicatively coupled to the client devices 1 10, the external system 130, and the system 300. However, it should be apparent to one of ordinary skill in the art that the network 120 may also communicatively couple the system 300, the gateways 140, the transaction processing systems 150, and/or any other computing device or network element in the system environment 100.

[0048] Figure 2 shows a block diagram of the system 300 for electronic payment and gateway routing in an electronic transaction processing environment 200 shown in Figure 1 , according to an example. Although Figure 2 is directed to a card processing environment 200, it will be apparent to one of ordinary skill in the art that the principles described with respect to card processing may be applied to other transaction processing environments, such as electronic funds transfers, mobile payments, debit, and/or other transactions. As shown, the client devices 1 10 may communicate with the system 300 to process a transaction via gateway 140. In the card processing environment 200, the transaction may be a card-related payment transaction (e.g., 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 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.

[0049] When a customer places an order for a product or service via one of the client devices 1 10 (e.g., a POS device or computing device capable of supporting an online purchase), data associated with the purchase may be generated or received at the client devices 1 10 and transmitted to the system 300. Among other things, the data associated with the purchase may include card payment data and/or profile information associated with a customer or purchaser. It should be appreciated that a web browser, mobile application, or other security-enabled feature at the client devices 1 10 or the system 300 may encrypt the data associated with the purchase. In some examples, this may be achieved via SSL (Secure Socket Layer) encryption or other encryption/security technique. In some examples, when the customer places the order via the client device 1 10, the client device 1 10 may transmit a request for a transaction or card payment to the system 300.

[0050] Once the system 300 receives a request for a card payment from one of the client devices 1 10, the system 300 may use a machine learning or other Al-based technique to select and route the transaction to one of the gateways 140 (e.g., payment gateway) that is identified and determined to have, for instance, the highest likelihood of success for processing the payment transaction. In some examples, the success of a payment transaction may be based on the likelihood that a payment transaction will be processed without failure. The success of a payment transaction may also be based on performance, such as speed. For instance, minimizing the time it takes to initiate and complete a payment transaction may be desirable, since this may translate to more transactions being completed in any given time period. The success of a payment transaction may also be based on the cost of processing a transaction (e.g., interchange rate, chargebacks, etc.). In some examples, performance or speed of a transaction may be affected by data load (or predicted data load) at the gateways 140 or transaction processing systems 150, network latencies, or other factors that may affect time for a transaction to process. Cost of a transaction may be affected by interchange cost, exchange rate, chargebacks, or other charges related to location, distance, product, service, issuer, or acquirer. Again, the system 300 may determine these and other conditions based on a variety of factors and/or parameters, described in more detail with respect to Figure 3. Accordingly, the system 300 may identify and select one of the gateways 140 that has the most likelihood of success, which may be referred to as a selected gateway or a target gateway, and may proceed to transmit the data associated with the purchase (or any other relevant purchase or transaction details) to the target gateway. It should also be appreciated that another (SSL) encrypted connection may also be provided to any payment server hosted by the payment gateway 140 or other similarly encrypted/secured connection.

[0051] In some examples, the system 300 may communicate with a 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, enterprises, 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 a plurality of customers, merchants, banks, users, systems, historical transactions, etc., in order to determine patterns, behaviors, and trends for current or future transactions. In this way, the system 300 may use the information included in the vault 225 to help facilitate processing a payment transaction (e.g., improve speed, cost, and/or success) as well as communicate with the client devices 1 10, external systems, or other downstream elements for payment processing in the card processing environment 200. This and other data at the vault 225 may be used by the system 300 to analyze and select the gateways 140 for transaction processing. As described in more detail with respect to Figure 3, the vault 225 may communicate and share data with with various components in the system 300 in order to help facilitate selection of and routing transactions to the gateways 140.

[0052] The gateway 140 that is 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, the gateway 140 may convert received data to usable data. For instance, the 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 a variant message format (e.g., a format understood by electronic funds transfer (EFT) switches). The gateway 140 may then transmit this transaction information to the acquirer processor 255 at the acquirer 250.

[0053] In some examples, it should be appreciated that the gateways 140 may receive transaction data, which may include data associated with purchases, directly from the client devices 1 10, bypassing any other systems, even the system 300. As described herein, this may involve the client devices 1 10 being able to access or support functionalities 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 a merchant’s Payment Card Industry Data Security Standard (PCI-DSS) compliance obligations without redirecting a customer away from any online portal or purchasing channel.

[0054] The acquirer processor 255 of the acquirer 250 may transmit the transaction information to the transaction or card network 260. The transaction or card network 260 may be any type of payment or transaction association, such as Visa®, Mastercard®, American Express®, and/or Discover®, to name a few. In some examples, the transaction or card network 260 may act and serve as the issuer 270. For instance, if an American Express® or Discover® card is used in the card processing environment 200, then the transaction or card network 260 associated with American Express® or Discover® card may act and serve as the issuer 270. In this case, the issuer 270, via the issuer processor 275, may directly provide a response of “approved” or“declined” to the payment gateway 140. In some examples, the transaction or card network 260 may allow or another entity (e.g., a card issuing bank or financial institution associated with the transaction or card network 260) to act and serve as the issuer 270. For example, if a Visa® or Mastercard® card is used, the transaction or card network 260 may route the transaction to a card issuing bank or financial institution associated with the transaction or card network 260. This is because Visa® or Mastercard® networks, in general, may allow other entities to act or serve as an issuer. Although the issuer 270 may be different depending on the transaction or card network 260 used, it should be appreciated that the system 300 may continue to analyze and select gateways 140 for routing and electronic transaction processing in a similar manner, regardless of what entity acts or serves as the issuer 270, as described herein.

[0055] In some examples, the card issuing bank or financial institution associated with the transaction or card network 260 may receive an authorization request, and may proceed to verify any available credit or debit balance, and/or transmit a response back to the issuer processor 275 (e.g., via a similar process or route as the request for authorization came in). The response may include a response code (e.g.,“approved” or“declined”). In addition, the response may also include a reason why any particular transaction may have failed. For example, this may include reasons, such as insufficient funds, bank link not available, or other reason for failed or declined transaction. Meanwhile, the issuer 270 may put a hold on this transaction until the system 300, client devices 1 10, or other entity can supply additional information to instruct the transaction process to proceed. This hold may result in a delay, which in turn may impact a consumer’s ability to spend further (because it reduces the line of credit available or it puts a hold on a portion of the funds in a debit account) as well as a merchant’s ability to collect and deliver purchased goods or services.

[0056] If authorization is received or there are no further authorization hurdles to be resolved, the issuer 270 may forward, via the issuer processor 275, an authorization response to the gateway 140. The gateway 140 may receive the authorization response, and forward the authorization response on to the system 300 (or any interface was used to process the payment) where the authorization response is interpreted as a relevant response and then relayed back to the merchant and/or cardholder. This may be commonly known as an“Authorization” or“Auth.” This entire process may take 2-3 seconds to complete. Although this may be a relatively short process, it should be appreciated that in the aggregate, when numerous transactions are taking place, overall processing time may increase. Furthermore, any problem or issue that is encountered during this process may affect other queued transactions, which in turn may affect the performance capabilities of the gateway 140.

[0057] Once authorization is received, the merchant may then begin to fulfill the purchase and the above process may be repeated again to“Clear” the authorization by consummating the transaction. In some examples, the“Clear” may be initiated after the merchant has fulfilled the transaction (e.g., shipped the order, or dispatching an agent for delivery of a service). This may result in the issuer 270, via the issuer processor 275,“Clearing” the“Auth” (e.g., moving auth- hold to a debit) and the issuer 270 may then be prepared to settle with the acquirer 250, via the acquirer processor 255. In other words, any authorization hold (e.g., auth-hold) that may have been instituted during the processing of verifying the transaction may be cleared (“Clear”) by the issuer 270 (e.g., approving the transaction or indicating there are sufficient funds or balance) so that the transaction may proceed to settlement with the acquirer 250.

[0058] It may not be unusual for a merchant, via system 300 or other system in the card processing environment 200, to submit all approved authorizations, in a batch (e.g., at the end of the day), to its acquirer 250 for settlement. This may help“Clear” any corresponding“Auth” if it had not been explicitly“Cleared” already by this point.

[0059] The acquirer 250 may then make a batch settlement request of the issuer 270, and the issuer 270 may make a settlement payment to the acquirer 250, which in most cases, will be completed within the following day. The acquirer 250 may subsequently deposit a total of approved funds into the merchant’s nominated account. This nominated account may be an account with the acquirer 250 if the merchant does its banking with the same bank, or an account with another bank or financial institution. The entire process from authorization to settlement to funding may take anywhere from 2-4 days.

[0060] As described herein, once a gateway 140 is selected, the variety of tasks to process the transaction may be achieved with very little, if any, input from any system, payor, or payee. Therefore, selecting a gateway as discussed herein may generally result in, among other things, a greater likelihood of success in processing a transaction, minimizing or eliminating transaction failure, increasing speed of the transaction, and/or reducing costs associated with processing the transaction.

[0061] Figure 3 illustrates a block diagram of the system 300 for electronic payment and gateway routing depicted in Figures 1 and 2, according to an example. In some examples, the system 300 may provide electronic payment and gateway routing for processing a payment transaction. As shown, the system 300 may include a parameters data store 305, a transaction data store 310, and a transaction server 315. [0062] The parameters data store 305 may store a variety of variables or parameters for analyzing, evaluating, identifying, and selecting gateways as discussed herein. The parameters that may be stored at the parameters data store 305 may include, but are not limited to, transaction type, amount, transaction currency, time, date, location, payor 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 capability, etc. Other parameters may include card information (e.g., issuer identification number (I IN), bank identification number (BIN), etc.), cardholder information, cardholder authentication codes or requirements, operating environment, terminal output capabilities, transaction and non transaction activity patterns, address verification system (AVS), merchant category code (MCC), trace number, retrieval reference number, EMV (Europay, Mastercard®, and Visa®) related information, etc.

[0063] Other information stored at the parameters data store 305 may include performance information and/or cost information related to processing a transaction. For example, performance information may include data associated with speed of processing a transaction, such as performance capabilities that may be affected by hardware, software, or network, or other elements. These may include network latencies or other network-related features of a given gateway 140A, 140B, and 140N, or other performance issues that a gateway 140A, 140B, and 140N is predicted (or observed) to experience that may affect speed or other performance capability. Cost information may include related costs to process any given transaction, such as interchange cost, exchange rate, chargebacks, or other charges related to location, distance, product, service, issuer, or acquirer.

[0064] The transaction data store 310 may store content associated with one or more transactions. These transactions may include payment transactions, advertisement transactions, online transactions, mobile transactions, merchant transactions, user-to-user transactions, toll-based transactions, card-based transactions, financial transactions, and digital transactions. The content may include an identification of a gateway 140A, 140B, and 140N used to process a transaction, a transaction request time, a transaction result time, and/or other data relevant to the transaction. As used herein, the transaction request time may be the desired time for a transaction to process, and the transaction result time may be the time it actually takes for that transaction to process. For example, based on the transaction request time and the transaction result time, the system 300 may, for a given transaction, determine an amount of time it takes for a gateway 140A, 140B, and 140N to return a response code or other result. The system 300 may use the amounts of times over various transactions processed via a gateway 140A, 140B, and 140N to determine the network characteristic for that payment gateway. For example, a multitude of transactions may be tracked and the 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 of a user, cardholder, payor, payee, or other profile data associated with the one or more transactions. The transaction server 315 may provide or implement at least one transaction service associated with the one or more transactions. [0065] The system 300 may also include an action logger 320, an action log 325, and a web server 330. In some examples, the action logger 320 may receive communications about user actions performed on or off the system 300, and may populate the action log 325 with information about various user actions. Such user actions may include, for example, adding a connection to another user or entity, sending a message from another user or entity, viewing content associated with another user or entity, initiating a payment transaction, etc. In some examples, the action logger 320 may receive, subject to one or more privacy settings or rules, content interaction activities associated with another user or entity. In addition, a number of actions described in connection with other objects may be directed at particular users, so these actions may be associated those users as well. Any or all of these user actions may be stored in the action log 325.

[0066] 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 context of user actions. For example, such content information may include date/time an action is performed, other actions logged around the similar date/time period, or other associated actions. Other context information may include user action patterns, patterns exhibited by other similar users, or even various interactions a user may have with any particular or similar object. These and other similar actions or other similar information may be stored at the action log 325 and may be used for gateway routing and selection, as described herein. [0067] The web server 330 may link the system 300 via a network (e.g., network 120 of Figure 1 ) to one or more client devices (e.g., client devices 1 10 of Figure 1 ). The web server 330 may serve web pages, as well as other web- related content, such as Java, Flash, XML, or other similar content. The web server 330 may communicate with various internal elements of the system 300 or external network components to provide various functionalities, such as receiving, transmitting, and/or routing content between the system 300, client devices, and other network components.

[0068] As described herein, the system 300 may also include the machine learning subsystem 340. The machine learning subsystem 340 may employ one or more Al-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, the machine learning subsystem 340 may include an artificial intelligence (Al) router 342, a model 344, a training data store 346, and a classifier 348.

[0069] In particular, the Al router 342 of the machine learning subsystem 340 may enable the system 300 to identify gateways that may lead to successful or desirable transaction processing, such as a payment transaction, as discussed herein. Specifically, the machine learning subsystem 340 may train the model 344 based on training data included in a training data store 346. The machine learning subsystem 340 may also train a classifier 348 based on the training data. The classifier 348 may be used to assess gateway performance capabilities. Based on these assessments, the Al router 342 may identify and select a gateway 140 to process any particular transaction. [0070] The machine learning subsystem 340 may use one or more Al- 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 assessing, evaluating, identifying, and selecting one or more gateways for successful transaction processing. In some examples, the model 344 may include a set of weights associated with a set of features for generating an output score or value as a weighted aggregation of scores or values associated with various features. In other examples, the model 344 may include a set of weights along with instructions for aggregating weights for generation of an output score or value. In some examples, a vector or array generator (not shown) may use the model 344 to generate a vector or array that represents the characteristics of a transaction 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 the vector or array generated using the model 344, to return an identification of whether the content represented by the vector may help determine which gateway will lead to successful transaction processing. In order to generate the vector or array, the training data may be provided as 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 performance capability for each of the gateways 140. These scores or values may help the system 300 analyze and determine those gateways 140 with“highest” likelihood of successful transaction processing. [0071] The machine learning subsystem 340 may ingest the training data from the training data store 346 to generate the model 344 and any classifier 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 likelihood of successful processing by various gateways. In some examples, the training data may not provide data specific to a particular transaction, and instead may merely indicate whether or not that particular transaction may be more likely to succeed or fail at a variety of gateways for downstream processing. The training data store 346 may include data obtained from the action log 325, the parameters data store 305, transaction data store 310, and/or other source. For example, the vault 225, as described with respect to Figure 2, may also share data with the training data store 346, the action log 325, the parameters data store 305, transaction data store 310, or any other data source, to help facilitate the machine learning subsystem 340 perform any number of actions associated with gateway selection and routing, as described herein.

[0072] The machine learning subsystem 340 may generate the model 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 these transactions. For example, the generated model 344 may include a neural network, a tree-based model, a Bayesian network, a support vector, clustering, a kernel method, a spline, a knowledge graph, or an ensemble of one or more of these and other techniques. The machine learning subsystem 340 may determine the weights of the model 344, e.g., the weights of edges of a neural network corresponding to the model 344. The machine learning subsystem 340 may further generate a classifier 348 that may use such techniques. The machine learning subsystem 340 may periodically update the model 344 and/or classifier 348 based on additional training or updated 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 intended to be solved. The machine learning subsystem 340, as described herein, 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, and semi-supervised learning may require iterative optimization using objection functions to fill in gaps when at least some of the outputs are missing. It should also be appreciated that the machine learning subsystem 340 may provide other types of machine learning approaches, such as reinforcement learning, feature learning, anomaly detection, etc.

[0073] It should be appreciated that classification algorithms may provide assignment of instances to pre-defined classes to decide whether there are matches or correlations. Alternatively, clustering schemes or techniques may use groupings of related data points without labels. Use of knowledge graphs may provide an organized graph that ties nodes and edges, where a node may be related to semantic concepts, such as persons, objects, entities, events, etc., and an edge may be defined by relations between nodes based on semantics. It should be appreciated that, as described herein, the term“node” may be used interchangeably with“entity,” and“edge” with“relation.” Also, techniques that involve simulation models and/or decision trees may provide a detailed and flexible approach to gateway selection and routing.

[0074] In some examples, the system 300 may correlate one or more transaction parameters with the data associated with the transaction. The transaction parameters may be associated with the plurality of gateways.

[0075] The system 300 may apply an artificial intelligence (Al) based machine learning technique to the one or more transaction parameters. The Al based machine learning technique may include clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, knowledge graph analysis, and/or other techniques. For example, the transaction parameters may be correlated with historical transaction outcomes (such as failed or approved response codes), amounts of time that historical transactions took to complete, and/or other performance capability data related to the gateways.

[0076] The system may calculate a value that represents the predicted performance capability of each of the plurality of gateways based on the artificial intelligence (Al) based machine learning technique. In some instances, the system may apply a weight to the value based on at least one of the one or more transaction parameters and the data associated with the transaction. For example, the weighted value may be based on weighting individual transaction parameters to reflect the predictive correlation of each parameter to the observed outcome. In this manner, particular parameters that correlate highly with certain outcomes may be weighted higher since they have been observed to more highly correlate with such outcomes.

[0077] The system 300 may select a target gateway from the plurality of gateways based on the weighted value for the predicted performance capability of the target gateway. For example, the weighted value may reflect a probability that the target gateway will successfully process the transaction, will process the transaction more efficiently (such as more quickly) than another gateway, and/or otherwise exhibit better performance than another gateway. The weighted value may also or alternatively reflect a probability that the target gateway will process the transaction in a cost-efficient manner based on considerations associated with cost of process, likelihood of chargebacks, or other applicable charges and rates. As discussed herein, the system 300 may make the gateway selection by comparing the weighted value against the weighted values of other gateways.

[0078] As described herein, the systems and methods for gateway/processor selection and routing may process the variables (or other parameters) involved in a given transaction and may apply at least one Al-based machine learning technique to evaluate gateways and select one or more of the gateways based on one or more of their predicted performance capabilities. The machine learning technique may analyze these or other parameters for a given transaction to determine the“best” or optimal gateway to successfully process that transaction. However, just because one gateway may successfully process one transaction at a particular time does not necessarily mean that the same gateway will be successful for another transaction at another time. Likewise, just because one gateway may process a 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.

[0079] Accordingly, the systems and methods for gateway selection and routing, as described herein, may provide a dynamic solution that may make a multitude of 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 a highest likelihood of success in processing the transaction (e.g., based on the score or value associated with the gateway relative the 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.

[0080] It should be appreciated that the systems and subsystems shown herein, as described herein, may include one or more servers or computing devices. Each of these servers or computing devices may further include a platform and at least one application. An 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 the application, an operating system (OS), and runtime libraries. The application may be compiled to run on the platform. The runtime libraries may include low-level routines or subroutines called by the application to invoke some behaviors, such as exception handling, memory management, etc., of the platform at runtime. A subsystem may be similar to a platform and may include software and hardware to run various software or applications. [0081] While the gateway, systems, subsystems, and/or other computing devices may be shown as single components or elements (e.g., servers), one of ordinary skill in the art would recognize that these single components or elements may represent multiple components or elements, and that these components or elements may be connected via one or more networks. Also, middleware (not shown) may be included with any of the elements or components described herein. The middleware may include software hosted by one or more servers. Furthermore, it should be appreciated that some of the middleware or servers may or may not be needed to achieve 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 functionalities of the system 300.

[0082] Figure 4 illustrates a block diagram of a computer system 400 for electronic payment and gateway routing, according to an example. The computer system 400 may be part of or any one of the client devices 1 10, the external system 130, and/or the system 300 to perform the functions and features described herein. The computer system 400 may include, among other things, an interconnect 410, a processor 412, a multimedia adapter 414, a network interface 416, a system memory 418, and a storage adapter 420.

[0083] The interconnect 410 may interconnect various subsystems, elements, and/or components of the 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, the 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), IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus, or“firewire,” or other similar interconnection element.

[0084] In some examples, the interconnect 410 may allow data communication between the processor 412 and system memory 418, which 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 an operating system and various application programs may be loaded. The ROM or flash memory may contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with one or more peripheral components.

[0085] The processor 412 may be the central processing unit (CPU) of the computing device and may control overall operation of the computing device. In some examples, the processor 412 may accomplish this by executing software or firmware stored in system memory 418 or other data via the storage adapter 420. The processor 412 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic device (PLDs), trust platform modules (TPMs), field- programmable gate arrays (FPGAs), other processing circuits, or a combination of these and other devices. [0086] The multimedia adapter 414 may connect to various multimedia elements or peripherals. These may include a devices associated with visual (e.g., video card or display), audio (e.g., sound card or speakers), and/or various input/output interfaces (e.g., mouse, keyboard, touchscreen).

[0087] The network interface 416 may provide the computing device with an ability to communicate with a variety of remove devices over a network (e.g., network 120 of Figure 1 ) and may include, for example, an Ethernet adapter, a Fibre Channel adapter, and/or other wired- or wireless-enabled adapter. The network interface 416 may provide a direct or indirect connection from one network element to another, and facilitate communication and between various network elements.

[0088] The storage adapter 420 may connect to a standard computer readable medium for storage and/or retrieval of information, such as a fixed disk drive (internal or external).

[0089] Many other devices, components, elements, or subsystems (not shown) may be connected in a similar manner to the interconnect 410 or via a network (e.g., network 120 of Figure 1 ). Conversely, all of the devices shown in Fig. 4 need not be present to practice the present disclosure. The devices and subsystems can be interconnected in different ways from that shown in Fig. 4. Code to implement the dynamic approaches for payment gateway selection and payment transaction processing of the present disclosure may be stored in computer-readable storage media such as one or more of system memory 418 or other storage. Code to implement the dynamic approaches for payment gateway selection and 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 MS-DOS®, MS- WINDOWS®, OS/2®, OS X®, IOS®, ANDROID®, UNIX®, Linux®, or another operating system.

[0090] By providing a gateway selection and routing system with Al-based and machine learning analytics as described herein, the system 300 may enable identification and selection of gateways to more successfully process a variety and a multitude of transactions. All the while, the system 300 may provide improved load balancing of network components, maximize utilization of resources, increase speed of processing, and minimize energy consumption. In addition, the system 300 may minimize failed or unsuccessful transactions that may harm users, consumers, merchants, or other entities that engage in various data-based transactions. The system 300 may incorporate a number of variables or parameters to analyze likelihood of gateway performance at any given time, in a heterogeneous manner, that results in a more efficient way of gateway selection and routing. It should be appreciated that examples described herein may have a flexible structure and offer many advantages over other traditional or convention solutions.

[0091] Figure 5 illustrates a method for electronic payment and gateway routing, according to an example. The method 500 is provided by way of example, as there may be a variety of ways to carry out the method described herein. Although the method 500 is primarily described as being performed by system 300 as shown in Figures 1 , 2 and 3, or computer system 400 of Figure 4, the method 500 may be executed or otherwise performed by other systems, or a combination of systems. Each block shown in Figure 5 may further represent one or more processes, methods, or subroutines, and one or more of the blocks may include machine-readable instructions stored on a non-transitory computer readable medium and executed by a processor or other type of processing circuit to perform one or more operations described herein.

[0092] 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 the data associated with the transaction into usable data. At least some of the data may be received based on data from the transaction, such as an amount of a payment transaction. At least some of the data may be received from a system clock, such as a current time at which the payment transaction is being processed.

[0093] At 520, the system 300 may determine predicted performance capabilities of a 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 transaction type, amount, transaction currency, time, date, location, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, and/or activity pattern.

[0094] In some examples, the predicted performance capabilities of each of the plurality of gateways may be determined using an artificial intelligence (Al) based machine learning technique. As described herein, the artificial intelligence (Al) based machine learning technique may include, but is not limited to clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, knowledge graph analysis, and/or other techniques.

[0095] To facilitate a determination of predicted performance capabilities, the system 300, using the Al-based machine learning technique, may calculate a value that represents the predicted performance capabilities of each of the plurality of gateways. In some examples, the value may further be weighted based on the one or more transaction parameters and/or the data associated with the transaction.

[0096] 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 the weighted value for predicted performance capability. As described above, each of the plurality of gateways may be associated with a value or weighted value indicative of predicted performance capabilities. In some examples, the gateway with the highest value or highest weighted value may be determined to have the highest likelihood of success in processing an electronic transaction is therefore selected as the target gateway.

[0097] At 540, the system 300 may transmit the data associated with the transaction to the target gateway to process the transaction over a transaction or card network 260, as described with respect to Figure 2.

[0098] Although the selection and routing methods and systems as described herein may be directed mainly to payment transactions, it should be appreciated that the system 300 may provide processor/network routing, which may or may not involve gateways. Furthermore, the system 300 may use routing or decisioning in transactions or scenarios that do not involve payments. For example, the system 300 may also use the Al-based machine learning techniques disclosed herein in other various environments, such as in advertisement transactions, online transactions, mobile transactions, merchant transactions, user-to-user transactions, toll-based transactions, card-based transactions, financial transactions, and/or digital transactions. Other applications or uses of the system 300 may also include social networking, competitive, marketing, performance analysis, risk analysis, data management, content-based recommendation engines, and/or other types of knowledge or data-driven systems.

[0099] It should be noted that the functionality described herein may be subject to one or more privacy policies, described below, enforced by the system 300 that may bar use of images for concept detection, recommendation, generation, and analysis.

[00100] 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, the system 300, the client devices 1 10, gateways 140, the 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 be applied to any other suitable computing system. Privacy settings (or“access settings”) for an 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. A privacy setting for an object may specify how the object (or particular information associated with the object) can be accessed, stored, or otherwise used (e.g., viewed, shared, modified, copied, executed, surfaced, or identified) within the online social network. When privacy settings for an object allow a particular user or other entity to access that object, the object may be described as being “visible” with respect to that user or other entity. As an example and not by way of limitation, a user of the online social network may specify privacy settings for a user-profile page that identify a set of users that may access work-experience information on the user-profile page, thus excluding other users from accessing that information.

[00101] In particular examples, privacy settings for 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 particular examples, the blocked list may include third-party entities. The blocked list may specify one or more users or entities for which an object is not visible. As an example and not by way of limitation, a user may specify a set of users who may not access photo albums associated with the user, thus excluding those users from accessing the photo albums (while also possibly allowing certain users not within the specified set of users to access the photo albums). In particular examples, privacy settings may be associated with particular social-graph elements. Privacy settings of a social- graph element, such as 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 can be accessed using the online social network. As an example and not by way of limitation, a particular concept node corresponding to a particular photo may have a privacy setting specifying that the photo may be accessed only by users tagged in the photo and friends of the users tagged in the photo. In particular examples, privacy settings may allow users to opt in to or opt out of having their content, information, or actions stored/logged by the system 300 or shared with other systems (e.g., an 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.

[00102] In particular examples, the system 300 may present a“privacy wizard” (e.g., within a webpage, a module, one or more dialog boxes, or any other suitable interface) to the first user to assist the first user in specifying 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 privacy settings, or any suitable combination thereof. In particular examples, the system 300 may offer a“dashboard” functionality to the first user that may display, to the first user, current privacy settings of the first user. The dashboard functionality may be displayed to the first user at any appropriate time (e.g., following an input from the first user summoning the dashboard functionality, following the occurrence of a particular event or trigger action). The dashboard functionality may allow the first user to modify one or more of the first user’s current privacy settings at any time, in any suitable manner (e.g., redirecting the first user to the privacy wizard).

[00103] Privacy settings associated with an object may specify any suitable granularity of permitted access or denial of access. As an example and not by way of limitation, access or denial of access may be specified for particular users (e.g., only me, my roommates, my boss), users within a particular degree-of- separation (e.g., friends, friends-of-friends), user groups (e.g., the gaming club, my family), user networks (e.g., employees of particular employers, students or alumni of particular university), all users (“public”), no users (“private”), users of third-party systems, particular applications (e.g., third-party applications, external websites), other suitable entities, or any suitable combination thereof. Although this disclosure describes particular granularities of permitted access or denial of access, this disclosure contemplates any suitable granularities of permitted access or denial of access.

[00104] In particular examples, 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. As an example and not by way of limitation, a first user may specify that the first user’s status updates are public, but any images shared by the first user are visible only to the first user’s friends 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, such as individual users, friends-of-friends, followers, user groups, or corporate entities. As another example and not by way of limitation, a first user may specify a group of users that may view videos posted by the first user, while keeping the videos from being visible to the first user’s employer. In particular examples, different privacy settings may be provided for different user groups or user demographics. As an example and not by way of limitation, a first user may specify that other users who attend the same university as the first user may view the first user’s pictures, but that other users who are family members of the first user may not view those same pictures.

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

[00106] In particular examples, privacy settings may allow a first user to specify (e.g., by opting out, by not opting in) whether the system 300 may receive, collect, log, or store particular objects or information associated with the user for any purpose. In particular examples, privacy settings may allow the first user to specify whether particular applications or processes may access, store, or use particular objects 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 specific applications or processes. The system 300 may access such information in order to provide a particular function or service to the first user, without the system 300 having access to that information for any other purposes. Before accessing, storing, or using such objects or information, the system 300 may prompt the user to provide privacy settings specifying which applications or processes, if any, may access, store, or use the object or information prior to allowing any such action. As an example and not by way of limitation, a first user may transmit a message to a second user via an application related to the online social network (e.g., a messaging app), and may specify privacy settings that such messages should not be stored by the system 300.

[00107] In particular examples, a user may specify whether particular types of objects or information associated with the first user may be accessed, stored, or used by the system 300. As an example and not by way of limitation, the first user may specify that images sent 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, a first user may specify that all objects sent via a particular application may be saved by the system 300.

[00108] In particular examples, privacy settings may allow a first user to specify whether particular objects or information associated with the first user may be accessed from client devices 1 10 or external systems 130. The privacy settings may allow the first user to opt in or opt out of having objects or information accessed from a particular device (e.g., the phone book on a user’s smart phone), 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 with respect to each device, system, or application, and/or the first user may be prompted to specify a particular privacy setting for each context. As an example and not by way of limitation, the first user may utilize a location-services feature of the system 300 to provide recommendations for restaurants or other places in proximity to the user. The first user’s default privacy settings may specify that the system 300 may use location information provided from one of the client devices 1 10 of the first user to provide the location-based services, but that the system 300 may not store the location information of the first user or provide it to any external system 130. The first user may then update the privacy settings to allow location information to be used by a third-party image-sharing application in order to geo-tag photos.

[00109] In particular examples, privacy settings may allow a user to specify whether current, past, or projected mood, emotion, or sentiment information associated with the user may be determined, and whether particular applications or processes may access, store, or use such information. The privacy settings may allow users to opt in or opt out of having mood, emotion, or sentiment information accessed, stored, or used by specific applications or processes. The system 300 may predict or determine a mood, emotion, or sentiment associated with a user based on, for example, inputs provided by the user and interactions with particular objects, such as pages or content viewed by the user, posts or other content uploaded by the user, and interactions with other content of the online social network. In particular examples, the system 300 may use a user’s previous activities and calculated moods, emotions, or sentiments to determine a present mood, emotion, or sentiment. A user who wishes to enable this functionality may indicate in their privacy settings that they opt in to the system 300 receiving the inputs necessary to determine the mood, emotion, or sentiment. As an example and not by way of limitation, the system 300 may determine that a default privacy setting is to not receive any information necessary for determining mood, emotion, or sentiment until there is an express indication from a user that the system 300 may do so. By contrast, if a user does not opt in to the system 300 receiving these inputs (or affirmatively opts out of the system 300 receiving these inputs), the system 300 may be prevented from receiving, collecting, logging, or storing these inputs or any information associated with these inputs. In particular examples, the system 300 may use the predicted mood, emotion, or sentiment to provide recommendations or advertisements to the user. In particular examples, if a user desires to make use of this function for specific purposes or applications, additional privacy settings may be specified by the user to opt in to using the mood, emotion, or sentiment information for the specific purposes or applications. As an example and not by way of limitation, the system 300 may use the user’s mood, emotion, or sentiment to provide newsfeed items, pages, friends, or advertisements to a user. The user may specify in their privacy settings that the system 300 may determine the user’s mood, emotion, or sentiment. The user may then be asked to provide additional privacy settings to indicate the purposes for which the user’s mood, emotion, or sentiment may be used. The user may indicate that the system 300 may use his or her mood, emotion, or sentiment to provide newsfeed content and recommend pages, but not for recommending friends or advertisements. The system 300 may then only provide newsfeed content or pages based on user mood, emotion, or sentiment, and may not use that information for any other purpose, even if not expressly prohibited by the privacy settings.

[00110] In particular examples, privacy settings may allow a user to engage in the ephemeral sharing of objects on the online social network. Ephemeral sharing refers to the sharing of objects (e.g., posts, photos) or information for a finite period of time. Access or denial of access to the objects or information may be specified by time or date. As an example and not by way of limitation, a user may specify that a particular image uploaded by the user is visible to the user’s friends for 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 post content related to a product release ahead of the official launch, and specify that the content may not be visible to other users until after the product launch.

[00111] In particular examples, for particular objects or information having privacy settings specifying that they are ephemeral, the system 300 may be restricted in its access, storage, or use of the objects or information. The system 300 may temporarily access, store, or use these particular objects or information in order to facilitate particular actions of a user associated with the objects or information, and may subsequently delete the objects or information, as specified by the respective privacy settings. As an example and not by way of limitation, a first user may transmit a message to a second user, and the system 300 may temporarily store the message in a 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 prior example, the message may be stored for a specified period of time (e.g., 2 weeks), after which point the system 300 may delete the message from the content data store.

[00112] In particular examples, privacy settings may allow a user to specify one or more geographic locations from which objects can be accessed. Access or denial of access to the objects may depend on the geographic location of a user who is attempting to access the objects. As an example and not by way of limitation, a user 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 second users only while the first user is in a particular location. If the first user leaves the particular location, the object may no longer be visible to the second users. As another example and not by way of limitation, a first user may specify that an object is visible only to second users within a threshold distance from the first user. If the first user subsequently changes location, the original second users with access to the object may lose access, while a new group of second users may gain access as they come within the threshold distance of the first user.

[00113] In particular examples, the system 300 may have functionalities that may use, as inputs, personal or biometric information of a user for user- authentication or experience-personalization purposes. A user may opt to make use of these functionalities to enhance their experience on the online social network. As an example and not by way of 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 particular processes, such as authentication, and further specify that such information may not be shared with any external system 130 or used for other processes or applications associated with the system 300. As another example and not by way of limitation, the system 300 may provide a functionality for a user to provide voice-print recordings to the online social network. As an example and not by way of limitation, if a user wishes to utilize this function of the online social network, the user may provide a voice recording of his or her own voice to provide a status update on the online social network. The recording of the voice-input may be compared to a voice print of the user to determine what words were spoken by the user. The user’s privacy setting may specify that such voice recording may be used only for voice-input purposes (e.g., to authenticate the user, to send voice messages, to improve voice recognition in order to use voice-operated features of the online social network), and further specify that such voice recording may not be shared with any external system 1 30 or used by other processes or applications associated with the system 300. As another example and not by way of limitation, the system 300 may provide a functionality for a user to provide a reference image (e.g., a facial profile, a retinal scan) to the online social network. The online social network may compare the reference image against a later-received image input (e.g., to authenticate the user, to tag the user in photos). The user’s privacy setting may specify that such voice recording may be used only for a limited purpose (e.g., authentication, tagging the user in photos), and further specify that such voice recording may not be shared with any external system 130 or used by other processes or applications associated with the system 300.

[00114] In particular examples, changes to privacy settings may take effect retroactively, affecting the visibility of objects and content shared prior to the change. As an example and not by way of limitation, a first user may share a first image and specify that the first image is to be public to all other users. At a later time, the first user may specify that any images shared by the first user should be made visible only to a first user group. The system 300 may determine that this privacy setting also applies to the first image and make the first image visible only to the first user group. In particular examples, the change in privacy settings may take effect only going forward. Continuing the example above, if the first user changes privacy settings and then shares a second image, the second image may be visible only to the first user group, but the first image may remain visible to all users. In particular examples, in response to a user action to change a privacy setting, the system 300 may further prompt the user to indicate whether the user wants to apply the changes to the privacy setting retroactively. In particular examples, a user change to privacy settings may be a one-off change specific to one object. In particular examples, a user change to privacy may be a global change for all objects associated with the user.

[00115] In particular examples, the system 300 may determine that a 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. As an example and not by way of limitation, a trigger action may be a change in the relationship between a first and second user of the online social network (e.g.,“un-friending” a user, changing the relationship status between the users). In particular examples, upon determining that a trigger action has occurred, the system 300 may prompt the first user to change the privacy settings regarding the visibility of objects associated with the first user. The prompt may redirect the first user to a workflow process for editing privacy settings with respect to one or more entities associated with the trigger action. The privacy settings associated with the first user may be changed only in response to an explicit input from the first user, and may not be changed without the approval of the first user. As an example and not by way of limitation, the workflow process may include providing the first user with the current privacy settings with respect to the second user or to a group of users (e.g., un-tagging the first user or second user from particular objects, changing the visibility of particular objects with respect to the second user or group of users), and receiving an indication from the first user to change the privacy settings based on any of the methods described herein, or to keep the existing privacy settings.

[00116] In particular examples, a user may need to provide verification of a privacy setting before allowing the user to perform particular actions on the online social network, or to provide verification before changing a particular privacy setting. When performing particular actions or changing a particular privacy setting, a prompt may be presented to the user to remind the user of his or her current privacy settings and to ask the user to verify the privacy settings with respect to the particular action. Furthermore, a user may need to provide confirmation, double-confirmation, authentication, or other suitable types of verification before proceeding with the particular action, and the action may not be complete until such verification is provided. As an example and not by way of limitation, a user’s default privacy settings may indicate that a person’s relationship status is visible to all users (i.e., “public”). However, if the user changes his or her relationship status, the system 300 may determine that such action may be sensitive and may prompt the user to confirm that his or her relationship status 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 friends of the user. However, if the user changes the privacy setting for his or her posts to being public, the system 300 may prompt the user with a reminder of the user’s current privacy settings of posts being visible only to friends, and a warning that this change will make all of the user’s past posts visible to the public. The user may then be required to provide a second verification, input authentication credentials, or provide other types of verification before proceeding with the change in privacy settings. In particular examples, a user may need to provide verification of a privacy setting on a periodic basis. A prompt or reminder may be periodically sent to the user based either on time elapsed or a number of user actions. As an example and not by way of limitation, the system 300 may send a reminder to the user to confirm his or her privacy settings every six months or after every ten photo posts. In particular examples, privacy settings may also allow users to control access to the objects or information on a per-request basis. As an example and not by way of limitation, the system 300 may notify the user whenever an 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.

[00117] What has been described and illustrated herein are examples of the disclosure along with some variations. 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

CLAIMS:

1. A system, comprising: a processor; a memory storing instructions, which when executed by the processor, causes the processor to: receive data associated with a transaction; determine a predicted performance capability for each of a plurality of gateways based on one or more transaction parameters associated with the data; select a target gateway from the plurality of gateways based on the predicted performance capability of the target gateway; and transmit the 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 capability 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 with which the target gateway will process the transaction, or a cost associated with processing the transaction by the target gateway.

4. The system of any preceding claim, wherein the instructions further cause the system to use an artificial intelligence, Al, based machine learning technique that analyzes the data associated with transaction and data associated with the plurality of gateways to determine the predicted performance capability of each of the plurality of gateways.

5. The system of claim 4, wherein the artificial intelligence, Al, based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis.

6. The system of claim 4 or claim 5, wherein the artificial intelligence, Al, based machine learning technique comprises calculating, for each of the plurality of gateways, a value that represents the predicted performance capability of the gateway;

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

further optionally wherein the target gateway is selected from the plurality of gateways based on the weighted value for the predicted performance capability.

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, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, 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 the payment system, processor, a predicted performance capability of 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 the predicted performance capability of the target gateway; and transmit, by the processor, the data associated with the transaction to the target gateway to process the transaction over the network.

9. The method of claim 8, wherein determining the predicted performance capability further comprises determining the predicted performance capability of each of the plurality of gateways using an artificial intelligence, Al, based machine learning technique that analyzes the data associated with transaction and data associated with the plurality of gateways; and

optionally wherein the Al based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis.

10. The method of claim 9, wherein using the Al based machine learning technique further comprises calculating, for each of the plurality of a gateways, a value that represents the predicted performance capability of the gateway, optionally, the method further comprising: weighting the value for each of the plurality of gateways to create, for each of the plurality of gateways, a weighted value for the gateway based on at least one of: the one or more transaction parameters, or the data associated with the transaction.

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

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

13. A non-transitory computer-readable storage medium having an executable stored thereon, which when executed instructs a processor to: receive data associated with a transaction; correlate one or more transaction parameters with the data associated with the transaction, wherein the one or more transaction parameters are associated with a performance capability of the plurality of gateways; apply an artificial intelligence, Al, based machine learning technique to the one or more transaction parameters, wherein the Al based machine learning technique comprises at least one of: clustering, classification, pattern mining, logistic regression, decision tree, random forest, semantics, simulation, or knowledge graph analysis; calculate a value for each of the plurality of gateways based on the Al based machine learning technique, wherein the value represents the performance capability of each of the plurality of gateways; and select 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 to create a weighted value for each of the plurality of gateways based on at least one of: the one or more transaction parameters, or the data associated with the transaction, 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 comprise at least one of: type, amount, transaction currency, time, date, location, payor identifier, payee identifier, acquirer identifier, issuer identifier authorization requirement, response requirement, security requirement, card information, user profile, transaction profile, authentication requirement, operating environment, output capability, or activity pattern.