Description:FIELD OF THE INVENTION

The present disclosure relates for executing financial transaction and more particularly, to a system and a method for executing cardless secured financial transaction.

BACKGROUND

In a conventional point-of-sale (POS) electronic financial transaction, the financial transaction is authorized and captured by means of swiping a credit/debit card in a POS machine. Similarly, for other means of electronic financial transaction also, a user may have to use the credit/debit card for concluding the financial transaction.
In an instance, usually in the authorization stage, a physical card with a magnetic stripe is swiped through a merchant's magnetic card reader, which may be, e.g., the POS machine. A payment request is sent electronically from the magnetic card reader to a card processor. The card processor routes the payment request to a card issuer, such as a Bank through a card network.
Assuming the card issuer approves the transaction, the approval is then routed back to the merchant. In the next stage, the user is required to enter a PIN/password in the POS machine to approve the financial transaction and finally the financial transaction is executed upon receiving correct PIN/password. The PIN/password is usually static and may be used by the user multiple times.
In other instance of performing financial transaction via online web, the user provides the physical card number for card processing. The merchant receives the card detail, and the card may be processed via a transaction server, e.g., a payment gateway. In the next stage, the user receives a time-bound one-time password (OTP). The OTP is generated by the card issuer for authenticating the payment. In instance, the OTP is received on cellular network of the user. The user may provide the OTP to the merchant online web portal for approving the financial transaction. Hence post receiving the OTP the financial transaction is executed.

The existing technology is prominently dependent on the card transactions and require the user to carry the physical card or at least always remember the physical card details for performing the financial transaction. Moreover, with rampant increase in financial service providers, the user may have multiple physical cards to manage. Thus, making it difficult for the user to manage multiple physical cards. Furthermore, the usage of physical card is dependent on the PIN/password, that the user is required to memorize or upon the OTP. Such techniques are known to be less secured as the user might risk forgetting or leaking the PIN/password. There might also be a risk of the cellular network being compromised and the OTP may be received by fraudsters.
Therefore, it is required to provide a technique that allows the user to execute cardless financial transactions and provides an added security for authenticating said cardless financial transactions.
.

SUMMARY

This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.

In an embodiment of the present invention, a method for executing a financial transaction is disclosed. The method includes receiving a first input indicative of selection of at least one digital card associated with a user account in an application, wherein the financial transaction is to be made from the at least one digital card. The method includes receiving a second input indicative of a transaction amount. The method includes generating, via the application, a unique token corresponding to the transaction amount and the at least one digital card, wherein the unique token is to be shared and used with a merchant. The method includes generating, upon usage of the unique token by the merchant, an approval request for executing the financial transaction. The method includes receiving a third input in response to the approval request, wherein the third input includes one of acceptance and refusal of the approval request; and executing the financial transaction based on the third input by deducting the transaction amount from the user account.

In another embodiment of the present invention, a system for executing a financial transaction is disclosed. The system includes a receiving module adapted to receive a first input indicative of selection of at least one digital card associated with a user account in an application, wherein the financial transaction is to be made from the at least one digital card. The system includes receive a second input indicative of a transaction amount, a generating module adapted to: generate via the application, a unique token corresponding to the transaction amount and the at least one digital card wherein the unique token is to be shared with a merchant. The system includes generate, upon the usage of the unique token by the merchant, an approval request for executing the financial transaction wherein the receiving module is adapted to receive a third input in response to the approval request includes one of acceptance and refusal of the approval request. The system includes an executing module adapted to execute the financial transaction based on the third input by deducting the transaction amount from the user account.

Accordingly, it is desired to create a system and a method for executing cardless secured financial transactions.

To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Figure 1 illustrates a block diagram depicting an environment of implementation of a system for executing a financial transaction, according to an embodiment of the present disclosure;
Figure 2 illustrates a block diagram of a controller of the system for executing a financial transaction, according to an embodiment of the present disclosure; and
Figure 3 illustrates a flowchart depicting a method for system for executing a financial transaction, according to an embodiment of the present disclosure.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

DETAILED DESCRIPTION OF FIGURES

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

For example, the term “some” as used herein may be understood as “none” or “one” or “more than one” or “all.” Therefore, the terms “none,” “one,” “more than one,” “more than one, but not all” or “all” would fall under the definition of “some.” It should be appreciated by a person skilled in the art that the terminology and structure employed herein is for describing, teaching, and illuminating some embodiments and their specific features and elements and therefore, should not be construed to limit, restrict, or reduce the spirit and scope of the present disclosure in any way.

For example, any terms used herein such as, “includes,” “comprises,” “has,” “consists,” and similar grammatical variants do not specify an exact limitation or restriction, and certainly do not exclude the possible addition of one or more features or elements, unless otherwise stated. Further, such terms must not be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated, for example, by using the limiting language including, but not limited to, “must comprise” or “needs to include.”

Whether or not a certain feature or element was limited to being used only once, it may still be referred to as “one or more features” or “one or more elements” or “at least one feature” or “at least one element.” Furthermore, the use of the terms “one or more” or “at least one” feature or element do not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, “there needs to be one or more...” or “one or more element is required.”

Unless otherwise defined, all terms and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by a person ordinarily skilled in the art.

Reference is made herein to some “embodiments.” It should be understood that an embodiment is an example of a possible implementation of any features and/or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and/or elements of the proposed disclosure fulfil the requirements of uniqueness, utility, and non-obviousness.

Use of the phrases and/or terms including, but not limited to, “a first embodiment,” “a further embodiment,” “an alternate embodiment,” “one embodiment,” “an embodiment,” “multiple embodiments,” “some embodiments,” “other embodiments,” “further embodiment”, “furthermore embodiment”, “additional embodiment” or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and/or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and/or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and/or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and/or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

Embodiments of the present invention will be described below in detail with reference to the accompanying drawings.

Figure 1 illustrates a block diagram depicting an environment of implementation of a system 100 for executing financial transaction, according to an embodiment of the present disclosure. For the sake of brevity, the system 100 for executing financial transaction is hereinafter interchangeably referred as the system 100.
In an embodiment, referring to Figure 1, the system 100 may be implemented between a user 102 operating a user equipment (UE) 104a, an application 104b adapted to be installed in the UE 104a of the user 102, and a merchant 112. The UE 104a may include, but is not limited to, a tablet PC, a Personal Digital Assistant (PDA), a mobile-device, a palmtop computer, a laptop computer, a desktop computer, a server, a cloud server, a remote server, a communications device, a wireless-telephone, or any other machine controllable through the wireless-network and capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
The application 104b is adapted to communicate with a financial institute 105, e.g., a bank. In an example, the user 102 may have a transaction account or an account with said financial institute 105 to perform financial transaction. In the example, the financial institute 105 may have a cloud server with capabilities to operate as a bank. Further, the user 102 communicates with the financial institute 105 via the application 104b. The user 102 may operate the application 104b to perform said financial transaction with respect to the transaction account. In an example, the application 104b may be adapted to share notifications relating to financial transaction and to receive inputs from the user 102. In the example, the application 104b may be adapted to share notifications relating to financial transaction and to receive inputs from the financial institute 105 and transmit data to the financial institute 105. The application 104b may be adapted to store a digital card. In the example, the digital card may be a version of the physical credit or debit card issued by the financial institute 105, virtually stored in the application 104b and linked to the account of the user 102.
In an embodiment, the user 102 may select the digital card in the application 104b to perform the financial transaction with respect to the account. The user 102 may enter a transaction amount to be debited from the account and to be paid to the merchant 112. In an example, a unique token may be generated via the application 104b. In the example, the application 104b may be adapted to receive a unique token from the financial institute 105 in response to receiving the transaction amount from the user 102. The application 104b may be configured to transmit to the cloud server residing at the financial institute 105 a response indicating submission of the transaction amount by the user 102 on the application 104b. As a feedback to the response form the application 104b, the cloud server at the financial institute 105 may be configured to generate the unique token and provide it to the application 104b. The application 104b may display the unique token on the screen of the UE 104a.
In another example the application 104b may be adapted to generate a unique token in response to receiving the transaction amount from the user 102, and further share the unique token generated with the financial institute 105
Further, the user 102 may provide the unique token to the merchant 112 as part of performing the financial transaction.
In an embodiment, the merchant 112 may be a person or a company involved in trade and adapted to accept financial transaction from the user 102. In an example, the merchant 112 may accept the user 102 request for executing the financial transaction via the POS machine such as the supermarket, the online web service such as the ecommerce websites. In an another example, an automated teller machine (ATM) or cash machine may also be the merchant 112.
In an embodiment, the merchant 112 may be configured to accept the unique token from the user 102. Upon receiving the unique token, the merchant 112 may use the unique token by entering the same in the one or more of the POS machine, the website, the ATM machine, thus a validation request may be sent from the one or more of the POS machine, the website, the ATM machine of the merchant 112 to the financial institute 105. In an example, the validation request may indicate matching of the unique token by the financial institute 105 to establish the unique token is authenticated. Upon using the unique token by the merchant 112, the application 104b may be adapted to display an approval request to the user 102 for approving the financial transaction. In the example, the user 102 approves the approval request for executing the financial transaction. Thus, the transaction amount is deducted from the user’s 102 account. In an another example, the user 102 may refuse the approval request for executing the financial transaction. Thus, the transaction amount may not be deducted from the user’s 102 account.

In an embodiment, the system 100 may include a controller 200 in communication with the UE 104a and the application 104b. Figure 2 illustrates a block diagram of the controller 200, according to an embodiment of the present disclosure. The controller 200 may include, but is not limited to, a processor 202, memory 204, modules 206, and data 208. The modules 206 and the memory 204 may be coupled to the processor 202.

The processor 202 can be a single processing unit or several units, all of which could include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is adapted to fetch and execute computer-readable instructions and data stored in the memory 204.

The memory 204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

The modules 206, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 206 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.

Further, the modules 206 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, a processor, such as the processor 202, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks or, the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 206 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities.

In an embodiment, the modules 206 may include a receiving module 210, a generating module 212, an executing module 214, and a transmitting module 216. The receiving module 210, the generating module 212, the executing module 214, and the transmitting module 216 may be in communication with each other. The data 208 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules 206.

Referring to Figure 1 and Figure 2, the receiving module 210 may be adapted to receive a first input from the user 102. In an example, with a user interface of the application 104b, receiving module 210 may be adapted to receive from the user 102 before the first input, a login credentials associated with the user account to log into the user account through the application 104b. In the example, the login credentials may be a username and password allowing the user 102 to access the user account associated with the financial institution via the application 104b.
In an example, the user 102 may provide the first input. In the example, the first input is indicative of selecting the digital card. In the example, the application 104b may store more than one digital card, linked to the user account for performing financial transaction. The digital card may be a credit card or a debit card. Further the digital card is associated with the user account in the application 104b and the financial transaction is to be made by selecting the digital card.
In another example, the receiving module 210 may be adapted to receive a second input from the user 102. In the example, the second input may be transaction amount. The transaction amount is indicative of a monetary value that the user 102 may desire to pay the merchant for executing the financial transaction. The user 102 may enter the transaction amount in the application 102b. In another example, the receiving module 210 may be adapted to receive from the user 102 an identification of the merchant 112. In the example, the identification of the merchant 112 may be an alphabetical code or a numerical code or a combination of both. Thus, the user 102 may specify that the transaction amount provided is related to said merchant 112.
The receiving module 210 is in communication with the generating module 212.
In an embodiment, the generating module 212 is adapted to generate the unique token. In an example, the unique token may be an alphanumeric combination, a barcode, and QR code. In the example, the unique token may be time-bound i.e., after a pre-defined time the unique token may not be valid for any use. In the example, the unique token may be an alternative to password, OTP and may be generated dynamically every time on receiving a request from the user 102 via the application 104b.
In the example, the unique token may be generated upon receiving the transaction amount from the user 102 via the application 104b. Thus, the unique token is associated with said transaction amount. In the example, the unique token may be valid and may perform financial transaction for said transaction amount only. In another example, the generating module 212 may be adapted to receive the unique token associated with said transaction amount from the financial institute 105.
In another example, the generating module 212 is adapted to block the transaction amount provided by the user 102. In an example, before generating the unique token, the transaction amount from the user’s account is blocked such that the transaction amount is temporarily deducted from the user account and is withhold in an escrow e.g., a temporary account with the bank. In the example, the blocked transaction amount is credited into the user account in response to a non-usage of the unique token by the merchant. In another example, the blocked transaction amount is credited into the user account if the user 102 refuse the approval request.

The receiving module 210 and the generating module 212 is in communication with the transmitting module 212.

In an embodiment, the transmitting module 212 is adapted to transmit the unique token to the merchant 112 based on the identification received from the user 102. In an example, the unique token is thus transmitted to the merchant 112 for further processing.
In an alternative embodiment, the user 102 may share the unique token with the merchant 112 manually. In the example, the merchant 112 may be the POS machine or any other machine configured to receive the unique token from the user 102 for performing the financial transaction. In the example, the merchant 112 may be the online web portal configured to receive the unique token from the user 102 for performing the financial transaction.
In the embodiment, the generating module 212 is further adapted to generate an approval request for executing the financial transaction. In an example, as the user 102 shares the unique token with the merchant 112, the merchant 112 may use the unique token to be redirected to a transaction server. In the example, the transaction server may be a third-party payment gateway for securing the payments between the merchant 112 and the application 104b.
Further, in an example, the approval request is generated for executing the financial transaction once the merchant uses the unique token. In the example, the approval request is generated via the application 104b and displayed on the UE 104a to the user 102. In an example, the user 102 may accept or refuse the approval request.
Thus, this provides the user 102 an added security layer as the user upon providing the unique token may also have to approve the usage of the unique token for further executing the financial transaction.

In the embodiment, the receiving module 210 is further adapted to receive a third input. In an example, the third input may be indicative of the user 102 response to the approval request. In the example, the user 102 may choose to approve or refuse the approval request. The receiving module 210, the generating module 212 is in communication with the executing module 214.

The executing module 214 is adapted to execute the financial transaction based on the third input. In an example, third input is the user’s 102 response to the approval request which may be to approve or refuse the approval request.
In the example, upon the user 102 approving the approval request, the transaction amount is deducted from the user account. The merchant 112 thus may receive the transaction amount. In another example, upon the user 102 providing the third input as refusing the approval request, the transaction amount is not deducted from the user account.

Figure 3 illustrates a flow chart depicting a method 300 for executing a financial transaction, according to an embodiment of the present disclosure. The method 300 may be a computer-implemented method executed, example, by the controller 200. For the sake of brevity, constructional and operational features of the system 100 that are already explained in the description of Figure 1, and Figure 2, are not explained in detail in the description of Figure 3.

At a block 302, the method 300 may include receiving a first input from the user 102.
In an example, the user 102 provides a login credentials associated with a user account to log into the user account through the application 104b.
In the example, the method 300 includes receiving from the user 102, the first input which may include selecting the digital card associated with a user account in the application 104b. In the example, the digital card may be a credit card, or a debit card and the financial transaction is to be made from the digital card.

At a block 304, the method 300 may include receiving a second input.
In an example, the method 300 includes receiving from the user 102 from the second input. In the example, the second input may be the transaction amount provided by the user 102 in the application 104b.

At a block 306, the method 300 may include generating the unique token. In an example, the application 104b may be adapted to share notifications relating to financial transaction and to receive inputs from the financial institute 105 and transmit data to the financial institute 105. In an example, a unique token may be generated via the application 104b. In the example, the application 104b may be adapted to receive a unique token from the financial institute 105 in response to receiving the transaction amount from the user 102. The application 104b may be configured to transmit to the cloud server residing at the financial institute 105 a response indicating submission of the transaction amount by the user 102 on the application 104b. As a feedback to the response form the application 104b, the cloud server at the financial institute 105 may be configured to generate the unique token and provide it to the application 104b. The application 104b may display the unique token on the screen of the UE 104a. In another example, in the method 300, the application 104b may be adapted to generate a unique token in response to receiving the transaction amount from the user 102, and further share the unique token generated with the financial institute 105.
In an example, the unique token is time bound. In the example, the unique token may be consisting of alphanumeric combination, barcode, and QR code.

In the example, the unique token corresponds to the transaction amount and the digital card selected by the user 102. Further, the unique token is to be shared and used with the merchant 112. In the example, the user 102 may share the unique token with the merchant 112 manually for receiving the transaction amount.

In an embodiment, the method 300 may include the merchant 112 to accept the unique token from the user 102. Upon receiving the unique token, the merchant 112 may use the unique token by entering the same in the one or more of the POS machine, the website, the ATM machine, thus a validation request may be sent from the one or more of the POS machine, the website, the ATM machine of the merchant 112 to the financial institute 105. In an example, the validation request may indicate matching of the unique token by the financial institute 105 to establish the unique token is authenticated. In an embodiment, the method 300 may include blocking the transaction amount from the user account upon generating the unique token. In an example, the transaction amount may be temporarily deducted from the user account.
In another example, the method 300 includes crediting the blocked transaction amount into the user account in response to a non-usage of the unique token by the merchant. In another example, the method 300 includes crediting the blocked transaction amount into the user account in response to the user refusing the approval request.

At a block 308, the method 300 may include generating an approval request for executing the financial transaction. In an example, the approval request is generated upon usage of the unique token by the merchant 112.

At a block 310, the method 300 may include receiving a third input. In an example, the third input is received from the user 102 in response to the approval request. In the example, the third input may be one of acceptance and refusal of the approval request. In the example, upon receiving the acceptance of the approval request from the user 102, the transaction amount is deducted from the user account. In another example, upon receiving the refusal of the approval request from the user 102, the transaction amount may not be deducted from the user account.

At a block 312, the method 300 may include executing the financial transaction. In an example, the financial transaction may be based on the third input by deducting the transaction amount from the user account. In the example, executing the financial transaction may include deducting the transaction amount from the user account upon usage of the unique token by the merchant 112.
The present invention has following advantages:
1) The present invention assists the user to execute cardless financial transactions.
2) The user may be able to manage multiple cards without a need for carrying physical cards.
3) The present invention provides enhanced security as the user provides a unique token and further approves the transaction.
4) In the present invention, the unique token is generated for specific transaction amount.

While specific language has been used to describe the present subject matter, any limitations arising on account thereto, are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein. The drawings and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. , Claims:1. A method (300) for executing a financial transaction, the method (300) comprising:
receiving (302) a first input indicative of selection of at least one digital card associated with a user account in an application (104b), wherein the financial transaction is to be made from the at least one digital card;
receiving (304) a second input indicative of a transaction amount;
generating (306) , a unique token corresponding to the transaction amount and the at least one digital card, wherein the unique token is to be shared and used with a merchant (112);
generating (308), upon usage of the unique token by the merchant (112), an approval request for executing the financial transaction;
receiving (310) a third input in response to the approval request, wherein the third input includes one of acceptance and refusal of the approval request; and
executing (312) the financial transaction based on the third input by deducting the transaction amount from the user account.
2. The method (300) as claimed in claim 1, comprising:
receiving, before the first input, login credentials associated with a user account to log into the user account through the application (104b).
3. The method (300) as claimed in claim 1, comprising:
generating, by one of a financial institute (105), the application (104b), the unique token based on the application (104b) receiving the second input from the user (102).

4. The method (300) as claimed in claim 1, comprising:
blocking, before generating the unique token, the transaction amount from the user account based on the submission of the transaction amount, indicating that the transaction amount is temporarily deducted from the user account.
5. The method (300) as claimed in claim 3, comprising crediting the blocked transaction amount into the user account in response to one of a non-usage of the unique token by the merchant, refusal of the approval request by the user (102).
6. The method (300) as claimed in claim 1, wherein the unique token is time bound and is selected from the group consisting of alphanumeric combination, barcode, and QR code.
7. The method (300) as claimed in claim 1, wherein the digital card is one of a credit card, a debit card.
8. A system (100) for executing a financial transaction, the system (100) comprising:
a receiving module (210) adapted to:
receive a first input indicative of selection of at least one digital card associated with a user account in an application (104b), wherein the financial transaction is to be made from the at least one digital card;
receive a second input indicative of a transaction amount;
a generating module (212) adapted to:
generate a unique token corresponding to the transaction amount and the at least one digital card wherein the unique token is to be shared with a merchant (112);
generate, upon the usage of the unique token by the merchant (112), an approval request for executing the financial transaction;
wherein the receiving module (210) is adapted to receive a third input in response to the approval request includes one of acceptance and refusal of the approval request; and
an executing module (214) adapted to execute the financial transaction based on the third input by deducting the transaction amount from the user account.
9. The system (100) as claimed in claim 8, wherein the receiving module (210) is adapted to:
receive, before the first input, login credentials associated with a user account to log into the user account through the application (104b).
10. The system (100) as claimed in claim 8, wherein the generating module (212) is adapted to:
generate, by one of a financial institute (105), the application (104b) the unique token based on the application (104b) receiving the second input from the user.
11. The system (100) as claimed in claim 8, wherein the generating module (212) is adapted to:
block, before generating the unique token, the transaction amount from the user’s account based on the submission of the transaction amount, indicating that the transaction amount is temporarily deducted from the user account.
12. The system (100) as claimed in claim 11, wherein the generating module is adapted to: credit the blocked transaction amount into the user account in response to one of a non-usage of the unique token by the merchant, refusal of the approval request by the user (102).
13. The system (100) as claimed in claim 11, a transmitting module (216) is in communication with the generating module and is adapted to:
transmit the unique token to a transaction server to initiate a transaction.
14. The system (100) as claimed in claim 8: wherein the unique token is time bound and is selected from the group consisting of alphanumeric combination, barcode, and QR code.
15. The system (100) as claimed in claim 8, wherein the digital card is one of a credit card, a debit card.