Claims:CLAIMS:

We claim:

1. A computer implemented method, the method comprising:
receiving, by a server system associated with a payment network, an instant payment transaction request from a payer device, the instant payment transaction request comprising an instant payment identification information of a payee, and a payment amount;
detecting, by the server system, an acquirer server associated with the payee as unavailable;
sending, by the server system, an offline instant payment confirmation message to the payer device for receiving a confirmation response for initiating an offline instant payment transaction;
upon receiving the confirmation response, retrieving, by the server system, a payee contact information associated with the instant payment identification information of the payee;
sending, by the server system, a hold instruction to hold the payment amount from a payer account to an issuer server associated with a payer, the issuer server configured to hold the payment amount from the payer account; and
electronically facilitating, by the server system, the offline instant payment transaction wherein electronically facilitating the offline instant payment transaction comprises notifying the payee using the payee contact information about the payment amount held from the payer account.

2. The method as claimed in claim 1, further comprising:
performing repetitive polling of the acquirer server at a pre-determined time interval to detect if the acquirer server is available; and
detecting the acquirer server as available.
3. The method as claimed in claim 2, further comprising:
notifying the issuer server about the availability of the acquirer server, wherein the issuer server is configured to debit the payment amount held from the payer account and wherein the acquirer server is configured to credit the payment amount to a payee account of the payee upon receiving a debit notification about debiting the payment amount from the issuer server.

4. The method as claimed in claim 1, wherein the offline instant payment transaction is a Unified Payment Interface (UPI) transaction.

5. The method as claimed in claim 1, wherein the instant payment identification information of the payee comprises a virtual payment address associated with the payee.

6. The method as claimed in claim 1, wherein the instant payment identification information of the payee comprises the payee contact information.

7. The method as claimed in claim 1, wherein the instant payment transaction request comprises a Unified Payment Interface Personal Identification Number (UPI PIN) of the payer.

8. The method as claimed in claim 7, further comprising:
sending the instant payment transaction request to the issuer server, wherein the issuer server is configured to verify the UPI PIN and the payment amount.

9. The method as claimed in claim 1, further comprising:
sending the payee contact information to the issuer server, the issuer server configured to notify the payee using the payee contact information about the payment amount held from the payer account.

10. A server system in a payment network, the server system comprising:
a communication interface configured to receive an instant payment transaction request from a payer device, the instant payment transaction request comprising an instant payment identification information of a payee, and a payment amount;
a memory comprising executable instructions;
a processor communicably coupled to the communication interface and configured to execute the executable instructions to cause the server system to at least:
detect an acquirer server associated with the payee as unavailable;
send an offline instant payment confirmation message to the payer device for receiving a confirmation response for initiating an offline instant payment transaction;
upon receiving the confirmation response, retrieve a payee contact information associated with the instant payment identification information of the payee;
send a hold instruction to hold the payment amount from a payer account to an issuer server associated with a payer, the issuer server configured to hold the payment amount from the payer account; and
electronically facilitate the offline instant payment transaction wherein electronically facilitating the offline instant payment transaction comprises notifying the payee using the payee contact information about the payment amount held from the payer account.

11. The server system as claimed in claim 10, wherein the server system is further caused to:
perform repetitive polling of the acquirer server at a pre-determined time interval to detect if the acquirer server is available; and
detect the acquirer server as available.

12. The server system as claimed in claim 11, wherein the server system is further caused to:
notify the issuer server about the availability of the acquirer server, wherein the issuer server is configured to debit the payment amount held from the payer account and wherein the acquirer server is configured to credit the payment amount to a payee account of the payee upon receiving a debit notification about debiting the payment amount from the issuer server.

13. The server system as claimed in claim 10, wherein the offline instant payment transaction is a Unified Payment Interface (UPI) transaction.

14. The server system as claimed in claim 10, wherein the instant payment identification information of the payee comprises a virtual payment address associated with the payee.

15. The server system as claimed in claim 10, wherein the instant payment transaction request comprises a Unified Payment Interface Personal Identification Number (UPI PIN) of the payer.

16. The server system as claimed in claim 15, wherein the server system is further caused to:
send the instant payment transaction request to the issuer server, wherein the issuer server is configured to verify the UPI PIN and the payment amount.

17. The server system as claimed in claim 10, wherein the server system is further caused to:
send the payee contact information to the issuer server, the issuer server configured to notify the payee using the payee contact information about the payment amount held from the payer account.

18. A computer implemented method, the method comprising:
receiving, by a server system associated with a payment network, an offline instant payment transaction request comprising an instant payment identification number of a payer, a payee contact information, and a payment amount;
receiving, by the server system, a hold instruction to hold the payment amount from a payer account of the payer, the hold instruction received based on detection of an acquirer server associated with a payee as unavailable;
verifying, by the server system, the instant payment identification number and the payment amount;
upon successful verification, electronically holding, by the server system, the payment amount from the payer account; and
electronically facilitating, by the server system, an offline instant payment transaction wherein electronically facilitating the offline instant payment transaction comprises notifying the payee using the payee contact information about the payment amount held from the payer account.

19. The method as claimed in claim 18, wherein the offline instant payment transaction is a Unified Payment Interface (UPI) transaction and wherein the instant payment identification number of the payer is a Unified Payment Interface Personal Identification Number (UPI PIN) of the payer.

20. The method as claimed in claim 18, further comprising:
receiving a notification about availability of the acquirer server;
debiting the payment amount held from the payer account; and
sending a debit notification about debiting the payment amount to the acquirer server, wherein the acquirer server is configured to credit the payment amount to a payee account of the payee.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR FACILITATING OFFLINE INSTANT PAYMENT TRANSACTION

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

METHODS AND SYSTEMS FOR FACILITATING OFFLINE INSTANT PAYMENT TRANSACTION

TECHNICAL FIELD

[0001] The present disclosure relates to electronic payment transactions and, more particularly to, methods and systems for facilitating offline instant payment transaction for eliminating transaction failure due to server down issues associated with acquirer server.
BACKGROUND

[0002] Nowadays, Unified Payment Interface (UPI) is a trending payment system in growing countries like India. UPI is a bank account linked instant payment system that enables a payer to instantly transfer funds from his bank account to the payee’s bank account through a UPI Virtual Payment Address (VPA - a unique ID generated by the bank) or by using his bank account number and IFSC code.
[0003] The UPI / instant payment transactions can fail due to multiple reasons, but most likely they fail due to connectivity issues in the banking system, incorrect virtual payment address entered by a payer, or a wrong UPI Personal Identification Number (UPI PIN) entry. The connectivity issues/server down issues are the main causes of concern as sometimes payment amount may be deducted from a payer account (as issuing bank server is working at the time of transaction) and then transactions fail (as acquiring bank server is down and not accepting payments at the time of transaction). Such occurrences wreak havoc for the payer as he will be concerned about his money, and also for the issuing bank as the issuing bank may have to perform the reversal of the payment amount in the payer account.
[0004] Hence, there is a need for techniques that enable the payer to facilitate an offline UPI transaction/instant payment transaction successfully when there is a connectivity issue with the acquiring bank server.

SUMMARY

[0005] Various embodiments of the present disclosure provide systems, methods, electronic devices and computer program products for facilitating offline instant payment transaction.
[0006] In an embodiment, a computer-implemented method is disclosed. The method includes receiving, by a server system associated with a payment network, an instant payment transaction request from a payer device. The instant payment transaction request includes an instant payment identification information of a payee and a payment amount. The method includes detecting an acquirer server associated with the payee as unavailable. The method includes sending an offline instant payment confirmation message to the payer device for receiving a confirmation response for initiating an offline instant payment transaction. The method includes retrieving a payee contact information associated with the instant payment identification information of the payee upon receiving the confirmation response. The method includes sending a hold instruction to hold the payment amount from a payer account to an issuer server associated with the payer. The issuer server is configured to hold the payment amount from the payer account. The method further includes electronically facilitating the offline instant payment transaction. The facilitating of the offline instant payment transaction includes notifying the payee using the payee contact information about the payment amount held from the payer account.
[0007] In another embodiment, a server system in a payment network is provided. The server system includes a communication interface configured to receive an instant payment transaction request from a payer device. The instant payment transaction request includes an instant payment identification information of a payee and a payment amount. The server system includes a memory including executable instructions and a processor communicably coupled to the communication interface. The processor is configured to execute the instructions to cause the server system to detect an acquirer server associated with the payee as unavailable. The server system is further caused to send an offline instant payment confirmation message to the payer device for receiving a confirmation response for initiating an offline instant payment transaction. The server system is further caused to retrieve a payee contact information associated with the instant payment identification information of the payee upon receiving the confirmation response. The server system is further caused to send a hold instruction to hold the payment amount from a payer account to an issuer server associated with the payer. The issuer server is configured to hold the payment amount from the payer account. The server system is further caused to electronically facilitate the offline instant payment transaction. The facilitation of the offline instant payment transaction includes notifying the payee using the payee contact information about the payment amount held from the payer account.
[0008] In yet another embodiment, a method is disclosed. The method includes receiving, by a server system associated with a payment network, an offline instant payment transaction request including an instant payment identification number of a payer, a payee contact information, and a payment amount. The method includes receiving a hold instruction to hold the payment amount from a payer account of the payer, the hold instruction received based on detection of an acquirer server associated with the payee as unavailable. The method includes verifying the instant payment identification number and the payment amount. The method includes electronically holding the payment amount from the payer account upon successful verification. The method further includes electronically facilitating an offline instant payment transaction. The facilitation of the offline instant payment transaction includes notifying the payee using the payee contact information about the payment amount held from the payer account.

BRIEF DESCRIPTION OF THE FIGURES

[0009] 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:
[0010] FIG. 1 illustrates an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0011] FIG. 2 is a sequence flow diagram representing holding of a payment amount from a payer account while facilitating offline instant payment transaction, in accordance with an example embodiment of the present disclosure;
[0012] FIG. 3A represents an example representation of a User Interface (UI) displaying an offline instant payment confirmation message sent to a payer device for receiving a confirmation response for initiating an offline instant payment transaction, in accordance with an example embodiment of the present disclosure;
[0013] FIG. 3B represents an example representation of a UI displaying a payment amount holding message sent to a payee device for informing payee about the offline instant payment transaction, in accordance with an example embodiment of the present disclosure;
[0014] FIGS. 4A is a sequence flow diagram representing credit of a payment amount in a payee account, in accordance with an example embodiment of the present disclosure;
[0015] FIGS. 4B represents an example representation of a UI displaying a transaction status message received by the payer on the payer device, in accordance with an example embodiment of the present disclosure;
[0016] FIG. 5 illustrates a flow diagram of a method for facilitating an offline instant payment transaction, in accordance with an example embodiment of the present disclosure;
[0017] FIG. 6 illustrates a flow diagram of another method for facilitating an offline instant payment transaction, in accordance with an example embodiment of the present disclosure;
[0018] FIG. 7 is a simplified block diagram of a server system, in accordance with one embodiment of the present disclosure;
[0019] FIG. 8 is a simplified block diagram of an issuer server, in accordance with one embodiment of the present disclosure;
[0020] FIG. 9 is a simplified block diagram of an acquirer server, in accordance with one embodiment of the present disclosure;
[0021] FIG. 10 is a simplified block diagram of a payment server, in accordance with one embodiment of the present disclosure; and
[0022] FIG. 11 shows simplified block diagram of an electronic device capable of implementing at least some embodiments of the present disclosure.
[0023] 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

[0024] 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.
[0025] 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 are not necessarily all referring 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.
[0026] 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.
[0027] The term “payer”, used throughout the description, refers to a person that performs an instant payment transaction for transferring funds to another person (i.e., a Person to Person (P2P) transaction) or a merchant (i.e., a Person to Merchant (P2M) transaction) using an instant payment transaction enabled application. The term “payee”, used throughout the description, refers to recipients (e.g., a merchant or a person) receiving the funds transferred by the payer.
[0028] The terms "payer account" and “payee account” used throughout the description refer to a payment account that is used to fund a financial transaction (interchangeably referred to as "instant payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by PayPal®, and the like.
[0029] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard®.
[0030] The term "Virtual Payment Address (VPA)" and “Unified Payment Interface Identification (UPI ID)” are used interchangeably throughout the description, and refer to a unique ID that a user needs to create in order to send and accept money through Unified Payment Interface (UPI).
OVERVIEW

[0031] Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for facilitating offline instant payment transaction when connectivity between a payer and an issuer server is up but an acquirer server is not accepting payment at that moment.
[0032] In various example embodiments, the present disclosure provides a server system e.g., a payment server in a payment network configured to receive an instant payment transaction request generated from a payer device, such as a mobile phone of a payer to perform an instant payment transaction. The instant payment transaction request is generated using a Unified Payment Interface (UPI) application accessible on the payer device. In an embodiment, the payer may be required to authenticate himself, for example, by providing a Unified Payment Interface Personal Identification Number (UPI PIN) on a user interface (UI) of the UPI application after initiating the instant payment transaction request. Examples of the UPI application include Google pay™, PhonePe™, Bharat Interface for Money (BHIM), Axis pay® etc. The instant payment transaction request includes instant payment identification information of a payee and a payment amount to be paid by the payer to a payee. The instant payment transaction request may also include additional information such as, but not limited to, payee contact information, account details of the payee, a Virtual Payment Address (VPA) of the payee, UPI PIN and the like.
[0033] In one embodiment, the UPI application sends the instant payment transaction request to an interchange server (i.e. a payment server, an example of the server system). The payment server sends a credit request signal to an acquirer server (an example of the server system) to determine whether the acquirer server is down / unavailable. The payment server sends an offline instant payment confirmation message to the payer device for taking confirmation for initiating offline instant payment transaction upon determining that the acquirer server is down. The payment server, upon receiving confirmation for the offline instant payment transaction from the payer device, sends the instant payment transaction request to an issuer server (an example of the server system) along with a hold instruction in form of a service flag. The issuer server is configured to validate the UPI PIN and funds available in a payer account. The issuer server is also configured to hold the payment amount from the payer account as the service flag is also received along with the instant payment transaction request. The service flag provides an indication that the payment amount needs to be held by the issuer server. The issuer server notifies the payment server about successful holding of the payment amount. Further, the payment server electronically facilitates the offline instant payment transaction by sending a payment amount holding message to the payee using payee contact information. The payment amount holding message indicates that the payment amount has been held from the payer account and will be credited in a payee account once the acquirer server is available / reachable / up.
[0034] In one embodiment, the payment server performs repetitive polling of the acquirer server at a pre-determined time interval to detect if the acquirer server is available. The acquirer server may accept the credit request signal sent by the payment server and may send a request acceptance message to the payment server when the acquirer server is up. Upon receiving the request acceptance message, the payment server detects that the acquirer server is available. The payment server then facilitates credit of the payment amount in the payee account by notifying issuer server about the availability of the acquirer server. The issuer server debits the held amount from the payer account and notifies the acquirer server about the debiting of the payment amount from the payer account by sending a debit notification. The acquirer server, upon receiving the debit notification, credits the payment amount in the payee account.
[0035] Various example embodiments of present disclosure are described hereinafter with reference to FIGS. 1 to 11.
[0036] FIG. 1 illustrates an example representation of an environment 100 related to at least some example embodiments of present disclosure. A UPI application 118 is shown running on a payer device 104 (i.e., a mobile phone) of a payer 102. Examples of the payer device 104 include, but are not limited to, a personal computer (PC), a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a voice activated assistant, a Virtual Reality (VR) device, a smartphone and a laptop. Examples of the UPI application 118 can be an application that can be used for facilitating instant payment transaction such as, but are not limited to, Google pay™, PhonePe™, Bharat Interface for Money (BHIM), Axis pay® etc. In one form, a barcode 120 (hereinafter alternatively referred to as “QR code 120”) is shown to be scanned using the UPI application 118 for processing an instant payment transaction as initiated by the payer 102 for paying for a purchase to a payee 108.
[0037] The payer 102 is shown scanning the QR code 120 using the UPI application 118 installed in the payer device 104. The UPI application 118 will fetch a Virtual Payment Address (VPA) associated with the payee 108 with the help of the scanned QR code 120. In a non-limiting example, the VPA may be similar to an email-id that is linked with a bank account, and is required for performing transactions through the UPI. The VPA may provide the account details of the payee 108. Once the account details of the payee 108 are obtained, the payment transactions can easily be completed. In an embodiment, the payer 102 can directly provide the VPA of the payee 108 in the UPI application 118 for transferring funds to the payee 108. In another embodiment, the payer 102 can provide a payee contact information (e.g., mobile number) associated with the payee 108 in the UPI application 118 for transferring funds to the payee 108. In case of the payee contact information, the UPI application 118 will first retrieve the VPA of the payee 108 through the payee contact information and then funds will be transferred using the VPA of the payee 108. In yet another embodiment, the payer 102 can directly provide account details of the payee 108 in the UPI application 118 for transferring funds to the payee 108.
[0038] Various embodiments of the present disclosure provide mechanisms such that the payer 102 is able to perform the instant payment transaction without fail even when an acquirer server 114 is not accepting payment at that moment.
[0039] In an example scenario, as shown in FIG. 1, the payer 102 has scanned the QR code 120 for initiating an instant payment transaction from the UPI application 118 installed in the payer device 104 for making payment to the payee 108. The QR code 120 is used by the UPI application 118 to retrieve the VPA associated with the payee 108 which helps in getting details of the payee 108. Once the QR code 120 is scanned, the UPI application 118 may ask the payer 102 to provide a payment amount that the payer 102 wants to transfer to the payee 108. After the payer 102 provides the payment amount, the UPI application 118 may send a verification request to an issuer server 112 along with payer details for verification of the payer details (e.g., the UPI PIN) and the funds in a payer account. As the issuer server 112 is up, the payer details and the funds in the payer account are verified. After successful verification, a credit request signal is sent to the acquirer server 114 to determine whether the acquirer server 114 is accepting the payment at that moment or not. If the acquirer server 114 is up, the transaction may be completed successfully.
[0040] In existing (conventional) instant payment transaction methods (i.e., not in accordance with the present disclosure), when the acquirer server is down or not accepting the payment, the transactions fail and the payer 102 receives a message in the payer device 104 stating that the transaction cannot be completed as the acquirer server is down. In an example, the acquirer server may be down because of some hardware problems, such as overheating or software problems, such as database problem. In another example, the acquirer server may be down because of some accident that has happened at the server site such as a fire or a flood. In yet another example, the acquirer server may be down because of some malware or external attacks. However, the mechanisms disclosed in the present disclosure provide an option of facilitating an offline UPI / instant payment transaction when the acquirer server (e.g., the acquirer server 114) associated with a payee (e.g., the payee 108) is not accepting the payment.
[0041] In a non-limiting example, the process of facilitating offline instant payment transaction (hereinafter alternatively referred to as “offline UPI transaction”) is facilitated by a combination of the issuer server 112, the acquirer server 114, and a payment server 116. In one embodiment, the offline UPI / instant payment transaction is facilitated by the payment server 116 associated with a payment network 130. The payment network 130 may be used by the UPI managing authorities as a payment interchange network.
[0042] The issuer server 112 is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which the payer 102 may have an account, which issues a payment card, such as a credit card or a debit card. The issuer server 112 also facilitates verification of the payer details received from the payer device 104. The issuer server 112 further facilitates generation of a VPA associated with the payer 102 to enable UPI based transaction for the payer 102.
[0043] To accept payment using the UPI based payment transaction, the payee 108 must normally establish an account with a financial institution that is part of the financial payment system. This financial institution is usually called the “payee bank” or the “acquiring bank” or “acquirer bank” or simply “acquirer”. The acquirer server 114 is associated with the acquirer bank.
[0044] The payer device 104, the payee device 110, the issuer server 112, the acquirer server 114, and the payment server 116 communicate with one another using a communication network 106. Examples of the communication network 106 may include any type of wired network, wireless network, or a combination of wired and wireless networks. A wireless network may be a wireless local area network (“WLAN”), a wireless wide area network (“WWAN”), or any other type of wireless network now known or later developed. Additionally, the communication network 106 may be or include the Internet, intranets, extranets, microwave networks, satellite communications, cellular systems, personal communication services (“PCS”), infrared communications, global area networks, or other suitable networks, etc., or any combination of two or more such networks.
[0045] Using the payment network 130, the computers of the payment server 116 communicate with the computers of the acquirer / the acquirer server 114 to determine whether the acquirer server 114 is up or down. Upon determining that the acquirer server 114 is down, the computers of the payment server 116 send an offline instant payment confirmation message in the payer device 104 for taking confirmation for the offline instant payment transaction. Once the confirmation for the offline instant payment transaction is received, the computers of the payment server 116 send a hold instruction to the computers of the issuer / the issuer server 112 to hold the payment amount from the payer account.
[0046] After the payment amount is held from the payer account, the computers of the payment server 116 electronically facilitate sending of a payment amount holding message on the payee device 110 indicating that the payment amount is held from the payer account and will be credited in the payee account once the acquirer server 114 is up.
[0047] The computers of the payment server 116 perform repetitive polling with the computers of the acquirer / the acquirer server 114 at a pre-determined time interval to determine whether the acquirer server 114 is available. The computers of the acquirer server 114 may accept the credit request signal sent by the computers of the payment server 116 and may send a request acceptance message to the computers of the payment server 116 when the computers of the acquirer server 114 start working to accept transaction. Upon receiving the request acceptance message, the computers of the payment server 116 detect that the acquirer server 114 is available. The computers of the payment server 116 may then send a notification to the computers of the issuer server 112 to notify that the acquirer server 114 is up. After receiving the notification, the computers of the issuer server 112 debit the held amount from the payer account and notify the computers of the acquirer server 114 about the debit of the payment amount from the payer account by sending a debit notification. The computers of the acquirer server 114, upon receiving the debit notification, credit the payment amount in the payee account.
[0048] After the instant payment transaction is completed, the transaction is settled among the payee, the acquirer and the issuer. Settlement refers to the transfer of financial data or funds among the payee account, the acquirer, and the issuer, related to the transaction. Usually, transactions are captured and accumulated into a “batch”, which is settled as a group.
[0049] Since the payer 102 has an option of performing offline instant payment transaction, the payer 102 and the payee 108 do not have to worry about the transaction failure due to unavailability of acquirer side connectivity or server down issues. In existing (conventional) UPI / instant payment transaction methods (i.e., not in accordance with the present disclosure), the payer 102 has to perform the transaction multiple times till the acquirer server 114 starts accepting payments. In contrast to existing instant payment transaction methods, by using the embodiments of the present disclosure, the payer 102 is only required to perform the transaction once. Hence, the payer 102 does not need to worry about transaction failure and thereby does not need to repeat the whole process again. Some non-exhaustive example embodiments of facilitating offline instant payment transactions are described with reference to the following description, particularly with reference to FIGS. 2 to FIGS. 11.
[0050] FIG. 2 represents a sequence flow diagram 200 representing the holding of the payment amount from the payer account while facilitating offline instant payment transaction, in accordance with an example embodiment of the present disclosure. In at least one embodiment, and as explained with reference to FIG. 1, when the acquirer server 114 is down and not accepting the payment, the payer 102 is provided with an option of performing an offline instant payment transaction. In the offline instant payment transaction, the payment amount will be held from the payer account which will be transferred to the payee account once the acquirer is up.
[0051] At 205, a payer (e.g., the payer 102) accesses a UPI application (e.g., the UPI application 118) accessible on the payer device (e.g., a payer device 104) to initiate and send an instant payment transaction request to the payment server 116 for transferring a payment amount to a payee account. As explained with reference to FIG. 1, the instant payment transaction request is generated using the UPI application 118 when the payer 102 provides payer details, such as UPI PIN, payee details, such as VPA, and the payment amount to be transferred to the payee account. In some embodiments, the instant payment transaction request includes the UPI PIN of the payer, an instant payment identification information of a payee, and a payment amount. In one embodiment, the instant payment identification information of the payee includes the VPA associated with the payee. In another embodiment, the instant payment identification information of the payee includes a payee contact information.
[0052] At 210, the payment server 116 sends a credit request signal (an example of repetitive polling) to the acquirer server 114 for determining whether the acquirer server 114 is accepting payment at that moment. The payment server 116 waits for a response from the acquirer server 114 for the credit request for a predefined time but no request acceptance message is received in the predefined time. In an embodiment, the predefined time is defined by an admin of the payment server 116.
[0053] At 215, the payment server 116 detects that the acquirer server 114 is down / unavailable and is not accepting payment currently as the credit request signal is not accepted by the acquirer server 114. At 220, the payment server 116 is configured to send an offline instant payment confirmation message to the payer device 104 for receiving a confirmation response for initiating an offline instant payment transaction. The offline instant payment confirmation message informs the payer 102 about the acquirer down issue and asks for permission to go ahead with the offline instant payment transaction. The offline instant payment confirmation message is explained in detail with reference to FIG. 3A.
[0054] At 225, the payer accepts an offline instant payment transaction request. At 230, the payer device 104 sends the confirmation response to the payment server 116 via the UPI application. At 235, the payment server 116 retrieves the payee contact information associated with the instant payment identification information of the payee. In an embodiment, the payment server 116 may retrieve the VPA of the payee which is further used to retrieve a mobile number of the payee associated with the VPA of the payee. In another embodiment, the payment server 116 may directly retrieve the payee contact information.
[0055] At 240, the payment server 116 is configured to send the offline instant payment transaction request including payer details, such as the UPI PIN and the payment amount to be transferred from the payer account to the payee account to the issuer server 112 along with a hold instruction to hold the payment amount. In an embodiment, the hold instruction is sent in form of a service flag. The service flag provides an indication to the issuer server 112 that the payment amount needs to be held till the time acquirer server 114 is not accepting the payment. Herein and throughout the present disclosure, the term “holding”, unless the context suggest otherwise, means that the payment amount will be available in the payer account but the payer cannot use that amount for making other transactions.
[0056] At 245, the issuer server 112 is configured to verify the payer details and funds available in the payer account. The UPI PIN provided by the payer 102 on the UPI application 118 is verified first, and upon successful verification of the UPI PIN, the funds available in the payer account are checked to determine whether the payer account is in good standing and whether the purchase is covered by the available balance in the payer account.
[0057] At 250, upon successful verification of the funds and UPI PIN, the issuer server 112 is configured to hold the payment amount from the payer account. At 255, the issuer server 112 is configured to send a notification to the payment server 116 to notify about the holding of the payment amount from the payer account.
[0058] At 260, the payment server 116 is configured to facilitate sending of a payment amount holding message to the payee device 110 using the payee contact information (e.g., the mobile number retrieved at step 235) of the payee 108. The payment amount holding message indicates that the issuer server 112 has held the payment amount from the payer account and the payment amount will be credited to the payee account once the acquirer server 114 starts accepting payment. Another example of the payee contact information includes a registered email ID of the payee. In an example embodiment, the payment server 116 sends the retrieved payee contact information to the issuer server 112. In that scenario, the issuer server 112 is configured to notify the payee using the payee contact information about the payment amount held from the payer account.
[0059] FIG. 3A shows an example representation of a User Interface (UI) 300 displaying an offline instant payment confirmation message sent to a payer device for receiving a confirmation response for initiating an offline instant payment transaction, in accordance with an example embodiment.
[0060] As shown in FIG. 3A, the UPI application 118 is configured to display the UI 300 displaying the offline instant payment confirmation message on the payer device 104 . As explained with reference to FIGS. 1 and 2, the UPI application 118 is used by the payer 102 for initiating the instant payment transaction request to make a payment to the payee 108 for the purchases. As the acquirer server 114 associated with the payee 108 is not accepting the payment at that moment, a normal instant payment transaction cannot be executed. So, a popup 302 including the offline instant payment confirmation message is displayed by the UI 300 on the UPI application 118. The offline instant payment confirmation message includes a text displaying, “The transaction cannot be completed as xyz bank server is not accepting the payment. Do you wish to continue with offline UPI transaction service?” Here, the xyz bank is a recipient bank which is not accepting the payment at the moment.
[0061] The UI 300 also includes two clickable buttons 304 and 306 labelled as ‘YES’ and ‘CANCEL’, respectively provided on the popup 302. The payer 102 may click the button 304 if the payer 102 wishes to continue with the offline instant payment transaction service or the button 306 if the payer 102 wishes to cancel the instant payment transaction. If the payer 102 clicks the button 304, an offline instant payment transaction request including payer details, such as the UPI PIN and the payment amount to be transferred from the payer account to the payee account are sent to the issuer server 112 along with a hold instruction to hold the payment amount from the payer account. Upon receiving the offline instant payment transaction request, the issuer server 112 holds the payment amount from the payer account after verifying the payer details and funds available in the payer account. After holding the payment amount, the issuer server 112 sends a notification to the payment server 116 to notify about the holding of the payment amount from the payer account. The payment server 116, upon receiving the notification, sends a payment amount holding message to the payee device 110 using the payee contact information of the payee 108. The payment amount holding message sent to the payee device 110 is explained in detail with reference to FIG. 3B. If the payer 102 clicks the button 306, the instant payment transaction request is cancelled and the payer 102 is enabled to again initiate the instant payment transaction request after a predetermined period of time.
[0062] FIG. 3B shows an example representation of a UI 350 displaying a payment amount holding message 352 sent to the payee device 110 for informing the payee 108 about the offline instant payment transaction, in accordance with an example embodiment.
[0063] As shown in FIG. 3B, the UI 350 displays the payment amount holding message 352 sent to the payee device 110. The payment amount holding message 352 includes a text displaying, “The ‘1234’ amount has been held from the ‘payer name’ account and will be credited to your account once the xyz bank server is available”.
[0064] In an embodiment, the payment amount holding message 352 is sent to the payee device 110 by the payment server 116 using the payee contact information. In another embodiment, the payment amount holding message 352 is sent to the payee device 110 by an on-behalf service opted by the issuer server 112. The on-behalf service may be facilitated by a third-party enterprise to the issuer bank. The issuer server 112, after holding the payment amount as instructed by the hold instruction received from the payment server 116, may share information about holding of the payment amount from the payer account with an on-behalf server (OBS) associated with the third-party enterprise along with the payee contact information. The OBS may then send the payment amount holding message 352 to the payee device 110 on behalf of the issuer server 112 using the payee contact information.
[0065] In one example embodiment, the on-behalf service may be provided by the payment server 116 to the issuer server 112. In such a scenario, instead of sending the payee contact information to the issuer server 112, the payment server 116 itself sends a payment amount holding message to the payee device 110 using the payee contact information of the payee 108 after receiving a notification about the holding of the payment amount from issuer server 112 as explained hereinabove with reference to FIG. 3B.
[0066] FIG. 4A represents a sequence flow diagram 400 representing crediting the payment amount in the payee account, in accordance with an example embodiment of the present disclosure. In at least one embodiment, and as explained with reference to FIG. 1, the payment server 116 may perform repetitive polling to determine /detect whether the acquirer server 114 is reachable. Once the acquirer server 114 is reachable, the payment server 116 may facilitate credit of the payment amount held from the payer account into the payee account.
[0067] At 405, a credit request signal is sent to the acquirer server 114 by the payment server 116. The credit request signal is sent as part of the repetitive polling of the acquirer server 114 by the payment server 116 at pre-determined time intervals to detect if the acquirer server 114 is available. If the acquirer server 114 is available, the acquirer server 114 accepts the credit request signal sent by the payment server 116. At 410, a request acceptance message is sent to the payment server 116 by the acquirer server 114. Upon receiving the request acceptance message, the payment server 116 gets to know that the acquirer server 114 is up/working now.
[0068] At 415, the payment server 116 is configured to send a notification to the issuer server 112 to notify about the availability of the acquirer server 114 i.e. the acquirer server 114 is accepting payments now. At 420, after receiving the notification, the issuer server 112 is configured to debit the payment amount held from the payer account. At 425, the issuer server 112 updates the account balance of the payer account after the deduction.
[0069] At 430, the issuer server 112 is configured to send a debit notification to the acquirer server 114 to notify about the debit of the payment amount from the payer account. At 435, after receiving the debit notification, the acquirer server 114 credits the payment amount in the payee account. At 440, the acquirer server 114 sends a transaction status to the payment server 116. The transaction status may include successful, failure or pending. At 445, the payment server 116 sends the transaction status to the payer device 104 of the payer 102. Alternatively, the transaction status may be sent on the UPI application 118 running on the payer device 104. The transaction process completes at operation 450.
[0070] FIG. 4B is an example representation of a UI 470 displaying a transaction status message received by the payer 102 on the payer device 104, in accordance with an example embodiment.
[0071] As shown in FIG. 4B, a messaging application 472 is configured to display the UI 470 displaying a transaction status message 474 on the payer device 104. The transaction status message 474 includes a text displaying, “The offline transaction has been successful”. The transaction status message 474 notifies the payer 102 about transaction status of the offline instant payment transaction that the payer 102 has performed using the UPI application 118.
[0072] In one example embodiment, the instant payment transaction request generated from the payer device 104 is sent directly to the issuer server 112 for authentication purposes by the payment server 116. The issuer server 112, upon verifying the UPI PIN and the available funds in the payer account, debits the payment amount from the payer account. Thereafter, the issuer server 112 sends a debit notification signal to the payment server 116. The payment server 116 forwards the debit notification signal to the acquirer server 114. The acquirer server 114 being unavailable at the moment, does not respond to the debit notification signal. After waiting for a pre-determined time-period, the payment server 116 determines that the acquirer server 114 is down. Thereafter, the payment server 116 sends a hold instruction to the issuer server 112 to hold the payment amount from the payer account. As the issuer server 112 has already debited the payment amount, a reversal of the payment amount is first initiated. Thereafter, the payment amount is held by the issuer server 112 as per the hold instruction received from the payment server 116. The payment server 116 performs repetitive polling of the acquirer server 114 at a pre-determined time interval to detect if the acquirer server 114 is available. When the acquirer server 114 is detected as available, the issuer server 112 receives a notification about availability of the acquirer server 114 by the payment server 116. The issuer server 112 is configured to debit the payment amount held from the payer account. The acquirer server 114 is configured to credit the payment amount to a payee account of the payee 108 upon receiving a debit notification about debiting the payment amount from the issuer server 112 via the payment server 116.
[0073] FIG. 5 illustrates a flow diagram of a method 500 for facilitating an offline instant payment transaction, in accordance with an example embodiment. More specifically, the method 500 for enabling a payer (e.g., the payer 102) to perform the instant payment transaction without fail even when the acquirer server (e.g., the acquirer server 114) is down, is disclosed. The method 500 depicted in the flow diagram may be executed by, for example, the at least one server system such as the acquirer server 114, the issuer server 112, and the payment server 116 explained with reference to FIG. 1. Operations of the method 500, and combinations of operation in the method 500, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 500 are described herein with help of the servers 112, 114 or 116. It is noted that the operations of the method 500 can be described and/or practiced by using a system other than these server systems. The method 500 starts at operation 502.
[0074] At 502, the method 500 includes receiving, by a server system (e.g., the payment server 116) associated with a payment network, an instant payment transaction request from a payer device. The instant payment transaction request includes an instant payment identification information of a payee, and a payment amount. In an embodiment, the instant payment identification information includes the VPA associated with the payee. In another embodiment, the instant payment identification information includes the payee contact information. The instant payment transaction request may be generated by a UPI application (e.g., the UPI application 118) running on the payer device. The payer device may send the instant payment transaction request to the payment server 116 over the payment network 130.
[0075] At 504, the method 500 includes, detecting, by the server system, an acquirer server (e.g., the acquirer server 114) associated with the payee as unavailable. The payment server 116 may send a credit request signal to the acquirer server 114 to determine whether the acquirer server 114 is reachable. The payment server 116 may validate that the acquirer server 114 is unavailable if a request acceptance message is not received from the acquirer server 114 within a predefined time-period. In an embodiment, the predefined time-period is set by the admin of the payment server 116.
[0076] At 506, the method 500 includes sending, by the server system, an offline instant payment confirmation message to the payer device for receiving a confirmation response for initiating an offline instant payment transaction. As explained with reference to FIG. 3, the payment server 116 may send the offline instant payment confirmation message to the payer device associated with the payer to inform the payer about the acquirer server down issue and also to take permission for going ahead with offline instant payment transaction.
[0077] At 508, the method 500 includes retrieving, by the server system, payee contact information associated with the instant payment identification information of the payee. The instant payment identification information of the payee includes the VPA associated with the payee or the payee contact information. In case of VPA, the payment server 116 may retrieve the VPA of the payee which is further used to retrieve a mobile number of the payee associated with the VPA of the payee. The payment server 116 may directly retrieve the mobile number of the payee if the instant payment identification information includes the payee contact information.
[0078] At 510, the method 500 includes sending, by the server system, a hold instruction to hold the payment amount from a payer account to an issuer server (e.g., the issuer server 112) associated with the payer. The issuer server 112 is configured to hold the payment amount from the payer account upon receiving the hold instruction. Once the confirmation for the offline instant payment transaction is received from the payer, the payment server 116 may send the offline instant payment transaction request including the payer details, such as the UPI PIN and the payment amount to be transferred from the payer account to the payee account to the issuer server 112 along with the hold instruction to hold the payment amount. In an embodiment, the hold instruction is sent in form of a service flag. The service flag provides an indication to the issuer server 112 that the payment amount needs to be held till the time acquirer server 114 is not accepting the payment. After receiving the hold instruction, the issuer server 112 may hold the payment amount from the payer account.
[0079] At 512, the method 500 includes electronically facilitating, by the server system, the offline instant payment transaction. The electronically facilitating of the offline instant payment transaction includes notifying the payee using the payee contact information about the payment amount held from the payer account. In an embodiment, the offline instant payment transaction is a UPI transaction. In an embodiment, the payee contact information is sent to the issuer server 112 and the issuer server 112 is configured to notify the payee by sending the payment amount holding message using the payee contact information about the payment amount held from the payer account. In another embodiment, the payment server 116 is configured to notify the payee by sending the payment amount holding message as explained with reference to FIG. 3B using the payee contact information.
[0080] FIG. 6 illustrates a flow diagram of another method 600 for facilitating the offline instant payment transaction, in accordance with an example embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the at least one server system such as the acquirer server 114, the issuer server 112, and the payment server 116 explained with reference to FIG. 1. Operations of the method 600, and combinations of operation in the method 600, 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 operations of the method 600 are described herein with help of the servers 112, 114 or 116. It is noted that the operations of the method 600 can be described and/or practiced by using a system other than these server systems. The method 600 starts at operation 602.
[0081] At 602, the method 600 includes receiving, by a server system associated with the payment network, an offline instant payment transaction request including an instant payment identification number of a payer, the payee contact information, and the payment amount. The payment server 116 may send the offline instant payment transaction request to the issuer server 112 when the payer opts for the offline instant payment transaction. The instant payment identification number of the payer is a Unified Payment Interface Personal Identification Number (UPI PIN) of the payer which is used by the issuer server 112 to authenticate the payer. The payee contact information may be used by the OBS to send an offline instant payment transaction status message to the payee. .
[0082] At 604, the method 600 includes receiving, by the server system, a hold instruction to hold the payment amount from a payer account of the payer. The hold instruction is received based on detection of the acquirer server 114 associated with the payee as unavailable. In an embodiment, the hold instruction is received in form of the service flag. The service flag provides an indication to the issuer server 112 that the payment amount needs to be held till the time acquirer server 114 is not accepting the payment. After receiving the hold instruction, the issuer server 112 holds the payment amount from the payer account.
[0083] At 606, the method 600 includes verifying, by the server system, the instant payment identification number and the payment amount. The issuer server 112 may verify the UPI PIN and, upon successful verification of the UPI PIN, verify the funds available in the payer account to determine whether the payer account is in good standing and whether the payment amount is covered by the payer available account balance.
[0084] At 608, the method 600 includes electronically holding, by the server system, the payment amount from the payer account associated with the payer upon successful verification. Once the payer details are verified, the issuer server 112 may hold the payment amount in the payer account as the service flag is received which indicates that the payment amount in the payer account needs to be held by the issuer server 112.
[0085] At 610, the method 600 includes electronically facilitating, by the server system, an offline instant payment transaction. The electronically facilitation of the offline instant payment transaction includes notifying the payee using the payee contact information about the payment amount held from the payer account. A payment amount holding message is sent to the payee device using the payee contact information by the on-behalf service opted by the issuer server 112. The issuer server 112, after holding the payment amount as instructed by the hold instruction received from the payment server 116, may share information about holding of the payment amount from the payer account with the OBS along with the payee contact information. The OBS may then send the payment amount holding message to the payee device on behalf of the issuer server 112 using the payee contact information. It should be noted that the OBS is a financial institution that may or may not be equivalent to the issuer server 112.
[0086] FIG. 7 is a simplified block diagram of a server system 700, in accordance with one embodiment of the present disclosure. The server system 700 is an example of a server system that is a part of the payment network 130. Examples of the server system 700 include, but not limited to, the acquirer server 114, the issuer server 112 and the payment server 116. The server system 700 includes a computer system 705 and a database 710.
[0087] The computer system 705 includes at least one processor 715 for executing instructions. Instructions may be stored in, for example, but not limited to, a memory 720. The processor 715 may include one or more processing units (e.g., in a multi-core configuration).
[0088] The processor 715 is operatively coupled to a communication interface 725 such that the computer system 705 is capable of communicating with a remote device such as a payer device 735 (e.g., the payer device 104) and a payee device 740 (e.g., the payee device 110) or communicating with any entity within the payment network 130. For example, the communication interface 725 may receive the instant payment transaction request from the payer device 735, via the Internet.
[0089] The processor 715 may also be operatively coupled to the database 710. The database 710 is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, instant payment transaction data generated as part of sales activities conducted over the bankcard network including data relating to payees, account holders or customers, and purchases. The database 710 may also store information related to a plurality of payer accounts. Each payer account data includes at least one of a payer name, a payer address, an account number, a UPI PIN, and other account identifiers. The database 710 may also store a payee identifier that identifies each payee registered to use the payment network, and instructions for settling transactions including payee VPA. The database 710 may further include issuer account information.
[0090] The database 710 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 710 may include a storage area network (SAN) and/or a network attached storage (NAS) system. In some embodiments, the database 710 is integrated within the computer system 705. For example, the computer system 705 may include one or more hard disk drives as the database 710. In other embodiments, the database 710 is external to the computer system 705 and may be accessed by the computer system 705 using a storage interface 730. The storage interface 730 is any component capable of providing the processor 715 with access to the database 710. The storage interface 730 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 715 with access to the database 710.
[0091] The processor 715 is configured to receive an instant payment transaction request via the communication interface 725. The request is initiated by a payer from a UPI application running on the payer device 735. The processor 715 is configured to detect that the acquirer server 114 associated with the payee as unavailable. The processor 715 is configured to send an offline instant payment confirmation message to the payer device 735 for receiving a confirmation response for initiating an offline instant payment transaction via the communication interface 725. The processor 715 is configured to send a hold instruction to the issuer server 112 associated with the payer to hold the payment amount from a payer account after receiving the confirmation response. The processor 715 is configured to electronically facilitate offline instant payment transaction. The processor 715 is configured to perform repetitive polling of the acquirer server 114 at a pre-determined time interval to detect if the acquirer server 114 is available. The processor 715 is also configured to notify the issuer server 112 about the availability of the acquirer server 114.
[0092] In at least one example embodiment, the processor 715 is configured to receive a notification about availability of the acquirer server 114. The processor 715 is configured to debit the payment amount held from the payer account. The processor 715 is also configured to send a debit notification about debiting the payment amount to the acquirer server 114. Further, the processor 715 is configured to credit the payment amount to the payee account of the payee.
[0093] FIG. 8 is a simplified block diagram of an issuer server 800, in accordance with one embodiment of the present disclosure. The issuer server 800 is an example of the issuer server 112 of FIG. 1 or may be embodied in the issuer server 112. The issuer server 800 is associated with an issuer bank / issuer, in which a payer may have an account. The issuer server 800 includes a processing module 805 operatively coupled to a storage module 810, an authorization module 815, and a communication module 820. The components of the issuer server 800 provided herein may not be exhaustive, and that the issuer server 800 may include more or fewer components than those depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 800 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0094] The storage module 810 is configured to store machine executable instructions to be accessed by the processing module 805. Additionally, the storage module 810 stores information related to, contact information of the payer, identification information of the payer, bank account number, payment card details, internet banking information, UPI ID and UPI PIN for UPI, mobile personal identification number (MPIN) for mobile banking and the like. The UPI PIN is a four to six-digit identification code issued by the issuer bank of the payer while registering for electronic instant payment transactions or while issuing the payment card to the payer. For example, the UPI PIN may be issued for UPI based transactions, swipe based transactions, mobile banking, internet banking, payment string based transaction and the like. The UPI PIN can also be created by the payer while registering the payer account in UPI applications. The UPI PIN is needed to be verified for authentication of the payer identity and association with the issuer bank to process the instant payment transaction. This information is retrieved by the processing module 805 for cross-verification during instant payment transactions.
[0095] The processing module 805, in conjunction with the authorization module 815, is configured to validate the payer details received from the payment server 116 via the communication module 820. The processing module 805 is also configured to receive a hold instruction to hold the payment amount from the payer account upon detection of the acquirer server 114 associated with the payee as unavailable via the communication module 820. Additionally, the processing module 805 is configured to verify the UPI PIN, the sufficient funds in the issuer account and the like. Upon successful authorization of the payer information, the payment transaction is processed further by the processing module 805 by electronically holding the payment amount from the payer account of the payer. The processing module 805 is further configured to communicate with one or more remote devices such as a remote device 825 using the communication module 820 over a network such as the communication network 106 or the payment network 130 of FIG. 1. The examples of the remote device 825 include an on-behalf server (not shown), the payment server 116, the acquirer server 114, other computing systems of issuer and the payment network 130 and the like. The processing module 805 is configured to notify the payee about the holding of the payment amount via the remote device 825. The processing module 805 is configured to receive a notification about availability of the acquirer server 114. The processing module 805 is also configured to debit the payment amount held from the payer account. The processing module 805 is further configured to send a debit notification about debiting the payment amount to the acquirer server 114. The communication module 820 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls.
[0096] FIG. 9 is a simplified block diagram of an acquirer server 900, in accordance with one embodiment of the present disclosure. The acquirer server 900 is associated with the acquirer bank of a payee where the payee has established an account to accept payment using the UPI. The acquirer server 900 is an example of the acquirer server 114 of FIG. 1 or may be embodied in the acquirer server 114. Further, the acquirer server 900 is configured to facilitate the offline instant payment transaction with the issuer server 800 using the payment network 130 of FIG. 1. The acquirer server 900 includes a processing module 905 communicably coupled to a database 910 and a communication module 915. The components of the acquirer server 900 provided herein may not be exhaustive, and that the acquirer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 900 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0097] The database 910 includes data related to a payee, such as, but not limited to, a payee VPA or UPI ID, a payee primary account number (PAN), a payee name, a payee city, a merchant postal code, a payee brand name, a payee ID and the like. The processing module 905 is configured to use the payee VPA to identify the payee during the normal processing of the instant payment transactions, adjustments, chargebacks, end-of-month fees and so forth.
[0098] In an embodiment, the communication module 915 is capable of facilitating operative communication with a remote device 920 (e.g., the issuer server 800 and/or the payment server 116) using API calls. The communication may be achieved over a communication network, such as the communication network 106. For example, the processing module 905 is configured to receive a credit request signal sent by the remote device 920 as part of repetitive polling using the communication module 915. The processing module 905 is also configured to accept the credit request signal sent by the payment server 116. Further, the processing module 905 is configured to send a request acceptance message to the remote device 920 using the communication module 915 when the acquirer server 900 starts functioning properly. Additionally, the processing module 905 is configured to receive a debit notification about debit of the payment amount from the payment server 116 or the issuer server 112 (or the issuer server 800) using the communication module 915. Thereafter, the processing module 905 may retrieve payee VPA from the database 910 to credit the payment amount debited from the payer account in the payee account of the payee. Further, the processing module 905 may be configured to send the offline instant payment transaction status to the payee device 740 of the payee.
[0099] FIG. 10 is a simplified block diagram of a payment server 1000, in accordance with one embodiment of the present disclosure. The payment server 1000 may correspond to the payment server 116 of FIG. 1. As explained with reference to FIG. 1, the acquirer server 114 is associated with a payment network 130. The payment network 130 may be used by the issuer server 800 and the acquirer server 900 as a payment interchange network. The payment server 1000 includes a processing system 1005 configured to extract programming instructions from a memory 1010 to provide various features of the present disclosure. The components of the payment server 1000 provided herein may not be exhaustive, and that the payment server 1000 may include more or fewer components than those depicted in FIG. 10. 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 1000 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00100] Via a communication interface 1020, the processing system 1005 receives an instant payment transaction request from a remote device 1030, such as the payer device 104. The instant payment transaction request includes an instant payment identification information of a payee, and a payment amount. The processing system 1005 is configured to communicate with a remote entity, such as the acquirer server 900 via the communication interface 1020 to determine whether the acquirer server 900 is down. The communication may be achieved through API calls, without loss of generality. An offline request generation module 1025 is operatively coupled to the processing system 1005. The offline request generation module 1025 includes one or more algorithms capable of generating an offline instant payment transaction request to be sent to the payer device 104 for receiving a confirmation response, upon determining that the acquirer server 900 is down. The database 1015 is configured to store UPI PIN, the payment amount, payer account information, transaction records, payee account information, a payee contact information associated with the instant payment identification information of a payee, and the like. Upon receiving the confirmation response, the processing system 1005 is configured to retrieve the payee contact information from the database 1015 which is used to notify payee about the offline instant payment transaction status. Further, the processing system 1005 is configured to communicate with another remote entity, such as the issuer server 800 via the communication interface 1020 to send a hold instruction to hold the payment amount to the issuer server 800. Apart from sending offline UPI / instant payment transaction request and hold instruction to hold the payment amount, the processing system 1005 may be configured to perform various functions such as maintenance and operation of the database 1015, performing repetitive polling, facilitating credit of the payment amount from the payer account to the payee account, sending transaction clearing related information and the like.
[00101] FIG. 11 shows simplified block diagram of an electronic device 1100, for example, a mobile phone capable of implementing the various embodiments of the present disclosure. For example, the electronic device 1100 may correspond to the payer device 735 (e.g., the payer device 104 of FIG. 1) and the payee device 740 (e.g., the payee device 110 of FIG. 1) of FIG. 7. The electronic device 1100 is depicted to include one or more applications, such as a UPI application. The UPI application 1106 is capable of communicating with any of the servers 112, 114, and 116 for facilitating offline instant payment transaction.
[00102] It should be understood that the electronic device 1100 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with the electronic device 1100 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 11. As such, among other examples, the electronic device 1100 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00103] The illustrated electronic device 1100 includes a controller or a processor 1102 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1104 controls the allocation and usage of the components of the electronic device 1100 and supports for one or more payment transaction applications programs (see, the applications 1106) such as the UPI application, that implements one or more of the innovative features described herein. In addition to the UPI application, the applications 1106 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00104] The illustrated electronic device 1100 includes one or more memory components, for example, a non-removable memory 1108 and/or removable memory 1110. The non-removable memory 1108 and/or the removable memory 1110 may be collectively known as a database in an embodiment. The non-removable memory 1108 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1110 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1104 and the applications 1106. The electronic device 1100 may further include a user identity module (UIM) 1112. The UIM 1112 may be a memory device having a processor built in. The UIM 1112 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1112 typically stores information elements related to a mobile subscriber. The UIM 1112 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA9000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00105] The electronic device 1100 can support one or more input devices 1120 and one or more output devices 1130. Examples of the input devices 1120 may include, but are not limited to, a touch screen / a display screen 1122 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1124 (e.g., capable of capturing voice input), a camera module 1126 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1128. Examples of the output devices 1130 may include, but are not limited to, a speaker 1132 and a display 1134. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1122 and the display 1134 can be combined into a single input/output device.
[00106] A wireless modem 1140 can be coupled to one or more antennas (not shown in the FIG. 11) and can support two-way communications between the processor 1102 and external devices, as is well understood in the art. The wireless modem 1140 is shown generically and can include, for example, a cellular modem 1142 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1144 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1146. The wireless modem 1140 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the electronic device 1100 and a public switched telephone network (PSTN).
[00107] The electronic device 1100 can further include one or more input/output ports 1150, a power supply 1152, one or more sensors 1154, for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the electronic device 1100 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1156 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1160, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00108] The disclosed methods with reference to FIG. 5 and FIG. 6, or one or more operations of the methods 500 and 600 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 non-volatile memory or storage components (e.g., hard drives or solid-state non-volatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). 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 network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00109] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00110] Particularly, the servers 112, 114 and 116, their various components such as the computer system 705 and the database 710 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.
[00111] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00112] 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.