Abstract: A method includes providing a brand-agnostic installment facility on transactions by way of transaction cards. A processing server receives authorization requests corresponding to the transactions from corresponding payment networks. The processing server translates the authorization requests to a format readable by an installment management server. The installment management server checks whether the transactions are eligible for the installment facility and generates installment plans when the transactions are determined to be eligible. The installment management server populates the authorization requests with the corresponding installment plans and communicates the populated authorization requests to the processing server. The processing server retranslates the populated authorization requests to their previous format for transmitting to corresponding issuers for approval of the installment plans. The approved installment plans are presented to customers, thereby enabling the customers to avail the installment facility on the corresponding transactions irrespective of card brands of their transaction cards.
Claims:1. A method for providing an installment facility on transactions, the method comprising:
receiving, by a processing server, a plurality of authorization requests from a plurality of payment networks, wherein a first authorization request of the plurality of authorization requests corresponds to a first transaction initiated by a customer at a terminal device, and wherein the first authorization request includes a first data element and is in a first format associated with a first payment network of the plurality of payment networks;
translating, by the processing server, the first authorization request to a second format readable by an installment management server, wherein the installment management server populates the first data element with one or more installment plans;
retranslating, by the processing server, the first authorization request to the first format for communicating to an issuer associated with the first transaction; and
transmitting, by the processing server, an authorization response including the one or more installment plans to the first payment network, when the first transaction is authorized and determined to be eligible for the installment facility by the issuer based on the first authorization request, wherein the one or more installment plans are presented to the customer for selection by way of a user interface rendered on the terminal device, thereby enabling the customer to avail the installment facility on the first transaction.
2. The method of claim 1, wherein the first authorization request further includes a second data element for storing a device capability indicator that indicates whether the terminal device is capable of presenting the one or more installment plans to the customer.
3. The method of claim 2, further comprising:
generating, by the processing server, a header that is indicative of the first payment network for the first authorization request, when the device capability indicator indicates that the terminal device is capable of presenting the one or more installment plans to the customer.
4. The method of claim 3, further comprising:
inserting, by the processing server, the header in the first authorization request.
5. The method of claim 4, further comprising:
identifying, by the processing server based on the header, the first format from a plurality of formats associated with the plurality of payment networks, respectively, for translating the first authorization request.
6. The method of any of claims 1 to 5, wherein the first authorization request further includes one or more additional data elements for storing at least a card number of a transaction card used for initiating the first transaction, a transaction amount of the first transaction, a time-stamp of the first transaction, and a merchant category code of a merchant associated with the terminal device.
7. The method of any of claims 1 to 6, wherein each installment plan of the one or more installment plans is indicative of a duration of the corresponding installment plan, a count of installments in the installment plan, an installment amount per installment, or a rate of interest charged to the customer for selecting the corresponding installment plan for the first transaction.
8. The method of any of claims 1 to 7, further comprising:
transmitting, by the processing server, the first authorization request to the issuer after retranslation, wherein the issuer authorizes the first transaction and determines whether the first transaction is eligible for the installment facility based on the first authorization request.
9. The method of any of claims 1 to 8, further comprising:
receiving, by the processing server, the authorization response from the issuer in response to the first authorization request, wherein the authorization response indicates whether the first transaction is authorized and is eligible for the installment facility.
10. The method of any of claims 1 to 9, further comprising:
receiving, by the processing server from the first payment network, a selection corresponding to a first installment plan of the one or more installment plans selected by the customer, wherein the first transaction is processed based on the selected first installment plan.
11. A system for providing an installment facility on transactions, the system comprising:
a processing server configured to:
receive a plurality of authorization requests from a plurality of payment networks, wherein a first authorization request of the plurality of authorization requests corresponds to a first transaction initiated by a customer at a terminal device, and wherein the first authorization request includes a first data element and is in a first format associated with a first payment network of the plurality of payment networks;
translate the first authorization request to a second format readable by an installment management server, wherein the installment management server populates the first data element with one or more installment plans;
retranslate the first authorization request to the first format for communicating to an issuer associated with the first transaction; and
transmit an authorization response including the one or more installment plans to the first payment network, when the first transaction is authorized and determined to be eligible for the installment facility by the issuer based on the first authorization request, wherein the one or more installment plans are presented to the customer for selection by way of a user interface rendered on the terminal device, thereby enabling the customer to avail the installment facility on the first transaction.
12. The system of claim 11, wherein the first authorization request further includes a second data element for storing a device capability indicator that indicates whether the terminal device is capable of presenting the one or more installment plans to the customer.
13. The system of claim 12, wherein the processing server is further configured to:
generate a header that is indicative of the first payment network for the first authorization request, when the device capability indicator indicates that the terminal device is capable of presenting the one or more installment plans to the customer.
14. The system of claim 13, wherein the processing server is further configured to:
insert the header in the first authorization request.
15. The system of claim 14, wherein the processing server is further configured to:
identify, based on the header, the first format from a plurality of formats associated with the plurality of payment networks, respectively, for translating the first authorization request.
16. The system of any of claims 11 to 15, wherein the first authorization request further includes one or more additional data elements for storing at least a card number of a transaction card used for initiating the first transaction, a transaction amount of the first transaction, a time-stamp of the first transaction, and a merchant category code of a merchant associated with the terminal device.
17. The system of any of claims 11 to 16, wherein each installment plan of the one or more installment plans is indicative of a duration of the corresponding installment plan, a count of installments in the installment plan, an installment amount per installment, or a rate of interest charged to the customer for selecting the corresponding installment plan for the first transaction.
18. The system of any of claims 11 to 17, wherein the processing server is further configured to:
transmit the first authorization request to the issuer after retranslation, and wherein the issuer authorizes the first transaction and determines whether the first transaction is eligible for the installment facility based on the first authorization request.
19. The system of any of claims 11 to 18, wherein the processing server is further configured to:
receive the authorization response from the issuer in response to the first authorization request, and wherein the authorization response indicates whether the first transaction is authorized and is eligible for the installment facility.
20. The system of any of claims 11 to 19, wherein the processing server is further configured to:
receive, from the first payment network, a selection corresponding to a first installment plan of the one or more installment plans selected by the customer, and wherein the first transaction is processed based on the selected first installment plan.
, Description:METHOD AND SYSTEM FOR PROVIDING INSTALLMENT FACILITY ON ELECTRONIC TRANSACTIONS
BACKGROUND
FIELD OF THE INVENTION
The present invention relates to a method and a system for processing electronic transactions, and, more particularly to a method and a system for providing a brand-agnostic installment facility on electronic transactions.
DESCRIPTION OF THE RELATED ART
Traditionally, a customer who makes a purchase from a merchant is required to pay the merchant in full at the time of purchase. This limits purchase capacity of the customer, as the customer can only make the purchase for an amount she has or is willing to spend. However, technological advancements have led to emergence and evolution of transaction systems that allow customers to avail an installment facility for making purchases, thereby increasing the purchase capacity of the customers. Such an installment facility enables the customers to pay for their purchases in installments, rather than paying in full. Since installments spread out a large purchase over a time period, a customer who has insufficient funds at the time of purchase is able to make the purchase by paying for it in installments. Installments are not only beneficial for the customers but also for merchants, as the sales at the merchants are increased due to the increased purchase capacities of the customers.
Usually, such an installment facility is offered by financial institutions that have sophisticated computing systems capable of handling complex payment schemes. While the computing systems used by the financial institutions largely accommodate installment transactions, they are capable of providing the installment facility on transactions initiated by transaction cards of select card brands, for example Mastercard®. In such a scenario, transactions that are initiated by transaction cards of any other card brand, such as JCB®, China UnionPay®, Discover®, or Diners Club®, are not entitled to the installment facility, thereby causing inconvenience to the customers who do not possess the transaction cards of the select card brands. Further, the transaction cards issued by a financial institution are not limited to the select card brands that are entitled to the installment facility. The financial institution also issues transaction cards of other card brands that do not offer the installment facility. Generally, the demand of such card brands is less among the customers, which is a cause of concern for the financial institution.
In light of the foregoing, there exists a need for a solution that enables a financial institution to make installment facility brand agnostic, i.e., to extend the installment facility to all transaction cards irrespective of their card brands.
SUMMARY
In an embodiment of the present invention, a method for providing an installment facility on transactions is provided. The method includes receiving, by a processing server, a plurality of authorization requests from a plurality of payment networks. A first authorization request of the plurality of authorization requests corresponds to a first transaction initiated by a customer at a terminal device. The first authorization request includes a first data element and is in a first format associated with a first payment network of the plurality of payment networks. The first authorization request is translated to a second format readable by an installment management server by the processing server. The installment management server populates the first data element with one or more installment plans. The first authorization request is retranslated to the first format by the processing server for communicating to an issuer associated with the first transaction. An authorization response including the one or more installment plans is transmitted to the first payment network by the processing server, when the first transaction is authorized and determined to be eligible for the installment facility by the issuer based on the first authorization request. The one or more installment plans are presented to the customer for selection by way of a user interface rendered on the terminal device, thereby enabling the customer to avail the installment facility on the first transaction.
In another embodiment of the present invention, a system for providing an installment facility on transactions is provided. The system includes a processing server that is configured to receive a plurality of authorization requests from a plurality of payment networks. A first authorization request of the plurality of authorization requests corresponds to a first transaction initiated by a customer at a terminal device. The first authorization request includes a first data element and is in a first format associated with a first payment network of the plurality of payment networks. The processing server translates the first authorization request to a second format readable by an installment management server. The installment management server populates the first data element with one or more installment plans. The processing server retranslates the first authorization request to the first format for communicating to an issuer associated with the first transaction. The processing server transmits an authorization response including the one or more installment plans to the first payment network, when the first transaction is authorized and determined to be eligible for the installment facility by the issuer based on the first authorization request. The one or more installment plans are presented to the customer for selection by way of a user interface rendered on the terminal device, thereby enabling the customer to avail the installment facility on the first transaction.
BRIEF DESCRIPTION OF DRAWINGS
Various embodiments of the present invention are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements, and in which:
FIG. 1 is a block diagram that illustrates an exemplary environment in which various embodiments of the present invention are practiced;
FIG. 2 is a block diagram that illustrates an exemplary scenario for providing a brand-agnostic installment facility, in accordance with an embodiment of the present invention;
FIGS. 3A and 3B are block diagrams that illustrate an exemplary user interface for presenting installment plans to customers, in accordance with an embodiment of the present invention;
FIGS. 4A-4C, collectively represent a process flow diagram that illustrates an exemplary scenario for providing a brand-agnostic installment facility on a transaction initiated by a customer, in accordance with an embodiment of the present invention;
FIG. 5 is a block diagram that illustrates a processing server of FIG. 1, in accordance with an embodiment of the present invention;
FIG. 6 is a block diagram that illustrates an installment management server of FIG. 1, in accordance with another embodiment of the present invention;
FIG. 7 is a block diagram that illustrates an issuer server of FIG. 1, in accordance with an embodiment of the present invention;
FIGS. 8A and 8B, collectively represent a flow chart that illustrates a method for providing a brand-agnostic installment facility on transactions, in accordance with an embodiment of the present invention;
FIG. 9 represents a high-level flow chart that illustrates a method for providing a brand-agnostic installment facility on transactions, in accordance with an embodiment of the present invention; and
FIG. 10 is a block diagram that illustrates system architecture of a computer system, in accordance with an embodiment of the present invention.
Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments is intended for illustration purposes only and is, therefore, not intended to necessarily limit the scope of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS
The present invention is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
References to “an embodiment”, “another embodiment”, “yet another embodiment”, “one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
Installment facility is usually offered on transactions that are initiated by using transaction cards of select card brands. Thus, customers who possess transaction cards of these select card brands are presented with various installment plans that are applicable on their transactions. However, customers who possess transaction cards of card brands that do not offer the installment facility are unable to avail the installment facility on their transactions, which is very inconvenient for such customers. Further, it may affect the business of financial institutions that issue transaction cards of the card brands that do not offer the installment facility, as the demand of such card brands among the customers is less as compared to the select card brands offering the installment facility.
Various embodiments of the present invention provide a method and a system that solve the abovementioned problems by providing a brand-agnostic installment facility on transactions. Customers initiate transactions at various terminal devices by way of their transaction cards for making purchases from merchants. Generally, the transaction cards used for initiating the transactions have different card brands affiliated to different payment networks (e.g., Mastercard, Diners Club, JCB, or the like). In one example, a debit card used for initiating a first transaction corresponds to a first payment network and a credit card used for initiating a second transaction corresponds to a second payment network. Payment network servers of these payment networks transmit authorization requests for the corresponding transactions to a processing server serving as a gateway. For example, a first payment network server of the first payment network transmits a first authorization request for the first transaction and a second payment network server of the second payment network transmits a second authorization request for the second transaction, to the processing server. Each authorization request has a specific format associated with the corresponding payment network. For each authorization request, the processing server identifies the corresponding payment network. The processing server further translates each authorization request to a default format readable by an installment management server and communicates the authorization requests having the default format to the installment management server. Based on each authorization request, the installment management server generates installment plans. The installment management server then populates the authorization requests with the corresponding installment plans and transmits the populated authorization requests to the processing server. The processing server retranslates the authorization requests from the default format to their previous formats and transmits them to a corresponding issuer for authorization and approval of the installment plans. When the transactions are authorized and the corresponding installment plans are approved, the customers are presented with the corresponding approved installment plans at the terminal devices. Thus, the customers are presented with the installment plans irrespective of the card brands of their transactions cards, thereby making the installment facility brand agnostic. The customers may select any installment plan for their transactions, and the transactions are further processed based on the selected installment plan.
Thus, the method and system of the present invention offer advantages to both the customers and issuers. Since, the processing server receives authorization requests initiated by transaction cards of various card brands and translates them to a format readable by the installment management server, the card brands no longer pose a limitation for offering the installment facility to the customers. Thus, an issuer is able to provide the installment facility to the customers possessing transaction cards of all card brands that the issuer issues.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
Installment facility is an offer provided to a customer that allows the customer to pay for a purchase in installments, rather than paying in full outrightly. The provision of the installment facility allows the customer to spread out a large purchase over a period of time, thereby allowing the customer to make the purchase despite having insufficient funds at the time of purchase.
A processing server is a gateway for receiving authorization requests of various transactions from corresponding payment networks. The processing server also serves as a translator for translating the authorization requests to a format readable by an installment management server that processes the authorization requests for offering a brand-agnostic installment facility.
An authorization request for a transaction refers to a request by which an acquirer ensures that the transaction is valid and authorized by a corresponding issuer. The acquirer communicates the authorization request to the issuer for authorization. The authorization request is pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard, and includes various fields, such as data elements (DEs), for storing transaction details of the transaction.
An authorization response is a response generated by an issuer for an authorization request corresponding to a transaction. The issuer generates the authorization response to indicate whether the transaction is authorized, and whether the transaction is eligible for an installment facility. The authorization response is pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard, and includes various data fields, such as data elements (DEs), for storing transaction details of the transaction.
A payment network is a transaction card association that acts as an intermediate entity between acquirers and issuers for processing transactions. Examples of payment networks include Mastercard, JCB, Diners Club, or the like. Processing by a payment network includes steps of authorization, clearing, and settlement.
Terminal device is a device installed at a merchant store by an acquirer for allowing customers to initiate transactions for their purchases. Examples of the terminal device include, but are not limited to, a point-of-sale (POS) device, a point-of-purchase (POP) device, and a point-of-interaction (POI) device.
[0001] An installment management server processes a transaction for offering installment facility and generates installment plans for the transaction, when the transaction is eligible for availing the installment facility.
Installment plan indicates an arrangement of payment via a series of installments. An installment plan includes an installment amount per installment, a count of installments in the installment plan, a duration of the installment plan, and a rate of interest charged to a customer for availing the installment plan.
User interface (UI) is a graphical interface that includes windows, icons, text boxes, and/or other interactive features to receive inputs from customers, provide information, or display output to customers. The UI presents various installment plans to the customers and enables the customers to select an installment plan of their choice.
Issuer is a financial institution, where customer accounts of several customers are established and maintained. The issuer ensures payment for authorized transactions in accordance with various payment network regulations and local legislation.
Server is a physical or cloud data processing system on which a server program runs. The server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server may be implemented in computer programs executing on programmable computers, such as personal computers, laptops, or a network of computer systems. The server may correspond to one of a payment network server, an issuer server, an acquirer server, a processing server, or a merchant server.
FIG. 1 is a block diagram that illustrates an exemplary environment 100 in which various embodiments of the present invention are practiced. The environment 100 includes first and second customers 102a and 102b (collectively referred to as “customers 102”) in possession of first and second transaction cards 104a and 104b (collectively referred to as “transaction cards 104”), respectively. The environment 100 further includes first and second customer devices 106a and 106b (collectively referred to as “customer devices 106”) of the first and second customers 102a and 102b, respectively. The environment 100 further includes first and second merchant terminal devices 108a and 108b (collectively referred to as “merchant terminal devices 108”), a merchant server 110, an acquirer server 112, first and second payment network servers 114a and 114b (collectively referred to as “payment network servers 114”), a processing server 116, an installment management server 118, and an issuer server 120. The customer devices 106, the merchant terminal devices 108, the merchant server 110, the acquirer server 112, the payment network servers 114, the processing server 116, the installment management server 118, and the issuer server 120 communicate with each other by way of a communication network 122 or through separate communication networks established therebetween.
The first customer 102a is an individual, who is an account holder of a first customer account maintained at a financial institution, such as an issuer. The first customer account is linked to a mobile number and an electronic mail (e-mail) ID of the first customer 102a, as part of a customer registration procedure performed by the issuer. The first customer 102a is entitled to perform electronic transactions (hereinafter referred to as “transactions”) from the first customer account. Similarly, the second customer 102b is an account holder of a second customer account maintained at the issuer and is entitled to perform transactions from the second customer account. For the sake of ongoing description, it is assumed that the first and second customer accounts are maintained with the same issuer. However, in one scenario, the first and second customer accounts may be maintained with different issuers without deviating from the scope of the invention.
The first transaction card 104a is a payment means linked to the first customer account and stores information (hereinafter referred to as “account information”) of the first customer account. The account information of the first customer account may be stored in an electronic chip or a machine-readable magnetic strip embedded in the first transaction card 104a. The account information may include an account number, a name of an account holder, and the like. The first transaction card 104a has a unique card number, an expiry date, a card security code, a card type, and a first card brand associated to it. The card number, the expiry date, the card security code, the card type, and the first card brand constitute transaction card details of the first transaction card 104a. Generally, a card brand is indicative of a payment network associated with a transaction card. For example, the first card brand indicates that the first transaction card 104a is associated with a first payment network. The first customer 102a may perform various transactions from the first customer account by using the first transaction card 104a. In one embodiment, the first transaction card 104a is a physical card. In another embodiment, the first transaction card 104a is a virtual card that is stored in a memory (not shown) of the first customer device 106a. Examples of the first transaction card 104a include a credit card, a debit card, a charge card, a prepaid card, a gift card, an electronic cash card, or the like. Likewise, the second transaction card 104b is linked to the second customer account and store account information of the second customer account. Further, the second transaction card 104b is associated with a second card brand. The second card brand may be similar to the first card brand or different from the first card brand. Examples of the first and second card brands include, but are not limited to, Mastercard, JCB, Discover, or Diners Club. For the sake of ongoing description, it is assumed that the second card brand is different from the first card brand and associated with a second payment network. The second customer 102b may perform various transactions from the second customer account by using the second transaction card 104b. It will be apparent to a person skilled in the art that the second transaction card 104b is functionally similar to the first transaction card 104a.
The first customer device 106a is a communication device of the first customer 102a. Examples of the first customer device 106a include, but are not limited to, a mobile phone, a smartphone, a laptop, a tablet, a phablet, or any other communication device. The first customer device 106a is linked to the mobile number and the e-mail ID of the first customer 102a. In one embodiment, the first customer 102a may access an application (for example, a mobile application or a web application) by way of the first customer device 106a to perform various online transactions from the first customer account. In one example, the application is a net-banking application. In another example, the application is an e-commerce application. Likewise, the second customer device 106b is a communication device of the second customer 102b. The second customer device 106b is linked to the mobile number and the e-mail ID of the second customer 102b. It will be apparent to a person skilled in the art that the second customer device 106b is functionally similar to the first customer device 106a.
The first merchant terminal device 108a is an electronic device that enables the customers 102 to perform various transactions from their customer accounts by using the corresponding transaction cards 104. The first merchant terminal device 108a is installed by an acquirer at a merchant store of a first merchant (not shown). Examples of the first merchant terminal device 108a include, but are not limited to, a POS device, a POP device, and a POI device. In a non-limiting example, the first merchant terminal device 108a is assumed to be a first POS device 108a. When a transaction card (e.g., the first or second transaction card 104a or 104b) is used at the first POS device 108a to initiate a transaction, the first POS device 108a transmits transaction details of the transaction to the merchant server 110 in an encrypted format. The transaction details may include the account information of the corresponding customer account, the transaction card details of the corresponding transaction card, a transaction amount of the transaction, a time-stamp of the transaction, an identification code of the first POS device 108a, a currency code, a merchant category code (MCC) of the first merchant, an acquirer code, and the like. The first POS device 108a is further capable of rendering a user-interface (UI) (shown in FIGS. 3A and 3B) for presenting installment plans that are applicable on the transactions performed at the first POS device 108a. In one embodiment, a device capability indicator, which indicates whether the first POS device 108a is capable of rendering the UI, is included in the transaction details. It will be apparent to a person skilled in the art that the second merchant terminal device 108b (hereinafter referred to as “second POS device 108b”) is functionally similar to the first POS device 108a and installed at the merchant store of the first merchant by the acquirer.
The merchant server 110 is a computing server that is associated with the first merchant. The first merchant may have established a merchant account with the acquirer to accept payments for products and/or services purchased and/or availed by the customers 102 from the first merchant. The merchant server 110 processes the transactions that are initiated by the customers 102 at the first and second POS devices 108a and 108b. The merchant server 110 receives the encrypted transaction details of the transactions initiated at the first and second POS devices 108a and 108b, and transmits the encrypted transaction details to the acquirer server 112.
The acquirer server 112 is a computing server that is associated with the acquirer. The acquirer server 112 receives the encrypted transaction details of the transactions initiated at the first and second POS devices 108a and 108b. In one embodiment, the acquirer server 112 may receive the encrypted transaction details directly from the first and second POS devices 108a and 108b. In another embodiment, the acquirer server 112 may receive the encrypted transaction details from the merchant server 110. In a scenario where a transaction is initiated by using a transaction card (for example, the first or second transaction card 104a or 104b), the acquirer server 112 identifies a payment network associated with the transaction. For example, when the transaction is initiated by using the first transaction card 104a, the acquirer server 112 identifies that the first payment network of the first transaction card 104a is associated with the transaction. The acquirer server 112 further generates an authorization request for the transaction and transmits the authorization request to a payment network server (e.g., the first or second payment network server 114a or 114b) of the identified payment network. Each authorization request generated by the acquirer server 112 has a specific format that is associated with the corresponding payment network and pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard. For example, the first and second payment networks may be associated with first and second formats, respectively. Thus, the acquirer server 112 generates authorization requests having the first format for transactions that correspond to the first payment network and authorization requests having the second format for transactions that correspond to the second payment network.
The first payment network server 114a is a computing server associated with the first payment network. The first payment network server 114a is an intermediate entity between the acquirer server 112 and the issuer server 120 for processing the transactions performed by using transaction cards (e.g., the first transaction card 104a) having the first card brand. Similarly, the second payment network server 114b is a computing server associated with the second payment network. The second payment network server 114b is an intermediate entity between the acquirer server 112 and the issuer server 120 for processing the transactions performed by using transaction cards (e.g., the second transaction card 104b) having the second card brand. The payment network servers 114 receive authorization requests from the acquirer server 112 and transmit the authorization requests to the processing server 116.
The processing server 116 is a computing server that receives the authorization requests from the payment network servers 114. In other words, the processing server 116 serves as a gateway for receiving the authorization requests from the payment network servers 114. The processing server 116 identifies a payment network that corresponds to an authorization request and then identifies a specific format of the identified payment network. The processing server 116 translates the authorization request to a default format readable by the installment management server 118 and transmits the translated authorization request to the installment management server 118. When the processing server 116 receives the authorization request populated with installment plans from the installment management server 118, the processing server 116 retranslates the authorization request to its previous format for communicating to the issuer server 120. In other words, the processing server 116 serves as a translator for the installment management server 118. In one embodiment, the processing server 116 may be maintained at the issuer. In another embodiment, the processing server 116 may be maintained at the first or second payment networks and offered to the issuer as a value-added service. In yet another embodiment, the processing server 116 may be maintained at a third-party management authority (not shown) and offered to the issuer as the value-added service. Various functional components of the processing server 116 are explained in detail in conjunction with FIG. 5.
The installment management server 118 is a computing server that receives the authorization requests that have the default format from the processing server 116. Based on a translated authorization request, the installment management server 118 checks eligibility of the corresponding transaction for the installment facility. The eligibility check depends on installment eligibility criteria specified by the issuer of the corresponding transaction. The installment eligibility criteria may be based on a card number of a transaction card, an account balance of a customer account, a transaction amount, a credit score of a customer associated with the transaction, and an MCC of a merchant associated with the transaction. For example, the installment management server 118 may determine that a transaction performed by the first customer 102a is eligible for the installment facility when the account balance of the first customer account is greater than or equal to a first threshold value and/or the credit score of the first customer 102a is greater than or equal to a second threshold value. In another example, the first customer 102a may have opted to discontinue the installment facility on the first transaction card 104a, thus the installment management server 118 may determine that a transaction performed by the first transaction card 104a is ineligible for the installment facility. It will be apparent to a person having ordinary skill in the art that the installment management server 118 may use any other installment eligibility criteria for checking the eligibility of the transactions for the installment facility without deviating from the scope of the invention.
When the installment management server 118 determines that the transaction is eligible for the installment facility, the installment management server 118 generates the installment plans that are applicable on the transaction. The installment management server 118 populates the generated installment plans in the corresponding authorization request and transmits the populated authorization request to the processing server 116. In one embodiment, the installment management server 118 may be maintained at the issuer. In another embodiment, the installment management server 118 may be maintained at the first or second payment networks and offered as a value-added service to the issuer. In yet another embodiment, the installment management server 118 may be maintained at a third-party installment provider (not shown) and offered as a value-added service to the issuer. Various functional components of the installment management server 118 are explained in detail in conjunction with FIG. 6.
The issuer server 120 is a computing server that is associated with the issuer. The issuer is a financial institution that manages customer accounts of multiple customers, such as the customers 102. The account information of the customer accounts established with the issuer is stored in a memory of the issuer server 120 or on a cloud server associated with the issuer server 120. The issuer server 120 receives the retranslated authorization requests that are populated with the installment plans (i.e., enhanced authorization requests) from the processing server 116. Based on an authorization request, the issuer server 120 authorizes the corresponding transaction and approves the corresponding installment plans when the corresponding transaction is determined to be eligible for the installment facility. In one embodiment, the issuer server 120 may verify whether the corresponding transaction is eligible for the installment facility based on the installment eligibility criteria. The issuer server 120 further generates an authorization response for each authorization request. The authorization responses are pursuant to the one or more standards for the interchange of transaction messages, such as the ISO8583 standard. An authorization response for an authorization request indicates a result of authorization for the corresponding transaction. The authorization response may further indicate an approval of the installment plans when the issuer server 120 approves the installment plans. The issuer server 120 transmits the generated authorization responses to the processing server 116.
The issuer server 120 further receives selections performed by the customers 102, when they are presented with the installment plans applicable on their transactions. A UI for presenting the installment plans to the customers 102 is explained in conjunction with FIGS. 3A and 3B. A selection is indicative of an installment plan selected by a customer, such as the first or second customer 102a or 102b. The issuer server 120 then processes the transactions based on the selections performed by the customers 102. Methods for processing transactions as installment transactions or regular transactions (i.e., transactions for which the customers 102 opt to pay in full) via the issuer server 120 will be apparent to a person having skill in the art and may include processing via the traditional four-party system or the traditional three-party system. Various functional components of the issuer server 120 are explained in detail in conjunction with FIG. 7.
It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the processing server 116, the installment management server 118, and the issuer server 120 as separate entities. In various other embodiments, the processing server 116 and the installment management server 118 may be integrated into the issuer server 120, without departing from the scope of the invention.
Examples of the merchant server 110, the acquirer server 112, the payment network servers 114, the processing server 116, the installment management server 118, and the issuer server 120 include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that can execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
The communication network 122 is a medium through which content and messages are transmitted between the customer devices 106, the first and second POS devices 108a and 108b (collectively referred to as “POS devices 108”), the merchant server 110, the acquirer server 112, the payment network servers 114, the processing server 116, the installment management server 118, the issuer server 120, and other entities that are pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard. Examples of the communication network 122 include, but are not limited to, a wireless fidelity (Wi-Fi) network, 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, and combinations thereof. Various entities in the environment 100 may connect to the communication 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, or any combination thereof.
FIG. 2 is a block diagram that illustrates an exemplary scenario 200 for providing a brand-agnostic installment facility, in accordance with an embodiment of the present invention. The first customer 102a uses the first transaction card 104a at the first POS device 108a to initiate a first transaction. Similarly, the second customer 102b uses the second transaction card 104b at the second POS device 108b to initiate a second transaction.
The first POS device 108a transmits transaction details of the first transaction to the merchant server 110 in an encrypted format. The transaction details of the first transaction include a first transaction amount of the first transaction, a time-stamp of the first transaction, the identification code of the first POS device 108a, the device capability indicator of the first POS device 108a, the transaction card details of the first transaction card 104a, the currency code, the MCC, the acquirer code, and the like. The device capability indicator indicates whether the first POS device 108a is capable of rendering the UI for presenting the installment plans applicable on the first transaction to the first customer 102a. For example, the device capability indicator is set to “1” when the first POS device 108a is capable of presenting the installment plans, else the device capability indicator is set to “0”. Likewise, the second POS device 108b transmits encrypted transaction details of the second transaction to the merchant server 110. In a non-limiting example, it is assumed that both the first and second POS devices 108a and 108b are capable of rendering the UI for presenting the installment plans and hence, the device capability indicator is set to “1” for both the first and second transactions. The merchant server 110 transmits the encrypted transaction details of the first and second transactions to the acquirer server 112.
The acquirer server 112 receives the encrypted transaction details of the first and second transactions. The acquirer server 112 generates first and second authorization requests that are pursuant to the ISO8583 standard based on the encrypted transaction details of the first and second transactions, respectively. The first and second authorization requests include various multibit data elements (DEs), such as DE 1 – DE 128, that store the transaction details of the first and second transactions, respectively. For the first authorization request, DE 2 stores the card number of the first transaction card 104a, DE 4 stores the first transaction amount, DE 18 stores the MCC of the first merchant, DE 20 stores the currency code, DE 32 stores the acquirer code, DE 48 has a sub element (SE) 95 (i.e., DE48SE95) that stores the device capability indicator of the first POS device 108a. Likewise, for the second authorization request, DE 2 stores the card number of the second transaction card 104b, DE 4 stores a second transaction amount of the second transaction, DE 18 stores the MCC of the first merchant, DE 20 stores the currency code, DE 32 stores the acquirer code, DE48SE95 stores the device capability indicator of the second POS device 108b. Each of the first and second authorization requests further includes an installment data element, which is currently empty, dedicated for storing the installment plans that are applicable on the first and second transactions, respectively. The first authorization request is in the first format associated with the first payment network as the first transaction card 104a has the first card brand. Likewise, the second authorization request is in the second format associated with the second payment network as the second transaction card 104b has the second card brand.
The acquirer server 112 identifies that the first and second transactions correspond to the first and second payment networks, respectively. Thus, the acquirer server 112 transmits the first authorization request to the first payment network server 114a and the second authorization request to the second payment network server 114b. The first and second payment network servers 114a and 114b transmit the first and second authorization requests to the processing server 116, respectively.
The processing server 116 receives the first and second authorization requests and identifies that the first and second payment networks are associated with the first and second authorization requests, respectively. The processing server 116 then translates the first authorization request from the first format to the default format readable by the installment management server 118. Likewise, the processing server 116 translates the second authorization request from the second format to the default format. The translation process is explained in detail in conjunction with FIGS. 4A-4C. The processing server 116 transmits the first and second authorization requests having the default format to the installment management server 118.
The installment management server 118 receives the first and second authorization requests having the default format from the processing server 116. Based on the first and second authorization requests and the installment eligibility criteria specified by the issuer server 120, the installment management server 118 determines whether the first and second transactions are eligible for the installment facility. When it is determined that the first and second transactions are eligible for the installment facility, the installment management server 118 generates the installment plans applicable on each of the first and second transactions, respectively. The installment plans may be different for the first and second transactions. The installment management server 118 then populates the corresponding installment data element of the first and second authorization requests with the corresponding installment plans. In one embodiment, the installment management server 118 may update DE48SE71 included in each of the first and second authorization requests to indicate installment eligibility of the first and second transactions. The installment management server 118 may further update DE48SE112 included in each of the first and second authorization requests to indicate a funding authority of the installment facility. For example, the installment facility may be issuer funded, acquirer funded, or co-funded by the issuer and acquirer. When the DE48SE112 is set to “21”, the installment facility is issuer funded. When the DE48SE112 is set to “22”, the installment facility is acquirer funded. Further, when the DE48SE112 is set to “23”, the installment facility is co-funded by the issuer and acquirer. After populating the corresponding installment plans in the first and second authorization requests, the installment management server 118 transmits the first and second authorization requests to the processing server 116.
The processing server 116 retranslates the first and second authorization requests from the default format to the first and second formats, respectively. The retranslation process is explained in detail in conjunction with FIGS. 4A-4C. The processing server 116 transmits the first and second authorization requests populated with the corresponding installment plans to the issuer server 120. The issuer server 120 receives the first and second authorization requests populated with the corresponding installment plans. The issuer server 120 verifies whether the first and second transactions are eligible for the installment facility. In a scenario where the issuer server 120 determines that a transaction is ineligible for the installment facility, the corresponding installment plans are discarded by the issuer server 120. In a non-limiting example, it is assumed that both the first and second transactions are determined to be eligible for the installment facility. Based on the first and second authorization requests, the issuer server 120 authorizes the first and second transactions. In one scenario where the first transaction is not eligible for the installment facility, the issuer server 120 authorizes the first transaction when the account balance of the first customer account is greater than the first transaction amount and the first customer 102a is successfully authenticated. In another scenario where the first transaction is eligible for the installment facility, the issuer server 120 authorizes the first transaction when the first customer 102a is successfully authenticated. In a non-limiting example, it is assumed that the issuer server 120 authorizes the first and second transactions.
The issuer server 120 then checks the installment plans corresponding to the first and second transactions for approval. In a non-limiting example, it is assumed that the issuer server 120 approves the installment plans corresponding to the first transaction and rejects the installment plans corresponding to the second transaction. As the installment plans for the second transaction are rejected, the issuer server 120 processes the second transaction as a regular transaction. The issuer server 120 further stores the approved installment plans corresponding to the first transaction in its memory. The issuer server 120 generates the first and second authorization responses for the first and second authorization requests to indicate that the first and second transactions are authorized, respectively. The first and second authorization responses are pursuant to the ISO8583 standard. Similar to the first authorization request, the first authorization response also includes the DE 1 – DE 128. Since the issuer server 120 has approved the installment plans corresponding to the first transaction, the first authorization response includes the installment plans applicable on the first transaction. The second authorization response indicates that the second transaction is processed for the second transaction amount and does not include any installment plans.
The issuer server 120 transmits the first and second authorization responses to the processing server 116. The processing server 116 transmits the first authorization response to the first POS device 108a by way of the first payment network server 114a, the acquirer server 112, and the merchant server 110. The processing server 116 transmits the second authorization response to the second POS device 108b by way of the second payment network server 114b, the acquirer server 112, and the merchant server 110.
When the first POS device 108a receives the first authorization response, a UI is rendered on a display (not shown) of the first POS device 108a. By way of the UI, the first customer 102a is presented with the installment plans that are applicable on the first transaction. Based on the selection of an installment plan performed by the first customer 102a, the issuer server 120 processes the first transaction. Based on the second authorization response, the second POS device 108b renders another UI to inform the second customer 102b that the second transaction is authorized and successful. The processing of the first transaction is explained in detail in conjunction with FIG. 4A-4C.
It will be apparent to a person having ordinary skill in the art that the processing server 116 and the installment management server 118 are capable of handling multiple authorization requests simultaneously without departing from the spirit of the invention.
FIGS. 3A and 3B are block diagrams 300a and 300b that illustrate an exemplary UI 302 for presenting the installment plans to the customers 102, in accordance with an embodiment of the present invention. The UI 302 may be rendered on the first and second POS devices 108a and 108b for presenting the installment plans that are applicable on the first and second transactions performed at the first and second POS devices 108a and 108b, respectively. For the sake of simplicity, the UI 302 is described in conjunction with the first transaction initiated by the first customer 102a at the first POS device 108a. When the first POS device 108a receives the first authorization response, the UI 302 is rendered on the display of the first POS device 108a as shown in FIG. 3A.
The UI 302 displays a first UI screen 304a that includes first and second options 306a and 306b. The first option 306a is only presented on the first UI screen 304a when the first transaction is determined to be eligible for the installment facility. The first option 306a, when selected, allows the first customer 102a to pay the first transaction amount in installments. The second option 306b, when selected, allows the first customer 102a to pay the first transaction amount in full. The first customer 102a may select any of the first and second options 306a and 306b based on her choice. In a scenario where the first customer 102a selects the first option 306a, the first POS device 108a redirects the control from the first UI screen 304a to a second UI screen 304b as shown in FIG. 3B. In another scenario where the first customer 102a selects the second option 306b, the issuer server 120 processes the first transaction as a regular transaction without installments.
With reference to FIG. 3B, the second UI screen 304b includes various sections each presenting one installment plan to the first customer 102a. For the sake of simplicity, the second UI screen 304b is shown to include two sections, such as first and second sections 308a and 308b. The first section 308a presents a first installment plan and the second section 308b presents a second installment plan. Each section 308a and 308b includes an installment amount per installment, a count of installments in the installment plan, a duration of the installment plan, and a rate of interest charged to the first customer 102a for availing the installment plan. The first and second sections 308a and 308b further includes first and second “select” tabs 310a and 310b that allow the first customer 102a to select the first and second installment plans, respectively. The first POS device 108a records and transmits information pertaining to a selection of the first or second installment plans to the issuer server 120 by way of the merchant server 110, the acquirer server 112, the first payment network server 114a, and the processing server 116. The issuer server 120 processes the first transaction as an installment transaction based on the selection made by the first customer 102a.
It will be apparent to a person having ordinary skill in the art that the first and second UI screens 304a and 304b are shown for illustrative purpose to describe the features of the invention. Changes can be made to the design of the first and second UI screens 304a and 304b, navigation among the first and second UI screens 304a and 304b, and the like, without deviating from the scope of the invention.
FIGS. 4A-4C, collectively represent a process flow diagram 400 that illustrates an exemplary scenario for providing the brand-agnostic installment facility on the first transaction initiated by the first customer 102a, in accordance with an embodiment of the present invention.
The first customer 102a uses the first transaction card 104a at the first POS device 108a to initiate the first transaction for making a purchase from the first merchant (as shown by arrow 402). The first POS device 108a transmits the encrypted transaction details of the first transaction to the merchant server 110 (as shown by arrow 404). The merchant server 110 further transmits the encrypted transaction details of the first transaction to the acquirer server 112 (as shown by arrow 406). The acquirer server 112 identifies that the first transaction corresponds to the first payment network based on the card number of the first transaction card 104a included in the encrypted transaction details (as shown by arrow 408). A number of characters in the card number of a transaction card (e.g., the first transaction card 104a) may vary from 12 to 19 and the first seven characters of the card number uniquely identifies a payment network associated with the transaction card. For example, if a card number of a transaction card has first and second characters as “51”, “52”, “53”, “54”, or “55”, the transaction card is associated with Mastercard. The acquirer server 112 generates the first authorization request based on the encrypted transaction details of the first transaction (as shown by arrow 410). The first authorization request has the first format associated with the first payment network. The first authorization request includes various data elements populated with the transaction details. For example, DE 2 stores “1234989837287648” (i.e., the card number of the first transaction card 104a), DE 4 stores “$600” (i.e., the first transaction amount), DE 18 stores the MCC of the first merchant, DE 20 stores the currency code, DE 32 stores the acquirer code, DE48SE95 stores “1” (i.e., the device capability indicator of the first POS device 108a). When the first authorization request is generated by the acquirer server 112, the installment data element is empty. The acquirer server 112 transmits the first authorization request to the first payment network server 114a (as shown by arrow 412). The first payment network server 114a transmits the first authorization request to the processing server 116 (as shown by arrow 414).
The processing server 116 then identifies that the first authorization request corresponds to the first payment network (as shown by arrow 416). The processing server 116 identifies the first payment network based on the card number (i.e., “1234989837287648”) of the first transaction card 104a included in the DE 2. In this scenario, the processing server 116 determines that the first authorization request corresponds to the first payment network as the fourth character of the card number is “4”. The processing server 116 then checks whether DE48SE95 (i.e., the device capability indicator) of the first authorization request is set to “1”. In a scenario where DE48SE95 is set to “0”, the processing server 116 transmits the authorization request to the issuer server 120 for processing as a regular transaction. In a scenario where DE48SE95 is set to “1”, the processing server 116 generates a header (e.g., FPN) for the first authorization request (as shown by arrow 418). The header (e.g., FPN) is indicative of the first payment network of the first authorization request and may correspond to a metadata. The processing server 116 then inserts the header in the first authorization request (as shown by arrow 420). The processing server 116 further links an installment service indicator to the first authorization request. The processing server 116 sets the installment service indicator to “1” to initiate a translation of the first authorization request.
When the installment service indicator is set to “1”, the processing server 116 identifies a format of the first authorization request by way of the header (as shown by arrow 422). For example, the processing server 116 may refer a look-up table that includes a list of formats and the corresponding payment networks for identifying a format of the first authorization request. The processing server 116 may refer the look-up table by using the header. In this scenario, the processing server 116 identifies that the first authorization request has the first format pursuant to the first payment network as the header is FPN.
After identifying the format of the first authorization request, the processing server 116 translates the first authorization request from the first format to the default format readable by the installment management server 118 (as shown by arrow 424). The default format includes fields corresponding to the DEs of the first format. In one embodiment, the processing server 116 may use a first Java® ARchive (JAR) file to translate the first authorization request from the first format to the default format. The processing server 116 maintains a specific JAR file for every format to translate the corresponding format to the default format. During translation, the first JAR file extracts information from the DEs of the first authorization request and stores the information in respective fields of the default format. For example, the first JAR file extracts information of the card number of the first transaction card 104a from DE 2 and stores it in “PAN” field of the default format. As the installment data element of the first authorization request is currently empty, a corresponding “installment payment” field of the default format is also empty. When the translation is complete, the processing server 116 sets the installment service indicator to “0” to indicate that the first authorization request is successfully translated to the default format. The processing server 116 transmits the first authorization request having the default format to the installment management server 118 (as shown by arrow 426).
The installment management server 118 receives the first authorization request in the default format. The installment management server 118 checks eligibility of the first transaction for the installment facility based on the installment eligibility criteria specified by the issuer server 120 (as shown by arrow 428). The installment management server 118 may check the eligibility of the first transaction for the installment facility by performing various eligibility checks known in the art. For example, if a credit score of the first customer 102a is below the second threshold value, the installment management server 118 may determine that the first transaction is ineligible for the installment facility. For the sake of ongoing description, it is assumed that the first transaction is eligible for the installment facility. The installment management server 118 updates the field that corresponds to the DE48SE71 of the authorization request to “26V” indicating that the first transaction is eligible for the installment facility. The installment management server 118 further updates the field that corresponds to the DE48SE112 to one of “21”, “22”, or “23” for indicating the funding authority of the installment facility. For the sake of ongoing description, it is assumed that the installment facility is issuer funded, thus the field that corresponds to the DE48SE112 is set to “21”. The installment management server 118 then generates installment plans applicable to the first transaction (as shown by arrow 430). Each installment plan includes an installment amount per installment, a count of installments in the installment plan, a duration of the installment plan, and a rate of interest charged to the first customer 102a for availing the corresponding installment plan. The installment management server 118 populates the generated installment plans in the “installment payment” field of the default format of the first authorization request (as shown by arrow 432). The installment management server 118 transmits the first authorization request populated with the installment plans to the processing server 116 (as shown by arrow 434).
The processing server 116 retranslates the first authorization request from the default format to the first format by using a second JAR file (as shown by arrow 436). The second JAR file extracts information from the fields of the default format and stores the information in the corresponding DEs of the first format of the first authorization request for retranslating the first authorization request to the first format. The processing server 116 transmits the retranslated first authorization request to the issuer server 120 (as shown by arrow 438).
The issuer server 120 verifies whether the first transaction is eligible for the installment facility for approving the installment plans, and further authorizes the first transaction based on the first authorization request and the installment eligibility criteria (as shown by arrow 440). The issuer server 120 then generates the first authorization response (as shown by arrow 442). The first authorization response includes the DEs of the first authorization request, and indicates the approval of the installment plans and the result of authorization. The issuer server 120 stores the approved installment plans in its memory.
The issuer server 120 transmits the first authorization response to the processing server 116 (as shown by arrow 444). The processing server 116 transmits the first authorization response to the first payment network server 114a (as shown by arrow 446) and the first payment network server 114a transmits the first authorization response to the acquirer server 112 (as shown by arrow 448). The acquirer server 112 transmits the first authorization response to the merchant server 110 (as shown by arrow 450) and the merchant server 110 transmits the first authorization response to the first POS device 108a (as shown by arrow 452). Based on the first authorization response, the UI 302 is rendered on the first POS device 108a to present the first UI screen 304a including the first and second options 306a and 306b (as shown by arrow 454). When the first customer 102a selects the first option 306a for paying the first transaction amount in installments, the first POS device 108a redirects the control from the first UI screen 304a to the second UI screen 304b for presenting the installment plans. The first customer 102a then selects an installment plan, for example by clicking on the first or second “select” tab 310a or 310b. The first POS device 108a records the selection of the installment plan and transmits the selection performed by the first customer 102a to the issuer server 120 by way of the merchant server 110, the acquirer server 112, the first payment network server 114a, and the processing server 116 (as shown by arrows 456, 458, 460, 462, and 464). The issuer server 120 processes the first transaction as the installment transaction based on the customer selection (as shown by arrow 466). The processing of installment transactions by the issuer server 120 is understood by those of skill in the art.
In one embodiment, the first transaction may be an online transaction initiated by the first customer 102a by way of the first customer device 106a. In such a scenario, the processing of the first transaction initiated at the first customer device 106a is similar to the processing of the first transaction initiated at the first POS device 108a. It will be apparent to a person skilled in the art that the process flow involved in the processing of the second transaction initiated by using the second transaction card 104b is similar to the process flow diagram 400 and involves the second payment network server 114b instead of the first payment network server 114a.
FIG. 5 is a block diagram that illustrates the processing server 116, in accordance with an embodiment of the present invention. The processing server 116 includes a first processor 502, a first memory 504, a gateway 506, a header generator 508, and a translator 510. The first processor 502, the first memory 504, the gateway 506, the header generator 508, and the translator 510 communicate with each other by way of a first communication bus 512.
The first processor 502 includes suitable logic, circuitry, and/or interfaces that execute one or more instructions stored in the first memory 504. Examples of the first processor 502 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
The first memory 504 includes suitable logic, circuitry, and/or interfaces to store information (such as look-up tables) pertaining to the list of formats (such as the first and second formats) and the corresponding payment networks. The first memory 504 further stores a JAR file, such as a first JAR file 514a, for every format to translate the corresponding format to the default format readable by the installment management server 118. For example, the first JAR file 514a is used in the translation of the first authorization request from the first format to the default format (as described in FIGS. 4A-4C). The first memory 504 further stores another JAR file, such as a second JAR file 514b, for every format to retranslate the default format to the corresponding format. For example, the second JAR file 514b is used in the retranslation of the first authorization request from the default format to the first format (as described in FIGS. 4A-4C). Examples of the first memory 504 include a random access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disc drive (HDD), a flash memory, a solid-state memory, and the like. It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the first memory 504 in the processing server 116, as described herein. In another embodiment, the first memory 504 may be realized in form of a database server or a cloud storage working in conjunction with the processing server 116, without departing from the scope of the invention.
The gateway 506 includes suitable logic, circuitry, and/or interfaces for transmitting and receiving authorization requests using one or more communication protocols (as explained in FIGS. 4A-4C). The gateway 506 further receives authorization responses from the issuer server 120 and communicates the authorization responses to the corresponding payment network servers 114 (as explained in FIGS. 4A-4C).
The header generator 508 includes suitable logic, circuitry, and/or interfaces for executing one or more instructions stored in the first memory 504. The header generator 508 identifies payment networks associated with the authorization requests received by the gateway 506. The header generator 508 may identifies a payment network associated with an authorization request based on transaction card details stored in the DEs of the authorization request (as described in FIGS. 4A-4C). Based on the identification of the payment networks, the header generator 508 generates a header for each authorization request that is indicative of the corresponding payment network (as described in FIGS. 4A-4C). The header generator 508 further inserts the generated headers in the corresponding authorization requests.
The translator 510 includes suitable logic, circuitry, and/or interfaces for translating authorization requests from their specific format to the default format readable by the installment management server 118. The translator 510 transmits the translated authorization requests to the installment management server 118 for populating the installment plans. The translator 510 further receives the populated authorization requests from the installment management server 118 and retranslates the populated authorization requests from the default format to their previous formats. The translator 510 uses the JAR files, such as the first and second JAR files 514a and 514b, stored in the first memory 504 for translation and retranslation of the authorization requests (as described in FIGS. 4A-4C).
FIG. 6 is a block diagram that illustrates the installment management server 118, in accordance with an embodiment of the present invention. The installment management server 118 includes a second processor 602, a database 604, an installment plan generator 606, and a first transceiver 608. The second processor 602, the database 604, the installment plan generator 606, and the first transceiver 608 communicate with each other by way of a second communication bus 610.
The second processor 602 includes suitable logic, circuitry, and/or interfaces to process translated authorization requests. The second processor 602 checks whether a transaction is eligible for the installment facility based on the installment eligibility criteria specified by the issuer. The second processor 602 further updates the field that corresponds to the DE48SE71 of the authorization request to “26V” when the transaction is determined to be eligible for the installment facility. The installment management server 118 further updates the field that corresponds to the DE48SE112 to one of “21”, “22”, or “23” for indicating the funding authority of the installment facility. The second processor 602 further populates the “installment payment” field of the default format of the authorization request with the installment plans applicable on the transaction. Examples of the second processor 602 include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, a FPGA, and the like.
The database 604 includes suitable logic, circuitry, and/or interfaces to store the installment eligibility criteria specified by the issuer for checking the eligibility of transactions for the installment facility. The installment eligibility criteria may include an account balance of a customer account associated with a transaction, a transaction amount of the transaction, a credit score of a customer associated with the transaction, and the like. The database 604 may further store various installment plans generated by the installment management server 118. Examples of the database 604 include a RAM, a ROM, a removable storage drive, an HDD, a flash memory, a solid-state memory, and the like. It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the database 604 in the installment management server 118, as described herein. In another embodiment, the database 604 may be realized in form of a database server or a cloud storage working in conjunction with the installment management server 118, without departing from the scope of the invention.
The installment plan generator 606 includes suitable logic, circuitry, and/or interfaces for generating the installment plans (as described in FIGS. 4A-4C). The first transceiver 608 transmits and receives data over the communication network 122 using one or more communication protocols. The first transceiver 608 includes suitable logic, circuitry, and/or interfaces for transmitting various requests and messages to the processing server 116, the issuer server 120, or other entities that are pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard. The first transceiver 608 further receives various requests and messages from the processing server 116 and the issuer server 120. The first transceiver 608 receives the translated authorization requests from the processing server 116 and transmits the authorization requests populated with the installment plans to the processing server 116. Examples of the first transceiver 608 include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, a universal serial bus (USB) port, or any other device configured to transmit and receive data.
FIG. 7 is a block diagram that illustrates the issuer server 120, in accordance with an embodiment of the present invention. The issuer server 120 includes a third processor 702, a second memory 704, and a second transceiver 706. The third processor 702, the second memory 704, and the second transceiver 706 communicate with each other by way of a third communication bus 708. The third processor 702 includes an authorization manager 710, an installment manager 712, and a transaction manager 714.
The third processor 702 includes suitable logic, circuitry, and/or interfaces to process transactions performed by the customers 102. The third processor 702 receives the authorization requests from the processing server 116 and verifies the eligibility of the transactions associated with the authorization requests for the installment facility (as described in FIGS. 4A-4C). The third processor 702 further authorizes the transactions and generates corresponding authorization responses. Examples of the third processor 702 include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, a FPGA, and the like. The third processor 702 processes the transactions by way of the authorization manager 710, the installment manager 712, and the transaction manager 714.
The authorization manager 710 authorizes the transactions and authenticates customers (such as the customers 102) who initiate the transactions. The authorization manager 710 authorizes the transactions based on the account balance of the customer accounts and the transaction amount of the transactions, and generates the authorization responses (as described in FIGS. 4A-4C). The installment manager 712 verifies the eligibility of the transactions for the installment facility based on the installment eligibility criteria and approves the installment plans (as described in FIGS. 4A-4C). The transaction manager 714 processes the transactions as regular transactions or installment transactions based on the customer selections.
The second memory 704 includes suitable logic, circuitry, and/or interfaces to store customer profiles of the customers 102 for their customer accounts maintained at the issuer. The second memory 704 further stores the installment plans generated by the installment management server 118. Examples of the second memory 704 include a RAM, a ROM, a removable storage drive, an HDD, a flash memory, a solid-state memory, and the like. It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the second memory 704 in the issuer server 120, as described herein. In another embodiment, the second memory 704 may be realized in form of a database server or a cloud storage working in conjunction with the issuer server 120, without departing from the scope of the invention.
The second transceiver 706 transmits and receives data over the communication network 122 using one or more communication protocols. The second transceiver 706 transmits various requests and messages to the customer devices 106, the POS devices 108, the merchant server 110, the acquirer server 112, the payment network servers 114, the processing server 116, or other entities that are pursuant to one or more standards for the interchange of transaction messages, such as the ISO8583 standard. The second transceiver 706 receives various requests and messages from the customer devices 106, the POS devices 108, the merchant server 110, the acquirer server 112, the payment network servers 114, and the processing server 116. The second transceiver 706 receives the authorization requests and the customer selections from the processing server 116. The second transceiver 706 further transmits the authorization responses generated by the third processor 702 to the processing server 116. Examples of the second transceiver 706 include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an Ethernet port, a USB port, or any other device configured to transmit and receive data.
FIGS. 8A and 8B, collectively represent a flow chart 800 that illustrates a method for providing the brand-agnostic installment facility on transactions, in accordance with an embodiment of the present invention. The customers 102 use the corresponding transaction cards 104 at the POS devices 108 to initiate the first and second transactions, respectively. The first and second payment network servers 114a and 114b receive the first and second authorization requests from the acquirer server 112 corresponding to the first and second transactions, respectively, and transmit the first and second authorization requests to the processing server 116. For the sake of simplicity, the flow chart 800 is explained with respect to the first authorization request.
At step 802, the processing server 116 receives the first authorization request from the first payment network server 114a. At step 804, the processing server 116 identifies the first payment network associated with the first authorization request based on the card number of the first transaction card 104a included in the first authorization request. At step 806, the processing server 116 generates the header indicative of the identified first payment network. The processing server 116 generates the header when the device capability indicator (i.e., DE48SE71) in the first authorization request indicates that the first POS device 108a is capable of rendering the UI 302 for presenting the installment plans to the first customer 102a. At step 808, the processing server 116 inserts the header in the first authorization request. At step 810, the processing server 116 identifies the first format associated with the first payment network for translating the first authorization request. At step 812, the processing server 116 translates the first authorization request from the first format to the default format readable by the installment management server 118. At step 814, the processing server 116 transmits the translated first authorization request to the installment management server 118 for populating the translated first authorization request with the installment plans.
At step 816, the processing server 116 receives the first authorization request populated with the installment plans from the installment management server 118. At step 818, the processing server 116 retranslates the first authorization request that is populated with the installment plans from the default format to the first format. At step 820, the processing server 116 transmits the retranslated first authorization request to the issuer server 120 for approving the installment plans and authorizing the first transaction. At step 822, the processing server 116 receives the first authorization response for the first authorization request from the issuer server 120. The authorization response includes DEs of the first authorization request, and indicates an approval of the installment plans and a result of authorization of the first transaction.
At step 824, the processing server 116 transmits the first authorization response to the first POS device 108a (i.e., the first merchant terminal device 108a) for rendering the UI 302 that presents the installment plans to the first customer 102a. At step 826, the processing server 116 receives the customer selection, corresponding to a selected installment plan, from the first POS device 108a. At step 828, the processing server 116 transmits the customer selection to the issuer server 120 for processing the first transaction.
FIG. 9 represents a high-level flow chart 900 that illustrates a method for providing the brand-agnostic installment facility on transactions, in accordance with another embodiment of the present invention. At step 902, the processing server 116 receives authorization requests (such as the first and second authorization requests) from the payment network servers 114. The first authorization request corresponds to the first transaction initiated by the first customer 102a at a terminal device (i.e., the first POS device 108a), and is in the first format associated with the first payment network. At step 904, the processing server 116 translates the first authorization request to the default format readable by the installment management server 118. The installment management server 118 populates the first authorization request with the installment plans. At step 906, the processing server 116 retranslates the first authorization request to the first format for communicating to the issuer associated with the first transaction. At step 908, the processing server 116 transmits an authorization response (i.e., the first authorization response) including the installment plans to the first payment network, when the first transaction is authorized and determined to be eligible for the installment facility by the issuer based on the first authorization request. The installment plans are presented to the first customer 102a for selection by way of the UI 302 rendered on the terminal device (i.e., the first POS device 108a), thereby enabling the first customer 102a to avail the installment facility on the first transaction.
FIG. 10 is a block diagram that illustrates system architecture of a computer system 1000, in accordance with an embodiment of the present invention. An embodiment of present invention, or portions thereof, may be implemented as computer readable code on the computer system 1000. In one example, the customer devices 106, the POS devices 108, the merchant server 110, the acquirer server 112, and the payment network servers 114 of FIG. 1 may be implemented in the computer system 1000 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of FIGS. 8A and 8B, and 9.
The computer system 1000 includes a processor 1002 that may be a special-purpose or a general-purpose processing device. The processor 1002 may be a single processor, multiple processors, or combinations thereof. The processor 1002 may have one or more processor cores. In one example, the processor 1002 is an octa-core processor. Further, the processor 1002 may be connected to a communication infrastructure 1004, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 1000 may further include a main memory 1006 and a secondary memory 1008. Examples of the main memory 1006 may include RAM, ROM, and the like. In one embodiment, the main memory 1006 is one of the first memory 504, the database 604, or the second memory 704. The secondary memory 1008 may include a hard disc drive or a removable storage drive, such as a floppy disc drive, a magnetic tape drive, a compact disc, an optical disc drive, a flash memory, and the like. Further, the removable storage drive may read from and/or write to a removable storage device in a manner known in the art. In one example, if the removable storage drive is a compact disc drive, the removable storage device may be a compact disc. In an embodiment, the removable storage unit may be a non-transitory computer readable recording media.
The computer system 1000 further includes an input/output (I/O) interface 1010 and a communication interface 1012. The I/O interface 1010 includes various input and output devices that are configured to communicate with the processor 1002. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 1012 may be configured to allow data to be transferred between the computer system 1000 and various devices that are communicatively coupled to the computer system 1000. Examples of the communication interface 1012 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 1012 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art. The signals may travel via a communication channel (not shown) which may be configured to transmit the signals to devices that are communicatively coupled to the computer system 1000. Examples of the communication channel may include, but are not limited to, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, and the like.
Computer program medium and computer usable medium may refer to memories, such as the main memory 1006 and the secondary memory 1008, which may be a semiconductor memory such as a DRAM. These computer program mediums may provide data that enables the computer system 1000 to implement the methods illustrated in FIGS. 8 and 9. In an embodiment, the present invention is implemented using a computer implemented application, the computer implemented application may be stored in a computer program product and loaded into the computer system 1000 using the removable storage drive or the hard disc drive in the secondary memory 1008, the I/O interface 1010, or the communication interface 1012.
A person having ordinary skill in the art will appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded in virtually any device. For instance, at least one processor such as the processor 1002 and a memory such as the main memory 1006 and the secondary memory 1008 implements the above described embodiments. Further, the operations may be described as a sequential process, however some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multiprocessor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
The method and system of the present invention offer advantages to both the customers 102 and issuers. Since the processing server 116 receives authorization requests for transactions that corresponds to multiple card brands and translates them to a format (e.g., the default format) readable by the installment management server 118, the card brands no longer pose a limitation for offering the installment facility to the customers 102. The customers 102 enjoy benefits of the installment facility irrespective of the card brand of their transaction cards 104. Thus, the method and system of the present invention eliminate the need for the customers 102 to possess transaction cards of select card brands to avail the installment facility. In addition, the method and system of the present invention provide a platform for the issuers to offer a brand-agnostic installment facility to the customers 102. The brand-agnostic installment facility is provided to the customers 102 by using existing infrastructure of various entities, such as the POS devices 108, the merchant server 110, the acquirer server 112, the payment network servers 114, the installment management server 118, and the issuer server 120. Further, the method and system of the present invention does not affect the installment facility currently provided on transactions performed by using transaction cards of select card brands, such as Mastercard.
Techniques consistent with the present invention provide, among other features, systems and methods for providing the installment facility on electronic transactions. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the invention, without departing from the breadth or scope.
In the claims, the words ‘comprising’, ‘including’ and ‘having’ do not exclude the presence of other elements or steps then those listed in a claim. The terms “a” or “an,” as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
While various embodiments of the present invention have been illustrated and described, it will be clear that the present invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present invention, as described in the claims.
| # | Name | Date |
|---|---|---|
| 1 | 201924053903-PROOF OF RIGHT [26-12-2019(online)].pdf | 2019-12-26 |
| 2 | 201924053903-PRIORITY DOCUMENTS [26-12-2019(online)].pdf | 2019-12-26 |
| 3 | 201924053903-POWER OF AUTHORITY [26-12-2019(online)].pdf | 2019-12-26 |
| 4 | 201924053903-FORM 1 [26-12-2019(online)].pdf | 2019-12-26 |
| 5 | 201924053903-DRAWINGS [26-12-2019(online)].pdf | 2019-12-26 |
| 6 | 201924053903-COMPLETE SPECIFICATION [26-12-2019(online)].pdf | 2019-12-26 |
| 7 | 201924053903-FORM 3 [27-12-2019(online)].pdf | 2019-12-27 |
| 8 | 201924053903-ENDORSEMENT BY INVENTORS [27-12-2019(online)].pdf | 2019-12-27 |
| 9 | Abstract1.jpg | 2019-12-31 |
| 10 | 201924053903-ORIGINAL UR 6(1A) FORM 26, ASSIGNMENT & CERTIFIED COPY OF PRIORITY DOCUMENT-311219.pdf | 2020-04-20 |
| 11 | 201924053903-FORM 18 [28-12-2022(online)].pdf | 2022-12-28 |
| 12 | 201924053903-FER.pdf | 2023-04-13 |
| 13 | 201924053903-Proof of Right [25-09-2023(online)].pdf | 2023-09-25 |
| 14 | 201924053903-OTHERS [25-09-2023(online)].pdf | 2023-09-25 |
| 15 | 201924053903-Information under section 8(2) [25-09-2023(online)].pdf | 2023-09-25 |
| 16 | 201924053903-FORM-26 [25-09-2023(online)].pdf | 2023-09-25 |
| 17 | 201924053903-FER_SER_REPLY [25-09-2023(online)].pdf | 2023-09-25 |
| 18 | 201924053903-DRAWING [25-09-2023(online)].pdf | 2023-09-25 |
| 19 | 201924053903-CLAIMS [25-09-2023(online)].pdf | 2023-09-25 |
| 20 | 201924053903-ABSTRACT [25-09-2023(online)].pdf | 2023-09-25 |
| 1 | SearchStrategyMatrixE_12-04-2023.pdf |
| 2 | SearchStrategyforApplicationNo201924053903AE_03-06-2024.pdf |