PAYMENT TRANSACTION

FIELD OF THE INVENTION

[0001] The invention generally relates to a method and system for processing a payment transaction for achieving higher payment success rates. Specifically, the invention relates to a method and system for converting a failed payment transaction to a successful payment transaction by analyzing an issuer response and shifting the liability of chargeback to one or more acquirer side parties for improving an approval rate of a payment authorization request based on a fraud or risk assessment of the payment transaction.

BACKGROUND OF THE INVENTION

[0002] In recent years, payment transactions are conducted at a physical store, online, or via mail order or telephone order. Additionally, a cardholder may conduct payment transactions using payment modes such as, but not limited to, a physical card, a mobile device, a token, and a mobile wallet. Consequently, each type of payment transaction can have different attributes. In this context, it may be useful to identify a payment transaction initiation mode to identify these attributes. The widely differing payment transaction attributes may have different risks, security and convenience characteristics that may be used during processing of the payment transaction by various participants of a transaction such as the issuer, acquirer, payment network, payment aggregator, transaction processor/transaction processing network or the merchant.

[0003] Accordingly, conventional payment card transaction systems enable the cardholder to purchase goods or services from a merchant with their payment card, such as a debit card or a credit card. At the time of purchase, the cardholder presents their payment card information to the merchant to complete the purchase. A process of payment authorization is conducted before the purchase is completed. The merchant transmits the payment card information and other transaction data, such as a total payment amount, to a payment card network. The payment card network analyzes the payment transaction and forwards it to an issuing bank, which either authorizes the payment transaction and provides an authorization code or declines the payment transaction with specific decline codes for acquirers to analyze the reason of the decline of the transaction.

[0004] Each party/entity involved in processing the payment transaction such as, but not limited to, merchants, acquirers, the payment network, and the issuing bank, has a specific role to play in the authorization process. Each entity may allow or decline the authorization based on their respective roles, as well as their potential risk and loss exposures. Conventional payment card transaction systems frequently have a default set of rules governing liability for the payment transaction when a transaction is disputed (for example, who will be responsible when the cardholder does not pay or files a dispute due to fraud or service not rendered reasons). Each entity may accept or decline the payment transaction based on their own individual authorization approval and risk assessment strategies. This may result in a declined transaction, a result that may not be favorable to other parties involved in the payment transaction.

[0005] When the payment transaction is declined, known authorization systems suffer from limitations in that the cardholder may be unable to quickly ask for the payment transaction to be attempted another time due to various reasons and limitations in today’s merchant or acquirer side systems. In such situations, multiple transactions within a short time may raise the suspicion of fraud and may lead to the same result as the previous one if the transaction is attempted without changing the attributes that were used in the previously attempted transaction. [0006] In some cases, the issuer declines a payment authorization for genuine risk involved with a transaction. For example, identity theft of the cardholder may lead to a malicious user using the account in one location while the legitimate cardholder uses the account in another location. A malicious user may use the account to compile several purchases quickly before the issuer deactivates the account.

[0007] In other cases where the legitimate cardholder wishes to make multiple purchases, known authorization systems often involve the cardholder having to contact the issuing bank (or issuer) where the cardholder’s account is located. Known systems sometimes require that the cardholder provide personally identifiable information (PII) that may not be readily available. For example, a cardholder may be standing in line at a store waiting to make a purchase at a point-of-sale (PoS) device in the store. When the transaction is declined, the cardholder may be required to contact the issuer via a telephone and collect an authorization code to progress a transaction to the next step or provide information that may not be in immediate possession of the cardholder.

[0008] In a remainder of the cases, the transaction that was initially attempted results in a decline that is not due to risk of the transaction as such, but the liability associated with it for issuers to take when a chargeback or dispute is filed due to reasons such as fraud and card theft. Even in this case, re-attempting the transaction with same attributes as that of the original transaction, would not result in an approval of a transaction and leads to loss of the transaction for the customer and the merchant.

[0009] Also, in typical online transactions, a consumer using a portable device to pay for goods or services from a merchant, need to be an authorized user. This is particularly important in situations where the consumer is not making the purchase in person, but rather is making the purchase online, or through mail. To address the issue of unauthorized use or fraudulent purchases, many solutions have been developed, which enables the issuer to verify ownership of the portable consumer device during an online purchase using a verification window, which allows the consumer to enter information that is authenticated by the issuer of the personal consumer device. After verifying the consumer's identity, the issuer creates and sends an authentication response to the merchant, who can thereafter decide to either proceed with or decline the transaction. In this case, the merchant must include the attributes received back from the issuer in the authentication response in the authorization request sent to the issuer to ensure that the liability of the transaction dispute is owned by the issuer and not the merchant or the acquirer.

[0010] However, there are many authentication mechanisms that have emerged for online transactions that are not conducive to the global consumers and which are regional and local in nature. For instance, a password may be prompted each time the consumer makes a purchase online or other forms of identification may be required every time a purchase or transaction is made online to authenticate the customer by the issuer of the payment card. This authentication mechanism may be different for different cards, different issuers and different countries and applying the same payment authentication flow to a transaction leads to confusion and loss of a transaction from the customer’s end as they may not be familiar with the authentication mechanism used. When any of these primitive methods fail to authenticate the customer, the entire transaction is declined by the issuer, resulting in a failed transaction.

[0011] Online card payment systems exist with an infrastructure where one or more parties (either the merchant, the acquirer or the issuer) accept liability for a payment card transaction if a fraud related dispute is received for that transaction. Such systems enable a party involved in a payment card transaction (for example, a merchant) to choose and utilize the authentication infrastructure built for processing the payment transactions. In many cases and countries, it a regulatory requirement for merchants that they must initiate authentication of the customer making the payment and only process the authorization once the customer authentication was successful. For instance, when a customer uses his payment card to complete a purchase, the transaction request may be declined due to factors such as, but not limited to, an insufficient authentication of the cardholder. However, since the merchant involved in the transaction has knowledge of the customer’s reputation/loyalty, the merchant and a payment aggregator system itself can choose to take the onus of authenticating the customer, rather than having the customer face a declined transaction due to non authentication on the issuer system. This problem is accentuated in a global setup where a merchant attempts to take the customer through a payment authentication but that leads to a failure due to issuer non-readiness to authenticate the customer or the global customer not able to identify an authentication process due to lack of knowledge or experience in handling such transactions.

[0012] Many a times when issuers do not have the infrastructure on their end to authenticate a transaction, issuers still participate in the payment authentication without actually carrying out the customer authentication. This case is generally known as the “attempted authentication” and in this case, the liability of a fraud transaction shifts to an issuer. This is because an issuer is not able to build and release the technical system required to authenticate a customer and when the merchant or their payment aggregator attempts to authenticate a customer, the issuer is unable to do the authentication. This gives the right to the merchant to shift the liability of that transaction’s fraud risk to the issuer as the merchant attempted the authentication but failed due to non-participation of the issuer in this ecosystem.

[0013] Today, payment gateways and processors attempt a payment transaction with a set of data elements with the network and card issuers. At times a transaction fails due to multiple reasons. In an instance, the payment authentication may fail as an issuer may not be participating in the authentication flow. In another instance, the issuer may decline the customer authentication due to various reasons. In yet another instance, the issuer may not approve an authorization of a transaction as the issuer has to take the liability of the fraud risk attached to that transaction.

[0014] Issuers also decline a transaction authorization due to multiple reasons. Some of the common reasons that are valid reasons and that which do not apply for re attempting a transaction again for processing after a decline include, but need not be limited to, invalid card (such as an expired card), insufficient funds in the account associated with the card, card blocked due to rules on the issuer’s end (such as card not enabled for online transactions or international transactions).

[0015] Another reason for which issuers decline a card transaction is when the issuers are not ready to take the liability of authorizing the transaction. This liability shift mainly happens when the merchant attempted to authenticate the customer but the issuer authenticated system could not authenticate due to non-readiness of their system and that led to “attempted authentication” making the issuer take the liability of the transaction fraud related risk. This leads to a transaction decline with specific reasons attached to it. This decline causes inconvenience to the parties that are involved in the payment transaction even after attempting the right transaction flow and merchants lose a legitimate payment transaction due to lack of capability on the issuer system. In such situations, today, the merchants or payment gateways do not have the technical system and methods required to take the liability for that transaction. This leads to sub-optimal transaction approval rates and leaves a transaction in a declined state when it can be converted into a successful transaction.

[0016] Therefore, there is a need for a method and system for converting a failed payment transaction to a successful payment transaction by enabling a payment gateway or a technical system build capability of receiving the reason of a transaction decline from the issuers and let the issuers know that acquirer side systems are open to take liability of that transaction. BRIEF DESCRIPTION OF THE FIGURES

[0017] The accompanying figures where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the invention.

[0018] FIG. 1 illustrates a system for reprocessing a previously failed payment transaction in accordance with an embodiment of the invention.

[0019] FIG. 2 illustrates various modules of a payment orchestration engine for reprocessing a previously failed payment transaction in accordance with an embodiment of the invention.

[0020] FIG. 3 illustrates a process flow diagram depicting a payment transaction flow for reprocessing a previously failed payment transaction using a payment gateway system in accordance with an exemplary embodiment of the invention.

[0021] FIG. 4 illustrates a flowchart of a method for reprocessing a previously failed payment transaction using a payment orchestration engine in accordance with an embodiment of the invention.

[0022] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION [0023] Before describing in detail embodiments that are in accordance with the invention, it should be observed that the embodiments reside primarily in combinations of method steps and system components for converting a failed payment transaction to a successful payment transaction by analyzing an issuer response and shifting the liability of chargeback to one or more acquirer side parties for improving an approval rate of a payment authorization request based on a fraud or risk assessment of the payment transaction.

[0024] Accordingly, the system components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0025] The terms “a” or “an”, as used herein, are defined as one or more than one. The term plurality, as used herein, is defined as two or more than two. The term another, as used herein, is defined as at least a second or more. The terms including and/or having, as used herein, are defined as comprising (i.e., open language). The term coupled, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. The terms program, software application, and the like as used herein, are defined as a sequence of instructions designed for execution on a computer system. A program, computer program, or software application may include a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system. [0026] Various embodiments of the invention disclose a method and system for reprocessing a previously failed payment transaction using a payment orchestration engine to achieve higher payment success rates. The method includes receiving, from a user device at a merchant system, a payment transaction processing request associated with a payment transaction. In an embodiment, the payment transaction processing request is initiated by a customer via an e-commerce platform or a point-of-sale (PoS) terminal associated with the merchant system on a merchant site. The payment transaction processing request includes information such as, but not limited to, payment data, customer data and other data that may be used for purposes such as risk assessment of a transaction such as order information and customer profile details to authenticate the customer.

[0027] The payment transaction processing request is transmitted by the merchant system to a payment gateway system or a payment aggregator. Upon receiving the payment transaction processing request, the payment gateway system forwards a transaction request to an issuer system, for authentication of the customer and authorization of the payment transaction. The transaction request includes a transaction authorization message containing a plurality of transaction attributes for authentication of the customer and authorization of the payment transaction by the issuer system. The plurality of transaction attributes include, but need not be limited to, account data necessary to authorize the customer’s use of their payment card, and other data including, but not limited to, an account identifier and an account number associated with the payment card, a transaction amount, a merchant identifier, an acquirer identifier, a merchant category, a transaction date/time, a transaction environment, a card or customer verification, and a party accepting liability for authorizing the payment transaction. [0028] In a typical scenario, when the payment gateway system initiates a transaction request to the issuer system for ensuring the customer is authenticated, and if the issuer system fails to authorize the transaction based on the authentication results of the customer authentication, the merchant system typically stops processing the payment transaction further for payment authorization. In this embodiment of the invention, when the payment gateway system receives a transaction authorization decline response from the issuer system with particular transaction authorization decline reason codes, the payment orchestration engine analyzes the transaction authorization decline reason codes, and determines if these reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible.

[0029] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is not possible, the payment orchestration engine drops the reattempting of the payment transaction. In this case, the reason codes may be indicative of insufficient funds, an invalid card and the issuer system blocking the payment transaction due to rules defined at the issuer system.

[0030] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible, the payment orchestration engine evaluates if a risk score (or a confidence score) associated with the payment transaction is more than a predefined or a configured risk score threshold. In this case, the reason codes may be indicative of non-readiness and/or lack of capability of the issuer system to take the liability of authorizing the payment transaction due to a fraud related risk.

[0031] The risk score threshold may be configured or defined by any party in the system such as the merchant system on the acquiring side, the acquirer system or the payment aggregator/payment gateway system. In an embodiment, the risk score is calculated by a fraud analysis system (may be a third-party fraud analysis system) based on a fraud probability of the payment transaction using the transaction attributes that were collected during the original payment such as payment data, customer data, order data and customer behavior data. In another embodiment, the risk score is pre emptively computed and checked even before attempting the payment transaction for the first time and before obtaining the response with the decline response codes, or while the payment gateway system receives the payment transaction processing request from the merchant system.

[0032] The payment orchestration engine then modifies the plurality of transaction attributes in the transaction authorization message in response to determining the risk score being more than the configured or predefined threshold. The modified transaction authorization message indicates to the issuer system that the payment transaction is to be re-attempted with the issuer system, and that the liability of chargeback for the payment transaction has been shifted to one or more acquirer systems. The payment orchestration engine assesses re-attempt of the payment transaction based on the plurality of transaction attributes that have been modified which include information such as, but not limited to, a card type and a transaction type. In an embodiment, if one acquirer system is not ready to take the liability of the payment system, another acquirer system at the backend takes the liability of chargeback for the payment transaction.

[0033] Upon receiving the modified transaction authorization message, the issuer system transmits a transaction approval message in a transaction authorization response, authorizing the payment transaction. The merchant system then transmits a transaction authorization success message for display at a web browser of either the e- commerce platform or the PoS terminal. [0034] FIG. 1 illustrates a system 100 for reprocessing a previously failed payment transaction in accordance with an embodiment of the invention.

[0035] As illustrated in FIG. 1, system 100 includes a user device 102 associated with a user 104 (for example, a customer) in communication with a merchant system 106 which operates on behalf of a merchant providing goods and/or services to user 104. User device 102 may include a computing device capable of initiating a payment transaction with merchant system 106.

[0036] Merchant system 106 can include, but need not be limited to, an e-commerce platform and a merchant PoS terminal at a merchant site.

[0037] A merchant controlling merchant system 106 can be, but need not be limited to, an online marketplace or a mall through which multiple other vendors collaborate to provide goods and/or services to customers. A merchant may refer to any individual or entity that offers goods and/or services, or access to such goods and/or services to customers in return for a payment transaction. User 104 operating user device 102 can access a website/webpage or a graphical user interface (GUI) of merchant system 106 through a web browser or any other software application resident on merchant system 106. User 104 may select goods and/or services offered from different merchants and can initiate a payment transaction via the GUI during checkout.

[0038] Merchant system 106 comprises one or more computer systems operated by or on behalf of a merchant. The one or more computer systems comprise a merchant server or a merchant computer executing one or more software applications. A merchant PoS terminal, as used herein, may include one or more computers and/or peripheral devices used by a merchant to enable customers to initiate a payment transaction. The peripheral devices include, but need not be limited to, Near-Field Communication (NFC) receivers, Radio Frequency Identification (RFID) receivers, card readers, contact-based and contactless transceivers, payment terminals, input devices, computers, servers, and other similar devices that may be utilized by customers for initiating a payment transaction at the merchant PoS terminal.

[0039] User device 102 communicates with merchant system 106 via a communication network 108 such as, but not limited to, the Internet, to initiate a payment transaction processing request on behalf of user 104. The payment transaction processing request includes, but is not limited to, payment data, customer data and other data that may be used for purposes such as risk assessment of a transaction such as order information and user/customer profile details.

[0040] In some non-limiting embodiments, user device 102 is interconnected to the Internet through various interfaces such as, but not limited to, a local area network (LAN) or a wide area network (WAN), dial-in-connections, cable modems, high-speed Integrated Services Digital Network (ISDN) lines, and Reliable Data Transfer (RDT) networks. User device 102, in this case, can be any device capable of interconnecting to the Internet including a web-based phone, a smartphone, a laptop, or a personal digital assistant (PDA).

[0041] In other non-limiting embodiments, user device 102 is connected via the Internet to merchant PoS terminals through various interfaces such as, but not limited to, a LAN, a WAN, dial-in-connections, cable modems, wireless modems, and special high-speed ISDN lines.

[0042] In accordance with some embodiments, user 104 initiates the payment transaction with merchant system 106 by physically presenting a payment device to the merchant. The payment device can be, but need not be limited to, a portable payment instrument, a payment card, a credit card, a debit card, and/or the like. The payment device can include information such as, but not limited to, payment device data associated with a payment device of user 104 that may be associated with a debit account of user 104 to be used to process the payment transaction. The payment device data includes, but is not limited to, an account identifier (for example, a Permanent Account Number (PAN)), a card verification value (CVV) code, a PIN number, an expiration date, and/or the like.

[0043] In accordance with other embodiments, the payment transaction may either be a card-present transaction or a card-not-present (CNP) transaction. A CNP transaction is a transaction initiated via a merchant e-commerce website or a merchant application without physically presenting any payment device.

[0044] A card-present transaction refers to a payment transaction initiated with a payment device in which a cardholder physically presents the payment device at the time the payment transaction is initiated with the payment device. A non-limiting example of a card-present transaction is a payment transaction initiated at a brick-and- mortar retail store using a physical PoS system, during which the cardholder physically presents his payment device to the merchant or retailer.

[0045] A CNP transaction refers to a payment transaction where a cardholder initiates a payment transaction with a payment device in which the cardholder does not physically present the payment device at the time the payment transaction is initiated with the merchant. Non-limiting examples of CNP transactions include mail order and / or telephone order transactions, or transactions initiated via facsimile, over the telephone or the Internet.

[0046] System 100 includes one or more acquirer systems 110a- 11 On that are interconnected with merchant system 106 to process payments on behalf of a merchant. [0047] An acquirer system or an acquirer institution may refer to a party or an entity that is licensed and/or approved by a transaction service provider or a card network to originate payment transactions using a payment device (for example, a debit card or a credit card) associated with the transaction service provider. The payment transactions that an acquirer system may initiate include, but need not be limited to, purchases, original credit transactions (OCTs), account funding transactions (AFTs), and/or the like. In some embodiments, an acquirer institution may be a financial institution, such as a bank. An acquirer system comprises one or more computer systems, computer devices, software applications, and/or the like operated by or on behalf of an acquirer system or an acquirer institution.

[0048] A transaction service provider may refer to an entity that receives transaction requests from merchants or other entities and provides guarantees of payment, through an agreement between the transaction service provider and an issuer system. For example, a transaction service provider may include a payment network such as Visa®, or Mastercard® or any other entity that processes transactions. A transaction service provider may include one or more computer systems, and one or more transaction processing systems that are operated by or on behalf of a transaction service provider, or a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors that are operated by or on behalf of a transaction service provider.

[0049] The payment transaction processing request is transmitted by merchant system 106 to a payment gateway system 112 (or a payment aggregator).

[0050] Payment gateway system 112 or a payment aggregator refers to a party and/or a payment processing system that is operated by or on behalf of such a party. This party may be, but need not be limited to, a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like, which provides payment services such as, but not limited to, payment processing services, transaction service provider payment services and/or the like, to one or more merchants. Payment gateway system 112 includes one or more computer systems, computer devices, payment gateway servers, and/or the like operated by or on behalf of payment gateway system 112.

[0051] Upon receiving the payment transaction processing request, payment gateway system 112 forwards a transaction request to an issuer system 114, for authentication of user 104 and authorization of the payment transaction.

[0052] Issuer system 114 comprises an issuer institution that refers to one or more entities, such as a bank, that provide accounts to customers for conducting payment transactions such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a PAN, to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a payment device, such as a physical financial instrument such as, but not limited to, a payment card, and/or may be electronic payments. Issuer system 114 includes one or more computer systems operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, issuer system 114 may include one or more authorization servers for authorizing a payment transaction.

[0053] The transaction request includes a transaction authorization message containing a plurality of transaction attributes for authentication of user 104 and authorization of the payment transaction. The plurality of transaction attributes include, but need not be limited to, account data necessary to authorize a customer’s use of their payment card, and other data including, but not limited to, an account identifier and an account number associated with the payment card, a transaction amount, a merchant identifier, an acquirer identifier, a merchant category, a transaction date/time, a transaction environment, a card or customer verification, and a party accepting liability for authorizing the payment transaction.

[0054] Account data can be, but need not be limited to, data related to one or more accounts of user 104 such as, but not limited to, one or more account identifiers, user identifiers, transaction histories, balances, credit limits, issuer institution identifiers, and/or the like. An account identified may include one or more types of identifiers associated with an account of user 104 such as, but not limited to, a PAN, a primary account number, a card number, a payment card number, a token, and/or the like. In some embodiments, an issuer institution may provide an account identifier (for example, a PAN, a token, and/or the like) to user 104 that uniquely identifies one or more accounts associated with user 104.

[0055] In a typical scenario, when payment gateway system 112 initiates a transaction request to issuer system 114 for ensuring user 104 is authenticated, and if issuer system 114 fails to authorize the transaction, merchant system 106 typically stops processing the payment transaction further for payment authorization.

[0056] In this embodiment of the invention, however, when payment gateway system 112 receives a transaction authorization decline response from the issuer system with particular transaction authorization decline reason codes, a payment orchestration engine 116 analyzes the transaction authorization decline reason codes, and determines if these reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible.

[0057] In an embodiment, issuer system 114 assesses an amount of risk involved in processing the payment transaction by determining a transaction assurance level. In other embodiments, merchant system 106 communicates with issuer system 114 to determine whether user 104’s bank account is in good standing and whether the payment transaction is covered by user 104’s available credit line. Based on these determinations, the transaction request will be declined or accepted by issuer system 114. If the transaction request is declined, it indicates that issuer system 114 is not ready to take up liability for processing the payment transaction and issuer system 114 forwards a transaction authorization decline response with the authorization decline reason codes to payment gateway system 112.

[0058] Payment orchestration engine 116 analyzes the transaction authorization decline reason codes and determines if these decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible.

[0059] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is not possible, payment orchestration engine 116 drops the reattempting of the payment transaction. In this case, the decline reason codes may be indicative of insufficient funds, an invalid card and issuer system 114 blocking the payment transaction due to rules defined at issuer system 114.

[0060] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible, payment orchestration engine 116 evaluates if a risk score (or a confidence score) associated with the payment transaction is more than a predefined or a configured risk score threshold. In this case, the reason codes may be indicative of non-readiness and/or lack of capability of issuer system 114 to take the liability of authorizing the payment transaction due to a fraud related risk. [0061] The risk score threshold may be configured or defined by any approving party in system 100 such as merchant system 106 on the acquiring side, one or more acquirer systems HOa-l lOn, or the payment aggregator or payment gateway system 112. In some embodiments, system 100 determines usage of multiple risk assessment vendors based on cost effectiveness or primary and secondary relationships.

[0062] In an embodiment, the risk score is calculated by a fraud analysis system 118 (may be a third-party fraud analysis system) based on a fraud probability of the payment transaction using the transaction attributes that were collected during the original payment such as payment data, customer data, order data and customer behavior data. In another embodiment, the risk score is pre-emptively computed and checked even before attempting the transaction for the first time and before obtaining decline response codes or while payment gateway system 112 receives the payment transaction processing request from merchant system 106.

[0063] Fraud analysis system 118 calculates the risk score associated with the payment transaction using attributes, such as, but not limited to, device fingerprint and IP address of user device 102. In an embodiment, fraud analysis system 118 calculates the risk score by running details of a payment instrument against a blacklist/whitelist, and checks previous transactions connected with this payment instrument and user device 102 at that time. In another embodiment, fraud analysis system 118 identifies a distance between the IP address and the payment instrument issued country to calculate the risk score.

[0064] In yet another embodiment, fraud analysis system 118 finds the miles distance and time difference between IP addresses of two transactions from a same payment instrument (such as a last transaction on a particular day was from London but another transaction on the same day was from Australia) for computing the risk score. The risk score is also computed based on a customer's behavior on a browser such as, but not limited to, a typing speed, and characteristics of the customer account with the merchant such as, but not limited to, if the customer account is a guest account and when the payment device or payment instrument was added or when a password was changed by the customer for their account. It should be understood by persons having ordinary skill in the art that these embodiments for calculating the risk score are not limiting, as elements in such embodiments may vary and various other techniques may be employed for the calculation.

[0065] Payment orchestration engine 116 then evaluates if the computed risk score associated with the payment transaction is more than the configured risk score threshold.

[0066] In response to determining the risk score being more than the configured or predefined threshold, payment orchestration engine 116 then modifies the plurality of transaction attributes in the transaction authorization message to generate a modified transaction authorization message. The modified transaction authorization message indicates to issuer system 114 that the payment transaction is to be re-attempted with issuer system 114, and that the liability of chargeback for the payment transaction has been shifted to one or more acquirer systems 1 lOa-110h. Payment orchestration engine 116 assesses re-attempt of the payment transaction based on the plurality of transaction attributes that have been modified which include information such as, but not limited to, a card type (such as credit, debit, corporate, gift and prepaid card) and a transaction type (such as one time, mail order telephone order, recurring or installment transactions). In an embodiment, if one acquirer system is not ready to take the transaction risk and liability, another acquirer system in the backend takes the liability of chargeback for the payment transaction. [0067] Upon receiving the modified transaction authorization message, issuer system 114 transmits a transaction approval message in a transaction authorization response, authorizing the payment transaction. Merchant system 106 transmits a transaction authorization success message for display at a web browser of an e-commerce platform or a PoS terminal.

[0068] FIG. 2 illustrates various modules of payment orchestration engine 116 for reprocessing a previously failed payment transaction in accordance with an embodiment of the invention.

[0069] As illustrated in FIG. 2, payment orchestration engine 116 comprises a memory 202 and a processor 204 communicatively coupled to memory 202. Memory 202 and processor 204 further communicate with various modules of payment orchestration engine 116 via a communication module 206.

[0070] Communication module 206 may be configured to transmit data between modules, engines, databases, memories, and other components of payment orchestration engine 116 for use in performing functions discussed herein. Communication module 206 may include one or more communication types and utilizes various communication methods for communication within payment orchestration engine 116.

[0071] Payment orchestration is about deciding how best to route a payment from checkout through to bank settlement, increasing the payment conversion and therefore making more money for merchants. In accordance with various embodiments, payment orchestration engine 116 performs payment orchestration by utilizing one or more middleware payment technology companies who connect to multiple payment service providers (PSPs), fraud technology, acquirers and banks. Payment orchestration engine 116 facilitates merchants to connect to multiple acquirers dynamically while being protected from fraud.

[0072] Payment orchestration engine 116 enables payment orchestration by utilizing functionalities that can be, but need not be limited to, dynamic transaction routing, Application Programming Interface (API), advanced analytics and reporting, and risk management. The functionalities that are utilized by payment orchestration engine 116 are consolidated into a single-layered architecture.

[0073] Referring to FIG. 2, payment orchestration engine 116 includes a response code analyzer module 208 for analyzing transaction authorization decline reason codes that are received in a transaction authorization message from issuer system 114.

[0074] Payment orchestration engine 116 further includes a transaction re-attempt assessment module 210 which determines if the transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible.

[0075] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is not possible, payment orchestration engine 116 drops the reprocessing of the payment transaction for further approval or authorization. In this case, the reason codes may be indicative of insufficient funds in the account associated with the card, card blocked due to rules on issuer system 114 (such as card not enabled for online transactions or international transactions). [0076] In response to determining one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible, payment orchestration engine 116 includes a risk score evaluation module 212 that evaluates if a risk score (or a confidence score) associated with the payment transaction is more than a predefined or a configured risk score threshold. In this case, the reason codes may be indicative of non-readiness and/or lack of capability of issuer system 114 to take the liability of authorizing the payment transaction due to a fraud related risk.

[0077] The risk score threshold may be configured or defined by any approving party such as merchant system 106 on the acquiring side, one or more acquirer systems 110a- 110h, or the payment aggregator/payment gateway system 112. In some embodiments, usage of multiple risk assessment vendors is determined based on cost effectiveness or primary and secondary relationships.

[0078] In an embodiment, the risk score is calculated by fraud analysis system 118 (may be a third-party fraud analysis system) based on a fraud probability of the payment transaction using the transaction attributes that were collected during the original payment such as payment data, customer data, order data and customer behavior data. In another embodiment, the risk score is pre-emptively computed while payment gateway system 112 receives the payment transaction processing request from merchant system 106.

[0079] Payment orchestration engine 116 further includes a liability shift tracking module 214 which identifies parties ready to take liability of authorizing the payment transaction based on information received from risk score evaluation module 212. In this case, liability shift tracking module 214 checks if the control system settings of one or more acquirer systems 1 lOa-110h have the configuration enabled where one or more acquirer systems 1 lOa-110h are ready to take the liability of the payment transaction if fraud analysis system 118 approves a payment transaction.

[0080] If this setting is configured as ‘Yes’, liability shift tracking module 214 determines that one or more acquirer systems 1 lOa-110h are ready to check with fraud analysis system 118 and re-attempt the payment transaction by taking liability of that transaction in case of a chargeback.

[0081] Payment orchestration engine 116 includes an authorization message modification module 216 which modifies the plurality of transaction attributes in the transaction authorization message to generate a modified transaction authorization message in response to determining the risk score being more than the configured or predefined threshold. The modified transaction authorization message indicates to issuer system 114 that the payment transaction is to be re-attempted with issuer system 114, and that the liability of chargeback for the payment transaction has been shifted to one or more acquirer systems llOa-llOn. Transaction re-attempt assessment module 210 assesses re-attempt of the payment transaction based on the plurality of transaction attributes that have been modified.

[0082] FIG. 3 illustrates a process flow diagram depicting a payment transaction flow for reprocessing a previously failed payment transaction in accordance with an exemplary embodiment of the invention.

[0083] In this particular embodiment, the technical capability of payment orchestration engine 116 is built into a payment gateway system.

[0084] As illustrated in FIG. 3, in this setup, a customer enters their card details on a merchant’s page on a browser or their application via a user device 302. Steps T1-T17 are described in conjunction with different components of FIG. 3 as follows. [0085] At step Tl, a payment transaction processing request is initiated along with payment data from user device 302 to a merchant system 304. At step T2, merchant system 304 sends the payment request along with the payment data to a payment gateway system 306.

[0086] At step T3, payment gateway system 306 attempts the payment with a card network 308 by forwarding an authorization request to card network 308 without performing a fraud analysis. The authorization request includes data elements or transaction attributes indicating that an issuer system 310 is to take liability for the payment transaction after a primary authentication (Auth 1) of the customer using the information received in the payment transaction processing request. At step T4, the authorization request is then transmitted from card network 308 to issuer system 310. In this case, payment gateway system 306 expects issuer system 310 to process the transaction and take liability of the payment transaction by sending an authorization message with appropriate data elements populated in the authorization request.

[0087] Assume that issuer system 310 declines the payment transaction and at step T5, issuer system 310 transmits a decline response message to card network 308 and at step T6, card network 308 forwards the decline response message to payment gateway system 306. The decline response message from issuer system 310 includes one or more decline reason codes which indicate reasons for issuer system 310 to decline the payment transaction. These decline reason codes in the response from issuer system 310 makes payment gateway system 306 understand that issuer system 310 rejected the transaction due to fraud considerations where issuer system 310 is not comfortable in taking the liability of that payment transaction. [0088] The decline reason codes from issuer system 310 are analyzed by payment gateway system 306. If the decline reason codes belong to a reason for which a transaction re-attempt is not possible, the payment transaction is dropped from being re-attempted. These reason codes include, but need not be limited to, insufficient funds, invalid card or issuer system 310 blocking the transactions for a valid reason or based on rules defined on issuer system 310.

[0089] If the decline reason codes belong to the reason where the transaction re-attempt is possible, at step T7, payment gateway system 306 sends a message to an acquirer system 312 to check if control system settings of acquirer system 312 have the configuration enabled where acquirer system 312 is fine to take the liability of a transaction if a third-party fraud analysis system 314 approves the payment transaction.

[0090] If this setting is configured as ‘Yes’, this means acquirer system 312 is ready to check with fraud analysis system 314 and re-attempt the payment transaction by taking liability of that transaction in case of a chargeback.

[0091] At step T8, acquirer system 312 responds with a message that acquirer system 312 is ready to take liability if fraud analysis system 314 approves the payment transaction.

[0092] At step T9, payment gateway system 306 sends a request to fraud analysis system 314 with the customer data, payment data and other information for enabling fraud analysis system 314 to perform a fraud analysis or risk assessment of the payment transaction. [0093] Assume that fraud analysis system 314, at step T10, responds with an approval by sending a message to payment gateway system 306 approving the payment transaction.

[0094] At step Til, payment gateway system 306 modifies data elements or transaction attributes of the authorization message (Auth 2) to indicate that the transaction can be re-attempted by issuer system 310, highlighting to issuer system 310 that acquirer system 312 is taking the liability of the transaction.

[0095] At step T12, payment gateway system 306 sends the modified authorization message to card network 308. At step T13, card network 308 sends the modified authorization message to issuer system 310.

[0096] The expectation is that in many cases, since issuer system 310 is not taking the liability of a transaction anymore, issuer system 310 will be approving that transaction, thus enhancing the approval rate for merchants when they process their payments using payment gateway system 306 that provides this orchestration and data enhancement of the authorization message.

[0097] Upon receiving the modified authorization message, at step T14, issuer system 310 approves the transaction and sends a transaction approval message in an authorization response to card network 308, which in turn transmits the authorization response to payment gateway system 306 at step T15.

[0098] At step T16, payment gateway system 306 transmits the authorization response to merchant system 304 which, at step T17, transfers a success message indicating that the transaction authorization was successful, for display at a web browser of user device 302 or a PoS terminal. [0099] FIG. 4 illustrates a flowchart of a method 400 for reprocessing a previously failed payment transaction using payment orchestration engine 116 of system 100 in accordance with an embodiment of the invention.

[00100] As illustrated in FIG. 4, at step 402, merchant system 106 receives a payment transaction processing request from user device 102 associated with a payment transaction. In an embodiment, the payment transaction processing request is initiated by a customer at an e-commerce platform or a PoS terminal associated with merchant system 106. The payment transaction processing request includes, but is not limited to, payment data, customer data and other data that may be used for purposes such as risk assessment of a transaction such as order information and customer profile details to authenticate the customer.

[00101] At step 404, the payment transaction processing request is transmitted by merchant system 106 to payment gateway system 112 or a payment aggregator.

[00102] Upon receiving the payment transaction processing request, at step 406, payment gateway system 112 forwards a transaction request to issuer system 114, for authentication of the customer and authorization of the payment transaction. The transaction request includes a transaction authorization message containing a plurality of transaction attributes for authentication of the customer and authorization of the payment transaction. The plurality of transaction attributes include, but need not be limited to, account data necessary to authorize the customer’s use of their payment card, and other data including, but not limited to, an account identifier and an account number associated with the payment card, a transaction amount, a merchant identifier, an acquirer identifier, a merchant category, a transaction date/time, a transaction environment, a card or customer verification, and a party accepting liability for authorizing the payment transaction.

[00103] At step 408, payment gateway system 112 receives a transaction authorization decline response from issuer system 114 with particular transaction authorization decline reason codes.

[00104] At step 410, payment orchestration engine 116 analyzes the transaction authorization decline reason codes, and at step 412, payment orchestration engine 116 determines if these reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible.

[00105] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is not possible, at step 414, payment orchestration engine 116 drops re attempting of the payment transaction. In this case, the reason codes may be indicative of insufficient funds, an invalid card and issuer system 114 blocking the payment transaction due to rules defined at issuer system 114.

[00106] In response to determining the one or more transaction authorization decline reason codes are indicative of a reason for which a re-attempt of the payment transaction is possible, at step 416, payment orchestration engine 116 evaluates if a risk score (or a confidence score) associated with the payment transaction is more than a predefined or a configured risk score threshold. In this case, the reason codes may be indicative of non-readiness and/or lack of capability of issuer system 114 to take the liability of authorizing the payment transaction due to a fraud related risk. [00107] The risk score threshold may be configured or defined by any approving party in system 100 such as merchant system 106 on the acquiring side, acquirer systems HOa-l lOn or the payment aggregator/payment gateway system 112. In an embodiment, the risk score is calculated by fraud analysis system 118 (which may be a third-party fraud analysis system) based on a fraud probability of the payment transaction using the transaction attributes that were collected during the original payment such as payment data, customer data, order data and customer behavior data. In another embodiment, the risk score is pre-emptively computed and checked even before attempting the payment transaction for the first time and prior to getting a reason code back, or while payment gateway system 112 receives the payment transaction processing request from merchant system 106.

[00108] At step 418, payment orchestration engine 116 modifies the plurality of transaction attributes in the transaction authorization message to generate the modified transaction authorization message, in response to determining the risk score being more than the configured or predefined threshold. The modified transaction authorization message indicates to issuer system 114 that the payment transaction is to be re attempted with issuer system 114, and that the liability of chargeback for the payment transaction has been shifted to one or more acquirer systems HOa-l lOn. Payment orchestration engine 116 assesses re-attempt of the payment transaction based on the plurality of transaction attributes that have been modified. The plurality of transaction attributes include information such as, but not limited to, a card type (such as credit, debit, corporate, gift and prepaid card) and a transaction type (such as one time, mail order telephone order, recurring or installment transactions).

[00109] In an embodiment, if one acquirer system is not ready to take the liability of the payment system, another acquirer system takes the liability of chargeback for the payment transaction. [00110] Upon receiving the modified transaction authorization message, issuer system 114 transmits a transaction approval message in a transaction authorization response, authorizing the payment transaction. Merchant system 106 then transmits a transaction authorization success message for display at a web browser of either the e- commerce platform or the PoS terminal.

[00111] The present invention is advantageous in that it enables a technical system or a payment gateway system to build the capability of receiving the reason of a transaction decline from a network/issuer system and build technical capabilities to modify an authorization message with data elements that allows the issuer system know that an acquirer system is open to take liability of that transaction.

[00112] If the issuer system is not ready to take the liability, the invention enables the acquirer system to use an external fraud prevention and analysis system to evaluate the transaction and send it for processing automatically with liability shift to an acquirer. This flow is built dynamically where evaluation of a transaction is done at run-time of a transaction and a decision is made to re-attempt the same authorization with modified data elements to potentially receive an approval.

[00113] Those skilled in the art will realize that the above recognized advantages and other advantages described herein are merely exemplary and are not meant to be a complete rendering of all of the advantages of the various embodiments of the present invention.

[00114] The system, as described in the invention or any of its components may be embodied in the form of a computing device. The computing device can be, for example, but not limited to, a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices, which are capable of implementing the steps that constitute the method of the invention. The computing device includes a processor, a memory, a nonvolatile data storage, a display, and a user interface.

[00115] In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.