Description:[0001] The present disclosure relates to payment transaction processing systems in payment ecosystems and, more particularly to methods and systems for enabling payment mandates for payment cards via a Unified Payments Interface (UPI).
BACKGROUND
[0002] As the financial sector has been continuously digitized over recent times, various methods and systems for performing or facilitating the digital transfer of funds between different entities such as users/cardholders and merchants have been developed. For instance, digitally settled transactions may include transactions settled via electronic transfer of funds using Immediate Payment Service (IMPS) or payment instruments such as payment cards (e.g., debit cards, credit cards, and the like). One such popular method for digitally settling transactions is Unified Payment Interface (UPI). UPI is an instant payment system developed by the National Payments Corporation of India (NPCI)®. The UPI system provides an open-source application programming interface (API) for facilitating inter-bank peer-to-peer (P2P i.e., account holder to account holder) and person-to-merchant (P2M i.e., account holder to merchant) transactions. In other words, a user can use the UPI system to instantly transfer funds between two different bank accounts. Using UPI, a merchant can accept payments from a cardholder using only a registered mobile device, without any additional account number requirement. Due to the simplicity and ease of use provided by the UPI system, its popularity has increased greatly in recent times. Further, the user-friendliness of the UPI system has contributed to its widespread adoption, making UPI a preferred choice for payment settlements across various countries.
[0003] However, despite the fast and secure fund transfer capabilities of the existing UPI payment rail, it suffers from various limitations as well. For instance, while UPI supports the integration of the UPI payment rails with existing payment card rails (e.g., credit card payment rails), the existing UPI system fails to provide comprehensive support for integrating the services offered by the payment cards. Consequently, account holders may be discouraged from utilizing the UPI system and prefer to rely solely on their payment cards. It is worth noting that settling payment transactions solely through payment cards also presents its own set of limitations. For instance, while performing payments via a payment card, the account holder or the cardholder is at a high risk of frauds such as skimming, card cloning, and the like. Furthermore, the merchant accepting the payment faces a variety of problems as well. For instance, for accepting payments via a payment card, the merchant has to set up a point-of-sale (POS) device, a secure database for storing cardholder details (for regulatory purposes), and bearing additional fees, all of which contribute to increased financial burden for the merchants.
[0004] Hence, there exists a technological need for an approach or solution for addressing the above-mentioned technical problems or limitations among other problems to overcome the limitations of the conventional UPI payment rail.
SUMMARY
[0005] Various embodiments of the present disclosure provide methods and systems for enabling payment mandates for payment cards via a Unified Payments Interface (UPI).
[0006] In an embodiment, a computer-implemented method performed by a server system includes receiving a Unified payment interface (UPI)-card payment initiation request from an electronic device for processing a payment transaction initiated by a cardholder with a merchant in multiple installments. Herein, the UPI-card payment initiation request includes a UPI identifier (ID) associated with the cardholder and transaction related information. Further, the method includes accessing payment card data corresponding to each of the one or more payment cards associated with the cardholder linked with the UPI ID from a database associated with the server system. Herein, the payment card data may include at least a Personal Account Number (PAN) of a payment card. Further, the method includes determining one or more eligible payment cards from the one or more payment cards based, at least in part, on corresponding payment card data. Herein, the one or more eligible payment cards indicate payment cards that are eligible for a payment installment option. Further, the method includes generating a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information. Herein, each installment option of the plurality of installment options includes information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure. Further, the method includes facilitating a display of the plurality of installment options on the electronic device.
[0007] In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a Unified payment interface (UPI)-card payment initiation request from an electronic device for processing a payment transaction initiated by a cardholder with a merchant in multiple installments. Herein, the UPI-card payment initiation request includes a UPI identifier (ID) associated with the cardholder and transaction related information. Further, the server system is caused to access payment card data corresponding to each of the one or more payment cards associated with the cardholder linked with the UPI ID from a database associated with the server system. Herein, the payment card data includes at least a Personal Account Number (PAN) of a payment card. Further, the server system is caused to determine one or more eligible payment cards from the one or more payment cards based, at least in part, on corresponding payment card data. Herein, the one or more eligible payment cards indicate payment cards that are eligible for a payment installment option. Further, the server system is caused to generate a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information. Herein, each installment option of the plurality of installment options includes information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure; Further, the server system is caused to facilitate a display of the plurality of installment options on the electronic device.
[0008] In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a Unified payment interface (UPI)-card payment initiation request from an electronic device for processing a payment transaction initiated by a cardholder with a merchant in multiple installments. Herein, the UPI-card payment initiation request includes a UPI identifier (ID) associated with the cardholder and transaction related information. Further, the method includes accessing payment card data corresponding to each of the one or more payment cards associated with the cardholder linked with the UPI ID from a database associated with the server system. Herein, the payment card data includes at least a Personal Account Number (PAN) of a payment card. Further, the method includes determining one or more eligible payment cards from the one or more payment cards based, at least in part, on corresponding payment card data. Herein, the one or more eligible payment cards indicate payment cards that are eligible for a payment installment option. Further, the method includes generating a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information. Herein, each installment option of the plurality of installment options includes information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure; Further, the method includes facilitating a display of the plurality of installment options on the electronic device.
[0009] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which.
[0011] FIG. 1 illustrates an exemplary representation of an environment related to at least some embodiments of the present disclosure;
[0012] FIG. 2 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0013] FIG. 3 is a sequence flow diagram depicting a process for linking a UPI payment rail with the payment card payment rail, in accordance with an embodiment of the present disclosure;
[0014] FIGS. 4A and 4B, collectively, depict a sequence flow diagram of a process for enabling payment mandate for payment cards via UPI payment rail for cardholder-initiated mandates, in accordance with an embodiment of the present disclosure;
[0015] FIGS. 5A and 5B, collectively, depict a sequence flow diagram of a process for enabling payment mandate for payment cards via UPI payment rail for merchant-initiated mandates, in accordance with an embodiment of the present disclosure;
[0016] FIG. 6 is a sequence flow diagram depicting a process for processing an installment payment between the merchant and the issuer, in accordance with an embodiment of the present disclosure;
[0017] FIGS. 7A-7G, collectively, illustrate various Graphical User Interfaces (GUIs) illustrating the process of generating a payment mandate, in accordance with various embodiments of the present disclosure;
[0018] FIGS. 8A and 8B, collectively, illustrate a method for enabling payment mandates for payment cards via a UPI system, in accordance with an embodiment of the present disclosure; and
[0019] FIG. 9 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
[0020] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.
DETAILED DESCRIPTION
[0021] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0022] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0023] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0024] Embodiments of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” "engine" “module” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
[0025] The term "payment account" used throughout the description refers to a financial account that is used to fund a financial transaction (interchangeably referred to as "card-on-file payment transaction" or “UPI payment transaction”). Examples of financial accounts include, but are not limited to, a savings account, a credit account, a checking account, a virtual payment account, a digital wallet, and the like. The financial account may be associated with an entity (known as an account holder) such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, a financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like. In other scenarios, the financial account may be linked to the UPI system by a mobile number of the account holder that is registered with the payment account at the issuer’s end.
[0026] The term “payment rail” refers to an underlying infrastructure or systems that facilitate the movement of funds between different entities involved in a payment transaction. In particular, a payment rail provides the necessary channels and protocols for securely transferring funds. Various examples of payment rails include a payment card payment rail (e.g., credit card payment rail and debit card payment rail), UPI payment rail, wire transfer payment rail, and the like. The payment card payment rail enables transactions using payment cards. They involve networks such as a payment service provider (e.g., Mastercard®) which connects the account holders also referred to (hereinafter interchangeably as ‘cardholders’), merchants, and financial institutions (such as issuer and acquirer) for authorizing and processing payment card-dependent transactions. The UPI payment rail facilitates seamless and instant fund transfers between different bank accounts.
[0027] The term ‘account holder’ used throughout the description refers to an owner of the payment account managed or linked to an issuing bank. Examples of the account holder include an entity associated with the issuing bank that has either a savings account, a credit account, a checking account, or a virtual payment account with the issuing bank. In some scenarios, the account holder may be issued a payment card (such as a credit card, debit card, or the like.) by the issuing bank. Upon being issued the payment card, the account holder can also be called a cardholder. To that end, the term "cardholder" as used throughout the description, and refers to a person (i.e., the account holder) who holds a payment card (such as a credit or a debit card) that will be used by the cardholder at a merchant (or another cardholder) to perform a card-on-file payment transaction. It should be noted that the terms account holder and cardholder are used interchangeably throughout the description for the purposes of explanation however, the account holder doesn’t necessarily have to be a cardholder. Further, it is understood that the payment account of the account holder may be linked to the UPI system via their mobile number that is registered with the payment account at the issuer’s end. Furthermore, in some instances, the payment card of the cardholder may be linked to the UPI system as well.
[0028] The term "payment network", used herein, refers to a network or collection of systems used for the transfer of funds through the use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include goods or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
[0029] The term "merchant", used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity. It is understood that in the context of UPI transactions, instead of a merchant, funds may be transferred to another cardholder (or accountholder) for any number of reasons as well.
OVERVIEW
[0030] Various embodiments of the present disclosure provide methods, systems, user devices, and computer program products for enabling payment mandates for payment cards via UPI.
[0031] In an embodiment, a server system is configured to receive a card link initiation request from the electronic device associated with the cardholder. In response to the card linking request, the server system is configured to access the UPI ID associated with the cardholder and the payment card data corresponding to each of the one or more payment cards associated with the cardholder from the electronic device. Further, the server system is configured to generate and transmit a card linking request for at least one of the one or more payment cards to an issuer server associated with the cardholder. Furthermore, upon receiving a card linking approval from the issuer server corresponding to at least one of the one or more payment cards, the server system is configured to link the at least one of the one or more payment cards with the UPI ID associated with the cardholder based, at least in part, on the corresponding payment card data.
[0032] In another embodiment, the server system is configured to receive a Unified payment interface (UPI)-card payment initiation request from an electronic device for processing a payment transaction initiated by a cardholder with a merchant in multiple installments. In various scenarios, the electronic device may be associated with one of the cardholder or the merchant. For instance, the electronic device may be a smartphone of the cardholder when the cardholder wishes to perform a transaction with the merchant through installments on their payer PSP application. On the other hand, the electronic device may be a merchant Point of Sale (POS) when the cardholder wishes to perform a transaction with the merchant through installments on using the Payee PSP application of the merchant. In other instances, the cardholder may perform the transaction on an instance of the payee PSP application running within a merchant application installed/operating on the electronic device associated with the cardholder as well. Herein, the UPI-card payment initiation request includes a UPI identifier (ID) associated with the cardholder and transaction related information.
[0033] In another embodiment, the server system is configured to access payment card data corresponding to each of the one or more payment cards associated with the cardholder linked with the UPI ID from a database associated with the server system. Herein, the payment card data may include at least a Personal Account Number (PAN) of a payment card.
[0034] In another embodiment, the server system is configured to determine one or more eligible payment cards from the one or more payment cards based, at least in part, on corresponding payment card data. Herein, the one or more eligible payment cards indicate payment cards that are eligible for a payment installment option. In an example, for determining the one or more eligible payment cards at first the server system generates and transmits an eligibility check request to one or more installment service providers. In one example, the eligibility check request includes the payment card data. Then, in response to the eligibility check request, the server system receives an eligibility check response from the one or more installment service providers. Herein, the eligibility check response indicates the one or more eligible payment cards.
[0035] In another embodiment, the server system is configured to generate a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information. Herein, each installment option of the plurality of installment options includes information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure. In an example, for generating the plurality of installment options at first the server system generates and transmits an installment option request to one or more installment service providers. Herein, the installment option request includes the payment card data corresponding to the one or more eligible payment cards. Further, in response to the installment option request, the server system receives an installment option response from the one or more installment service providers. Herein, the installment option response includes the plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards.
[0036] In another embodiment, the server system is configured to receive an installment initiation request including a selected installment option from the plurality of installment options by the cardholder. Upon receiving the installment initiation request the server system is configured to facilitate authentication of the cardholder by the issuer server, based, at least in part, on the UPI ID and the selected installment option. Further, upon successful authentication by the issuer server, generate and transmit by the server system a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to the UPI server. Herein, the UPI card payment mandate registration request includes mandate related information such that the mandate related information includes the UPI ID and the selected installment option. In an example, upon receiving the UPI card payment mandate registration request, the UPI server is configured to first register the mandate with the issuer server of the eligible payment card corresponding to the selected installment option based, at least in part, on the UPI ID and the selected installment option. Herein, the selected installment option is associated with the payment card from which the installment has to be deducted. Then, the UPI server is configured to transmit a mandate registration successful message to the server system upon successful mandate registration with the issuer server.
[0037] In another embodiment, the server system is configured to generate a Unique Mandate Reference Number (UMRN) linked to the PAN of the payment card for the mandate corresponding to the UPI ID and the selected installment option. Then, the server system is configured to generate and transmit a UPI card mandate authorized message to at least one of the cardholder and the merchant. Herein, the UPI card mandate authorized message includes the UMRN linked to the PAN of the payment card.
[0038] In another embodiment, the server system is configured to receive an installment payment authorization request from an acquirer server associated with the merchant. Herein, the installment payment authorization request includes the UMRN linked to the PAN of the payment card. It is noted that the PAN can be masked or encrypted as well. Then, the server system is configured to access the mandate corresponding to the UPI ID and the selected installment option from the database based, at least in part, on the UMRN linked to the PAN of the payment card. Further, the server system is configured to generate and transmit a mandate payment authorization request to the UPI server for processing the installment payment transaction between the cardholder and the merchant. In one example, the mandate payment authorization request includes the mandate corresponding to the UPI ID, and the selected installment option. More specifically, upon receiving the mandate payment authorization request, the UPI server is configured to at first request the issuer server associated with the cardholder to authorize the installment payment transaction for the mandate based, at least in part, on the UPI ID and the selected installment option. Then, upon successful installment payment transaction authorization by the issuer server, the UPI server is configured to process the installment payment transaction with an acquirer server associated with the merchant.
[0039] In another embodiment, the server system is configured to facilitate a display of the plurality of installment options on the electronic device. More specifically, the server system facilitates the display of one or more graphical user interfaces (GUIs) on the electronic device associated with the cardholder through the plurality of installment options displayed on the electronic device.
[0040] Various embodiments of the present disclosure provide multiple advantages and technical effects while addressing technical problems such as how to link the UPI payment rail with the payment card payment rail for enabling payment mandates for payment cards via UPI. Various embodiments address this technical problem by connecting the UPI payment rail with the payment card payment rail. Further, various embodiments allow the generation of a payment mandate for payment cards using the UPI payment rail. Further, various embodiments allow the cardholder to avail the ability to pay in installments created on the payment card through the UPI system. Furthermore, the various embodiments of the present disclosure enable either or both the Payer PSP or Payee PSP to generate UPI-card payment mandates. In other words, the present disclosure provides a universal approach that can be used by both the Payer PSP and Payee PSP to generate the UPI card payment mandates with ease and reduced complexity.
[0041] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for linking one or more payment cards associated with a cardholder with a UPI system, providing a plurality of installments options for different eligible payment cards of the cardholder to the cardholder using the UPI system, generating payment mandates for payment cards associated with the cardholder using UPI system, and the like for enabling the cardholder to complete a payment transaction in installments over a time period using payment mandates executed on the UPI system.
[0042] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, generating payment mandates for payment cards associated with a cardholder using the UPI system, etc. The environment 100 generally includes a plurality of entities, for example, a server system 102, a cardholder 104 associated with an electronic device 106, one or more payment cards 108(1), 108(2), and 108(3) (hereinafter collectively referred to interchangeably as ‘one or more payment cards 108’ or ‘payment card 108’) associated with the cardholder 104, an issuer server 110, an acquirer server 112, a merchant 114, a Unified Payment Interface (UPI) server 116 (referred to hereinafter as ‘UPI server 116’), a database 118, a payment network 124 including a payment server 126, each coupled to, and in communication with (and/or with access to) a network 120. The network 120 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among the entities illustrated in FIG. 1, or any combination thereof.
[0043] Various entities in the environment 100 may connect to the network 120 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. For example, the network 120 may include multiple different networks, such as a private network made accessible by the payment network 124 to the issuer server 110, the acquirer server 112, the UPI server 116, the server system 102, and the payment server 126, separately, and a public network (e.g., the Internet, etc.).
[0044] In an embodiment, the issuer server 110 is a computing server that is associated with an issuer bank of the cardholder 104 (i.e., an account holder). The issuer bank is a financial institution that manages the accounts of multiple cardholders. Account details of the accounts established with the issuer bank are stored in the cardholder profiles of the account holder in a memory of the issuer server 110 or on a cloud server associated with the issuer server 110. The issuer server 110 is responsible for approving or denying any request associated with a payment transaction such as a payment authorization request. The terms “issuer”, “issuer bank”, “issuing bank” or “issuer server” are used interchangeably herein for the sake of description.
[0045] In an embodiment, the merchant 114 may be a retail shop, a restaurant, a supermarket or an establishment, a government and/or private agency, or any such places equipped with POS terminals or UPI QR codes, where cardholders such as the cardholder 104 may visit for performing the financial transaction in exchange for any goods and/or services. Such scenarios are an example of Card-Present (CP) transactions or UPI transactions, respectively. In another embodiment, the merchant 114 may also be a digital retailer or digital service provider that has a digital platform where the cardholder 104 may log on to perform a financial transaction in exchange for any goods and/or services. In such a scenario, the transaction performed by the cardholder 104 is called a Card-Not-Present (CNP) transaction. In a non-limiting example, the merchant 114 may be associated with a Payee Payment Service Provider (PSP) or the merchant 114 may hold a Payee PSP license. It is noted that the term ‘merchant’ may be referred to interchangeably with the term ‘Payee PSP’.
[0046] In an embodiment, the merchant 114 is associated with the acquirer server 112. In an embodiment, the acquirer server 112 is a computing server that is associated with an acquirer bank of any merchant such as the merchant 114. The acquirer bank is a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein for the sake of description.
[0047] In an embodiment, the UPI server 116 is a computing server that facilitates interaction between an issuer server 110 and an acquirer server 112 for carrying out financial transactions. The UPI server 116 is managed by an institution that processes financial transactions between any two entities, for example, cardholder-merchant transactions, cardholder-cardholder transactions, and merchant-merchant transactions. It is understood for processing the transaction, the cardholder 104 has to register themselves with the payer PSP application with their registered mobile number (i.e., the mobile number used by the cardholder to register their payment account with the issuer server 110). Upon successful registration, a UPI identifier (ID) and a UPI Personal Identification Number (UPI PIN) can be assigned to or generated by the cardholder 104. Thereafter, the cardholder 104 can perform any payment transaction using any third-party application associated or linked with the UPI server 116 using their UPI ID and UPI PIN. It is noted that the term “UPI ID” (or Virtual payment address (VPA)) refers to a unique identifier, associated with the financial/bank account of the registered user (i.e., payment account of the cardholder 104). In other words, the UPI ID is associated with the payment account of the account holder (i.e., the cardholder 104) with the issuer server 110. As described earlier, the UPI ID can be used to carry out payment transactions. In some scenarios, the UPI ID may include a registered mobile number, an Aadhaar number, a bank account number, or any other identifier that can uniquely and securely identify the registered user (i.e., the cardholder 104). In some scenarios, formats of UPI ID may include [username]@[VPA], [username]@[bankname], and the like.
[0048] In an embodiment, the cardholder 104 may be any individual, representative of a corporate entity, a non-profit organization, or any other person that is associated with a payment card 108 offered by the issuer server 110. In a non-limiting example, the cardholder 104 may perform UPI based payment transactions using an application known as Payer PSP application. It is noted that the term ‘cardholder’ may be referred to interchangeably with the term ‘Payer PSP’ for the sake of simplicity as well. Further, the cardholder 104 may perform an electronic payment transaction using the payment card 108 using an application supporting UPI transactions, i.e., the payer PSP application. In some scenarios, the cardholder 104 may have a payment account issued by an issuing bank (not shown in figures) associated with the issuer server 110 and may be provided a payment card such as payment card 108(1) with financial or other account information encoded onto the payment card 108(1) such that the cardholder 104 may use the payment card 108(1) to initiate and complete a payment transaction using a bank account at the issuing bank.
[0049] In an example, the cardholder 104 may use the electronic device 106 to access a mobile application such as an application supporting the UPI system for performing a payment transaction with the merchant 114. In various non-limiting examples, the electronic device 106 may include any portable communication devices such as a smartphone, tablet, personal digital assistant (PDA), phablet, wearable device, smartwatch, laptop computer, an augmented reality (AR) headset, a virtual reality (VR) headset, and the like. In some other examples, the electronic device 106 may include any fixed communication device such as a desktop, mainframe computer, workstation, and the like. In one exemplary implementation, the electronic device 106 may be equipped with an application (such as an instance of the payment application 122 described later on) for communicating with the server system 102 and the UPI server 116 over the network 120. In various non-limiting examples, the application may correspond to a web browser, an application associated with the UPI server 116, an application programming interface (API) associated with the UPI server 116, an application associated with the server system 102, an API associated with the server system 102, and the like.
[0050] As may be understood, a cardholder 104 may have one or more payment accounts with different issuers therefore, a cardholder 104 may actually own more than one payment card. In another scenario, an issuer server 110 may provide more than one payment card to the cardholder 104 as well. To that end, it is noted that the cardholder 104 may be associated with one or more payment cards 108. In some non-limiting examples, the one or more payment cards 108 may include at least one of a credit card, a debit card, a charge card, an automatic teller machine (ATM) card, a rewards card, and the like.
[0051] In an embodiment, the payment server 126 is a computing server that is associated with a payment processing financial institution (e.g., Mastercard®) that facilitates the communication between the issuer server 110, the acquirer server 112, and the UPI server 116. In various non-limiting examples, various messages and requests are exchanged between the issuer server 110, the acquirer server 112, and the UPI server 116 through the payment server 126. For example, the issuer server 110 routes an authorization response message to the acquirer server 112 via the payment network 124 through the payment server 126.
[0052] In an exemplary scenario, to perform a payment transaction, the cardholder 104 may wish to use the UPI system due to it being fast, secure, and hassle-free. To that end, for performing the transaction, the cardholder 104 may open an Application (or App) associated or linked with the UPI server 116 on their electronic device 106 and add the UPI ID of the merchant 114. Thereafter, the cardholder 104 can enter the desired amount which they wish to transfer to merchant 114 in the App followed by their UPI PIN to authenticate and complete the funds transfer. Upon successful authentication, the funds will be transferred to the merchant’s bank account associated with their UPI ID. In other scenarios, the cardholder 104 may wish to perform the payment transaction using their payment card. As may be understood, to achieve this, the cardholder 104 can either link their payment card 108(1) with their UPI ID or use it to complete the transaction, or use their payment card 108(1) directly. It is noted that each of these approaches faces various limitations. In the first scenario, while the existing UPI system supports the integration of UPI payment rails with the existing payment card 108(1) payment rails, the existing UPI system fails to provide comprehensive support for integrating the services offered by the payment cards. For instance, UPI lacks features like generating payment mandates for payment cards within the UPI framework (or the UPI payment rail) and offering installment facilities to the account holders when conducting transactions using payment cards via the UPI system.
[0053] Consequently, cardholders may be discouraged from utilizing the UPI system and prefer to rely solely on their payment cards to complete the payment transaction. However, this second scenario also presents its own set of limitations. For instance, while performing payments via a payment card 108(1), the cardholder 104 is at a high risk of fraud such as skimming, card cloning, and the like. Furthermore, the merchant accepting the payment faces a variety of problems as well. For instance, for accepting payments via a payment card, the merchant has to set up a point-of-sale (POS) device, a secure database for storing cardholder details (for regulatory purposes), and bearing additional fees, all of which contribute to increased financial burden for merchants.
[0054] To address the above-mentioned technical problem among other problems, the server system 102 provided by the present disclosure is configured to perform one or more of the operations described herein. In one non-limiting example, the server system 102 is embodied in the payment server 126. In some scenarios, the server system 102 is a separate part of the environment 100 and may operate apart from (but still in communication with, for example, via the network 120), the issuer server 110, the acquirer server 112, the UPI server 116, the payment server 126, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 126. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 120, which may be specifically configured, via executable instructions, to perform as described herein, and/or embodied in at least one non-transitory computer-readable media. In a non-limiting scenario, the server system 102 may be used by both the payer (i.e., cardholder 104) PSP and the payee (i.e., merchant) PSP to perform the different functionalities described with reference to various embodiments herein. In an embodiment, the server system 102 may be any server that is capable of running or providing an instance of a payment application 122 or UPI-supported application to a cardholder’s electronic device 106. In other scenarios, the server system 102 may be configured to provide various functionalities described with reference to various embodiments herein to different payee PSPs or payer PSPs via different API calls and API responses.
[0055] In an embodiment, the server system 102 is associated with the database 118, In one embodiment, the database 118 is a central repository for storing data including the UPI ID of the cardholder 104, payment card data associated with each of the one or more payment cards 108 of the cardholder 104, transaction data, machine-readable instructions, and algorithms for operating the server system 102. In various implementations, the database 118 can be embodied within the server system 102, as a part of the server system 102, or as an independent entity that is communicably coupled with the server system 102 via the network 120.
[0056] In various non-limiting examples, the database 118 may include one or more hard disk drives (HDD), solid-state drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a redundant array of independent disks (RAID) controller, a storage area network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 118. In one implementation, the database 118 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 118.
[0057] In another embodiment, the server system 102 is configured to run an instance of a payment application 122 or UPI-supported application (referred, interchangeably hereafter). In one embodiment, the server system 102 utilizes the payment application 122 to facilitate payment transactions between the cardholder 106 and the merchant 114. In one embodiment, the payment application 122 is an application/tool resting at the server system 102. In another embodiment, the payment application 122 is configured to facilitate a payment transaction using the UPI payment rail for a payer PSP or a payee PSP.
[0058] In an embodiment, the payment application 122 may include one or more graphical user interfaces for facilitating the cardholder 104 to perform a payment transaction with the merchant 114 using the one or more payment cards 108 associated with the cardholder 104. In one embodiment, the electronic device 106 is communicably coupled with the server system 102 through the network 120 and the electronic device 106 is capable of interacting with the payment application 122 associated with the server system 102 through a web browser or an application programming interfaces (APIs) installed on the electronic device 106. In other words, the electronic device 106 of the cardholder 104 is capable of performing one or more operations using the payment application 122. In one implementation, the payment application 122 utilizes communication application programming interfaces (APIs) to communicate back and forth with the electronic device 106. In an example, the payment application 122 utilizes various distribution methods for sharing one or more messages, requests, or responses with the cardholder 104. In various non-limiting examples, the distribution methods may include short message service (SMS), electronic mail (email), communication APIs, embeddable widgets, and the like. In an example, the payment application 122 utilizes communication APIs to share the results of their various operations (described later on) with the server system 102 or the electronic device 106. Herein, it is understood that the term “API” generally refers to a set of programming standards and/or instructions for web-based applications and tools. For instance, “communication APIs” refer to APIs specifically designed to enable communication (e.g., voice calls, e-mail functionality, third-party messaging functionality, other communication functionality, etc.).
[0059] In some scenarios, the payment application 122 may include a mobile application or “app”. In various non-limiting examples, the payment application 122 may be a UPI-based application (i.e., an application that allows a cardholder 104 to perform a transaction using UPI server 116) installed and accessed in the electronic device 106. Herein, in various examples, the electronic device 106 may be an Android®-based smartphone, an iOS®-based iPhone®, iPadOS®-based iPad®, a Windows®-based computer, a macOS®-based computer, an augmented reality (AR) device, a virtual reality (VR) device, and the like. The payment application 122 may also include a “plug-in” or an “extension” to another application, such as a pre-existing application (i.e., a third-party application) or API associated with the third-party application that supports performing UPI transactions. For instance, a third-party application that supports UPI transactions may use or utilize the API associated with the payment application 122 of the server system 102 or an API associated with the instance of the payment application 122 to implement the functionality of the payment application 122 within the third-party application. In an implementation, the payment application 122 is managed, hosted, or executed by the server system 102 or the UPI server 116. In another implementation, the payment application 122 is managed, hosted, or executed by a communication device (not shown in figures) associated with the server system 102 or the UPI server 116. In a non-limiting example, the payment application 122 may be a payer PSP application depending on the set of operations to be performed. In another non-limiting example, the payment application 122 may be a payee PSP application depending on the set of operations to be performed.
[0060] In an embodiment, the payment application 122 associated with the server system 102 is configured to perform one or more of the operations described herein. The payment application 122 associated with the server system 102 is configured to receive a UPI-card payment initiation request from the electronic device 106 associated with the cardholder 104 for settling/processing/completing a payment transaction with the merchant 114 in multiple installments (e.g., installments of 3 months, 6 months, 9 months and so on). In an example, the UPI-card payment initiation request may at least include the UPI ID associated with the cardholder 104 and transaction related information. In various non-limiting examples, the transaction related information may at least include information related to at least the merchant’s UPI ID, the transaction amount, and the like. In other examples, the transaction related information may include information related to at least a merchant name identifier, a unique merchant identifier, timestamp information, geo-location related data, a merchant category code (MCC), information related to payment instruments involved in the set of historical payment transactions, a cardholder identifier (ID), a permanent account number (PAN), a merchant database name, a country code, a transaction identifier and the like. It is noted that the PAN indicates the card number of a particular payment card 108 held by the cardholder 104.
[0061] Then, the payment application 122 is configured to access payment card data corresponding to each of the one or more payment cards 108 associated with the cardholder 104 linked with the UPI ID from the database 118 associated with the server system 102. In various examples, the payment card data may include information related to cardholder ID, issuer ID, payment card category, payment card type, product name, product type, PAN of a payment card, and the like. It is understood that payment card data corresponding to different payment cards will be different. For example, a first payment card issued by a first issuer to a cardholder 104 will have corresponding payment card data that is different from the corresponding payment card data of a second payment card issued by a second issuer (or the same issuer when the payment card category or type is different) to the same cardholder. In one example, if payment card 108(1) and payment card 108(2) are considered, the payment card data corresponding to the payment card 108(1) will be distinct from the payment card data corresponding to the payment card 108(2).
[0062] Thereafter, the payment application 122 is configured to determine one or more eligible payment cards from the one or more payment cards 108 based, at least in part, on the corresponding payment card data. Herein, the one or more eligible payment cards indicate the payment cards that are eligible for a payment installment option from within the one or more payment cards 108. For example, if payment card 108(1), payment card 108(2), and payment card 108(3) are considered, then only payment card 108(1) and payment card 108(3) may be determined to be eligible for the payment installment option. The process for determining or assessing the eligibility of each of the one or more payment cards 108 is described later in the present disclosure.
[0063] Further, the payment application 122 is configured to generate a plurality of installment options corresponding to each eligible payment card such as payment card 108(1) of the one or more eligible payment cards based, at least in part, on the corresponding payment card data and transaction related information. In one embodiment, each installment option of the plurality of installment options may include information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure. Then, the payment application 122 is configured to facilitate a display of the plurality of installment options on the electronic device 106 associated with the cardholder 104. It is understood that upon receiving this plurality of installment options, the cardholder 104 may consider or select any installment option from the plurality of installment options on their own for completing the payment transaction. Upon performing this selection, the electronic device 106 generated an installment initiation request for the payment application 122. In various non-limiting examples, the installment initiation request includes at least the selected installment option from the plurality of installment options by the cardholder 104. To that end, upon performing this selection the payment application 122 is configured to receive the installment initiation request. Upon receiving the installment initiation request, the payment application 122 is configured to facilitate authentication of the cardholder 104 by the UPI server 116, based, at least in part, on the UPI ID of the cardholder 104 and the selected installment option. In various scenarios, the authentication of the cardholder 104 may include asking the cardholder 104 to input their UPI PIN and validating the UPI PIN using the issuer server 110 by the payment application 122. Further, upon successful authentication by the issuer server 110, the payment application 122 is configured to generate and transmit a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card 108(1) to the UPI server 116. In an example, the UPI card payment mandate registration request may include at least mandate related information. In various non-limiting examples, the mandate related information includes at least the UPI ID and the selected installment option. It is understood that the UPI card payment mandate is generated on the UPI payment rail, therefore the mandate generation process as described earlier has the advantages of the UPI system and it also addresses the various limitations or disadvantages described earlier.
[0064] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device as shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0065] FIG. 2 is a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. It is noted that the server system 200 is identical to the server system 102 of FIG. 1. In one embodiment, the server system 200 is a part of the payment server 126. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture. The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, a storage interface 212, and a user interface 216 that communicate with each other via a bus 214. It is noted that the server system 200 may facilitate various functionalities to both the payer PSP and the payee PSP depending on the application of the various embodiments of the present disclosure.
[0066] In some embodiments, the database 204 is integrated into the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. The storage interface 212 is any component capable of providing the processor 206 with access to the database 204. The storage interface 212 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204. In one implementation, the database 204 is configured to store a UPI ID 228, payment card data 230, and transaction related information 232.
[0067] In an embodiment, the UPI ID 228 is a unique identifier (ID) that is assigned to or generated by the cardholder 104 at the time of registering with the UPI system. It is noted that the UPI ID 228 is linked to the payment account of the cardholder 104 with a particular issuer server 110. Further, each UPI ID 228 is associated with a UPI PIN that can be used by the cardholder 104 to validate or authenticate their identity with the UPI server 116 in order to authenticate a payment transaction. In an example, the UPI ID 228 is made up of two distinct portions. The two distinct portions include a ‘username portion’ and a ‘bank name portion’. For instance, a UPI ID 228 may be represented as [username]@[bank name]. It is also understood, that instead of [bank name], the term ‘UPI’ can also be used e.g., [username]@VPA. In various non-limiting examples, the UPI PIN may be a 4-digit PIN code, a 6-digit PIN code, and the like. It is noted that the same UPI ID may be linked to different payment accounts of the cardholder 104 associated with different issuers. For instance, ABC@VPA might be linked to a payment account A offered by Bank A with UPI PIN ‘1234’ and a payment account B offered by Bank B with UPI PIN ‘4321’. Furthermore, different UPI IDs may be created for the same payment account of the cardholder 104 offered by the same issuer by different payer PSP applications as long as the UPI PIN associated with the payment account remains the same. For instance, ABC@VPA, DEF@VPA, and GHI@VPA may be assigned to a payment account A offered by Bank A with UPI PIN ‘1234’. It is noted that the process for the generation of a UPI ID 228 along with a UPI PIN is well known in the art, therefore the same is not repeated herein for the sake of brevity.
[0068] In an embodiment, the payment card data 230 is data associated with each payment card of the one or more payment cards 108 associated with the cardholder 104. As may be understood, since each payment card is unique, therefore, the payment card data 230 associated with it will be unique as well. In various non-limiting examples, the payment card data 230 includes at least information related to cardholder ID, issuer ID, payment card category, payment card type, product name, product type, and the like. As described earlier, the payment data 230 corresponding to different payment cards will be different. For example, the payment data corresponding to payment card 108(2) will be different from the payment card data corresponding to payment card 108(3). In one scenario, even if the same issuer issues different payments cards (e.g., payment card 108(2) and payment card 108(3)) to the same cardholder, the corresponding payment card data for the payment card 108(2) and the corresponding payment card data of the payment card 108(2) will be distinct since this different payment card will at least have a different product name or different product type.
[0069] In an embodiment, the transaction related information 232 includes information related to an ongoing payment transaction between the cardholder 104 and the merchant 114. For instance, when a cardholder 104 opts to perform a payment transaction using an application that supports UPI transactions (such as payment application 122), at first the cardholder 104 may enter the merchant’s UPI ID into the payment application 122 as an input, followed by a transaction amount associated with the payment transaction. In some scenarios, the payment application 122 may provide a facility to cardholder 104 through which the cardholder 104 may scan a Quick Response (QR) code associated with or provided by the merchant 114 to identify the merchant’s UPI ID. Further, to initiate the transaction process, the cardholder 104 may validate or authenticate their identity using their UPI PIN. Upon successful authentication by the issuer server 110, the UPI server 116 may initiate the transfer of funds, thus completing the payment transaction. To that end, it should be noted that the transaction related information 232 is captured during the described payment process. In various non-limiting examples, the transaction related information 232 includes at least the merchant’s UPI ID, the transaction amount, and the like. In other examples, the transaction related information may include information related to at least a merchant name identifier, a unique merchant identifier, timestamp information, geo-location related data, a merchant category code (MCC), information related to payment instruments involved in the set of historical payment transactions, a cardholder identifier, a permanent account number (PAN), a merchant database (DBA) name, a country code, a transaction identifier and the like.
[0070] In various embodiments, the processor 206 includes suitable logic, circuitry, and/or interfaces to execute computer-readable instructions for performing various operations described with respect to the payment application 122 described earlier among other operations. Examples of the processor 206 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 memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
[0071] The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 218 such as an electronic device 106 associated with the cardholder 104, an external database, the UPI server 116, or communicate with any entity connected to the network 120 (as shown in FIG. 1). Further, the processor 206 is operatively coupled to the user interface 216 for performing one or more embodiments described herein. The user interface 216 is an interface such as a Human Machine Interface (HMI) or a software application that allows users such as an administrator to interact with and control the server system 200 or one or more parameters associated with the server system 200. It may be noted that the user interface 216 may be composed of several components that vary based on the complexity and purpose of the application. Examples of components of the user interface 216 may include visual elements, controls, navigation, feedback and alerts, user input and interaction, responsive design, user assistance and help, accessibility features, and the like. More specifically these components may correspond to icons, layout, color schemes, buttons, sliders, dropdown menus, tabs, links, error/success messages, mouse and touch interactions, keyboard shortcuts, tooltips, screen readers, and the like.
[0072] It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.
[0073] In one embodiment, the processor 206 includes an UPI-card linking module 220, an installment option generation module 222, a mandate generation module 224, and a payment processing module 226. It should be noted that components, described herein, such as the UPI-card linking module 220, the installment option generation module 222, the mandate generation module 224, and the payment processing module 226 can be configured in a variety of configurations, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies. Further, it is noted that the various components (or modules) of the processor 206 are communicably coupled with each other and are configured to transmit data and receive data to/from each other. In one implementation, the processor 206 is configured to run or execute an algorithm (stored in the database 204) for generating a plurality of installment options for the cardholder 104 while also enabling the creation of payment mandates for one or more payment cards 108 associated with the cardholder 104 via the UPI system (i.e., the UPI server 116).
[0074] In an embodiment, the UPI-card linking module 220 includes suitable logic and/or interfaces for receiving a card link initiation request from the electronic device 106 associated with the cardholder 104 for initiating the UPI-card linking process. In a non-limiting example, the UPI-card linking process may be initiated by the cardholder 104 for adding at least one of the one or more payment cards 108 associated with them with their UPI ID 228. It is understood that upon linking at least one of the one or more payment cards 108 with their UPI ID 228, the cardholder 104 can now choose to enable the option of processing any or eligible payment transactions using any of the one or more payment cards 108. For instance, in some non-limiting scenarios, the option of processing payment transactions may be shown for transactions over a certain amount or with eligible merchants. Now, upon receiving the card link initiation request on the electronic device 106, the cardholder 104 may enter his/her credentials in the payment application 122 to authorize the card link initiation request. For instance, the payment application 122 may require a biometric authentication of the cardholder 104 to confirm the linking of a new payment card to a particular UPI ID. Upon confirming the cardholder’s authorization by the payment application 122, the UPI-card linking module 220 is configured to access the UPI ID 228 associated with the cardholder 104 and the payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 104 from the UPI server 116.
[0075] In some non-limiting scenarios, the UPI-card linking module 220 is configured to access the UPI ID 228 associated with the cardholder 104 and the payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 104 from the issuer server 110 corresponding to each of the one or more payment cards 108. In some scenarios, the UPI ID 228 associated with the cardholder 104 and the payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 104 may be received (or requested and received) from the storage associated with the payment application 122 or the UPI server 116. In another embodiment, the accessed UPI ID associated with the cardholder 104 and the accessed payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 104 is stored in the database 204 associated with the server system 200.
[0076] Thereafter, the UPI-card linking module 220 is configured to generate and transmit a card linking request for each of the one or more payment cards 108 to an issuer server (such as issuer server 110) associated with the cardholder 104 for each of the corresponding payment card. It is understood that if the cardholder 104 has different payment cards, each of them may be issued by a separate issuer bank associated with the same cardholder 104. Therefore, a different card linking request might have to be generated for each of the issuing banks corresponding to these different payment cards. For example, Bank A and Bank B may both provide a payment card to the same cardholder (i.e., cardholder 104), therefore an individual card linking request has to be made for each of these payment cards for each of these banks if the cardholder 104 wishes to link these payment cards with his/her UPI ID 228. Then, upon receiving a card linking approval from the issuer server 110 corresponding to at least one of the one or more payment cards 108, the UPI-card linking module 220 is configured to link at least of the one or more payment cards 108 with the UPI ID 228 associated with the cardholder 104 based, at least in part, on the corresponding payment card data such as payment card data 230.
[0077] In an embodiment, the installment option generation module 222 includes suitable logic and/or interfaces for receiving a UPI-card payment initiation request from the electronic device 106 associated with the cardholder 104 for processing a payment transaction with a merchant 114 in multiple installments. In various non-limiting examples, the UPI-card payment initiation request may include at least a UPI ID 228 associated with the cardholder 104 and the transaction related information 232. Upon receiving the UPI-card payment initiation request, the installment option generation module 222 is configured to access payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 104 linked with the UPI ID 228 from the database 204. Further, the installment option generation module 222 is configured to determine one or more eligible payment cards from the one or more payment cards 108 based, at least in part, on corresponding payment card data. Herein, the one or more eligible payment cards indicate the payment cards that are determined to be eligible for a payment installment option. More specifically, for determining the one or more eligible payment cards, the installment option generation module 222, at first, generates and transmits an eligibility check request to one or more installment service providers or installment provider platforms (such as third-party installment providers). In a non-limiting example, the eligibility check request includes the payment card data 230 corresponding to each of the one or more payment cards 108. It is noted that the one or more installment service providers are financial institutions that specialize in providing cardholders or account holders with installment options based, at least in part, on the account holder’s or cardholder’s needs or requirements. Upon receiving the payment card data 230 corresponding to each of the one or more payment cards 108, the one or more installment service providers may perform an eligibility check based on their own predetermined eligibility criteria to determine which payment cards among the one or more payment cards 108 are eligible for receiving the plurality of installment options. In one non-limiting scenario, while performing the eligibility check, the one or more installment service providers may pull information such as a credit score, a payment history, and the like of the cardholder 104 by leveraging the corresponding payment card data for each payment card. Further, the one or more installment service providers may determine the eligibility for a payment card based on this pulled data. In another non-limiting scenario, while performing the eligibility check, the one or more installment service providers may determine if a payment card provider (i.e., the issuing bank) is eligible for installment options based on predefined rules. For instance, cards issued by Bank A may be eligible as per the predefined rules of the installment provider while the cards issued by Bank B may not be eligible. Further, the one or more installment service providers may share or transmit an eligibility check response indicating the one or more eligible payment cards to the installment option generation module 222.
[0078] Further, the installment option generation module 222 is configured to generate a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information 232. In various non-limiting examples, each installment option of the plurality of installment options may include information related to at least a PAN of a payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure for the corresponding installment option. For example, if the transaction related information 232 indicates that a payment transaction is for $2000, then for eligible payment cards, the installment option generation module 222 may generate various installment options such as a first installment option corresponding to a monthly payment frequency of $173 at 7% interest for 12 months, a second installment option corresponding to a monthly payment frequency of $ 18 at 10% interest for 24 months and the like.
[0079] In particular, for generating the plurality of installment options, the installment option generation module 222, at first, generates and transmits, an installment option request to one or more installment service providers. In a non-limiting example, the installment option request includes the payment card data such as payment card data 230 corresponding to the one or more eligible payment cards. Upon receiving the installment option request, the one or more installment service providers may determine a plurality of suitable installment options for the one or more eligible payment cards based, at least in part, on their internal policies and risk assessment. Further, the one or more installment service providers generate and transmit an installment option response to the installment option generation module 222. In a non-limiting example, the installment option response includes the plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards. Furthermore, the installment option generation module 222 is configured to facilitate a display of the plurality of installment options on the electronic device 106. In a non-limiting example, the installment option generation module 222 generates one or more graphical user interfaces (GUIs) on the electronic device 106 for facilitating the display of the plurality of installment options on the electronic device 106.
[0080] In an embodiment, the mandate generation module 224 includes suitable logic and/or interfaces for monitoring the cardholder activity for tracking if the cardholder 104 has made a selection of an installment option associated with a payment card such as payment card 108(1) from the plurality of installment options presented to them on their electronic device 106. Upon determining that the cardholder 104 has selected an installment option from the plurality of installment options, generating and transmitting, by the electronic device 106 associated with the cardholder 104, an installment initiation request to the server system 200 (i.e., mandate generation module 224). In various non-limiting examples, the installment initiation request includes information related to at least a selected installment option from the plurality of installment options by the cardholder 104 among other relevant data. Upon receiving the installment initiation request, the mandate generation module 224 is configured to facilitate authentication of the cardholder 104 by the issuer server 110, based, at least in part, on the UPI ID 228 and the selected installment option. In a non-limiting scenario, facilitating the authentication of the cardholder 104 includes requesting the cardholder 104 for their UPI PIN and upon receiving the UPI PIN from the cardholder 104, the mandate generation module 224 authenticates the cardholder 104 via the issuer server 110. It is noted that the authentication process has been described earlier, therefore the same has not been repeated for the sake of brevity.
[0081] In an embodiment, upon successful authentication of the cardholder 104 by the issuer server 110, the mandate generation module 224 is configured to generate and transmit a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to the UPI server 116. In a non-limiting example, the UPI card payment mandate registration request includes mandate related information. In some examples, the mandate related information may further include at least the UPI ID 228 and the selected installment option. In an alternative embodiment, if the authentication by the issuer server 110 is unsuccessful, the mandate generation process is terminated and the cardholder 104 is notified.
[0082] In a non-limiting scenario, upon receiving the UPI card payment mandate registration request, the UPI server 116 is configured to register the mandate with the issuer server 110 of the eligible payment card corresponding to the selected installment option based, at least in part, on the UPI ID 228 and the selected installment option. Then, the UPI server 116 is configured to transmit a mandate registration successful message to the server system 200 (i.e., the mandate generation module 224) upon successful mandate registration with the UPI server 116 and the issuer server 110.
[0083] Furthermore, the mandate generation module 224 is configured to generate a Unique Mandate Reference Number (UMRN) linked to a PAN of the payment card 108(1) for the mandate corresponding to the UPI ID 228 and the selected installment option associated with the payment card 108(1). It is noted that the UMRN indicates the mandate generated for the corresponding UPI 228 and the selected installment option for the cardholder 104. Further, the UMRN may be used by either the cardholder 104, the merchant 114, the server system 200, the UPI server 116, the issuer server 110, or the acquirer server 112 at any point in time to look up the desired mandate details. Thereafter, the mandate generation module 224 is configured to generate and transmit a UPI card mandate authorized message to at least one of the cardholder 104 and the merchant 114. In a non-limiting example, the UPI card mandate authorized message includes at least the UMRN linked to the PAN of the payment card 108(1). It is noted that the UMRN along with other data are stored within the database 204 associated with the server system 200. It is noted that the PAN can be masked or encrypted as well.
[0084] In an embodiment, the payment processing module 226 includes suitable logic and/or interfaces for receiving an installment payment authorization request from an acquirer server 112 associated with the merchant 114. It is noted that the installment payment authorization request is generated by the acquirer server 112 associated with the merchant 114 when it’s time to request funds from the issuing bank of the cardholder 104 in order to process the installment payment. For instance, if the initially selected installment option by the cardholder 104 corresponded to an equal monthly installment (EMI) of 6 months for $100, then the acquirer server 112 or the merchant 114 will transmit the installment payment authorization request once a month for six months on a predefined installment date. In a non-limiting example, the installment payment authorization request includes at least the UMRN linked to a PAN of the payment card of the cardholder 104. Then, the payment processing module 226 is configured to access the mandate corresponding to the UPI ID 228 and the selected installment option from the database 204 based, at least in part, on the UMRN linked to the PAN of the payment card of the cardholder 104. Thereafter, the payment processing module 226 is configured to generate and transmit a mandate payment authorization request to the UPI server 116 for processing the installment payment transaction between the cardholder 104 and the merchant 114.
[0085] In a non-limiting example, the mandate payment authorization request includes at least the mandate corresponding to the UPI ID 228 and the selected installment option. In particular, upon receiving the mandate payment authorization request, the UPI server 116 is configured to request the issuer server 110 associated with the cardholder 104 to authorize the installment payment transaction for the mandate based, at least in part, on the UPI ID 228 and the selected installment option. Upon successful installment payment transaction authorization by the issuer server 110, the UPI server 116 is configured to process the installment payment transaction with the acquirer server 112 associated with the merchant 114.
[0086] In an alternative embodiment, the payment processing module 226 is configured to process the full transaction amount of the transaction to the merchant 114 from an Installment Provider Platform (IPP) upon determining that the UPI card payment mandate registration is successful. It is noted in this scenario, the selected installment option may dictate that the cardholder 104 may enter in an installment contract with the IPP. In other words, IPP will make the full payment to the merchant 114 and the cardholder 104 has to pay back the IPP in installments. To that end, the payment processing module 226 is configured to receive the installment payment authorization request from the acquirer server 112 associated with the IPP. It is noted that for the sake of simplicity, hereinafter it is assumed that acquirer server 112 is associated with the acquiring bank of the IPP as well. It is noted that the installment payment authorization request is generated by the IPP when it’s time to request funds from the issuing bank of the cardholder 104 in order to process the installment payment. For instance, if the initially selected installment option by the cardholder 104 corresponded to an equal monthly installment (EMI) of 9 months for $200, then the acquirer server 112 or the IPP will transmit the installment payment authorization request once a month for nine months on a predefined installment date. In a non-limiting example, the installment payment authorization request includes at least the UMRN linked to the PAN of the payment card of the cardholder 104.
[0087] Then, the payment processing module 226 is configured to access the mandate corresponding to the UPI ID 228 and the selected installment option from the database 204 based, at least in part, on the UMRN linked to the PAN of the payment card 108(1) of the cardholder 104. Thereafter, the payment processing module 226 is configured to generate and transmit a mandate payment authorization request to the UPI server 116 for processing the installment payment transaction between the cardholder 104 and the merchant 114. In a non-limiting example, the mandate payment authorization request includes at least the mandate corresponding to the UPI ID 228 and the selected installment option. In particular, upon receiving the mandate payment authorization request, the UPI server 116 is configured to request the issuer server 110 associated with the cardholder 104 to authorize the installment payment transaction for the mandate based, at least in part, on the UPI ID 228 and the selected installment option. Upon successful installment payment transaction authorization by the issuer server 110, the UPI server 116 is configured to process the installment payment transaction with the acquirer server 112 associated with the IPP.
[0088] It is noted that although, it has been assumed that the installment provider such as the credit card provider through credit card EMIs or the IPP transfers the full amount of the purchase with the merchant 114. As may be understood, in some scenarios, the payment may be made to the merchant 114 in installments as well from the payment card of the cardholder 104. For instance, merchant-initiated mandates or cardholder-initiated mandates may be generated for monthly installments for services such as subscriptions, split clearing in the payment industry, and the like.
[0089] FIG. 3 is a sequence flow diagram 300 depicting a process for linking a UPI payment rail with the payment card payment rail, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 300, references may be made to elements described in FIGS. 1-2. It is understood that the various steps of the sequence flow have already been explained wither reference to FIGS. 1 and 2, therefore an explanation for the same is not repeated herein for the sake of brevity. It is noted that the server system 304 of FIG. 3 is identical to the server system 200 of FIG. 2. Further, it is noted that issuer server 306 and UPI server 308 are identical to the issuer server 110 and the UPI server 116 of FIG. 1, respectively. It is understood that the various steps of this sequence flow have already been described with reference to FIGS. 1 and 2 earlier, therefore the explanation for the various steps is not repeated again for the sake of brevity. The sequence flow begins at step 310.
[0090] At 310, the cardholder 302 initiates the UPI-card linking process using the electronic device (such as electronic device 106) associated with the cardholder 302. In an example, an application that supports a UPI payment facility may be installed on the electronic device 106 of the cardholder 302. The cardholder 104 may use this application to initiate the UPI-card linking process. In another example, the application may be configured to communicate with the server system 200 to access the functionality of the payment application (such as payment application 122 described earlier) via one or more API calls to perform the various operations described hereinafter.
[0091] At 312, cardholder 302 generates via the application such as the payment application 122 installed on the electronic device 106, a card link initiation request.
[0092] At 314, the electronic device 106 of the cardholder 302 transmits the card link initiation request to the server system 304.
[0093] At 316, the server system 304 generates a card linking request for each of the one or more payment cards 108 for the cardholder 302 a UPI server 308.
[0094] At 318, the server system 304 transmits the card linking request to the UPI server 308.
[0095] At 320 the UPI server 308 generates and transmits a card linking initiation request to the issuer server 306 associated with the cardholder 302 for each of the corresponding payment cards.
[0096] At 322, the issuer server 306 generates a card linking approval. More specifically, the issuer server 306 first determines if the payment card such as payment card 108(1) associated with the cardholder 302 is eligible to be linked with the UPI payment rail. Upon determining that the payment card 108(1) for which the card linking request is received, is eligible, the issuer server 306 generates the card linking approval message.
[0097] At 324, the issuer server 306 transmits the card linking approval to the UPI server 308.
[0098] At 326, the UPI server 308 forwards the card linking approval to the server system 304.
[0099] At 328, upon receiving the card linking approval, the server system 304 links the one or more payment cards such as one or more payment cards 108 with the UPI ID associated with the cardholder 302 based, at least in part, on the corresponding payment card data such as payment card data 230.
[00100] At 330, the server system 304 transmits a card link successful notification to the cardholder 302 on his/her electronic device such as electronic device 106.
[00101] FIGS. 4A and 4B, collectively, depict a sequence flow diagram 400 of a process for enabling payment mandate for payment cards via UPI payment rail for cardholder-initiated mandates, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 400, references may be made to elements described in FIGS. 1-2. It is understood that the various steps of this sequence flow have already been described with reference to FIGS. 1 and 2 earlier, therefore the explanation for the various steps is not repeated again for the sake of brevity. It is noted that the server system 404 of FIGS. 4A-4B is identical to the server system 200 of FIG. 2. Further, it is noted that issuer server 406, and UPI server 408 are identical to the issuer server 110 and the UPI server 116 of FIG. 1, respectively. The sequence flow begins at step 414.
[00102] At step 414, the electronic device 106 of the cardholder 402 transmits a UPI-card payment initiation request to the server system 404. For instance, when the cardholder 402 decides to pay a merchant 410 for a good/service in installments using his/her payment card (such as a credit card) then, at first the cardholder 402 may enter the UPI ID of the merchant 410 in the payment application 122 installed on their electronic device 106. In some instances, the cardholder 402 may scan a QR code associated with the merchant 410 via the payment app that has a QR scanning functionality for determining the merchant UPI ID. Upon entering the merchant UPI ID, the cardholder 402 may enter the transaction amount into the payment application 122. Further, the cardholder 402 may select an option for initiating the UPI-card payment process. Upon selecting this option, the electronic device 106 generates and transmits the UPI-card payment initiation request to the server system 404. In various examples, the UPI-card payment initiation request may include at least a UPI ID (such as UPI ID 228) associated with the cardholder 402 and transaction related information.
[00103] At step 416, upon receiving the UPI-card payment initiation request, the server system 404 accesses payment card data (for instance, payment card data 230) corresponding to each of the one or more payment cards 108 associated with the cardholder 402 linked with the UPI ID 228 from the database 204 associated with the server system 404. For instance, if the server system 404 is providing the functionalities described herein to a payer PSP application installed on the electronic device 106 of the cardholder 402, then the payment card data 230 may be accessed by the payer PSP.
[00104] At step 418, the server system 404 initiates an eligibility check for each payment card of the one or more payment cards 108 and transmits an eligibility check request to the installment service provider 412. For instance, if the server system 404 is providing the functionalities described herein to a payer PSP application, then the eligibility check is performed by the payer PSP.
[00105] At step 420, the installment service provider 412 performs the eligibility check to determine one or more eligible payment cards. For instance, the installment service provider 412 may rely on one or more factors such as the credit score of the cardholder 402, available offers for different types of payment cards, and the like for determining the one or more eligible payment cards.
[00106] At step 422, the installment service provider 412 determines a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards. For instance, a few of the plurality of installment options may be provided by different IPPs.
[00107] At step 424, the installment service provider 412 transmits an installment option response to the server system 404. In one non-limiting implementation, the installment option response may include the plurality of installment options.
[00108] At step 426, in response to receiving the plurality of installment options, the server system 404 facilitates the display of the plurality of installment options on the electronic device 106 of the cardholder 402.
[00109] At step 428, the electronic device 106 associated with the cardholder 402 generates and transmits an installment initiation request upon receiving a selection of an installment option from the plurality of installment options from the cardholder 402 to the server system 404. For instance, the payer PSP application installed on the electronic device 106 of the cardholder 402 may generate and transmit the installment initiation request.
[00110] At step 430, the server system 404 facilitates and initiates authentication of the cardholder 402 by the issuer server 406, based, at least in part, on the UPI ID 228 and the selected installment option. In an implementation, the server system facilitates the payer PSP application installed on the cardholder’s electronic device 106 to perform the authentication. In particular, the payer PSP application may request the cardholder 402 for their UPI PIN associated with their UPI ID. Upon receiving the UPI PIN, the payer PSP application transmits the same to the issuer server 406. For instance, once the UPI PIN is entered, the payer PSP application on the electronic device 106 transmits the UPI PIN to the issuer server 406 via a secure message. It is noted that in the UPI system of payment processing, the issuer server such as issuer server 406 is responsible for authenticating the cardholder 402 based on the UPI PIN. To that end, the issuer server 406 authenticates the cardholder 402.
[00111] Upon successful authentication, the issuer server 406 transmits an authorization successful flag to the server system 404 at step 432(1). Otherwise, the issuer server 406 transmits an authorization unsuccessful flag to the server system 404 at step 432(2).
[00112] At step 434(1), the server system 404, if the authorization successful flag was received, generates and transmits a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to the UPI server 408. Otherwise, at 434(2), the server system terminates the mandate generation process.
[00113] At step 436, the UPI server 408, registers the UPI card payment mandate registration request with the issuer server 406. Upon receiving the UPI card payment mandate registration request, the issuer server 406 is configured to register the mandate for the cardholder 402. Further, the issuer server 406 generates and transmits a UPI card payment mandate registration response to the UPI server 408 at step 438. In a non-limiting example, the UPI card payment mandate registration response includes at least a registration successful flag or a registration unsuccessful flag. Herein, the registration successful flag indicates that the mandate registration was successful and the registration unsuccessful flag indicates that the mandate registration was unsuccessful.
[00114] Upon receiving the UPI card payment mandate registration response, the UPI server 408 determines if the mandate registration was successful or not based at least on the flag included in the response message. Upon determining that the UPI card payment mandate registration was successful based on the registration successful flag, the UPI server 408 sends UPI card payment mandate registration confirmation with the server system 404 at 440(1). Otherwise, the process is terminated at step 440(2).
[00115] Upon receiving the UPI card payment mandate registration confirmation from the UPI server 408, the server system 404 generates a UPI card mandate authorized message to the cardholder at step 442(1), the merchant at step 442(2), and the installment server provider 412 at 442(3). In an example, the UPI card mandate authorized message may include at least the UMRN linked to a PAN of a payment card.
[00116] FIGS. 5A and 5B, collectively, depict a sequence flow diagram 500 of a process for enabling payment mandate for payment cards via UPI payment rail for merchant-initiated mandates, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 500, references may be made to elements described in FIGS. 1-2. It is understood that the various steps of this sequence flow have already been described with reference to FIGS. 1 and 2 earlier, therefore the explanation for the various steps is not repeated again for the sake of brevity. It is noted that the server system 504 of FIGS. 5A-5B is identical to the server system 200 of FIG. 2. Further, it is noted that issuer server 506, and UPI server 508 are identical to the issuer server 110 and the UPI server 116 of FIG. 1, respectively. Furthermore, it is noted that the various steps depicted by FIGS. 5A-5B are similar to the steps explained in reference to FIGS. 4A-4B therefore, the explanation for the same is not repeated for the sake of brevity. The sequence flow begins at step 514.
[00117] At step 514, a merchant 502 transmits a UPI-card payment initiation request to the server system 504 on behalf of a cardholder such as cardholder 510. In various example, the UPI-card payment initiation request may include at least a UPI ID (such as UPI ID 228) associated with the cardholder 510 and transaction related information.
[00118] At step 516, upon receiving the UPI-card payment initiation request, the server system 504 accesses payment card data such as payment card data 230 corresponding to each of the one or more payment cards 108 associated with the cardholder 510 linked with the UPI ID 228 from the database 204 associated with the server system 504. In an example, the payment card data 230 may include the PAN of the payment card. For instance, if the server system 504 is providing the functionalities described herein to a payee PSP application of the merchant 502 installed on the electronic device 106 of the cardholder 510, then the payment card data 230 may be accessed by the payee PSP.
[00119] At step 518, the server system 504 initiates an eligibility check for each payment card of the one or more payment cards 108 and transmits an eligibility check request to the installment service provider 512. For instance, if the server system 504 is providing the functionalities described herein to a payee PSP application, then the eligibility check is performed by the payee PSP.
[00120] At step 520, the installment service provider 512 performs the eligibility check to determine one or more eligible payment cards.
[00121] At step 522, the installment service provider 512 determines a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards.
[00122] At step 524, the installment service provider 512 transmits an installment option response to the server system 504.
[00123] At step 526, in response to receiving the plurality of installment options, the server system 504 facilitates the display of the plurality of installment options by the merchant 502 on the electronic device 106 of the cardholder 510 or on a POS device of the merchant 502.
[00124] At step 528, the merchant 502 generates and transmits an installment initiation request upon receiving a selection of an installment option from the plurality of installment options from the cardholder 510 to the server system 504. For instance, the payee PSP application associated with the merchant 502 that may be installed on the electronic device 106 of the cardholder 510 may generate and transmit the installment initiation request.
[00125] At step 530, the server system 504 facilitates and initiates authentication of the cardholder 510 by the issuer server 506, based, at least in part, on the UPI ID 228 and the selected installment option. In an implementation, the server system facilitates the payee PSP application installed on the cardholder’s electronic device 106 to perform the authentication. In particular, the payee PSP application may request the cardholder 510 for their UPI PIN associated with their UPI ID. Upon receiving the UPI PIN, the payer PSP application transmits the same to the issuer server 506. For instance, once the UPI PIN is entered, the payee PSP application on the electronic device 106 transmits the UPI PIN to the issuer server 506 via a secure message. It is noted that in the UPI system of payment processing, the issuer server such as issuer server 506 is responsible for authenticating the cardholder 510 based on the UPI PIN. To that end, the issuer server 506 authenticates the cardholder 510.
[00126] Upon successful authentication, the issuer server 506 transmits an authorization successful flag to the server system 504 at step 532(1). Otherwise, the issuer server 506 transmits an authorization unsuccessful flag to the server system 504 at step 532(2).
[00127] At step 534(1), the server system 504, if the authorization successful flag was received, generates and transmits a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to the UPI server 508. Otherwise, at 534(2), the server system terminates the mandate generation process.
[00128] At step 536, the UPI server 508, registers the UPI card payment mandate registration request with the issuer server 506. Upon receiving the UPI card payment mandate registration request, the issuer server 506 is configured to register the mandate for the cardholder 510. Further, the issuer server 506 generates and transmits a UPI card payment mandate registration response to the UPI server 508 at step 538. In a non-limiting example, the UPI card payment mandate registration response includes at least a registration successful flag or a registration unsuccessful flag. Herein, the registration successful flag indicates that the mandate registration was successful and the registration unsuccessful flag indicates that the mandate registration was unsuccessful.
[00129] Upon receiving the UPI card payment mandate registration response, the UPI server 508 determines if the mandate registration was successful or not based at least on the flag included in the response message. Upon determining that the UPI card payment mandate registration was successful based on the registration successful flag, the UPI server 508 sends UPI card payment mandate registration confirmation with the server system 504 at 540(1). Otherwise, the process is terminated at step 540(2).
[00130] Upon receiving the UPI card payment mandate registration confirmation from the UPI server 508, the server system 504 generates a UPI card mandate authorized message to the merchant 502 at step 542(1), to the cardholder 510 at step 542(2), and to the installment server provider 512 at 542(3). In an example, the UPI card mandate authorized message may include at least the UMRN linked to a PAN of a payment card. It is noted that the PAN can be masked or encrypted as well.
[00131] FIG. 6 is a sequence flow diagram 600 depicting a process for processing an installment payment between the merchant and the issuer, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 600, references may be made to elements described in FIGS. 1-2. It is understood that the various steps of this sequence flow have already been described with reference to FIGS. 1 and 2 earlier, therefore the explanation for the various steps is not repeated again for the sake of brevity. It is noted that the server system 604 of FIG. 6 is identical to the server system 200 of FIG. 2. Further, it is noted that issuer server 606, acquirer server 612, and UPI server 608 are identical to the issuer server 110, acquirer server 112, and the UPI server 116 of FIG. 1, respectively. The sequence flow begins at step 614.
[00132] At step 614, the merchant 610 generates and transmits an installment payment authorization request for the cardholder 602 to the server system 604. In another embodiment, the installment payment authorization request may also be generated by the acquirer server 612 associated with the merchant 610.
[00133] At step 616, the server system 604 accesses the mandate corresponding to the UPI ID 228 and the selected installment option from the database 204 based, at least in part, on the UMRN linked to a PAN of a payment card selected for paying the installments in the selected installment option.
[00134] At step 618, the server system 604 generates and transmits a mandate payment authorization request to the UPI server 608 for processing the installment payment transaction between the cardholder 602 and the merchant 610.
[00135] At step 620, the UPI server 608 generates and transmits a debit payment authorization request to the issuer server 606 for requesting the issuer server 606 to authorize the installment payment transaction for the mandate based, at least in part, on the UPI ID 228 and the selected installment option.
[00136] At step 622, issuer server 606 generates and transmits a debit payment authorization response to the UPI server 608 for processing the installment payment transaction with the acquirer server 612 associated with the merchant 610.
[00137] At step 624, the UPI server 608 generates and transmits an installment payment transaction credit request to the acquirer server 612.
[00138] At step 626, the acquirer server 612 generates and transmits an installment payment transaction credit response to the UPI server 608.
[00139] Upon receiving the installment payment transaction credit response, the UPI server 608 generates and transmits an installment payment confirmation to both the cardholder 602 and the merchant 610 at step 628(1) and step 628(2), respectively.
[00140] FIGS. 7A-7G, collectively, illustrate various Graphical User Interfaces (GUIs) illustrating the process of generating a payment mandate, in accordance with various embodiments of the present disclosure. It is noted that the various GUIs depicted by FIGS. 7A-7G, may be displayed on either an electronic device associated with the cardholder or the merchant. More specifically, either one of the payment application 122, the payee PSP application (installed on the cardholder’s electronic device) or the payer PSP application associated with the merchant 114 may be responsible for displaying these GUIs on a display screen associated with the electronic device 106. For instance, if the cardholder 104 performs a transaction on a merchant application, then the cardholder 104 may be redirected to the payee PSP application that may display the GUIs depicted by FIGS. 7A-7G to the cardholder 104 for processing the transaction using a selected installment option.
[00141] In another instance, if the cardholder 104 performs a transaction on a merchant Point of Sale (POS) device then, the cardholder 104 may be redirected to the payer PSP application that may display the GUIs depicted by FIGS. 7A-7G to the cardholder 104 for processing the transaction using a selected installment option. In yet another instance, if the cardholder 104 performs a transaction on a merchant application that is linked to a payee PSP application (in other words, a merchant with a payee PSP license), then the payee PSP may display the GUIs depicted by FIGS. 7A-7G to the cardholder 104 for processing the transaction using a selected installment option. To that end, it may be noted the GUIs depicted by FIGS. 7A-7G may be generated by different entities in the payment network 124. However, it is crucial to note that the server system 200 is responsible for facilitating the generation of these GUIs on the electronic devices of either the cardholder 104 or the merchant 114. In other words, the server system 200 is responsible for providing the functionalities required for processing a payment transaction initiated by a cardholder with a merchant in multiple installments for either or both the payer PSP associated with the cardholder 104 or the payee PSP associated with merchant 114.
[00142] However, for the sake of simplicity, herein it is assumed that the GUIs depicted by FIGS. 7A-7G are displayed on the electronic device 106 of the cardholder 104 on a payment application such as payment application 122 that may be an example of the payer PSP application. To that end, as depicted by GUI 702 of FIG. 7A, the cardholder such as cardholder 104 may initiate the payment process by entering the merchant UPI ID into a payment application that supports UPI transactions. For example, the electronic device 106 associated with the cardholder 104 may run an instance of the payment application 122 associated with the server system 102 (or server system 200) for initiating the transaction process. In another example, the electronic device 106 associated with the cardholder 104 may run a UPI supported application that is able to leverage the functionality of the payment application 122 through various API calls by communicating with the server system 200. As depicted by FIG. 7A, the cardholder 104 enters the merchant UPI ID, i.e., JOHN.ABC@VPA. To proceed further, the cardholder 104 may click on the PROCEED button and to go back, the cardholder 104 may click on the BACK button.
[00143] Upon clicking the PROCEED button, the cardholder 104 may be shown a list of linked payment cards, i.e., the one or more payment cards 108 that the cardholder 104 has already linked with the application (see, GUI 704 of FIG. 7B). As depicted in FIG. 7B, the cardholder 104 is also provided with an option/button for adding or linking a new payment card (see, ADD NEW CREDIT CARD). The cardholder 104 may click on the one or more desired payment cards for which he/she wishes to receive the installment options and press on the SELECT button to proceed further.
[00144] As depicted by GUI 706 of FIG. 7C, upon proceeding further, the cardholder 104 is asked to input the transaction amount that the cardholder 104 has to pay the merchant 114. Upon entering the transaction amount, the cardholder 104 may press the ENTER button.
[00145] Upon pressing the ENTER button, the cardholder 104 is redirected to the GUI shown in FIGS. GUI 708 of 7D and GUI 710 of 7E. As depicted, the cardholder 104 is provided with a plurality of installment options for the one or more eligible payment card from the selected desired payment cards. Further, the cardholder 104 may also be provided with a functionality for comparing the installment options by card or by tenure (see, ‘COMAPRE BY CARD’ and ‘COMPARE BY TENSURE’). The cardholder 104 can decide which installment option is suitable for him/her and click on the suitable card. Further, the cardholder 104 may proceed further by clicking the SELECT button.
[00146] Upon clicking the SELECT button, the cardholder 104 is redirected to the GUI 712 shown in FIG. 7F. As depicted, for generating the mandate, the cardholder 104 has to be authenticated. For authentication, the cardholder 104 is prompted to enter their UPI PIN. Once the UPI PIN is entered, the cardholder 104 can proceed by clicking on the ENTER button. Thereafter, upon successful authentication, the payment mandate is generated and a notification of the same is displayed to the cardholder 104 (see, GUI 714 of FIG. 7G).
[00147] FIGS. 8A-8B, collectively, illustrate a method 800 for enabling payment mandates for payment cards via a UPI system, in accordance with an embodiment of the present disclosure. The sequence of operations of the method 800 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is noted that the operations of the method 800, and combinations of operations in the method 800, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 800 starts at operation 802.
[00148] At 802, the method 800 includes receiving, by a server system such as server system 200, a Unified payment interface (UPI)-card payment initiation request from an electronic device (such as electronic device 106) for processing a payment transaction initiated by a cardholder (such as cardholder 104) with a merchant (such as merchant 114) in multiple installments. Herein, the UPI-card payment initiation request includes a UPI identifier (ID) associated with the cardholder 104 and transaction related information 232. In various scenarios, the electronic device 106 may be associated with one of the cardholder 104 or the merchant 114. For instance, the electronic device 106 may be a smartphone of the cardholder 104 when the cardholder 104 wishes to perform a transaction with the merchant 114 through installments on their payer PSP application. On the other hand, the electronic device 106 may be a merchant’s POS device when the cardholder 104 wishes to perform a transaction with the merchant 114 through installments using the Payee PSP application of the merchant 114. In other instances, the cardholder 104 may perform the transaction on an instance of the payee PSP application running within a merchant application installed/operating on the electronic device 106 associated with the cardholder 104 as well.
[00149] At 804, the method 800 includes accessing, by the server system 200, payment card data (such as payment card data 230) corresponding to each of the one or more payment cards 108 associated with the cardholder 104 linked with the UPI ID from a database such as database 204 associated with the server system 200. Herein, the payment card data 230 may include at least a Personal Account Number (PAN) of a payment card such as payment card 108(1).
[00150] At 806, the method 800 includes determining, by the server system 200, one or more eligible payment cards from the one or more payment cards 108 based, at least in part, on corresponding payment card data 230, the one or more eligible payment cards indicating payment cards that are eligible for a payment installment option.
[00151] At 808, the method 800 includes generating, by the server system 200, a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data 230 and transaction related information 232. Herein, each installment option of the plurality of installment options includes information related to at least a Personal Account Number (PAN) of a payment card 108(1), a payment frequency, an installment amount, an interest rate, and an installment tenure.
[00152] At 810, the method 800 includes facilitating, by the server system 200, a display of the plurality of installment options on the electronic device 106.
[00153] At 812, the method 800 includes receiving, by the server system 200, an installment initiation request including a selected installment option from the plurality of installment options by the cardholder 104.
[00154] At 814, the method 800 includes upon receiving the installment initiation request facilitating, by the server system 200, an authentication of the cardholder 104 by the issuer server 110, based, at least in part, on the UPI ID and the selected installment option.
[00155] At 816, the method 800 includes upon successful authentication by the issuer server 110, generating and transmitting, by the server system 200, a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to a UPI server such as UPI server 116. Herein, the UPI card payment mandate registration request may include mandate related information, the mandate related information including the UPI ID, and the selected installment option.
[00156] The sequence of operations of the method 800 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner
[00157] FIG. 9 is a simplified block diagram of a payment server 900, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 126 of FIG. 1. The payment server 900 and the server system 200 may use the payment network 124 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
[00158] The payment server 900 includes a processing system 905 configured to extract programming instructions from a memory 910 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and the payment server 900 may include more or fewer components than that depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00159] Via a communication interface 915, the processing system 905 receives a request from a remote device 920, such as the issuer server 110 or the acquirer server 112. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 900 includes a database 925. The database 925 also includes transaction processing data such as an issuer ID, a country code, an acquirer ID, and a merchant identifier (MID), among others.
[00160] When the payment server 900 receives a payment transaction request from the acquirer server 112 or a payment terminal (e.g., point of sale (POS) device, etc.), the payment server 900 may route the payment transaction request to an issuer server (e.g., the issuer server 110). The database 925 stores transaction identifiers for identifying transaction details such as the transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00161] In one example, the acquirer server 112 is configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request.
[00162] The processing system 905 further sends the payment transaction request to the issuer server 110 for facilitating the payment transactions from the remote device 920. The processing system 905 is further configured to notify the remote device 920 of the transaction status in the form of an authorization response message via the communication interface 915. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 110. Alternatively, in one embodiment, the processing system 905 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 915, to the acquirer server 112.
[00163] The disclosed methods with reference to FIGS. 1 to 8A-8B, or one or more operations of the methods 800 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Webbook, tablet computing device, smartphone, or other mobile computing devices)). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00164] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad scope of the disclosure. For example, the various operations, blocks, etc. described herein may be enabled and operated using hardware circuitry (for example, complementary metal-oxide-semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00165] Particularly, the server system 200 (or the server system 102) and its various components such as the computer system 202 and the database 204 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media. Non-transitory computer-readable media include any type of tangible storage media.
[00166] Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g., magneto-optical disks), compact disc read-only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-R/W), Digital Versatile Disc (DVD), BLU-RAY® Disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash memory, random access memory (RAM), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00167] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different from those which are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.
[00168] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A computer-implemented method comprising:
receiving, by a server system, a Unified Payment Interface (UPI)-card payment initiation request from an electronic device for processing a payment transaction initiated by a cardholder with a merchant in multiple installments, the UPI-card payment initiation request comprising a UPI identifier (ID) associated with the cardholder and transaction related information;
accessing, by the server system, payment card data corresponding to each of the one or more payment cards associated with the cardholder linked with the UPI ID from a database associated with the server system, the payment card data comprising at least a Personal Account Number (PAN) of a payment card;
determining, by the server system, one or more eligible payment cards from the one or more payment cards based, at least in part, on corresponding payment card data, the one or more eligible payment cards indicating payment cards that are eligible for a payment installment option;
generating, by the server system, a plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards based, at least in part, on corresponding payment card data and transaction related information, each installment option of the plurality of installment options comprises information related to at least the PAN of the payment card, a payment frequency, an installment amount, an interest rate, and an installment tenure; and
facilitating, by the server system, a display of the plurality of installment options on the electronic device.

2. The computer-implemented method as claimed in claim 1, wherein the electronic device is associated with one of the cardholder and the merchant.

3. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, an installment initiation request comprising a selected installment option from the plurality of installment options by the cardholder;
upon receiving the installment initiation request facilitating, by the server system, an authentication of the cardholder by the issuer server, based, at least in part, on the UPI ID and the selected installment option; and
upon successful authentication by the issuer server, generating and transmitting, by the server system, a UPI card payment mandate registration request corresponding to a mandate for making installment payments using the eligible payment card to a UPI server, the UPI card payment mandate registration request comprising mandate related information, the mandate related information comprising the UPI ID and the selected installment option.

4. The computer-implemented method as claimed in claim 2, wherein upon receiving the UPI card payment mandate registration request, the UPI server is configured to:
register the mandate with the issuer server of the eligible payment card corresponding to the selected installment option based, at least in part, on the UPI ID and the selected installment option, wherein the selected installment option is associated with the payment card; and
transmit a mandate registration successful message to the server system upon successful mandate registration with the issuer server.

5. The computer-implemented method as claimed in claim 2, further comprising:
generating, by the server system, a Unique Mandate Reference Number (UMRN) linked to the PAN of the payment card for the mandate corresponding to the UPI ID and the selected installment option; and
generating and transmitting, by the server system, a UPI card mandate authorized message to at least one of the cardholder and the merchant, the UPI card mandate authorized message comprising the UMRN linked to the PAN of the payment card.

6. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a card link initiation request from the electronic device associated with the cardholder;
in response to the card linking request, accessing, by the server system, UPI ID associated with the cardholder and the payment card data corresponding to each of the one or more payment cards associated with the cardholder from the electronic device;
generating and transmitting, by the server system, a card linking request for at least one of the one or more payment cards to an issuer server associated with the cardholder; and
upon receiving a card linking approval from the issuer server corresponding to at least one of the one or more payment cards, linking, by the server system, the at least one of the one or more payment cards with the UPI ID associated with the cardholder based, at least in part, on the corresponding payment card data.

7. The computer-implemented method as claimed in claim 1, wherein determining the one or more eligible payment cards, further comprises:
generating and transmitting, by the server system, an eligibility check request to one or more installment service providers, the eligibility check request comprising the payment card data; and
in response to the eligibility check request, receiving, by the server system, an eligibility check response from the one or more installment service providers, the eligibility check response indicating the one or more eligible payment cards.

8. The computer-implemented method as claimed in claim 1, wherein generating the plurality of installment options, further comprises:
generating and transmitting, by the server system, an installment option request to one or more installment service providers, the installment option request comprising the payment card data corresponding to the one or more eligible payment cards; and
in response to the installment option request, receiving, by the server system, an installment option response from the one or more installment service providers, the installment option response comprising the plurality of installment options corresponding to each eligible payment card of the one or more eligible payment cards.

9. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, an installment payment authorization request from an acquirer server associated with the merchant, the installment payment authorization request comprising a Unique Mandate Reference Number (UMRN) linked to the PAN of the payment card;
accessing, by the server system, the mandate corresponding to the UPI ID and the selected installment option from the database based, at least in part, on the UMRN linked to the PAN of the payment card; and
generating and transmitting, by the server system, a mandate payment authorization request to the UPI server for processing the installment payment transaction between the cardholder and the merchant, the mandate payment authorization request comprising the mandate corresponding to the UPI ID, and the selected installment option, wherein upon receiving the mandate payment authorization request, the UPI server is configured to:
request the issuer server associated with the cardholder to authorize the installment payment transaction for the mandate based, at least in part, on the UPI ID and the selected installment option, and
upon successful installment payment transaction authorization by the issuer server, process the installment payment transaction with an acquirer server associated with the merchant.

10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.