Claims:CLAIMS
We claim:
1. A computer-implemented method, comprising:
receiving, by a server system, a payment transaction request associated with a cross-border payment transaction between a cardholder and a merchant, the payment transaction request comprising cardholder account data associated with the cardholder and merchant information associated with the merchant;
identifying, by the server system via a payment directory server, whether the merchant is enrolled for an authentication service or not based, at least in part, on a storage database at the payment directory server;
in response to identifying that the merchant is not enrolled for the authentication service, sending, by the server system, a request to an access control server (ACS) to determine whether a cardholder account associated with the cardholder is enrolled for an additional factor of authentication (AFA) service for cross-border payment transactions;
receiving, by the server system, a response indicating an enrolment status of the cardholder account for the AFA service for the cross-border payment transactions;
initiating, by the server system acting as an on-behalf-of (OBO) merchant, an AFA process for the cardholder based, at least in part, on the response and the cardholder account data;
populating, by the server system, an additional data field to generate an updated payment authorization request message, the additional data field indicating that the server system is acted as the OBO merchant while performing the AFA process; and
transmitting, by the server system, the updated payment authorization request message to an issuer server associated with the cardholder for completing payment authorization of the cross-border payment transaction.

2. The computer-implemented method of claim 1, wherein the server system is a payment server associated with a payment network.

3. The computer-implemented method of claim 1, wherein the AFA process is initiated when the enrolment status included in the response from the ACS indicates that the cardholder is already enrolled for the AFA service for the cross-border payment transactions.

4. The computer-implemented method of claim 1, wherein initiating the AFA process comprises:
sending, by the server system, a payer authentication request (PAReq) message to the ACS to perform the AFA process for the cardholder; and
receiving, by the server system, a payer authentication response (PARes) message from the ACS based, at least in part, on authentication decision in the AFA process.

5. The computer-implemented method of claim 1, further comprising:
determining, by the server system via the payment directory server, whether the cardholder account data is a part of stored card ranges in the storage database.

6. The computer-implemented method of claim 1, wherein if the enrolment status indicates that the cardholder is not enrolled for the AFA service for the cross-border payment transactions, the computer-implemented method further comprising:
transmitting, by the server system, a payment authorization request message to the issuer server without performing the AFA process.

7. The computer-implemented method of claim 1, wherein the cross-border payment transaction is an e-commerce payment transaction.

8. The computer-implemented method of claim 1, wherein the AFA process comprises authenticating the cardholder based on at least one of: a password, a PIN, a one-time password (OTP), and a biometric input.

9. The computer-implemented method of claim 1, wherein the authentication service is in compliant with 3D-Secure authentication protocol.

10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9. , Description:METHODS AND SYSTEMS FOR PROVIDING ADDITIONAL FACTOR OF AUTHENTICATION IN CROSS-BORDER PAYMENT TRANSACTIONS

TECHNICAL FIELD
[0001] The present disclosure generally relates to an authentication system and, more particularly to, electronic methods and systems for providing additional factor authentication (AFA) process in cross-border payment transactions.
BACKGROUND
[0002] E-commerce refers to an exchange of goods and services through electronic transactions. E-commerce may also include online services or any form of online exchange between businesses and consumers. Due to increased accessibility of the Internet, changing business landscape and deeper penetration of smart devices, businesses (referred to as merchants, hereinafter) and consumers are increasingly participating in e-commerce transactions. Moreover, as the merchants are not restricted to a specific geographical location for participating in the e-commerce transactions, product and/or service offerings are provided to the consumers across multiple states and countries, i.e., the product and service offerings are available for international business activities or cross-border e-commerce payments.
[0003] Typically, e-commerce transactions are performed based on rules defined by a regulatory authority of a country. In particular, the regulatory authority defines the rules for the regulation of payment services within the corresponding country to protect consumers' interests and prevent potential frauds. In such a country, an e-commerce payment transaction is performed between a merchant and a consumer, via a payment account associated with the merchant and the consumer and in compliance with the rules defined by the regulatory authority. For example, a regulatory authority of a country may enforce an additional factor of authentication, such as second-factor authentication (2FA) for e-commerce transactions within the country. In such a case, a domestic e-commerce transaction between the merchant and the consumer may include the 2FA process of the consumer for performing the e-commerce transaction. In one example, the Reserve Bank of India (RBI), India’s central bank requires that all domestic e-commerce transactions should be authenticated.
[0004] However, in the case of cross-border payment transactions, there is a possibility that the payment transactions may lead to financial losses for the customer as international merchants are not directly under the purview of the regulatory authority. Therefore, the cross-border payment transactions may go through directly without any additional authentication.
[0005] Therefore, there exists a technological need to overcome drawbacks associated with conventional cross-border payment transaction processes for protecting consumers from cross-border fraudulent transactions.
SUMMARY
[0006] Various embodiments of the present disclosure provide methods and server systems for providing additional factor authentication (AFA) processes for cross-border payment transactions.
[0007] In an embodiment, a computer-implemented method is disclosed. The method includes receiving, by a server system, a payment transaction request associated with a cross-border payment transaction between a cardholder and a merchant. The payment transaction request includes cardholder account data associated with the cardholder and merchant information associated with the merchant. The method includes identifying, by the server system via a payment directory server, whether the merchant is enrolled for an authentication service or not based, at least in part, on a storage database at the payment directory server. The method includes sending, by the server system, a request to an access control server (ACS), in response to identifying that the merchant is not enrolled for the authentication service. The request is sent to determine whether a cardholder account associated with the cardholder is enrolled for an additional factor of authentication (AFA) service for cross-border payment transactions. The method includes receiving, by the server system, a response indicating enrolment status of the cardholder account for the AFA service for the cross-border payment transactions. The method further includes initiating, by the server system acting as an on-behalf-of (OBO) merchant, an AFA process for the cardholder based, at least in part, on the response and the cardholder account data. The method includes populating, by the server system, an additional data field to generate an updated payment authorization request message. The additional data field indicates that the server system is acting as the OBO merchant while performing the AFA process. The method includes transmitting, by the server system, the updated payment authorization request message to an issuer server associated with the cardholder for completing payment authorization of the cross-border payment transaction.
BRIEF DESCRIPTION OF THE FIGURES
[0008] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0009] FIG. 1 illustrates an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0010] FIG. 2 represents a sequence flow diagram for obtaining cardholder choice for implementing additional factor of authentication (AFA) for cross-border payment transactions, in accordance with an embodiment of the present disclosure;
[0011] FIGS. 3A, 3B, and 3C, collectively, represent a sequence flow diagram for performing AFA process in cross-border payment transactions, in accordance with an embodiment of the present disclosure;
[0012] FIGS. 4A and 4B, collectively, represent a flow chart for processing cross-border payment transactions, in accordance with an embodiment of the present disclosure;
[0013] FIG. 5 is a flow diagram of a computer-implemented method for providing additional factor of authentication (AFA) in cross-border payment transactions, in accordance with an embodiment of the present disclosure;
[0014] FIG. 6 is a simplified block diagram of a server system, in accordance with one embodiment of the present disclosure;
[0015] FIG. 7 is a simplified block diagram of a payment directory server, in accordance with one embodiment of the present disclosure;
[0016] FIG. 8 is a simplified block diagram of an access control server (ACS), in accordance with an embodiment of the present disclosure; and
[0017] FIG. 9 is a simplified block diagram of an issuer server, in accordance with one embodiment of the present disclosure; and
[0018] FIG. 10 is a simplified block diagram of a cardholder device capable of implementing at least some embodiments of the present disclosure.
[0019] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.
DETAILED DESCRIPTION
[0020] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0021] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” at various places in the specification is not necessarily all referring to the same embodiment, nor to separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0022] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0023] The term “issuer”, used throughout the description, refers to a financial institution normally called an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, e-commerce purchase, etc., to the account holders through a server system called “issuer server” throughout the description.
[0024] Further, the term "acquirer" is an organization that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in consideration. Typically, the acquirer has an agreement with merchants, wherein the acquirer receives authorization requests for purchase transactions from the merchants and routes the authorization requests to the issuers of the payment cards being used for the purchase transactions. The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer bank” will be used interchangeably herein. Further, one or more server systems associated with the acquirer are referred to as "acquirer server" to carry out its functions.
[0025] The term "payment network" used throughout the description, refers to a network or collection of systems used for the transfer of funds through the use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard.
[0026] The term "payment account" used throughout the description refers to a financial account that is used to fund a financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by a digital wallet or other payment applications.
[0027] The term "payment card" used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data (e.g., a digital token) stored in a cardholder device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account. In an example, a payment card may be associated with a payment account that belongs to an entity (referred to as a cardholder, hereinafter). The payment account may have associated payment account data. For example, the payment account data may include, but are not limited to, payment account details, cardholder details, and payment card details.
[0028] The term "merchant", used throughout the description, may include a merchant that has a relationship with the payment processing network. The merchant may receive the proceeds from a purchase when the purchase is settled. The merchant is the company that is ultimately responsible for the financial transaction. In particular, the merchant may offer products and/or services for purchase that may be purchased by a buyer, such as a cardholder. Further, the term "offshore merchant" refers to a merchant having a country of operation of the merchant different from a country of residence of the cardholder. In particular, an acquirer bank associated with the offshore merchant may be operating in a country that is outside or different from a country to which an issuer of the cardholder belongs.
[0029] The term "transaction" used throughout the description, unless the context suggests otherwise, includes electronic financial transactions such as cash withdrawal, online payment, payment at POS terminal, and the like, and also includes financial related transactions such as balance inquiry, account statement generation, the addition of a beneficiary or activation/deactivation of finance-related services, etc. The transaction is performed between two entities, such as a buyer and a seller. It may be noted that a transaction is followed by a payment of a transaction amount from one entity to another entity, in exchange of a good or a service. Further, the term “cross-border payment transaction” refers to a financial transaction, typically for online payment, when a country of operation of the two entities engaging in the cross-border transaction for payment is different. For example, an acquiring bank associated with a merchant may have a country of operation different from an issuing bank of a cardholder.
OVERVIEW
[0030] Various example embodiments of the present disclosure provide methods, systems, and computer program products for authenticating cross-border payment between an offshore merchant and a cardholder to protect the cardholder’s interest and prevent security threats. More specifically, techniques disclosed herein enable cardholders to securely perform international e-commerce transactions when engaging with offshore merchants.
[0031] Conventionally, security rules for payment transactions that may be enforced in the country of residence of a cardholder may not be applicable to overseas merchants. In other words, international merchants are not directly under the purview of the regulatory authority of the country of residence of the cardholder. Therefore, owing to costs associated with the cardholder authentication process and the non-binding nature of such regulatory rule of the cardholder’s country, the merchant may choose to not participate in the cardholder authentication process while performing e-commerce transactions. This may expose the cardholder to the risk of cross-border fraud. For example, despite cardholder authentication process being enforced for e-commerce transactions by the regulatory authority of the country associated with the cardholder, cross-border payment transactions may go through without any cardholder authentication process (for example, without an OTP or password) when such cardholder authentication process is not enforced in the country of operation of the merchant.
[0032] In certain cases, payment details of the cardholder may be stored on an e-commerce website (or a merchant website), thereby rendering the payment details prone to leaks and further unauthorized and fraudulent transactions. Due to such security threats associated with the cross-border payment transactions, the cardholder may be apprehensive about participating in online cross-border payment transactions, thereby changing purchasing trends of the consumers. Therefore, merchants may also suffer financial and reputational loss in case of a cybercrime committed through their website.
[0033] At least one of the technical problems addressed by the present disclosure includes: (i) high-security threats associated with online cross-border payment transactions due to different regulatory directives for payment service in different countries, and (ii) allowing fraudulent cross-border transactions to be successfully processed if a foreign merchant is not enrolled in any cardholder authentication program. Additionally, the present disclosure removes limitations such as the merchant should purchase, install, implement and/or maintain merchant plug-in software to implement cardholder authentication processes.
[0034] To overcome such problems or limitations, the present disclosure allows cardholders to select additional factor of authentication (AFA) service for cross-border payment transactions. The present disclosure also enables overseas merchants that are not enabled for cardholder authentication program (e.g., 3DS authentication) can also seamlessly transact with AFA service enabled cardholder accounts, thereby reducing risks of fraudulent transactions. The present disclosure implements a server system acting as an on-behalf-of (OBO) merchant to initiate AFA process for a cardholder. In one embodiment, the server system is a part of a payment network.
[0035] In one embodiment, the server system is configured to receive a payment transaction request associated with a cross-border payment transaction between a cardholder and a merchant. The payment transaction request is initiated by a payment gateway of the merchant, such as a plug-in application provided by a technology vendor and integrated with the merchant e-commerce server or merchant website. The cardholder may provide cardholder account data associated with the cardholder. The cardholder account data may relate to a payment account associated with a payment card that belongs to the cardholder. For example, the cardholder account data may include payment card details (such as, payment card number, payment card validity, name on payment card, CVV, etc.), payment account details (such as, payment account number, name associated with the payment account, issuer name, issuer identifier, etc.) and cardholder details (such as, name, gender, an identifier contact information, email, etc.).
[0036] The server system is configured to identify whether the merchant is enrolled for an authentication service or not based, at least in part, on a storage database at the payment directory server. The server system may access the payment directory server to facilitate the decision-making in determining whether the merchant is enrolled for the authentication service or not. In one example, when information of the merchant is not stored within the storage database of the payment directory server, it means that the merchant is not enrolled for the authentication service. In addition, the server system may validate if the cardholder account associated with the cardholder is a part of an issuer’s card range, which can participate in cardholder authentication process.
[0037] In response to identifying that the merchant is not enrolled for the 3DS authentication service, the server system is configured to send a request to an access control server (ACS) to determine whether the cardholder account is enrolled for an additional factor of authentication (AFA) service for cross-border payment transactions. For example, an issuer associated with the cardholder account may receive a selection of user preference for enabling cross-border payments and participating in the AFA service for cross-border payments. On receiving the user-preference, the issuer may update the ACS associated with the issuer to indicate an enrolment status of the cardholder. For example, the ACS associated with the issuer may maintain a record of such user-preference of the cardholder in association with cardholder account details and user authentication credentials for participating for additional factor of authentication. Based on the request, the ACS may send a response to the server system indicating the enrolment status of the cardholder. In particular, the server system receives the response indicating the enrolment status of the cardholder account for the AFA service for the cross-border payment transactions.
[0038] The server system is configured to initiate an AFA process for the cardholder based, at least in part, on the response and the cardholder account data. When the server system identifies that the merchant does not participate in additional factor of authentication and the cardholder has enrolled for the AFA service for cross-border payment transactions, the server system acts as an on-behalf-of (OBO) merchant to initiate the AFA process for the cross-border payment transaction. In particular, the server system acting as an OBO merchant sends a request for authentication to the ACS. On receiving the request for authentication from the OBO merchant, the ACS may perform the authentication of the cardholder as per the AFA process. For example, the ACS may provide an authentication window on a cardholder device associated with the cardholder to perform authentication. Upon the AFA process, the ACS may send a response indicating authentication report, i.e., successfully authenticated or not, to the server system.
[0039] The server system is configured to populate an additional data field to generate an updated payment authorization request message. In particular, the server system may generate the updated payment authorization request message for the issuer server, for the successfully authenticated cardholder. In other words, the server system is configured to generate the updated payment authorization request message including the additional data field indicative of the server system being acted as the OBO merchant for performing the AFA process.
[0040] The server system is configured to transmit the updated payment authorization request message to the issuer server associated with the cardholder for completing the payment authorization. For example, the issuer server may validate the additional data field as part of processing and authorizing the cross-border payment transaction.
[0041] Various embodiments of the present disclosure offer multiple technical advantages and technical effects. For instance, the present disclosure substantially reduces cross-border frauds and provides a secure online authentication process for cross-border payment transactions. In particular, the present disclosure substantially eliminates vulnerable points to attacks in cross-border payment transactions. The present disclosure also advantageously shifts the liability from overseas merchants for any fraud and/or chargebacks with regard to an authorized online purchase transaction to issuers. The present disclosure reduces the volume of network traffic at merchant servers which results in the increased speed of online cross-border payment transaction processing.
[0042] The technical improvement in the cross-border online payment system as described herein is a computer-based solution to a technical deficiency or problem that is itself rooted in computer technology (e.g., the problem itself derives from the use of computer technology). More specifically, fraud is a significant problem for transactions conducted over an electronic payment network, especially for card-not-present transactions and involving international payment service means. Therefore, the present disclosure provides a consumer authentication system to authenticate consumers by acting as an OBO merchant for foreign merchants for reducing frauds in cross-border payments.
[0043] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 10.
[0044] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, performing cardholder authentication for cross-border payments. The environment 100 generally includes a server system 102, a cardholder device 104 associated with a cardholder 106, a merchant 108, a payment network 110 including a payment server 112 and a payment directory server 114, an issuer server 116, an acquirer server 118, an access control server (ACS) 120, each coupled to, and in communication with a network 122. The network 122 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber-optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in FIG. 1, or any combination thereof.
[0045] Various entities in the environment 100 may connect to the network 122 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 122 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet, etc.) through which the server system 102, the cardholder device 104, the merchant 108, the payment network 110, the issuer server 116, the acquirer server 118, and the ACS 120 may communicate.
[0046] In one embodiment, the cardholder 106, who belongs to a country “A”, may be any individual, representative of a corporate entity, non-profit organization, or any other person. The cardholder 106 may be an entity that may engage with a financial organization, such as a bank, a credit card provider, and the like, to start a payment account. Further, the cardholder 106 may request a payment card corresponding to the payment account, to use the payment card for performing electronic transactions via the payment account. In certain cases, the cardholder 106 may also perform electronic transactions without the payment card, using certain payment credentials, such as net banking, and so forth.
[0047] Examples of the cardholder device 104 associated with the cardholder 106 may include, but is not limited to, smartphone, tablet computer, other handheld computers, wearable devices, laptop computers, desktop computers, servers, portable media players, gaming devices, and so forth. The cardholder device 104 may be installed with an application. Examples of the application include merchant applications associated with a merchant (e.g., merchant 108) and a digital wallet application associated with a wallet service provider. In one embodiment, the cardholder device 104 may be installed with the application that is configured to integrate various APIs for performing payment transactions with the merchant 108. The term “application” is used broadly to include any software program(s) capable of implementing the features described herein.
[0048] In one embodiment, the issuer server 116 is a financial institution that manages cardholder accounts (i.e., payment accounts) of multiple cardholders. Payment account details of the payment accounts established with the issuer server 116 are stored in cardholder profiles of the cardholders in memory of the issuer server 116 or on a cloud server associated with the issuer server 116. The issuer server 116 approves or denies an authorization request, and then routes, via the payment network 110, an authorization response back to the acquirer server 118. The acquirer server 118 sends the approval to the merchant 108. The payment account details may include an account balance, an available credit line, details of an account holder, transaction history of the cardholder, account information, or the like. The details of the cardholder may include name, age, gender, physical attributes, registered contact number, alternate contact number, registered e-mail ID, or the like of the cardholder. The cardholder account may be associated with one or more payment means that enable the cardholder 106 to facilitate the payment transaction. Examples of one or more payment means may include, payment card, Unified Payment Interface (UPI) links, and/or the like. Methods for processing transactions via the issuer server 116 will be apparent to a person of ordinary skill in the art and may include processing the transactions via the traditional four-party system.
[0049] In one embodiment, the issuer server 116 provides various services to the cardholders such as enabling an additional-factor of authentication (AFA) process for performing payment transactions. In one embodiment, the issuer server 116 may enable the multi-factor authentication for the cardholder account of the cardholder 106 on a default basis. The issuer server 116 also provides a user interface to the cardholder 106 to select a mode of communication (such as SMS, email, phone call, or any messaging application, etc.) to perform the user authentication. Hence, the cardholder account of the cardholder 106 is enrolled for the 3D secure messaging protocol (or subsequent versions of 3D secure messaging protocols). According to the 3D secure messaging protocol, an access control server (ACS) 120 is installed in the issuer domain. Each issuer is required to maintain an ACS which is used to support cardholder authentication. In one embodiment, the ACS 120 is Payment Card Industry (PCI) compliant. The ACS 120 may be deployed by the issuer associated with the issuer server 116. Alternatively, the issuer server 116 can outsource the ACS 120 to a third-party developer or the payment network 110.
[0050] In one embodiment, the merchant 108, who belongs to country “B”, may be an e-commerce business accessible through a merchant application. In an example, the cardholder device 104 may be installed with the merchant application that is configured to integrate various APIs for performing payment transactions with the merchant 108. The term “merchant application” is used broadly to include any software program(s) capable of providing e-commerce services to a consumer, such as the cardholder 106. In some embodiments, the merchant application may include any API, service, application, applet, or other executable code suitable to retrieve product or service information, receive payment information from an entity, such as the cardholder device 104, and communicate with an acquirer server 118 and/or any other application in order to securely process the payment. The merchant application may be configured to obtain stored information including payment card details, payment account details, cardholder private key, payment credentials, third party keys, mobile gateway credentials, and may be capable of communicating with an acquirer to process a payment.
[0051] In one embodiment, the merchant 108 represents the authorized accepter of payment cards for the payments for goods/services sold by the merchant 108. In one embodiment, the acquirer server 118 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0052] In one embodiment, the payment network 110 may be used by the payment cards issuing authorities as a payment interchange network. The payment network 110 may include a plurality of computing servers such as, the payment server 112 and the payment directory server 114. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.)
[0053] In one non-limiting example, when an end party in one country (e.g., the cardholder 106) conducts an e-commerce transaction with an end party (e.g., merchant 108), in another country, a payment transaction may be referred to as a cross-border payment transaction. To initiate the cross-border payment transaction, the cardholder 106 may open a merchant application operated by the merchant 108 on the cardholder device 104 and submit a purchase request with the merchant 108. The cardholder 106 enters payment account data (such as payment account details, payment card details, any payment wallet details associated with the payment account, etc.), via the cardholder device 104. The payment transaction request message typically includes the payment account number (PAN), the amount of the transaction, and other information, such as merchant identification and location. The payment transaction request message is sent to the payment network 110. Thereafter, the payment directory server 114 uses the bank identification number (BIN), which is part of the PAN, to check card range eligibility for the payment account number of the cardholder 106 to verify whether the issuer server 116 has enforced cardholder authentication system or not.
[0054] Typically, in the case of domestic transactions, the 3DS authentication process is initiated by a domestic merchant involved in the domestic transaction using the associated merchant server plug-in (MPI), via the acquirer server. The domestic merchant sends a 3DS verification request to the payment directory server 114, via the acquirer server 118. The payment directory server 114 includes a list of one or more Bank Identifier Numbers (BINs). Each of the one or more BINs is stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more ACSs participating/enrolled for performing multi-factor authentication. The payment directory server 114 routes a verification request to the issuer ACS 120. The ACS 120 reviews the information within the verification request, authenticates the cardholder 106 using their form of authentication and user preferences stored at the ACS 120, and responds back to the merchant 108. For example, the ACS 120 may authenticate the cardholder 106 based on a one-time password (OTP), a static PIN, a static password, a biometric input, etc. The ACS 120 may also send a response to the issuer server 116 indicating the authentication. The information within the 3DS verification request may include, for example, cardholder identification, cardholder’s payment account details, cardholder’s payment card details, transaction amount, merchant details, acquirer details, and the like
[0055] In one example scenario (i.e., not in accordance with the present disclosure), the payment directory server 114 identifies that the merchant 108 is not enrolled for the cardholder authentication program (e.g., 3DS authentication) since opting of the cardholder authentication program is not mandated in merchant’s country. In this example scenario, the payment request message is directly passed to the issuer server 116 for the authorization process that exposes the cardholder 106 to a risk of cross-border frauds. Thus, the cross-border payment transaction will go through without an OTP/password increasing the chances of fraudulent activities in cross-border payments.
[0056] Various embodiment of the present disclosure attempts to solve the above technical problem by enabling additional-factor of authentication (AFA) services for cross-border payment transactions based on cardholder preference.
[0057] In order to use additional-factor of authentication (AFA) service for cross-border payment transactions, the cardholder 106 must first visit an issuer enrolment website and provide issuer enrolment data to prove identity, and if the appropriate information is provided, the cardholder 106 is permitted to enable the AFA service to be associated with his or her payment card account number. This information associated with the payment card account number is stored by the issuer server 116 or the ACS 120 for later use during offshore purchases at merchant websites.
[0058] In one embodiment, when the payment directory server 114 identifies that the merchant 108 is an international merchant (i.e., cross-border merchant) and the merchant 108 is not enrolled for the 3DS cardholder authentication, the payment directory server 114 is configured to send the corresponding URL of the ACS 120 associated with the issuer server 116 to the server system 102. The server system 102 is configured to act as an on-behalf-of (OBO) merchant and sends a request to the ACS 120 to initiate the AFA service for authenticating the cross-border payment transaction. In one embodiment, the Payer Authentication Request/Response (PAReq/PARes) messages are sent from the server system 102 to the ACS 120 to initiate actual authentication.
[0059] The server system 102 (interchangeably used as “OBO merchant”, throughout the description) is configured to perform one or more operations described herein. In one example, the server system 102 coupled with a database 124 is embodied in the payment network 110. In another example, the server system 102 is a part of the issuer server 116. In general, the server system 102 is configured to facilitate cross-border payment transactions between the cardholder 106 the merchant 108, where the merchant 108 is an offshore merchant. The server system 102 is configured in a manner (described in connection with the next set of figures) that enables the cardholder 106 to avail additional factor of authentication (AFA) service while transacting with the merchant 108 of the foreign country.
[0060] In another embodiment, when the payment directory server 114 identifies that a merchant involved in a payment transaction (e.g., domestic transaction) is associated with the same country where the payment card is issued for the cardholder 106 and is not enrolled for the 3DS cardholder authentication, the payment directory server 114 is configured to send the corresponding URL of the ACS 120 associated with the issuer server 116 to the server system 102. The server system 102 is configured to act as an on-behalf-of (OBO) merchant and sends a request to the ACS 120 to initiate the AFA service for authenticating the payment transaction.
[0061] The server system 102 is a separate part of the environment 100, and may operate apart from (but still in communication with, for example, via the network 122) the payment server 112, the payment directory server 114, the issuer server 116, the acquirer server 118, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 112, the issuer server 116, or the acquirer server 118. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 122, which may be specifically configured, via executable instructions, to perform as described herein, and/or embodied in at least one non-transitory computer-readable media. In one embodiment, the server system 102 is connected with a database to store executable instructions and other information.
[0062] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks, and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0063] FIG. 2 represents a sequence flow diagram 200 for obtaining cardholder choice for implementing additional factor of authentication (AFA) for cross-border payment transactions, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0064] At 202, the cardholder 106 opens an issuer application installed on the cardholder device 104. For example, the cardholder 106 may access a website (e.g., net-banking website), or an application associated with a financial organization, such as a bank, a credit card company, and the like.
[0065] At 204, the cardholder 106 navigates to a card-control UI on the issuer application. In other words, the cardholder 106 accesses card control UI on the issuer application. The cardholder device 104 loads a user interface (UI) for receiving consent from the cardholder 106 for enabling the AFA service for future cross-border payment transactions. For example, the issuer server 116 may provide an application programming interface (API) on cardholder device 104 to enter cardholder preference for enabling the AFA service for the cross-border payment transactions.
[0066] At 206, the cardholder 106 selects a user-selectable icon on the card-control UI to enroll for the AFA service for the cross-border payment transactions. In one embodiment, the cardholder 106 may select a mode of authentication, such as contact number, email address, etc. to enable the AFA service for the cross-border payment transactions.
[0067] At 208, the cardholder device 104 sends a user consent message to the issuer server 116. The user consent message may include, but is not limited, information of cardholder input and cardholder identification.
[0068] At 210, the issuer server 116 may send the user consent message to the access control server (ACS) 120. The ACS 120 may be maintained and managed by the issuer associated with the issuer server 116. In some cases, the issuer server 116 and the access control server 120 may be packaged together.
[0069] At 212, the ACS 120 updates consumer card controls of the cardholder 106 to enable the AFA service for the cross-border transactions. In particular, the ACS 120 stores the user preferences, such as the consumer card controls in association with the mode of authentication details associated with the cardholder 106. The ACS 120 may then be used for authenticating the cardholder 106 based on the mode of authentication. In an example, the ACS 120 stores user preference pertaining to allowing cross-border payments using the payment card associated with the cardholder 106 and instruction pertaining to performing AFA service during cross-border payment transactions.
[0070] FIGS. 3A, 3B, and 3C, collectively, represent a sequence flow diagram 300 for performing the AFA process in cross-border payment transactions, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0071] The sequence flow diagram 300 is explained herewith including entities such as the cardholder 106 associated with a country 'A' and the merchant 108 associated with a country 'B'.
[0072] At 302, the cardholder 106 initiates a cross-border payment transaction on an application associated with the merchant 108 accessible on the cardholder device 104. The application can be a merchant website, mobile or desktop applications, or third-party websites or applications using which the consumer/user may purchase goods or services from a remote location. In an example, the cardholder 106 may select one or more products and/or services offered by the merchant 108 for purchase on the application. The cardholder 106 may then initiate the payment transaction by pressing, for example, “pay”, “checkout” or “proceed to pay” on the application.
[0073] At 304, the cardholder 106 enters cardholder account data on the cardholder device 104. In one example, the payment account data may include, but are not limited to, a payment card number, a name, a validity date, a CVV of the payment card, a payment account number, a virtual payment account identifier, issuer details, and a biometric data or password for a payment account associated with the cardholder 106. In certain cases, the payment account data may be stored on the cardholder device 104 or the application, and the application may retrieve the payment account data to initiate the payment transaction.
[0074] At 306, the cardholder device 104 sends the cardholder account data and purchased product information to the merchant 108. The merchant 108 may have an associated server for hosting the merchant application and/or the merchant website. The merchant server may also be associated with the acquirer or the acquirer server 118. For example, the merchant server may include a merchant server plug-in that creates messages and processes a payment transaction.
[0075] At 308, the merchant 108 retrieves payment transaction information for the cross-border payment transaction. The payment transaction information may include, for example, transaction amount, transaction initiation date, type of transaction (such as cross-border or domestic), merchant name, merchant category code, merchant URL, merchant country code, transaction currency, transaction time, recurring or e-commerce transaction, cross-border transaction flag, geo-location of the merchant and/or the cardholder device 104, network-related information, device-related information, merchant payment account data, acquirer information, and other transaction-related information.
[0076] At 310, the merchant 108 sends a payment transaction request to the payment directory server 114 of the payment network 110, via the acquirer server 118. The payment transaction request may include the cardholder account data and the payment transaction information.
[0077] In one embodiment, the merchant 108 may send a payment transaction request to the server system 102 or the payment server 112 via the acquirer server 118.
[0078] At 312, the payment directory server 114 checks or determines whether the cardholder account data is part of an issuer’s card range, who is participating in an authentication service (e.g., 3-D Secure authentication), or not. In other words, the payment directory server 114 extracts corresponding BIN from the cardholder account data and verifies whether the ACS 120 has enrolled for performing AFA during the payment transaction using the BIN or not. Upon successful verification, the payment directory server 114 retrieves the corresponding URL of the ACS 120. The payment directory server 114 includes a list of one or more Bank Identifier Numbers (BINs). The BIN is key in the process of matching transactions to the issuer of the charged card. Each of the one or more BINs is stored against each of one or more corresponding Universal Resource Locators (URLs) of each of one or more ACSs participating / enrolled for performing multi-factor authentication.
[0079] In one embodiment, the payment directory server 114 identifies whether the merchant 108 is an offshore merchant with respect to the cardholder 106 based on the payment transaction request. The merchant 108 is identified to be the off-shore merchant upon determining that a country code and geo-location associated with the acquirer server 118 and/or the merchant 108 are different from a country code and geo-location of the issuer server 116 and/or the cardholder 106.
[0080] At 314, the payment directory server 114 extracts the merchant account data from the payment transaction request and determines whether the merchant account data is enrolled for an authentication service (e.g., 3DS authentication) or not.
[0081] When the merchant account number is not enrolled for the authentication service (e.g., 3DS authentication) and the merchant 108 is the offshore merchant, it means that the merchant 108 cannot initiate additional factors of authentication with the ACS 120.
[0082] At 316, the payment directory server 114 sends the URL of the ACS 120 to the server system 102 that is configured to be an OBO merchant for the cross-border payment transaction and a merchant enrolment flag indicating the enrolment status of the merchant 108 for the authentication service (e.g., 3DS authentication).
[0083] When the merchant enrolment flag indicates that the merchant 108 is not enrolled for the authentication service, at 318, the server system 102 acts as an OBO merchant for the cross-border payment transaction and sends a request to the ACS 120 to validate that the cardholder account associated with the cardholder 106 is enrolled for an additional factor authentication (AFA) service for cross-border payment transactions.
[0084] At 320, the ACS 120 sends a response indicating the enrolment status of the cardholder account for the AFA service in case of the cross-border payment transactions, to the server system 102.
[0085] Upon determining that the cardholder 106 is enrolled for the AFA service for the cross-border payment transactions, at 322, the server system 102 initiates the AFA process for the cardholder 106 based, at least in part, on the response and the cardholder account data. In one embodiment, the Payer Authentication Request/Response (PAReq/PARes) messages are sent from the server system 102 to the ACS 120 to initiate the actual authentication.
[0086] More illustratively, the server system 102 sends a payer authentication request (PAReq) message to the ACS 120 to perform the AFA process for the cardholder 106. The AFA process may include multi-factor authentication of the cardholder 106.
[0087] At 324, the ACS 120 performs the AFA process for the cardholder 106. The ACS 120 retrieves the contact information of the cardholder 106 associated with the cardholder account data from the database. For example, the mobile number and email ID of the cardholder 106 may be retrieved. The ACS 120 sends an OTP to the contract information of the cardholder 106.
[0088] For example, the cardholder 106 may have logged in to his email via a browser running on the desktop computer on which he may be able to receive the email and access the OTP. Alternatively, if the child cardholder 106 is checking out from a mobile application of a merchant using his smartphone, he may be able to access the OTP sent from the ACS 120 in the SMS application and / or the email application present in the smartphone.
[0089] Thereafter, the OTP is entered on a corresponding UI displayed on the cardholder device 104 by the cardholder 106. The ACS 120 validates the OTP entered by the cardholder 106 by matching with the OTP was sent.
[0090] In one embodiment, the ACS 120 may perform the AFA process based on a static password or a static PIN, and a biometric input associated with the cardholder 106. To this end, the ACS 120 may present an authentication window on a display of the cardholder device 104 to enable the cardholder 106 to provide an input for the AFA process. Upon successful validation, the ACS 120 generates an Accountholder Authentication Value (AAV) indicating the successful authentication.
[0091] At 326, the ACS 120 sends a payer authentication response (PARes) message indicating successfully performed additional-factor authentication, to the OBO merchant (i.e., the server system 102). In one embodiment, the response includes the AAV generated by the ACS 120 to indicate proof of a fully authenticated transaction.
[0092] In an embodiment, the Accountholder Authentication Value (AAV) is a specific token that uses a Universal Cardholder Authentication Field (UCAF) for transport within authorization messages. It is generated by the ACS 120 and presented to the OBO merchant or the server system 102 for placement in an authorization request message. This AAV may be proof of a fully authenticated transaction.
[0093] At 330, the server system 102 generates an updated payment authorization request message. In particular, the server system 102 generates the updated payment authorization request message upon receiving the PARes including the AAV that indicates authentication of the cardholder 106. In one embodiment, the updated payment authorization request message includes a plurality of data elements. The plurality of data elements may include, but is not limited to, BIN of the card issuer of the payment card, a payment transaction identifier, a payment transaction amount, a payment transaction date/time, a payment transaction terminal identifier, a merchant name and location, an acquirer identifier, etc. The updated payment authorization request message may comply with a message type defined by an International Organization for Standardization (ISO) 8583 standard, which is a standard for systems that exchanges electronic transaction information associated with payments made by users using the payment card, or the payment account. In one example, an ISO 8583 transaction message may include one or more data elements that store data usable by the server system 102 to communicate information such as transaction requests, responses to transaction requests, inquiries, indications of fraud, security information, or the like.
[0094] The server system 102 may include the AAV received from the ACS 120 in a universal cardholder authentication field (UCAF) within the updated payment authorization request message.
[0095] Further, the server system 102 populates an additional data field within the payment authorization request message to indicate that the server system 102 acted as an OBO merchant for performing the AFA process. The payment authorization request message indicates that the server system 102 acted as a forwarding merchant who communicated with the ACS 120 for performing the AFA process.
[0096] The following table depicts data fields for payment authorization of the cross-border payment transaction.
Data Element Value
DE 48 SE 41 SF1 218
DE 48 SE 42 SF1, position 1 (security protocol-channel) 2
DE 48 SE 42 SF1, position 2 (cardholder authentication-ecommerce) 1
DE 48 SE 42 SF1, position 3 (Server system acted as OBO merchant) 8
DE 48 SE 43 (UCAF Collection Indicator) UCAF value
DE 48 SE 31 (Server system as OBO merchant) An identifier indicating server system acted as OBO merchant
Table 1
[0097] In one example, the server system 102 may populate a data element (DE) 48, sub element 43 with a value indicating that the server system 102 acted as the OBO merchant. Further, the server system 102 may populate a data element (DE) 48, sub element 42, subfield 1, position 3 with a value ‘8’ to indicate that the server system 102 acted as OBO merchant. For example, the payment authorization message at DE 48, sub element 42, subfield 1 (Electronic Commerce Security Level Indicator and UCAF Collection Indicator) may have position 1 (Security Protocol) containing a value of ‘2’ (Channel), and position 2 (Cardholder Authentication) containing a value of ‘1’ (Cardholder certificate not used). In addition, at private data sub element (PDS) 0052 (Electronic Commerce Security Level Indicator) subfield 3 (UCAF Collection Indicator) in a clearing record submitted to global clearing management system (GCMS) for processing (where applicable) a value of ‘8’ is set, to indicate that the server system 102 acted as OBO merchant. In such case, the PDS 0052, subfield 1 (security protocol) is set to “2”, and sub field 2 (cardholder authentication) is set to ‘1’.
[0098] It may be noted that the UCAF is a universal, multi-purpose data transport infrastructure that is used to communicate authentication information among cardholder, issuer, merchant, and acquirer communities. For example, the UCAF has a variable length, 32-position field with a flexible data structure that can be tailored to support the needs of a variety of issuer security and authentication approaches. In one example, the payment authorization request message may include a security level indicator (SLI). The SLI may be determined based on the value of status field of the PARes message and/or the ECI flag value indicated in the PARes message.
[0099] At 332, the server system 102 transmits the payment authorization request message to the issuer server 116 associated with the cardholder 106 for completing payment authorization. The issuer server 116 may extract AAV from the payment authorization message. Based on the DE 48, sub element 42, sub field 1, and position 3 of the payment authorization request message, the issuer server 116 may determine that the authentication is performed by the server system 102 acting as the OBO merchant. Further, the issuer server 116 may validate the AAV within the payment authentication message based on AAV received from the ACS 120 as part of authorization request processing. In an example, the issuer server 116 may store the AAV for use in potential cardholder disputes. After validating the AAV, the issuer server 116 may process the payment authorization request message and generate a payment authorization response message.
[0100] FIGS. 4A and 4B, collectively, represent a flow chart 400 for processing cross-border payment transactions, in accordance with an embodiment of the present disclosure. The sequence of operations of the flow chart 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the flow chart 400, references may be made to elements described in FIG. 1.
[0101] The flow chart 400 explains the process of transaction flow for the cross-border payment transaction when the cardholder 106 and the merchant 108 belong to a different country. The flow chart starts at 402 from the start block.
[0102] At 404, the merchant 108 sends a payment transaction request to the payment directory server 114 of the payment network 110 via the acquirer server 118. The payment transaction request may include, but is not limited to, cardholder account data associated with the cardholder 106 transaction amount, transaction initiation date, type of the transaction (such as cross-border or domestic), merchant name, merchant category code, merchant URL, merchant country code, merchant account data, transaction currency, transaction time, recurring or e-commerce transaction, cross-border transaction flag.
[0103] In one embodiment, the payment transaction request is received by the server system 102 from the merchant 108 that transmits the cardholder account data and merchant account data to the payment directory server 114. The server system 102 then transmits a verify enrolment request (“VEReq”) message to the payment directory server 114 (for example, a service directory server operated by a payment network).
[0104] At 406, the payment directory server 114 extracts BIN associated with the cardholder account data included in the payment transaction request.
[0105] At 408, the payment directory server 114 checks whether the cardholder account data is a part of stored card ranges in a storage database, that is participating in 3-D Secure authentication. In other words, the payment directory server 114 verifies whether the ACS 120 has enrolled for performing AFA during the payment transaction using the BIN. Upon successful verification, the payment directory server 114 retrieves the corresponding URL of the ACS 120.
[0106] When the BIN is not included in the stored card ranges, at 410, a payment authorization request message is transmitted to the issuer server 116 for authorization processing without 3DS authentication processing and the process ends.
[0107] When the BIN is included in the stored card ranges, at 412, the payment directory server 114 checks whether the merchant 108 involved in the cross-border payment transaction is enrolled for an authentication service (e.g., 3DS authentication program) or not. In one embodiment, the payment directory server 114 stores information of 3DS enrolled merchant accounts. The payment directory server 114 compares the merchant account data involved in the cross-border payment transaction with stored 3DS enrolled merchant accounts to determine an indication that a cross-border payment transaction should undergo through an OBO merchant for 3DS authentication or not. In some embodiments, a merchant ID and/or an acquirer ID of a received payment transaction request is compared to the stored merchant and/or acquirer FI identifiers in the payment directory server 114.
[0108] In one embodiment, when the merchant 108 is enrolled for the authentication service, at 418, a payment authorization request message is transmitted to the issuer server 116 for authorization processing with 3DS authentication processing, which is as usual business processing and the process ends. It may be noted that 3DS authentication program may be a compulsory regulatory directive in certain countries, such as India, Europe, South Africa, Brazil, etc. Subsequently, payment accounts operating in such countries may have a 3DS mandate and thus, the merchants may interact with ACSs for 3DS authentication.
[0109] In another embodiment, when the merchant 108 is not enrolled for the authentication service (e.g., 3DS authentication program), at 416, the payment directory server 114 routes the payment transaction request and the corresponding URL of the ACS 120 to the OBO merchant (i.e., server system 102). Thus, the payment directory server 114 provides a centralized decision-making process to merchants and uses the account number in the VEReq message to direct that VEReq to an appropriate issuer ACS 120 via the OBO merchant 102.
[0110] At 418, the OBO merchant 102 sends a request (e.g., VEReq) to the ACS 120 to determine the enrolment status of the cardholder 106 for the AFA service of cross-border payment transactions. Upon receipt of the VEReq, the ACS 120 verifies whether the cardholder 106 has selected a 3DS authentication service for cross-border payment transactions.
[0111] At 420, the ACS 120 checks or determines whether the cardholder 106 has selected the AFA service for the cross-border payment transactions based, at least in part, on stored consumer card controls for the cardholder account of the cardholder 106.
[0112] If the cardholder 106 has selected the AFA service for the cross-border payment transactions, the ACS 120 transmits a positive verify enrolment response (“VERes”) message to the OBO merchant 102.
[0113] If the cardholder 106 has not selected the AFA service for the cross-border payment transactions, at 422, the OBO merchant 102 sends a payment authorization request message to the issuer server 116 via the payment network 110 without performing the additional factor of authentication (AFA) for the cardholder 106.
[0114] At 424, the OBO merchant 102 then initiates the AFA process for the cross-border payment transaction. In particular, the OBO merchant 102 generates a payer authentication request (“PAReq”) message to authenticate the cardholder 106 for the cross-border payment transaction and transmits the PAReq message directly to the ACS 120 (by using the ACS URL) for cardholder authentication.
[0115] At 426, the ACS 120 performs the AFA process for the cross-border payment transaction. If the ACS 120 successfully authenticates the cardholder 106, the ACS 120 then generates a positive payer authentication response (“PARes”) message including a UCAF. The positive PARes message is transmitted to the OBO merchant 102. In some embodiments, the positive PARes message includes fields containing the cardholder's PAN, an acquirer identifier, a merchant identifier, the date and/or time of the transaction, the transaction amount, a transaction currency code, and the UCAF. In addition, in some implementations, a transaction identifier is included in the PARes message.
[0116] Upon successful authentication, at 428, the OBO merchant 102 populates a data field indicating that the OBO merchant 102 acts as a forwarding merchant who has communicated with the ACS 120 for 3DS authentication and generates an updated payment authorization request message. In other words, the OBO merchant 102 generates the updated payment authorization request message including the additional data field indicative of the OBO merchant 102 being acted as an OBO merchant for performing the AFA process.
[0117] At 430, the OBO merchant 102 sends the updated payment authorization request message to the issuer server 118 via the payment network 110 for payment authorization.
[0118] FIG. 5 is a flow diagram of a computer-implemented method 500 for providing additional factor of authentication (AFA) in cross-border payment transactions, in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by the server system 102 which may be a standalone server or a server wholly incorporated in another server system. Operations of the method 500, and combinations of operations in the method 500, may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions.
[0119] In certain implementations, the method 500 may be performed by a single processing thread. Alternatively, the method 500 may be performed by two or more processing threads, each processing thread implementing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing the method 500 may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing the method 500 may be executed asynchronously with respect to each other. The method 500 starts at operation 502.
[0120] At 502, the method 500 includes receiving a payment transaction request associated with a cross-border payment transaction between a cardholder 106 and a merchant 108. The payment transaction is initiated by the cardholder 106 on a cardholder device 104, via a website or an application provided by the merchant 108. The merchant 108 may send the payment transaction request, via an acquirer server 118 or payment directory server 114. The payment transaction request includes cardholder account data associated with the cardholder 106, payment transaction information, merchant information associated with the merchant 108, and acquirer information.
[0121] At 504, the method 500 includes identifying whether the merchant 108 is enrolled for an authentication service (e.g., 3DS authentication program) or not based, at least in part, on a storage database at a payment directory server 114. For example, the merchant 108 is identified based on a bank identification number (BIN) associated with a payment account of the merchant 108. For example, the BIN associated with the merchant 108 may be searched in the storage database at the payment directory server 114 to determine if the BIN is registered and whether the payment account associated with the merchant 108 is enrolled for authentication service.
[0122] At 506, the method 500 includes sending a request to an access control server (ACS) 120 to determine whether the cardholder account associated with the cardholder is enrolled for an additional factor of authentication (AFA) service for cross-border payment transactions. In particular, the request is sent in response to identifying that the merchant 108 is not enrolled for the authentication service. Moreover, the ACS may store information relating to the cardholder account associated with the cardholder 106 that indicates enrolment status of the cardholder account for the AFA service for the cross-border payment transactions.
[0123] At 508, the method 500 includes receiving a response indicating the enrolment status of the cardholder account for the AFA service for the cross-border payment transactions, from the ACS 120.
[0124] At 510, the method 500 includes initiating an AFA process for the cardholder 106 based, at least in part, on the response and the cardholder account data. Upon determining that the merchant 108 is not enrolled for the 3DS authentication service and the cardholder 106 has enrolled for the AFA service for the cardholder account, AFA process for the cross-border payment transaction is initiated. The ACS 120 may be invoked for performing the AFA process for authenticating the cardholder 106. The ACS 120 may then send a response including AAV that indicates successful or failed authentication of the cardholder 106.
[0125] At 512, the method 500 includes populating an additional data field to generate an updated payment authorization request message. The additional data field in the updated payment authorization request message is populated to indicate that the server system 102 is acting as the OBO merchant while performing the AFA process. In other words, the method 500 includes generating the updated payment authorization request message including the additional data field indicative of the server system 102 being acted as the OBO merchant for performing the AFA process.
[0126] At 514, the method 500 includes transmitting the updated payment authorization request message to an issuer server 116 associated with the cardholder 106 for completing payment authorization.
[0127] FIG. 6 is a simplified block diagram of the server system 600, in accordance with one embodiment of the present disclosure. The server system 600 includes a computer system 602 and a database 604. In an embodiment, the server system 600 is integrated, but not limited to, in the payment server 112 of the payment network or the issuer server 116.
[0128] The computer system 602 includes at least one processor 606 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 608. The components of the computer system 602 provided herein may not be exhaustive and the computer system 602 may include more or fewer components than that depicted in FIG. 6. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 602 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[0129] The processor 606 is operatively coupled to a communication interface 610 such that the computer system 602 is capable of communicating with a remote device 614 such as a cardholder device 104, the merchant 108, the payment server 112, and the payment directory server 114 associated with the payment network 110, the issuer server 116, and acquirer server 118, respectively or communicated with any entity connected to the network 122 (shown in FIG. 1). In an embodiment, the communication interface 610 is configured to receive a payment transaction request associated with a cross-border payment transaction between the cardholder 106 and the merchant 108, from the merchant 108. The payment transaction request may include cardholder account data associated with the cardholder 106, merchant information associated with the merchant 108, transaction information, and acquirer information. The communication interface 610 is configured to send a request to the access control server (ACS) 120 to determine whether a cardholder account associated with the cardholder 106 is enrolled for an additional factor of authentication (AFA) service for cross-border payment transactions, in response to identifying that the merchant 108 is not enrolled for the 3DS authentication service. The communication interface 610 is configured to receive a response indicating the enrolment status of the cardholder account of the cardholder 106 for the AFA service for the cross-border payment transactions from the ACS 120. Further, the communication interface 610 is configured to transmit an updated payment authorization request message to the issuer server 116 associated with the cardholder 106 for completing payment authorization.
[0130] In an example, the database 604 is external to the computer system 602 and may be accessed by the computer system 602 using a storage interface 612. The storage interface 612 is configured to store cardholder account data, enrolment status of the cardholder 106, acquirer information, merchant information, and the transaction information associated with the payment transaction.
[0131] The processor 606 may also be operatively coupled to the database 604. The database 604 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of a merchant, transaction data generated as part of sales activities conducted over a payment network including data relating to merchants, payees, or customers, and purchases. The database 604 may also include instructions for settling transactions including merchant bank account information. The database 604 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 604 may include a storage area network (SAN) and/or a network-attached storage (NAS) system.
[0132] In some embodiments, the database 604 is integrated within computer system 602. For example, the computer system 602 may include one or more hard disk drives as the database 604. The storage interface 612 is any component capable of providing the processor 606 with access to the database 604. The storage interface 612 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 606 with access to the database 604.
[0133] The processor 606 is configured to identify whether the merchant 108 is enrolled for an authentication service or not based, at least in part, on a storage database at the payment directory server 114. In one embodiment, the authentication service is compliant with the 3-D secure authentication protocol. The processor 606 is configured to initiate an AFA process for the cardholder 106 based, at least in part, on the response and the cardholder account data. In this regard, the ACS 120 may be invoked by the server system 600 acting as an on-behalf-of (OBO) merchant, and the ACS 120 performs the AFA process for the cross-border payment transaction. The processor 606 is configured to generate an updated payment authorization request message and populate an additional data field of the updated payment authorization request message to indicate that the server system 600 is acting as the OBO merchant for performing the AFA process.
[0134] FIG. 7 is a simplified block diagram of the payment directory server 700, in accordance with one embodiment of the present disclosure. The payment directory server 700 includes a computer system 702 and a storage database 704. In an embodiment, the payment directory server 700 is integrated, but not limited to, in the payment server 112 within the payment network 110. An exemplary payment network 110 may include Mastercard™.
[0135] The computer system 702 includes at least one processor 706 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 708. The components of the computer system 702 provided herein may not be exhaustive and that the computer system 702 may include more or fewer components than that of depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 702 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0136] The processor 706 is operatively coupled to a communication interface 710 such that the computer system 702 is capable of communicating with a remote device 714, such as a cardholder device 104, an acquirer server 118, the merchant 108, the issuer server 116, the ACS 120, the server system 102, or communicate with any entity connected to the network 122 (shown in FIG. 1).
[0137] The processor 706 may also be operatively coupled to the storage database 704. The storage database 704 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of cardholders, eligibility for 3DS, information of merchants, transaction data generated as part of sales activities conducted over a payment network including data relating to merchants, payees, or customers, and purchases. The payment directory server 700, via the storage database 704, may store, organize and provide access to information stored in the storage database 704. The storage database 704 may include a BIN storage 716 that includes a list of bank identification numbers (BINs) associated with several banks that are registered with the payment directory server 700 and are enrolled for the 3DS authentication service. The storage database 604 may also include instructions for performing an action on the stored information for settling payment transactions. The storage database 704 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The storage database 704 may include a storage area network (SAN) and/or a network-attached storage (NAS) system.
[0138] In an example, the storage database 704 stores, within the BIN storage 716, a set of data records including information relating to financial organizations associated with the payment network 110. The set of data records may also include information relating to users (such as, cardholders or account holders) associated with the financial organizations. For example, each data record may include a unique identifier and a set of attributes. The set of attributes may define various pieces of information that are associated with the corresponding data entry. By way of example, in the BIN storage 716 of the payment directory server 700, each entry may relate to a financial organization, such as a bank, based on the corresponding bank identification number. Moreover, a data entry associated with a financial organization may also include or be linked to data entries relating to primary account numbers of accountholder in the financial organization.
[0139] In some embodiments, the storage database 704 is integrated within the computer system 702. For example, the computer system 702 may include one or more hard disk drives as the storage database 704. The storage interface 812 is any component capable of providing the processor 706 with access to the storage database 704. The storage interface 812 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 706 with access to the storage database 704.
[0140] In an embodiment, the communication interface 710 is configured to receive a cross-border payment transaction request from the merchant 108 via the acquirer server 118. In this regard, the processor 706 is configured to determine a BIN of a financial organization associated with a cardholder account of the cardholder 106 and BIN of a financial organization associated with a payment account of the merchant 108. If data record corresponding to the BIN of the financial organization associated with the merchant 108 is not stored within the BIN storage 716, the payment directory server may identify that the merchant is not enrolled for the 3DS authentication service. Moreover, based on data records corresponding to the BIN associated with the cardholder 106, the processor 706 may determine if the cardholder account of the cardholder 106 is participating in 3DS.
[0141] The communication interface 710 is further configured to send a verification response message to the merchant 108 indicating whether the cardholder account associated the cardholder 106 relates to a financial organization that is participating in the 3DS authentication program. In an example, the communication interface 710 is configured to send the cross-border payment transaction request to the server 102 on determining that the merchant 108 is the merchant is not enrolled for the 3DS authentication service, or include an instruction for routing payment transaction request to the server system 102 within the verification response message.
[0142] The communication interface 710 is configured to receive a request from the server system 102 for identifying whether the merchant is enrolled for 3DS authentication service or not. The processor 706 is configured to access the storage database 704 to determine whether the merchant 108 (BIN associated with the merchant’s payment account) is stored within the BIN storage 716 to determine if the merchant 108 is enrolled or not. The communication interface 710 is configured to send a response indicating the determination that the merchant 108 is not enrolled for the authentication service.
[0143] FIG. 8 is a simplified block diagram of an access control server (ACS) 800, in accordance with an embodiment of the present disclosure. The ACS 120 is associated with an issuer bank/issuer, in which a cardholder (e.g., the cardholder 106) may have an account. The ACS 800 includes a processor 805 communicably coupled to a database 810 and a communication module 815. The components of the ACS 800 provided herein may not be exhaustive, and the ACS 800 may include more or fewer components than those depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the ACS 800 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[0144] The database 810 includes information associated with the cardholder 106, such as, but not limited to, a primary account number (PAN one or more parameters), payment card number, a name, a city, a postal code, a payment card PIN, payment card controls, a payment card code such as CVV, a payment card validity and the like.
[0145] Via a communication module 815, the processor 805 may receive a payer authentication request (PAReq) message from a remote device 820 such as the merchant 108, the acquirer server 118, and the server system 102. Moreover, the processor 805 may receive a request to determine whether the payment account of the cardholder 106 is enrolled for an additional factor of authentication (AFA) service for cross-border payments, via the communication module 815, from the remote device 820 such as the server system 102. In response to receiving PAReq message, the processor 805 may authenticate the cardholder 106, using a cardholder authentication module 825. The processor may generate an AAV for the authentication process, send a payer authentication response (PARes) message including the AAV to the merchant 108, the server system 102, or the acquirer server 118, and send the AAV to the issuer server 116.
[0146] The communication module 815 may enable the ACS 800 to send and receive information from, for example, the server system 102, the payment directory server 114, the acquirer server 118, the merchant 108, the issuer server 116, and the payment server 112. In an embodiment, the processor 805 may process a PAReq message to perform the AFA process for processing a cross-border payment transaction between the cardholder 106 and the offshore merchant 108.
[0147] The cardholder authentication module 825 takes control of the communication frame or window, and presents a Purchase Authentication Page to the cardholder 106 on the cardholder device 104. The Purchase Authentication Page requests information, such as a password or an answer to a question, needed to authenticate the cardholder 106. The cardholder 106 provides information needed for authentication, and the cardholder authentication module 825 conducts an authentication procedure, which may include testing the received information against information stored at the database 810 of the ACS 800. The cardholder authentication module 825 then sends the PARes message to the server system 102 indicating whether the cardholder could be authenticated or not. If the cardholder 106 is indicated as being authenticated, the server system 102 acting as OBO merchant may proceed to process the transaction with cardholder AFA service (e.g., 3DS authentication). If the cardholder 106 is not indicated as being authenticated, the server system 102 may decline the transaction.
[0148] FIG. 9 is a simplified block diagram of the issuer server 900, in accordance with an embodiment of the present disclosure. The issuer server 900 is associated with an issuer bank/issuer, in which a cardholder (e.g., the cardholder 106) may have an account. The issuer server 900 includes a processor 905 communicably coupled to a database 910 and a communication module 915. The components of the issuer server 900 provided herein may not be exhaustive, and the issuer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[0149] The database 910 includes information associated with the cardholder 106, such as but not limited to, a primary account number (PAN one or more parameters), payment card number, a name, a city, a postal code, a payment card PIN, a payment card code, such as CVV, a payment card validity and the like.
[0150] Via a communication module 915, the processor 905 may receive an updated payment authorization request message from a remote device 920 such as the merchant 108, the acquirer server 118, the server system 102, and authentication information, such as AAV, from the ACS 120. The communication module 915 may enable the issuer server 900 to send and receive information from, for example, the server system 102, the payment directory server 114, the acquirer server 118, ACS 120, and the payment server 112. In an embodiment, the processor 905 may process the payment authorization message for processing the payment transaction between the cardholder 106 and the offshore merchant 108.
[0151] FIG. 10 is a simplified block diagram of the cardholder device 1000 capable of implementing at least some embodiments of the present disclosure. The cardholder device 1000 is depicted to include one or more applications such as a mobile application. The mobile application can be an instance of an application downloaded from a third-party server or the merchant website. The mobile application is capable of communicating with the merchant 108, the payment server 112, the acquirer server 118, the issuer server 116, the server system 102, and the payment directory server 114 for facilitating the processing of a payment transaction and for enabling real-time authentication of a cardholder associated with the cardholder device 1000 participating in a cross-border payment with a merchant.
[0152] It should be understood that the cardholder device 1000 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the cardholder device 1000 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 10. As such, among other examples, the cardholder device 1000 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[0153] The illustrated cardholder device 1000 includes a controller or a processor 1002 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1004 controls the allocation and usage of the components of the cardholder device 1000 and supports one or more e-commerce applications programs (such as the applications 1006) such as the merchant application that implements one or more of the innovative features described herein. In addition, to the merchant application, the applications 1006 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[0154] The illustrated cardholder device 1000 includes one or more memory components, for example, a non-removable memory 1008 and/or removable memory 1010. The non-removable memory 1008 and/or the removable memory 1010 may be collectively known as a database in an embodiment. The non-removable memory 1008 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1010 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1004 and the applications 1006. The cardholder device 1000 may further include a user identity module (UIM) 1012. The UIM 1012 may be a memory device having a processor built-in. The UIM 1012 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1012 typically stores information elements related to a mobile subscriber. The UIM 1012 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA5000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[0155] The cardholder device 1000 can support one or more input devices 1020 and one or more output devices 1030. Examples of the input devices 1020 may include, but are not limited to, a touch screen / a display screen 1022 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1024 (e.g., capable of capturing voice input), a camera module 1026 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1028. Examples of the output devices 1030 may include, but are not limited to a speaker 1032 and a display 1034. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1022 and the display 1034 can be combined into a single input/output device.
[0156] A wireless modem 1040 can be coupled to one or more antennas (not shown in the FIG. 10) and can support two-way communications between the processor 1002 and external devices, as is well understood in the art. The wireless modem 1040 is shown generically and can include, for example, a cellular modem 1042 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1044 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1046. The wireless modem 1040 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the cardholder device 1000 and a public switched telephone network (PSTN).
[0157] The cardholder device 1000 may further include one or more input/output ports 1050, a power supply 1052, one or more sensors 1054 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the cardholder device 1000 and biometric sensors for scanning biometric identity of an authorized cardholder, a transceiver 1056 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1060, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[0158] The disclosed method with reference to FIGS. 4 and 5, or one or more operations performed by the server system 102 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Webbook, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[0159] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[0160] Particularly, the server system 102 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read-only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[0161] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.
[0162] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.