Claims:1. A method for facilitating offline transactions, the method comprising:
receiving, by a server, from a user device of a user, a first request for generating a first offline code, wherein the first request is indicative of a first payment account of the user and a first amount from the first payment account that is to be linked to the first offline code;
generating, by the server, based on the received first request, the first offline code having the first amount linked thereto and a first authorization parameter for authorizing the first offline code;
communicating, by the server, the first offline code and the first authorization parameter to the user device, wherein the first offline code is accessible by the user on the user device when the user device lacks network connectivity;
receiving, by the server, from a merchant device of a merchant, a transaction request indicative of a transaction amount of an offline transaction, the first offline code, and the first authorization parameter, wherein the first offline code is provided to the merchant device through the user device and the first authorization parameter is provided to the merchant device by the user for authorizing the first offline code, when the user device lacks the network connectivity; and
processing, by the server, the transaction request for a transfer of the transaction amount to a second payment account of the merchant upon successful authorization of the first offline code, wherein the transaction amount is deducted from the first amount.

2. The method of claim 1, wherein the first offline code is in a tokenized format and is indicative of a first token identifier that is mapped to the first amount and user information of the user.

3. The method of claim 1, further comprising generating, by the server, a set of offline codes, in addition to the first offline code, wherein each of the set of offline codes is linked to a corresponding amount based on a corresponding request received from the user device, and wherein the set of offline codes is presented to the user on the user device and is accessible by the user on the user device when the user device lacks the network connectivity.

4. The method of claim 1, wherein the transaction amount is less than or equal to the first amount.

5. The method of claim 4, further comprising:
receiving, by the server, from the user device, a second request to link a second amount equal to a difference between the first amount and the transaction amount to a new offline code, wherein the second request is received upon usage of the first offline code for the offline transaction, and wherein the second request is received when the network connectivity is available to the user device;
generating, by the server, based on the second request, the new offline code having the second amount linked thereto and a second authorization parameter for authorizing the second offline code; and
communicating, by the server, the second offline code and the second authorization parameter to the user device, wherein the second offline code is accessible by the user on the user device when the user device lacks the network connectivity.

6. The method of claim 4, further comprising:
receiving, by the server, from the user device, a second request to credit a second amount equal to a difference between the first amount and the transaction amount to the first payment account, wherein the second request is received upon usage of the first offline code for the offline transaction, and wherein the second request is received when the network connectivity is available to the user device; and
crediting, by the server, to the first payment account, the second amount based on the second request.

7. The method of claim 1, wherein the first offline code is one of a quick response code or a barcode.

8. The method of claim 1, further comprising hosting, by the server, a service application that is executable on the user device, wherein the first request received by the server is initiated by way of the service application and the first offline code is presented on the user device by way of the service application.

9. The method of claim 8, wherein the service application is hosted by the server to provide an open banking service to the user and the merchant on the user device and the merchant device, respectively.

10. The method of claim 1, further comprising initiating, by the server, the transfer of the transaction amount from the first payment account to the second payment account.

11. A system for facilitating offline transactions, the system comprising:
a server configured to:
receive, from a user device of a user, a first request for generating a first offline code, wherein the first request is indicative of a first payment account of the user and a first amount from the first payment account that is to be linked to the first offline code;
generate, based on the received first request, the first offline code having the first amount linked thereto and a first authorization parameter for authorizing the first offline code;
communicate, the first offline code and the first authorization parameter to the user device, wherein the first offline code is accessible by the user on the user device when the user device lacks network connectivity;
receive, from a merchant device of a merchant, a transaction request indicative of a transaction amount of an offline transaction, the first offline code, and the first authorization parameter, wherein the first offline code is provided to the merchant device through the user device and the first authorization parameter is provided to the merchant device by the user for authorizing the first offline code, when the user device lacks the network connectivity; and
process, the transaction request for a transfer of the transaction amount to a second payment account of the merchant upon successful authorization of the first offline code, wherein the transaction amount is deducted from the first amount.

12. The system of claim 11, wherein the first offline code is in a tokenized format and is indicative of a first token identifier that is mapped to the first amount and user information of the user.

13. The system of claim 11, wherein the server is further configured to generate a set of offline codes, in addition to the first offline code, wherein each of the set of offline codes is linked to a corresponding amount based on a corresponding request received from the user device, and wherein the set of offline codes is presented to the user on the user device and is accessible by the user on the user device when the user device lacks the network connectivity.

14. The system of claim 11, wherein the transaction amount is less than or equal to the first amount.

15. The system of claim 14, wherein the server is further configured to:
receive, from the user device, a second request to link a second amount equal to a difference between the first amount and the transaction amount to a new offline code, wherein the second request is received upon usage of the first offline code for the offline transaction, and wherein the second request is received when the network connectivity is available to the user device;
generate, based on the second request, the new offline code having the second amount linked thereto and a second authorization parameter for authorizing the second offline code; and
communicate, the second offline code and the second authorization parameter to the user device, wherein the second offline code is accessible by the user on the user device when the user device lacks the network connectivity.

16. The system of claim 14, wherein the server is further configured to:
receive, from the user device, a second request to credit a second amount equal to a difference between the first amount and the transaction amount to the first payment account, wherein the second request is received upon usage of the first offline code for the offline transaction, and wherein the second request is received when the network connectivity is available to the user device; and
credit, to the first payment account, the second amount based on the second request.

17. The system of claim 11, wherein the first offline code is one of a quick response code or a barcode.

18. The system of claim 11, wherein the server is further configured to host a service application that is executable on the user device, and wherein the first request received by the server is initiated by way of the service application and the first offline code is presented on the user device by way of the service application.

19. The system of claim 18, wherein the server hosts the service application to provide an open banking service to the user and the merchant on the user device and the merchant device, respectively.

20. The system of claim 11, wherein the server is further configured to initiate the transfer of the transaction amount from the first payment account to the second payment account.
, Description:METHOD AND SYSTEM FOR FACILITATING OFFLINE DIGITAL TRANSACTIONS
BACKGROUND

FIELD OF THE DISCLOSURE

Various embodiments of the disclosure relate generally to digital transactions. More particularly, various embodiments of the present disclosure relate to a method and a system for facilitating offline digital transactions.

DESCRIPTION OF THE RELATED ART

Advancements in technology have led to widespread adoption of various new age payment technologies such as digital wallets, netbanking, transaction cards, or the like. These payment technologies have enabled users to perform quick and secure cashless transactions using their user devices, such as mobile phones, smartphones, tablets, or the like.
A significant number of these payment technologies (e.g., digital wallet accounts, netbanking, or third-party payment solutions) typically require a user device of a user to possess network connectivity (e.g., cellular or Internet connectivity) at a time of initiating or performing a transaction. However, various regions of the world still have limited or no network connectivity, and in the absence of network connectivity, the user may be unable to transact with these payment technologies. Thus, the lack of Internet or strong cellular network on the user device may force the user to eschew these payment technologies, and instead, use cash to transact, undesirably leading to an increase in the number of cash transactions.
In light of the foregoing, there is a need for a technical solution that solves the abovementioned problems and enables users to use cashless modes of payment to transact offline.

SUMMARY

In an embodiment of the present disclosure, a method for facilitating offline transactions is provided. The method includes receiving, by a server, from a user device of a user, a first request for generating a first offline code. The first request is indicative of a first payment account of the user and a first amount from the first payment account that is to be linked to the first offline code. Based on the received first request, the first offline code having the first amount linked thereto and a first authorization parameter for authorizing the first offline code are generated by the server. The first offline code and the first authorization parameter are communicated by the server to the user device. The first offline code is accessible by the user on the user device when the user device lacks network connectivity. A transaction request indicative of a transaction amount of an offline transaction, the first offline code, and the first authorization parameter is received by the server from a merchant device of a merchant. The first offline code is provided to the merchant device through the user device and the first authorization parameter is provided to the merchant device by the user for authorizing the first offline code, when the user device lacks network connectivity. The transaction request is processed by the server for a transfer of the transaction amount to a second payment account of the merchant upon successful authorization of the first offline code. The transaction amount is deducted from the first amount.
In another embodiment of the present disclosure, a system for facilitating offline transactions is provided. The system includes a server configured to receive, from a user device of a user, a first request for generating a first offline code. The first request is indicative of a first payment account of the user and a first amount from the first payment account that is to be linked to the first offline code. The server generates, based on the received first request, the first offline code having the first amount linked thereto and a first authorization parameter for authorizing the first offline code. The server communicates the first offline code and the first authorization parameter to the user device. The first offline code is accessible by the user on the user device when the user device lacks network connectivity. The server receives, from a merchant device of a merchant, a transaction request indicative of a transaction amount of an offline transaction, the first offline code, and the first authorization parameter. The first offline code is provided to the merchant device through the user device and the first authorization parameter is provided to the merchant device by the user for authorizing the first offline code, when the user device lacks network connectivity. The server processes the transaction request for a transfer of the transaction amount to a second payment account of the merchant upon successful authorization of the first offline code. The transaction amount is deducted from the first amount.

BRIEF DESCRIPTION OF DRAWINGS

Various embodiments of the present disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements, and in which:
FIG. 1 is a block diagram that illustrates an exemplary environment for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 2A-2C, collectively represent a process flow diagram that illustrates facilitation of offline transactions by an application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 3A and 3B, collectively represent another process flow diagram that illustrates facilitation of offline transactions by the application server, in accordance with another exemplary embodiment of the present disclosure;
FIG. 4 represents a process flow diagram that illustrates generation of a new offline code by the application server, in accordance with an exemplary embodiment of the present disclosure;
FIG. 5 represents a process flow diagram that illustrates crediting or reverting an amount to a payment account of a user of FIG. 1 by the application server, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 6A and 6B, collectively represent an exemplary scenario that illustrates user interface screens rendered on a user device of FIG. 1 for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 7 is a block diagram that illustrates the application server, in accordance with an exemplary embodiment of the present disclosure;
FIG. 8 is a block diagram that illustrates a system architecture of a computer system, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 9A-9C, collectively represent a flow chart that illustrates a method for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 10 represents a flow chart that illustrates a method for generating a new offline code, in accordance with an exemplary embodiment of the present disclosure;
FIG. 11 represents a flow chart that illustrates a method for crediting or reverting an amount to a payment account of the user, in accordance with an exemplary embodiment of the present disclosure; and
FIG. 12 represents a high-level flow chart that illustrates a method for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments is intended for illustration purposes only and is, therefore, not intended to necessarily limit the scope of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The present disclosure is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
References to “an embodiment”, “another embodiment”, “yet another embodiment”, “one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
Many users are unable to use new-age payment technologies (e.g., netbanking or digital wallet accounts) owing to limited network connectivity or a lack network connectivity on their user devices. As a consequence, these users are forced to transact using cash, undesirably leading a cumbersome transaction experience.
Various embodiments of the present disclosure provide a method and a system that solve the abovementioned problem by using digital or offline codes for facilitating offline transactions. The system of the present disclosure includes a server that may receive, from a user device of a user, a request for generating a first offline code. The request may be indicative of a first payment account of the user and a first amount from the first payment account that is to be linked to the first offline code. The server may generate, based on the received request, the first offline code (e.g., a bar code or a quick response code) having the first amount linked thereto and a first authorization parameter for authorizing the first offline code. To ensure data security to the user, the first offline code may be in a tokenized format. The server may communicate, to the user device, the first offline code and the first authorization parameter. The first offline code and the first authorization parameter may be accessible by the user on the user device even when the user device lacks network connectivity. In a similar manner, multiple such offline codes having different amounts may be generated by the server on user’s requests. For initiating a transaction when the user device lacks network connectivity, the user may provide the first offline code and the authorization parameter to a merchant device of the merchant. The server may receive, from the merchant device, a transaction request indicative of a transaction amount of the transaction, the first offline code, and the authorization parameter. The server processes the received transaction request for a transfer of the transaction amount to a second payment account of the merchant, based on a successful authorization of the first offline code. The transaction amount is deducted from the first amount. After successful processing of the transaction, an amount equal to a difference between the transaction amount and the first amount may be reverted to the first payment account or linked to a new offline code based on another request of the user. Thus, the method and system of the present disclosure facilitates easy and quick cashless transactions, in spite of the user device lacking network connectivity.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
Offline transaction is a digital transaction initiated or performed by a user when a user device of the user lacks network connectivity to a communication network such as a cellular network or the Internet.
Offline code is a digital code that is linked to (or encoded with) an amount of money for a purpose of performing an offline transaction. Examples of the offline code include, but are not limited to, a barcode or a quick response code, or the like. The offline code is accessible on a user device of a user in spite of the user device lacking network connectivity to a communication network. The user may provide the offline code by way of the user device to a merchant device of a merchant for performing the offline transaction, provided that a transaction amount of the transaction is less than or equal to the linked amount of money. For example, the merchant device scans the offline code presented on a display of the user device.
Authorization parameter is a passcode that is uniquely associated with an offline code for authorization or validation of the offline code. Examples of the authorization parameter include, but are not limited to, a numeric code, an alphanumeric code, or the like. When a user wants to use the offline code for performing an offline transaction at a merchant, the user is required to provide the offline code and the correct authorization parameter to a merchant device of the merchant. When the authorization parameter provided by the user matches the authorization parameter associated with the offline code, the offline code is successfully authorized and the offline transaction is processed, else the offline transaction is declined.
Merchant device is a point-of-sale device of a merchant that is configured to receive offline codes and authorization parameters from users or user devices for initiating offline transactions. For example, the merchant device may be configured to scan a quick response code displayed on a smartphone of a user and receive an authorization parameter entered by the user for initiating an offline transaction. Examples of the merchant device may include a smartphone, a tablet, a phablet, a mobile phone, a laptop, a point-of-sale (POS) device, a point-of-interaction (POI) device, a point-of-purchase (POP) device, a scanner device, or the like.
First payment account refers to a payment account of a user. Examples of the first payment account includes a bank account, a savings account, a current account, a credit account, a digital wallet, or the like.
Second payment account refers to a payment account of a merchant. Examples of the second payment account includes a bank account, a savings account, a current account, a credit account, a digital wallet, or the like.
Server is a physical or cloud data processing system on which a server program runs. The server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server may be implemented in computer programs executing on programmable computers, such as personal computers, laptops, or a network of computer systems. The server may correspond to one of an acquirer server, a payment network server, or an issuer server.
FIG. 1 is a block diagram that illustrates an exemplary environment 100 for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure. The environment 100 includes a user 102, a user device 104, an application server 106, a merchant device 108, and an issuer server 110. The user device 104, the application server 106, the merchant device 108, and the issuer server 110 may communicate with each other by way of a communication network 112 or through separate communication networks established therebetween.
The user 102 may be an individual, who is associated with a first payment account maintained at a financial institution, such as an issuer operating the issuer server 110. Examples of the first payment account may include a bank account, a savings account, a current account, a credit account, a digital wallet, or the like. The user 102 may be further associated with another payment account, such as a digital wallet, that is maintained at a third-party entity.
The user device 104 may be a computing device of the user 102, such as a mobile phone, a smartphone, a tablet, a phablet, a laptop, or the like. The user device 104 may be configured to run or execute various web or mobile applications such as a service application 114 hosted by the application server 106. The user device 104 may be utilized by the user 102 to access the service application 114 for requesting generation of offline codes and receiving the offline codes. The user device 104 may also be used by the user 102 for providing one or more of the received offline codes to the merchant device 108 for performing offline transactions. For the sake of brevity, the terms “offline transaction” and “transaction” have been used interchangeably throughout the disclosure.
The application server 106 may be a computing server, which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for facilitating offline transactions. The application server 106 may be operated by various entities such as, but not limited to, the issuer, an acquirer, a payment network (e.g., Mastercard®), a third-party non-banking institution that provides open banking services, or the like. The application server 106 may be configured to host the service application 114 that is executable on various devices, such as the user device 104 and the merchant device 108. The application server 106 offers an offline transaction service by way of the service application 114. The offline transaction service provides the user 102 a means to perform digital transactions from the first payment account or other payment accounts even when the user device 104 lacks network connectivity. Various operations performed by the application server 106 for enabling the user 102 to perform offline transactions are described in detail in FIGS. 2A-2C, 3A-3B, and 4.
The merchant device 108 may be a computing device that includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for facilitating digital (or electronic) transactions at a merchant. The merchant is an entity that offers one or more products or services for sale and associated with a second payment account maintained at a financial institution (such as an acquirer). The financial institution maintaining the second payment account of the merchant may be same or different from the financial institution that maintains the first payment account of the user 102. For the sake of brevity, it is assumed that both the first payment account of the user 102 and the second payment account of the merchant are maintained at the same the financial institution, i.e., the issuer. The merchant device 108 may include an image capturing device or a scanning device therein for scanning one or more offline codes displayed on user devices, such as the user device 104. The merchant device 108 may be further configured to execute a merchant-specific version of the service application 114. In some embodiments, the merchant device 108 may further serve as a merchant server of the merchant that stores, in a corresponding memory, details of transactions (e.g., sale of a product or a service) performed at the merchant. Examples of the merchant device 108 may include, but are not limited to, be a smartphone, a tablet, a phablet, a point-of-sale (POS) device, a point-of-interaction (POI) device, a point-of-purchase (POP) device, a scanner device, or the like.
The issuer server 110 may be operated by the issuer that maintains the first payment account of the user 102 and the second payment account of the merchant. The issuer is a financial institution that manages payment accounts (e.g., digital wallet accounts or bank accounts) of multiple users (e.g., the user 102) and merchants. Details of the payment accounts established with the issuer may be stored as account profiles. Each account profile may be indicative of a transaction history of a corresponding user or merchant. For example, an account profile of the user 102 may be indicative of a transaction history of the user 102 and another account profile of the merchant may be indicative of a transaction history of the merchant. The issuer server 110 may credit and debit the payment accounts based on transactions made by the users or merchants from their corresponding payment accounts.
The communication network 112 is a medium through which content and messages are transmitted between the user device 104, the application server 106, the merchant device 108, and the issuer server 110. Examples of the communication network 112 may include, but are not limited to, a Wi-Fi network, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, and combinations thereof. Various entities in the environment 100 may connect to the communication network 112 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof.
In operation, when network connectivity is available to the user device 104 for connecting to the communication network 112, the user device 104 may be utilized by the user 102 to access the service application 114 executable on the user device 104. The user 102 may access the service application 114 and initiate a first request by way of the service application 114 for generating a first offline code. The first request may be indicative of one or more details of the first payment account and a first amount from the first payment account that is to be linked to (i.e., encoded into) the first offline code. The user device 104 may communicate the first request to the application server 106. Based on the received first request, the application server 106 may generate the first offline code that is linked to (i.e., encoded with) the first amount deducted from the first payment account.
In one embodiment, to ensure data security to the user 102, the application server 106 may tokenize the first offline code. In such embodiment, the first offline code is indicative of a first token identifier that is mapped to the first amount, the first payment account, and user information of the user 102. The mapping between the first token identifier, the first amount, the first payment account, and the user information may be stored in the form of a look-up table stored in a memory of the application server 106. The application server 106 may further generate a first authorization parameter for authorizing the first offline code. The application server 106 may communicate the first offline code and the first authorization parameter to the user device 104. The first offline code and the first authorization parameter may be presented to the user 102 on the user device 104 through the service application 114. The first offline code may be accessible by the user 102 on the user device 104 even when the user device 104 lacks network connectivity to the communication network 112. In a similar manner, the user 102 may request the application server 106 to generate multiple such offline codes for offline use.
The user 102 may intend to purchase one or more products and/or services from the merchant. In a non-limiting example, at a time of initiating a transaction (i.e., the purchase of the one or more products and/or services), the user device 104 may lack network connectivity to the communication network 112. In such a scenario, the user 102 may provide the first offline code to the merchant device 108. For example, the user 102 may present, to the merchant device 108, the user device 104 displaying the first offline code. The merchant device 108 may then scan or capture an image of the first offline code displayed on the user device 104. In the interest of security, the user 102 may be required to further provide the first authorization parameter to the merchant device 108 to authorize the first offline code. Consequently, the merchant device 108 may communicate a transaction request to the application server 106. The transaction request may be indicative of the first offline code, the first authorization parameter, a transaction amount of the transaction, and details pertaining to the second payment account of the merchant. In some embodiments, the merchant device 108 may be configured to execute the merchant-specific version of the service application 114 for scanning the displayed first offline code, receiving the first authorization parameter, and communicating the transaction request.
The application server 106 may process the transaction request. For example, the application server 106 may compare the first offline code and the first authorization parameter indicated by the transaction request with the first offline code and the first authorization parameter communicated to the user device 104 by the application server 106, respectively. Based on a match, the application server 106 may process the transaction request for facilitating deduction of the transaction amount from the first amount linked to the first offline code and a transfer of the deducted transaction amount to the second payment account of the merchant.
FIGS. 2A-2C, collectively represent a process flow diagram 200 that illustrates facilitation of offline transactions by the application server 106, in accordance with an exemplary embodiment of the present disclosure. Specifically, the process flow diagram 200 represents a scenario where the application server 106 is an open-banking service platform that offers open-banking services to users and merchants by means of an application interface (API), e.g., the service application 114. The process flow diagram 200 involves the user device 104, the application server 106, the merchant device 108, and the issuer server 110. FIGS. 2A-2C are explained in conjunction with FIG. 1.
With reference to FIG. 2A, the user 102 may access (e.g., log-in or sign-up) the service application 114 being executed on the user device 104 (as shown by arrow 202). The service application 114 may be a mobile application or a web application accessible by way of a browser installed on the user device 104. The service application 114 may render a user interface (UI) on a display of the user device 104. By way of the UI, the user 102 may initiate the first request for generating the first offline code (as shown by arrow 204). The user 102 may initiate the first request by entering, in the service application 114, the first amount (e.g., ‘$25’) that is to be linked to (i.e., encoded into) the first offline code and an identifier(s) of the first payment account from which the first amount is to be linked to the first offline code. Examples of the identifier may include an account number of the first payment account, a transaction card number linked to the first payment account, a contact number linked to the first payment account, and/or the like. In one embodiment, the user 102 may have previously added the first payment account or a transaction card linked to the first payment account to the service application 114. In such a scenario, the user 102 may be required to enter the first amount and select the previously added payment account for initiating the first request. The first amount may be less than or equal to a balance of the first payment account. The user device 104 may communicate the first request to the application server 106 (as shown by arrow 206).
Based on the received first request, the application server 106 may identify the issuer that maintains the first payment account of the user 102. Consequently, the application server 106 may communicate a first blocking request to the issuer server 110 for blocking the first amount from the first payment account (as shown by arrow 208). Based on the first blocking request, the issuer server 110 may compare the first amount with the balance of the first payment account. If the first amount exceeds the balance of the first payment account, the issuer server 110 may communicate an error notification to the application server 106, indicating an insufficient balance in the first payment account. However, in the current embodiment, it is assumed that the first amount is less than or equal to the balance of the first payment account. In such a scenario, the issuer server 110 may block the first amount from the first payment account of the user 102 (as shown by arrow 210). Once blocked, the first amount may not be accessible by the user 102. Following the blocking of the first amount, the issuer server 110 may communicate a first blocking response to the application server 106 (as shown by arrow 212). The first blocking response may be indicative of a successful blocking of the first amount from the first payment account. In another embodiment, the blocked first amount may be further deducted from the first payment account and transferred, by the issuer, to a temporary account associated with the application server 106.
Based on the first blocking response, the application server 106 may generate the first offline code and the first authorization parameter for authorizing the first offline code (as shown by arrow 214). The generated first offline code may be a data matrix code (e.g., a barcode, a quick response code), a pictorial code, or the like. In a non-limiting example, it is assumed that the generated first offline code is a quick response (QR) code. The first authorization parameter may be a numeric or alphanumeric code. In the interest of preserving data security, the first offline code may be in a tokenized format. In other words, the generated first offline code may be indicative of a first token identifier that is mapped to the first amount, the first payment account, the user information (e.g., a name of the user 102), or the like. The mapping between the first token identifier, the first amount, the first payment account, and the user information may be stored in the look-up table in the memory of the application server 106. The application server 106 may communicate the first offline code and the first authorization parameter to the user device 104 (as shown by arrow 216). The service application 114 may present the first offline code and the first authorization parameter to the user 102 on a display of the user device 104 (as shown by arrow 218). The first offline code may be accessible, on the user device 104, by the user 102 even when the user device 104 lacks network connectivity to the communication network 112. For example, the service application 114 may have an offline mode of operation which is activated when the user device 104 lacks network connectivity to the communication network 112. When operating in the offline mode, the service application 114 may allow access to the first offline code received from the application server 106.
In a similar manner, the application server 106 may generate multiple offline codes (e.g., a set of offline codes) for the user 102, in addition to the first offline code. Each of the set of offline codes may be linked to a corresponding amount based on a corresponding request received from the user device 104. Each of the set of offline codes may be presented to the user 102 on the user device 104 and accessible by the user 102 for offline use, i.e., when the user device 104 lacks network connectivity.
Referring now to FIG. 2B, the user 102 may attempt to initiate an offline transaction (i.e., purchase one or more products and/or services from the merchant) when the user device 104 lacks network connectivity to the communication network 112. In such a scenario, the user 102 may provide the first offline code to the merchant device 108 for initiating the offline transaction. The user 102 may provide the first offline code to the merchant device 108 through the user device 104. The merchant device 108, executing the merchant-specific version of the service application 114, may scan the first offline code displayed by the user device 104 (as shown by arrow 220). Consequently, the merchant device 108 may prompt the user 102 to provide the first authorization parameter to authorize or validate the first offline code. Based on prompting, the user 102 may provide the first authorization parameter to the merchant device 108 (as shown by arrow 222).
The merchant-specific version of the service application 114 being executed by the merchant device 108 may act as a gateway to the application server 106. Thus, the merchant device 108 may communicate, to the application server 106, a transaction request (as shown by arrow 224) for the transaction initiated by the user 102. The transaction request may be indicative of the scanned first offline code (i.e., the first token identifier), the first authorization parameter, and one or more transaction details of the offline transaction. The one or more transaction details may include, but are not limited to, a transaction amount of the offline transaction, a time of the offline transaction, an identifier of the second payment account of the merchant, or the like.
On reception of the transaction request, the application server 106 may process the transaction request (as shown by arrow 226). For processing the transaction request, the application server 106 may determine whether the first offline code and the first authorization parameter indicated by the transaction request match the first offline code and the first authorization parameter communicated by the application server 106 to the user device 104. When the first offline code and the first authorization parameter indicated by the transaction request match the first offline code and the first authorization parameter communicated to the user device 104, the first offline code is successfully authorized or validated by the application server 106.
Upon successful authorization of the first offline code, the application server 106 may detokenize the first offline code. For example, the application server 106 may search in the look-up table stored in the corresponding memory to identify the information mapped to the first token identifier. In other words, the application server 106 may identify the first amount linked to the first offline code, the first payment account, and the user information of the user 102 mapped to the first token identifier. The application server 106 may then compare the transaction amount of the transaction and the first amount linked to the first offline code (as shown by arrow 228). If the transaction amount exceeds the first amount, the application server 106 may communicate a transaction failure notification to the merchant device 108. In a non-limiting example, it is assumed that the transaction amount is less than or equal to the first amount. The application server 106 may then identify, based on the transaction request, the entities (here, the issuer) corresponding to the transaction request (as shown by arrow 230).
Referring now to FIG. 2C, the application server 106 may communicate, to the issuer server 110, a second request for transferring the transaction amount to the second payment account of the merchant (as shown by arrow 232). The second request may be indicative of the transaction details. Based on the second request, the issuer server 110 may deduct the transaction amount from the first amount, and transfer the transaction amount to the second payment account of the merchant (as shown by arrows 234 and 236). Therefore, the application server 106 processes the transaction request for the transfer of the transaction amount to the second payment account of the merchant upon successful authorization of the first offline code. Following the transfer of the transaction amount, the issuer server 110 may communicate a first notification, indicative of the transfer of the first amount to the second payment account of the merchant, to the merchant device 108 and the application server 106 (as shown by arrows 238 and 240). The offline transaction initiated, by the user 102, is now complete.
In a non-limiting example, each offline code may be one-time usable, i.e., valid for a single transaction. Thus, on receiving the transaction request, the application server 106 may determine whether the first offline code (i.e., token identifier) indicated by the transaction request has already been used for a previous transaction. If the application server 106 determines that the first offline code has already been used, the application server 106 may communicate the transaction failure notification to the merchant device 108.
In another embodiment, the user 102 may use a combination of multiple offline codes for performing a single transaction. For example, if the amount linked to a single offline code is less than the transaction amount, the user 102 may use a combination of two or more offline codes to perform the transaction.
In some scenarios, the first amount may be greater than the transaction amount. In some embodiments, after performing the offline transaction, the user 102 may choose to link a remainder of the first amount to another offline code. The user 102 may initiate, by way of the service application 114, a request for generation of a new offline code that is to be linked to a second amount equal to a difference between the first amount and the transaction amount (as shown in FIG. 4). In other embodiments, the user 102 may initiate a request for a roll-back or a credit of the second amount to the first payment account (as shown in FIG. 5).
Although in the process flow diagram 200 the first offline code is used for performing a transaction between a merchant and a user, the scope of the disclosure is not limited to it. The first offline code may be further used for performing a peer-to-peer transaction. For example, the first offline code may be further utilized to transfer the first amount to a payment account of another user in a similar manner as described in the foregoing description of FIGS. 2A-2C.
FIGS. 3A and 3B, collectively represent a process flow diagram 300 that illustrates facilitation of offline transactions by the application server 106, in accordance with another exemplary embodiment of the present disclosure. Specifically, the process flow diagram 300 illustrates a scenario where the application server 106 is one of a third-party digital wallet service platform or a digital wallet service platform of the issuer. In this scenario, the application server 106 maintains another payment account of the user 102, e.g., a first digital wallet of the user 102, and another payment account of the merchant, e.g., a second digital wallet of the merchant. The process flow diagram 300 involves the user device 104, the application server 106, and the merchant device 108.
With reference to FIG. 3A, the user 102 may access the service application 114 being executed on the user device 104 (as shown by arrow 302). The service application 114 may render the UI on the display of the user device 104. By way of the UI, the user 102 may initiate a first request for generating the first offline code (as shown by arrow 304). The user 102 may initiate the first request by entering, in the service application 114, the first amount (e.g., ‘$25’) that is to be linked to (i.e., encoded into) the first offline code from the first digital wallet. The first amount may be less than or equal to the balance of the first digital wallet. Loading of a digital wallet with an amount is a known practice and will be known to those of ordinary skill in the art. For example, the first digital wallet may be loaded by way of the first payment account maintained at the issuer or the transaction card linked to the first payment account.
The user device 104 may communicate the first request to the application server 106 (as shown by arrow 306). Based on the received first request, the application server 106 may compare the first amount with the balance of the first digital wallet. If the first amount exceeds the balance of the first digital wallet, the application server 106 may communicate an error notification to the user device 104, indicating an insufficient balance in the first digital wallet. However, in the current embodiment, it is assumed that the first amount is less than or equal to the balance of the first digital wallet. In such a scenario, the application server 106 may block the first amount from the first digital wallet (as shown by arrow 308). The blocked amount is rendered unavailable to the user 102.
Following the blocking of the first amount, the application server 106 may generate the first offline code and the first authorization parameter for authorizing the first offline code (as shown by arrow 310). The first offline code may be in the tokenized format. In other words, the generated first offline code may be indicative of the first token identifier that is mapped to the first amount, the first digital wallet, and the user information of the user 102. The mapping between the first token identifier, the first amount, the first digital wallet, and the user information may be stored in the look-up table in the memory of the application server 106. The application server 106 may communicate the first offline code and the first authorization parameter to the user device 104 (as shown by arrow 312). The service application 114 may present the first offline code and the first authorization parameter to the user 102 on the display of the user device 104 (as shown by arrow 314). The first offline code may be accessible, on the user device 104, by the user 102 even when the user device 104 lacks network connectivity to the communication network 112.
Referring now to FIG. 3B, the user 102 may attempt to initiate an offline transaction (i.e., purchase one or more products and/or services from the merchant) when the user device 104 lacks network connectivity to the communication network 112. In such a scenario, the user 102 may provide the first offline code to the merchant for initiating the offline transaction. The user 102 may provide the first offline code to the merchant device 108 through the user device 104. The merchant device 108, executing the merchant-specific version of the service application 114, may scan the first offline code displayed by the user device 104 (as shown by arrow 316) and prompt the user 102 to provide the first authorization parameter to authorize or validate the first offline code. The user 102 may provide the first authorization parameter to the merchant device 108 (as shown by arrow 318).
The merchant device 108 may then communicate, to the application server 106, a transaction request (as shown by arrow 320) for the transaction. The transaction request may be indicative of the first offline code (i.e., the first token identifier), the first authorization parameter, and one or more transaction details of the offline transaction. The one or more transaction details may include, but are not limited to, a transaction amount of the offline transaction, a time of the offline transaction, an identifier of the second digital wallet of the merchant, or the like. On reception of the transaction request, the application server 106 may process the transaction request (as shown by arrow 322). For processing the transaction request, the application server 106 may determine whether the first offline code and the first authorization parameter indicated by the transaction request match the first offline code and the first authorization parameter communicated to the user device 104. When the first offline code and the first authorization parameter indicated by the transaction request match the first offline code and the first authorization parameter communicated to the user device 104, the first offline code is successfully authorized by the application server 106.
Upon successful authorization of the first offline code, the application server 106 may detokenize the first offline code. For example, the application server 106 may search in the look-up table stored in the corresponding memory to identify the information mapped to the first token identifier. In other words, the application server 106 may identify the first amount linked to the first offline code, the first payment account, and the user information of the user 102 mapped to the first token identifier. The application server 106 may compare the first amount and the transaction amount (as shown by arrow 324). If the transaction amount exceeds the first amount, the application server 106 may communicate a transaction failure notification to the merchant device 108.
In a non-limiting example, it is assumed that the transaction amount is less than or equal to the first amount. Consequently, the application server 106 may deduct the transaction amount from the first amount and transfer the transaction amount to the second digital wallet of the merchant (as shown by arrows 326 and 328). Therefore, the application server 106 processes the transaction request for the transfer of the transaction amount to a merchant payment account (i.e., the second digital wallet) upon successful authorization of the first offline code. Following the transfer of the transaction amount, the application server 106 may communicate the first notification, indicative of the transfer of the first amount to the second digital wallet, to the merchant device 108. The offline transaction initiated, by the user 102, is now complete.
FIG. 4 represents a process flow diagram 400 that illustrates generation of a new offline code by the application server 106, in accordance with an exemplary embodiment of the present disclosure. The process flow diagram 400 involves the user device 104 and the application server 106. The user 102 may have used the first offline code for performing an offline transaction (as described in conjunction with FIGS. 2A-2C and 3A-3B) for an amount less than the first amount and since the first offline code is one-time usable, the user 102 may want to link the remainder of the first amount (i.e., the second amount) to a new offline code.
With reference to FIG. 4, the user 102 may initiate, by way of the service application 114, a third request for generating a new offline code that is linked to the second amount remaining after the use of the first offline code (as shown by arrow 402). The third request may be initiated at a time instance after the processing of the transaction request, when network connectivity is available to the user device 104. The user device 104 may communicate the third request to the application server 106 (as shown by arrow 404). Based on the received third request, the application server 106 may generate a second offline code having the second amount linked thereto and a second authorization parameter for authorizing the second offline code (as shown by arrow 406). The second offline code may be in a tokenized format. The application server 106 may communicate the second offline code and the second authorization parameter to the user device 104 (as shown by arrow 408). The service application 114 may present the second offline code and the second authorization parameter to the user 102 on the display of the user device 104 (as shown by arrow 410).
FIG. 5 represents a process flow diagram 500 that illustrates crediting or reverting the second amount to a payment account of the user 102 by the application server 106, in accordance with an exemplary embodiment of the present disclosure. The process flow diagram 500 involves the user device 104, the application server 106, and the issuer server 110. The user 102 may have used the first offline code for performing an offline transaction (as described in conjunction with FIGS. 2A-2C and 3A-3B) for an amount less than the first amount and since the first offline code is one-time usable, the user 102 may want to revert the remainder of the first amount (i.e., the second amount) to the first payment account or the first digital wallet. For the sake of brevity, it is assumed that the user 102 wants to revert the second amount to the first payment account.
The user 102 may initiate, by way of the service application 114, a fourth request for crediting or reverting the second amount to the first payment account (as shown by arrow 502). The fourth request may be initiated at a time instance after the processing of the transaction request, when network connectivity is available to the user device 104. The user device 104 may communicate the fourth request to the application server 106 (as shown by arrow 504). Based on the fourth request, the application server 106 may communicate a credit request to the issuer server 110 for crediting the second amount to the first payment account of the user 102 (as shown by arrow 506). Based on the credit request, the issuer server 110 may release the remainder of the blocked first amount (i.e., the second amount) or credit the second amount to the first payment account (as shown by arrow 508). Consequently, the issuer server 110 may communicate a credit response to the application server 106, indicating the release or credit of the second amount (as shown by arrow 510). Consequently, the application server 106 may communicate a credit notification to the user device 104, indicating the release or credit of the second amount (as shown by arrow 512).
In another embodiment, where the first digital wallet is maintained by the application server 106, the application server 106 may release the block on the second amount or credit the second amount to the first digital wallet.
FIGS. 6A and 6B, collectively represent an exemplary scenario 600 that illustrates UI screens 602-612 rendered on the user device 104 for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure. FIGS. 6A and 6B are explained in conjunction with FIGS. 2A-2C. The UI screens 602-612 are displayed on the display of the user device 104 by the service application 114.
When the user 102 accesses the service application 114, the service application 114 may render the UI screen 602. The UI screen 602 may request the user 102 to enter a username and a password to log into the service application 114. The user 102 may enter the username and the password in first and second text boxes 614a and 614b, respectively. After entering the username and the password, the user 102 may select a first submit button 616 for logging into the service application 114. The user device 104 may communicate an authentication request to the application server 106 for authentication of the user 102. The authentication request may include the entered username and password. The application server 106 may authenticate the user 102 and communicate an authentication response to the user device 104. When the authentication response indicates successful authentication of the user 102, control is redirected to the UI screen 604.
The UI screen 604 may present first through third user-selectable options 618, 620, and 622 to the user 102 for selection. The first user-selectable option 618 may allow the user 102 to request for generation of a new offline code. The second user-selectable option 620 may allow the user 102 to view the previously generated offline codes and the corresponding authentication parameters. The third user-selectable option 622 may allow the user 102 to view the previously generated offline codes for initiating an offline transaction. The user 102 may select the first user-selectable option 618 for requesting the generation of the first offline code. Control is redirected to UI screen 606. The UI screen 606 may present a message, requesting the user 102 to enter an amount that is to be linked to the first offline code. The UI screen 606 may present a third text box 624 for entering the first amount that is to be linked to the first offline code from the first digital wallet or the first payment account. After entering the first amount (here, ‘$25’), the user 102 may select a second submit button 626.
Based on the selection of the second submit button 626, the user device 104 may communicate the first request to the application server 106. Consequently, the application server 106 may generate and communicate the first offline code and the first authorization parameter to the user device 104. Control is the redirected to UI screen 608. The UI screen 608 may present the first offline code (hereinafter, referred to as “the first offline code 628”) and the first authorization parameter (here, “3a76”).
When the user 102 intends to initiate the offline transaction, the user 102 may select the third user-selectable option 622 presented on the UI screen 604. The UI screen 604 and the second and third user-selectable option 620 and 622 may be available to the user 102 even when the user device 104 lacks network connectivity. Control is then redirected to UI screen 610. The UI screen 610 presents the first offline code 628 and another previously generated offline code. The user 102 may select the first offline code 628 for initiating the transaction and the control is then redirected to the UI screen 612. The UI screen 612 displays the selected first offline code 628 for the merchant device 108 to scan and initiate the offline transaction. Upon scanning the first offline code 628, the merchant device 108 prompts the user 102 to provide the first authorization parameter for authorizing the first offline code 628.
FIG. 7 is a block diagram that illustrates the application server 106, in accordance with an exemplary embodiment of the present disclosure. The application server 106 may include processing circuitry 702, the memory (hereinafter, referred to as ‘the memory 704’), and a transceiver 706. The processing circuitry 702, the memory 704, and the transceiver 706 may communicate with each other by way of a communication bus 708. The processing circuitry 702 may include an application host 710, a tokenization engine 712, and a transaction engine 714.
The processing circuitry 702 may include suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, to facilitate offline transactions. The processing circuitry 702 may be configured to receive requests for generation of offline codes, generate offline codes and authorization parameters, and process offline transactions. Examples of the processing circuitry 702 may include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a field programmable gate array (FPGA), and the like. The processing circuitry 702 may execute various operations for facilitating offline transactions by way of the application host 710, the tokenization engine 712, and the transaction engine 714.
The memory 704 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to store information required for performing offline transactions such as generated offline codes and corresponding authorization parameters, token identifiers, or the like. The memory 704 may further store the look-up table (hereinafter, referred to as ‘the look-up table 716’). The look-up table 716 may be a database that stores mapping between a token identifier of an offline code and information (such as encoded amount, user information, or the like) linked to the offline code. Examples of the memory 704 may include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), a flash memory, a solid-state memory, and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 704 in the application server 106, as described herein. In another embodiment, the memory 704 may be realized in form of a database server or a cloud storage working in conjunction with the application server 106, without departing from the scope of the disclosure.
The application host 710 may host the service application 114 that facilitates the offline transactions. The application host 710 may receive, from the user device 104, requests (e.g., the first request and the third request) for generation of offline codes (e.g., the first and second offline codes). The application host 710 may communicate, to the user device 104, generated offline codes and corresponding authorization parameters (e.g., the first offline code 628 and the first authorization parameter ‘3a76’). The application host 710 may further receive, from the user device 104 by way of the service application 114, requests (e.g., the fourth request) for crediting remainder money (e.g., the second amount) to the first digital wallet or the first payment account.
The tokenization engine 712 may generate offline codes and authorization parameters, based on received requests. The generated offline codes (e.g., the first offline code 628) are in a tokenized format. In other words, each offline code may indicative of a unique token identifier that is mapped to sensitive information such as an amount linked to the corresponding offline code, an identifier associated with a corresponding payment account (e.g., first digital wallet), or the like. The sensitive information may be encrypted and stored in the look-up table 716. The tokenization engine 712 may communicate generated offline codes and authorization parameters to corresponding user devices (e.g., the user device 104).
The transaction engine 714 may process received transaction requests and facilitate deductions and transfers of corresponding transaction amounts to corresponding merchant payment accounts.
The transceiver 706 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to transmit and receive data over the communication network 112 using one or more communication network protocols. The transceiver 706 may transmit requests and messages to and receive requests and messages from the user device 104, the merchant device 108, and the issuer server 110. Examples of the transceiver 706 may include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, a universal serial bus (USB) port, or any other device configured to transmit and receive data.
FIG. 8 is a block diagram that illustrates a system architecture of a computer system 800, in accordance with an exemplary embodiment of the present disclosure. An embodiment of disclosure, or portions thereof, may be implemented as computer readable code on the computer system 800. In one example, the user device 104, the application server 106, the merchant device 108, and the issuer server 110 may be implemented as the computer system 800.
Hardware, software, or any combination thereof may embody modules and components used to implement methods of FIGS. 9A-9C and FIGS. 10-12. The computer system 800 includes a processor 802 that may be a special-purpose or a general-purpose processing device. The processor 802 may be a single processor, multiple processors, or combinations thereof. Further, the processor 802 may be connected to a communication infrastructure 804, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 800 may further include a main memory 806 and a secondary memory 808. Examples of the main memory 806 may include a RAM, a ROM, and the like. The secondary memory 808 may include an HDD or a removable storage drive, such as a floppy disk drive, a magnetic tape drive, a compact disc, an optical disk drive, a flash memory, and the like.
The computer system 800 further includes an input/output (I/O) interface 810 and a communication interface 812. The I/O interface 810 includes various input and output devices that are configured to communicate with the processor 802. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 812 may be configured to allow data to be transferred between the computer system 800 and various devices that are communicatively coupled to the computer system 800. Examples of the communication interface 812 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 812 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art.
FIGS. 9A-9C, collectively represent a flow chart 900 that illustrates a method for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure.
With reference to FIG. 9A, at step 902, the application server 106 receives the first request for generation of the first offline code 628. The process proceeds to step 904. At step 904, based on the first request, the application server 106 facilitates the blocking of the first amount from the first payment account or the first digital wallet (as described in the foregoing descriptions of FIGS. 2A and 3A). The process proceeds to step 906. At step 906, the application server 106 generates the first offline code 628 and the first authorization parameter. The first offline code 628 may be in the tokenized format. The application server 106 stores, in the look-up table 716, the mapping between the first token identifier and the information linked to the first offline code 628. The linked information may include, but is not limited to, the first amount, the identifier of the first digital wallet or the first payment account, the name of the user 102, or the like. The process proceeds to step 908. At step 908, the application server 106 communicates the first offline code 628 and the first authorization parameter to the user device 104. The service application 114 may present the first offline code 628 and the first authorization parameter on the UI screen 608. The first offline code 628 and the first authorization parameter may be accessible by the user 102 on the user device 104 even when the user device 104 lacks network connectivity to the communication network 112. The process proceeds to step 910.
With reference to FIG. 9B, at step 910, the application server 106 receives the transaction request from the merchant device 108 (as described in the foregoing description of FIG. 2B). The process proceeds to step 912. At step 912, the application server 106 determines whether the first offline code 628 and the first authorization parameter included in the transaction request match the first offline code 628 and the first authorization parameter communicated by the application server 106 to the user device 104. If at step 912, the application server 106 determines that there is no match, step 914 is performed. At step 914, the application server 106 communicates a transaction failure notification to the merchant device 108, indicating a mismatch between the first offline code 628 and the first authorization parameter. If at step 912, the application server 106 determines that there is a match and the first offline code 628 is successfully authorized, step 916 is performed. At step 916, the application server 106 processes the transaction request. The process proceeds to step 918.
With reference to FIG. 9C, at step 918, the application server 106 compares the transaction amount of the transaction with the first amount linked to the first offline code 628. The process proceeds to step 920. At step 920, the application server 106 determines whether the transaction amount of the transaction is less than or equal to the first amount linked to the first offline code 628. If at step 920, the application server 106 determines that the transaction amount of the transaction is greater than the first amount, step 922 is performed. At step 922, the application server 106 communicates a notification to the merchant device 108, indicating that transaction has failed. If at step 920, the application server 106 determines that the transaction amount of the transaction is less than or equal to the first amount, step 924 is performed. At step 924, the application server 106 facilitates the deduction and transfer of the transaction amount to the second payment account or the second digital wallet of the merchant (as described in foregoing FIGS. 2C and 3B). For example, in explained the foregoing description of FIG. 2C, the application server 106 communicates the second request to the issuer server 110 for the deduction and transfer of the transaction amount to the second payment account of the merchant. Based on the second request, the issuer server 110 may deduct the transaction amount from the first amount and transfer the transaction amount to the second payment account of the merchant. In FIG. 3B, the application server 106 deducts the transaction amount from the first digital wallet and transfers the transaction amount to the second digital wallet of the merchant.
FIG. 10 represents a flow chart 1000 that illustrates a method for generating a new offline code, in accordance with an exemplary embodiment of the present disclosure.
The user 102 initiates, by way of the service application 114, the third request for generating a new offline code that is linked to the second amount remaining after the use of the previously generated first offline code. The third request may be initiated at a time instance after the processing of the transaction request, when network connectivity is available to the user device 104. The user device 104 communicates the third request to the application server 106. At step 1002, the application server 106 receives the third request. The process proceeds to step 1004. At step 1004, the application server 106 generates the second offline code having the second amount linked thereto and a second authorization parameter for authorizing the second offline code. The process proceeds to step 1006. At step 1006, the application server 106 communicates the second offline code and the second authorization parameter to the user device 104. The service application 114 presents the second offline code and the second authorization parameter to the user 102 on the display of the user device 104.
FIG. 11 represents a flow chart 1100 that illustrates a method for crediting or reverting the second amount to a payment account of the user 102, in accordance with an exemplary embodiment of the present disclosure.
The user 102 initiates, by way of the service application 114, the fourth request for crediting or reverting the second amount remaining after the use of the first offline code to the first payment account or the first digital wallet. The fourth request may be initiated at a time instance after the processing of the transaction request, when network connectivity is available to the user device 104. The user device 104 communicates the fourth request to the application server 106. At step 1102, the application server 106 receives the fourth request. The process proceeds to step 1104. At step 1104, the application server 106 facilitates the release of the second amount or the credit of the second amount to the first payment account or the first digital wallet (as described in the foregoing description of FIG. 4). The process proceeds to step 1106. At step 1106, the application server 106 communicates the credit notification to the user device 104, indicating the release or credit of the second amount.
FIG. 12 represents a high-level flow chart 1200 that illustrates a method for facilitating offline transactions, in accordance with an exemplary embodiment of the present disclosure. At step 1202, the application server 106 receives the first request from the user device 104 of the user 102. The first request is indicative of a payment account (e.g., the first payment account or the first digital wallet) of the user 102 and the first amount of the payment account that is to be linked to the first offline code 628. The process proceeds to step 1204. At step 1204, the application server 106 generates, based on the first request, the first offline code 628 having the first amount linked thereto and the first authorization parameter for authorizing the first offline code 628. The process proceeds to step 1206. At step 1206, the application server 106 communicates the first offline code 628 and the first authorization parameter to the user device 104. The first offline code 628 is accessible by the user 102 on the user device 104 when the user device 104 lacks network connectivity to the communication network 112. The process proceeds to step 1208. At step 1208, the application server 106 receives, from the merchant device 108, the transaction request indicative of a transaction amount of the offline transaction, the first offline code 628, and the first authorization parameter. The first offline code is provided to the merchant device 108 through the user device 104 and the authorization parameter is provided to the merchant device 108 by the user 102 for authorizing the first offline code 628, when the user device 104 lacks network connectivity to the communication network 112. The process proceeds to step 1210. At step 1210, the application server 106 processes the transaction request for a transfer of the transaction amount to a payment account (e.g., the second payment account or the second digital wallet) of the merchant upon successful authorization of the first offline code 628. The transaction amount is deducted from the first amount and transferred to the payment account of the merchant upon successful authorization of the first offline code 628.
Technological improvements in the application server 106 offers a convenient means for facilitating offline transactions. The application server 106 allows the user 102 to request for generation of any number of offline codes, enabling the user 102 to perform multiple offline transactions at the time when the user device 104 lacks network connectivity. Each offline code is tokenized and requires a corresponding authorization parameter for authorization, thereby enhancing transaction security and minimizing chances of fraud. The method of the present disclosure is compatible with all types of existing cashless transaction services, such as open banking services, digital wallet services, virtual transaction card services, netbanking services, or the like. Further, implementing the disclosure requires little to no hardware upgrades to existing payment infrastructure, thus facilitating cost-effective implementation of proposed solutions. Financial entities such as issuers, payment networks, and acquirers may achieve higher revenues as a result of users using non-cash payment modes to transact. Users, especially those that reside in areas with limited network connectivity, may experience quick and seamless transactions as a result of using non-cash payment modes to transact, in lieu of cash.
Techniques consistent with the present disclosure provide, among other features, systems and methods for facilitating offline transactions. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the disclosure, without departing from the breadth or scope.
In the claims, the words ‘comprising’, ‘including’ and ‘having’ do not exclude the presence of other elements or steps then those listed in a claim. The terms “a” or “an,” as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
While various embodiments of the present disclosure have been illustrated and described, it will be clear that the present disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present disclosure, as described in the claims.