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

Field

[0001] In general, the subject matter relates to the field of enabling online based transactions and offline based transactions using electronic devices. More particularly, but not exclusively, the subject matter relates to enabling individuals to carry out secured and simplified transactions even in the absence of a card, using user's electronic device

Discussion of related field

[0002] The evolution of internet has involved merchants and consumers in electronic commerce. Generally, a user of an e-commerce site, while making a purchase, provides details, which include, personal details, billing details, shipping details and financial instrument details. It has been observed that remembering and providing such details in an orderly manner is a cumbersome task and the consumer looses interest in purchasing the product. Also, users end up sharing such details across multiple e-commerce sites. When such details are shared, there are chances that details may be compromised, as a result of hacking and phishing, among others, especially in public environments like cyber cafe. [0003] One of the conventional technologies tries to address the drawback related to providing details by a user during each visit to an e-commerce site. In this technique, when a user visits an e-commerce site, the details are stored in the cookie. During subsequent visits to the e-commerce site, the details are fetched from the cookie. Hence, the user will not have to manually enter at least a part of the required details during subsequent visits to the e- commerce site. However, as is well known, deleting cookie is advised for security reasons. Such deletion will result in erasing of the details, and hence the user will have to enter the details during subsequent visits to the e-commerce site. On the other hand, if cookie is not deleted, any compromise in security of the user's device will result in compromising the details stored in the cookie. [0004] In another conventional technique, a user can create an account in an e-commerce site. Subsequent to creating the account, the user can store the requisite details in that account. Thereafter, the user can log into the account during subsequent visits, and make purchases without entering the details that are stored. In this technique however, the user will have to create such accounts in each of the e-commerce sites where he desires to make purchases, if the user wishes to enjoy the aforementioned facility. Furthermore, any security compromise at the e-commerce sites' end may result in compromising the stored details. It must be noted that these email-and-pas sword based accounts are open for access to anyone on internet and hence can get impersonated. It must be also be noted that these accounts are active for access in a permanent way i.e. with same credentials. The credentials to access account is not temporary and hence the chance for compromise is present all the time.

[0005] While there are several challenges, as highlighted above, in enabling online transactions, even enabling offline transactions pose challenges. During offline transaction, a user usually swipes a card to make a payment. In such transactions, there are chances that the card swiped is read through a card reader that has been illegitimately set up to record the information from the card's magnetic stripe, which is known as skimming. Further, during such transactions, a person with malicious intent can compromise the card details by capturing the details using cell phone camera, further adding to the risk. It must be noted that in these cases too, the data that's compromised is permanent in nature and can be used at any time after the transaction. [0006] Further, at present, it is not possible to enable social acquaintances or family members to make transaction using one's card without passing sensitive personal and financial instrument information completely. There is high probability of such information being leaked or compromised due to very weak support for such functionality in existing systems. Another similar case is teleshopping, where sensitive information that gets passed to tele-callers is susceptible to compromise. As noted in earlier use cases, here too the data that is compromised is permanent in nature and can be used at any time after the transaction.

[0007] Further, in the recent time, it is common for users to carry multiple cards, such as, credit card, debit card, membership card, food card and cash card. Carrying multiple cards is not only burdensome, but also unsafe, as there is a possibility of losing the cards or the cards being stolen.

[0008] Therefore, in light of the foregoing discussion, a need exists for a technique for enabling individuals to carry out secured and simplified online and offline transactions even in the absence of a card.

SUMMARY [0009] In an embodiment, a system for enabling transaction is provided. The system includes an application module and a transaction module. The application module is configured to collect data from a user. The transaction module includes a storage module and a processing module. The storage module is configured to store at least a part of the collected data from the user. The processing module is configured to, set a temporary authentication code to data collected from user based on a request received from the user; provide the temporary authentication code to the specified recipient; and provide at least a part of the stored collected data from the user, to at least a first third-party application, based on authentication carried out using the authentication code and its role in transaction.

[0010] Another embodiment provides a method for enabling transaction. The method includes collecting data from a user; storing at least a part of the collected data from the user; generating a temporary authentication code based on a request received from the user; providing the authentication code to the specified recipient; and providing at least a part of the stored collected data from the user, to at least a first third-party application, based on authentication carried out using the authentication code and its role in transaction. BRIEF DESCRIPTION OF DRAWINGS

[0011] Embodiments are illustrated by way of example and not limitation in the Figures of the accompanying drawings, in which like references indicate similar elements and in which:

[0012] FIG. 1 is a block diagram of an exemplary system 100 for enabling transactions, in accordance with an embodiment;

[0013] FIG. 2 illustrates an interface provided in an application module 102 that enables a user to register, in accordance with an embodiment;

[0014] FIG. 2A to 2C illustrate interfaces provided in an application module 102 that enables collection of data from the user, in accordance with an embodiment; [0015] FIG. 3 is an illustration of an exemplary interface provided by the application module 102 to enable the user to request for an authentication code, in accordance with an embodiment;

[0016] FIG. 3A is an illustration of an exemplary interface provided by the application module 102 to enable the user to set an authentication code, in accordance with an embodiment;

[0017] FIG. 4A and 4B are illustrations of an exemplary interfaces provided by the application module 102 for displaying the generated authentication code, in accordance with embodiments;

[0018] FIG. 5 exemplifies communication of a first third-party application 502 with a transaction module 106, in accordance with an embodiment;

[0019] FIG. 6 exemplifies communication of a second third-party application 602 with the transaction module 106, in accordance with an embodiment;

[0020] FIG. 7 is a flowchart of an exemplary method for enabling transactions, in accordance with an embodiment; and

[0021] FIG. 8 is a flowchart of an exemplary method of carrying out authentication using an authentication code, in accordance with an embodiment.

DETAILED DESCRIPTION

I. OVERVIEW

II. EXEMPLARY SYSTEM

III. EXEMPLARY METHOD

IV. FIRST EXAMPLE

V. SECOND EXAMPLE

VI. THIRD EXAMPLE

VII. CONCLUSION

I. OVERVIEW

[0022] Embodiments relate to technique for enabling individuals to carry out secured and simplified online and offline transactions.

[0023] In an embodiment, a system is provided to enable users to make purchases on e- commerce sites. This system comprises of an application module, which can be installed on a user's communication device, such as a tablet or a smart phone. The system also includes a transaction module, which can reside on cluster of servers in the internet. Each of these servers can perform the role of processing module or storage module. The application module is enabled to collect data corresponding to the user, such as, personal details of the user, one or more billing details, one or more shipping details and details corresponding to one or more financial instruments (Ex: credit cards and debit cards, net banking details, online wallet accounts and loyalty discount cards, among others). The application module communicates with a transaction module provided in the system, and stores the data in the storage module.

[0024] In the event of the user wanting to make a purchase on an e-commerce site, the user through the application module, sends a request to the transaction module to generate a temporary authentication code. The transaction module on receiving the request, generates a temporary authentication code, which can be in the form of a number and sends it to the application module. The user enters this authentication code in the e-commerce site, which can be referred to as a first third-party application. The e-commerce site communicates this authentication code to the transaction module. The transaction module does validity checks, which may just include comparing the received authentication code and the generated authentication code. In the event of successful authentication, the transaction module communicates at least a part of the data, such as a billing address, shipping address and personal details to the e-commerce site. Hence, the user will not have to enter such details manually at the e-commerce site and more importantly the financial instrument data is protected from merchant. E-commerce site may then pass the authentication code to payment gateway, which can be referred to as second third-party application. When payment gateway communicates authentication code, the system shares another part of user's data, the financial instrument details, to enable transaction.

[0025] The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments are described in enough detail to enable those skilled in the art to practice the present subject matter. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. The embodiment can be combined, other embodiments can be utilized or structural and logical changes can be made without departing from the scope of the invention. The following detailed description is, therefore, not to be taken as a limiting sense.

[0026] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one. In this document, the term "or" is used to refer to a nonexclusive "or," such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated.

II. EXEMPLARY SYSTEM

[0027] FIG. 1 is a block diagram of an exemplary system 100 for enabling transactions, in accordance with an embodiment. The system 100 includes an application module 102 and a transaction module 106. The transaction module 106 includes a storage module 108 and a processing module 110.

[0028] The modules described can reside in part or fully in any of the physical entities, such as, but not limited to, electronic device of user, cluster of servers and third-party applications. Therefore, in this description and claims, as one skilled in the art can appreciate, functionalities described can be part of any entity and need not be tied to any discrete entity.

[0029] In an embodiment, the application module 102 is installed in a communication device. The communication device can be, for example, mobile phone, a tablet, a desktop or a laptop, among others. Alternatively, the application module 102 can be a web based application that can be accessed by a user through the communication device.

[0030] The application module 102 is configured to communicate with the transaction module 106 through a communication network 104. The communication can occur through internet protocol. Alternatively, or in combination, the communication can occur through messaging service, such as Short Messaging Service (SMS), USSD, Multimedia Messaging Service (MMS), email and phone call, among others.

[0031] The communication network 104 can be a wired, wireless or a combination of wired and wireless network. Communication can also be through Inter Process Communication (IPC), when the two or more modules are part of the same software in a device.

[0032] In an embodiment, the application module 102 enables a user to create an account for enabling the transaction. The account can be created by accessing the application module 102. In an embodiment, the application module 102 is downloaded onto the user's device, thereby enabling communication between the application module 102 and the transaction module 106. FIG. 2 illustrates an interface 200 provided in the application module 102 that enables the user to register, in accordance with an embodiment. The user provides at least the mandatory data to register and create an account. In an embodiment, during installation and registration, the mobile device and the transaction module 106 sets up a 2-way encryption key, which is used in future operations for encrypting data. The mobile device number, such as, the mobile number and IMIE number, among others, can be used for this purpose from the mobile device, which protects the system 100 against spoofing from other unauthorized devices.

[0033] In an embodiment, the registration can be carried out using another means, such as at ATM, online website or financial instrument issuing authority, among others. It shall be noted that a user may submit data, such as, personal details, billing addresses, shipping addresses and financial instrument details to a third party application. Thereafter, registration to the application module 102 can be initiated through the third party website, wherein the details submitted to the third party application, either partially or completely, is synced with the application module 102. The process of creating an account is well known in the art, and hence not discussed in detail.

[0034] Subsequent to creating the account, the application module 102 enables a user to provide data. FIG. 2A to 2C illustrate interfaces provided in the application module 102 that enable collection of data from the user, in accordance with an embodiment. FIG. 2A illustrates an interface 202 that enables addition of a billing address. Likewise, FIG. 2B illustrates an interface 204 that enables addition of a shipping address. Similarly, FIG. 2C illustrates an interface 206 that enables addition of details corresponding to a financial instrument. It shall be noted that, multiple such billing addresses, shipping addresses and financial instruments can be added using the respective interfaces provided by the application module 102. It shall be further noted that, one or more fields illustrated in the figures may be absent. Alternatively, one or more fields, which are not illustrated in the figures, may be present. Furthermore, some of the fields may be mandatory, while others may be optional. It shall be noted that any data relevant for a transaction can be collected in user's device apart from the sections described here in this embodiment.

[0035] The data received by the application module 102 is communicated to the transaction module 106. In an embodiment, a part of the data received by the application module 102 is communicated to the transaction module 106. For example, data corresponding to the financial instruments may be communicated to the transaction module 106, while data corresponding to the billing and shipping addresses may not be communicated to the transaction module 106 at the instance of adding the addresses, they may be communicated, when the need arises.

[0036] In an embodiment, sensitive information, such as, some or all of the details corresponding to the financial instrument, is stored in the transaction module 106, and such data may be deleted, encrypted or password protected in the application module 102.

[0037] As noted earlier, storage module which is part of transaction module 106 can exist in part or full in any physical entities. Hence in an embodiment, data collected from user may be stored in user device. In another embodiment, data collected from user may get stored in cluster of servers hosting database. In yet another embodiment, data collected gets stored in both user device and remote cluster of servers.

[0038] The application-module 102 is further configured to enable the user to request for a temporary authentication code. FIG. 3 is an illustration of an exemplary interface 300 provided by the application module 102 to enable the user to request for a temporary authentication code, in accordance with an embodiment. The user can select a billing address, shipping address and financial instrument to be used for the transaction, while requesting for the authentication code. The selection made by the user will be communicated to the transaction module 106. It shall be noted that, in an embodiment, default values, such as default billing address, shipping address and financial instrument may be displayed. Thereafter, if required, the user can select an alternate value, for example by selecting a value by clicking on the dropdown button. The default values may be selected by the user, or alternatively, the default value may be selected by the system based on user's selection trend. In an embodiment, the user can make changes, such as, for example, phone number, email address and physical address, among others while requesting for authentication code.

[0039] In an embodiment, the user sets the authentication code, as illustrated in FIG. 3A. The authentication code that the user sets may be of his own choice or based on the instructions received by him. At the same time, the user is enabled to override at least a part of the collected data corresponding to the user, prior to sending the request for the authentication code to the processing module.

[0040] In an embodiment, the application module 102 is configured to collect additional data related to the transaction, such as, transaction limit, expiry time, merchant and product, among others. [0041] In an embodiment, the user has to enter a password and authenticate himself before opening the application module 102 to enable a transaction or to access some or all of the functionalities of the application module 102.

[0042] In an embodiment, the user has to enter a password and authenticate himself before requesting the authentication code.

[0043] The request made by the user through the application module 102 is received by the transaction module 106, and the transaction module 106 generates the temporary authentication code. The temporary authentication code is communicated back to the application module 102. FIG. 4A and 4B are illustrations of exemplary interfaces provided by the application for displaying the generated authentication code, in accordance with embodiments. In FIG. 4A, the selection made by the user and the authentication code, which is a four digit number code, is displayed. On the other hand, in FIG. 4B, the selection made by the user and the authentication code, which is a matrix barcode, is displayed.

[0044] In an embodiment, an authentication code is displayed by a third party website, such as an e-commerce website. This authentication code is further used to enable the transaction.

[0045] In an embodiment, the authentication code includes alphanumeric character.

[0046] In another embodiment, the authentication code includes barcode, such as matrix barcode.

[0047] In another embodiment, the authentication code can include one or more of alphanumeric character, barcode, text, pictogram, audio and video. It shall be noted that in case of multiple authentication codes used to enable a transaction, the term 'authentication code' used in description and claims can denote one or more authentication codes.

[0048] In an embodiment, the authentication code represents at least a part of the data collected from the user.

[0049] In an embodiment, the application module 102 enables the user to select a destination to which the authentication code has to be communicated. The destination, for example, can be specified by specifying, one or more of, phone number, email address or identification code, which can correspond to friend, family or social acquaintance, which may be recognizable by the application module 102 or the transaction module 106, among others. It shall be noted that, actual sensitive information is not communicated, thereby making the system 100 more secure. In an exemplary embodiment the recipient can be first third party application, which avoids the step of passing authentication code again to first third party application manually.

[0050] In an embodiment, the user can add constraints before requesting the authentication code. The constraints, for example, can be one or more of, specifying the transaction amount, maximum transaction amount, expiry time for the authentication code, number of times the authentication code can be used, merchant system identifier like website domain and sender/recipient role in transaction, among others. System 100 can have default values for the constraints if they are not provided by user.

[0051] In an embodiment, the application module 102 enables the user to alter data that was previously entered by the user, which is updated in the transaction module 106.

[0052] The transaction module 106, as mentioned earlier, includes the storage module 108 and the processing module 110. The transaction module 106 is enabled to communicate through the communication network 104 with the application module 102.

[0053] In an embodiment, the storage module 108 is configured to store the data provided by the application module 102. The data stored in the storage module 108 can include, billing details, shipping details, personal details and details corresponding to the financial instruments, which corresponds to the user of the respective application module 102. Storage module 108 can exist in part or full in any physical entities and hence in one of the embodiments, storage module 108 may be present along with application module 102.

[0054] In an embodiment, the processing module 110 is configured to generate an authentication code based on the request received from the user, for example through the application module 102. Further, the processing module 110 is configured to provide at least a part of the stored collected data corresponding to the user, to at least a first third-party application, based on authentication carried out using the authentication code.

[0055] In an embodiment, the transaction module 106 is configured to communicate with the first third-party application. FIG. 5 exemplifies communication of a first third-party application 502 with the transaction module 106, in accordance with an embodiment. The communication can occur through the communication network 104.

[0056] In an embodiment, the first third-party application 502 is configured to receive an authentication code from a user. In another embodiment, in addition to the authentication code, the first third-party application 502 is configured to receive a second data set from the user. The second data set, for example, can be an email address, user name, phone number or identification code. [0057] The first third-party application 502 is configured to communicate the authentication code along with the second data set, if required, to the transaction module 106, which uses the same to authenticate a transaction.

[0058] The first third-party application 502 is further configured to receive data, such as, one or more of, billing address, shipping address and details corresponding to a financial instrument, as may be required and authorized, from the transaction module 106, upon successful authentication.

[0059] In an embodiment, the transaction module 106 is configured to communicate with a second third-party application. FIG. 6 exemplifies communication of a second third-party application 602 with the transaction module 106, in accordance with an embodiment. The communication between the second third-party application 602 and the transaction module 106 can occur through the communication network 104. In an embodiment, temporary authentication code is passed from first third party application 502 to second third party application 602. In another embodiment, user re-enters temporary authentication code at second third party application 602.

[0060] In an embodiment, the second third-party application 602 is further configured to receive data, such as, one or more of, billing address, shipping address and details corresponding to a financial instrument, as may be required and authorized, from the transaction module 106, upon successful authentication.

[0061] Roles of third party applications are maintained by system 100 and system can have controls like password and firewall checks for every interaction by third party applications.

[0062] It shall be noted that, the third party applications receive data based on the role of the third party application in the transaction.

III. EXEMPLARY METHOD

[0063] FIG. 7 is a flowchart of an exemplary method for enabling transactions, in accordance with an embodiment. The method includes, at step 702, collecting data from a user. Subsequently, at step 704, at least a part of the collected data corresponding to the user is stored. Further, when the user has to initiate a transaction, the user makes a request to set a temporary authentication code to data collected from the user, which is received by the transaction module 106, at step 706. Subsequent to receiving the request, a temporary authentication code is set corresponding to data collected from user at step 708. Thereafter, at step 710, the authentication code is provided to the user. Further, at step 712, at least a part of the stored collected data corresponding to the user is provided to at least a first third-party application 502, based on authentication carried out using the authentication code. [0064] It shall be noted that some of the steps mentioned above are carried out during registration process or while updating data. Hence, some of the steps may not be necessary each time a transaction has to be enabled. Some of the data may be set as default based on user settings so that it is not required each time a transaction has to be enabled

[0065] In an embodiment, the application module 102 collects the data from the user at step 702. The data received by the application module 102 is communicated to the transaction module 106 through the communication network 104. In the transaction module 106, the collected data is stored in the storage module 108, at step 704.

[0066] In an embodiment, the transaction module 106 receives a request from the user to generate an authentication code through the application module 102, at step 706. Upon receiving this request, the processing module 110 generates the code, at step 708.

[0067] In an embodiment, the transaction module 106 uses a algorithm to generate an authentication code, which is sufficiently random. The user's data may also be used in the algorithm to generate the authentication code.

[0068] In an embodiment, authentication code generated may include the actual user data itself but in an encoded manner.

[0069] In an embodiment, the processing module 110 communicates the generated authentication code to the application module 102, at step 710.

[0070] In an embodiment, the user enters the authentication code into the first third-party application 502, along with an optional second data set. The processing module 110 uses the data received from the first third-party application 502, and provides at least a part of the stored collected data corresponding to the user, to the first third-party application 502, based on authentication carried out using the authentication code.

[0071] FIG. 8 is a flowchart of an exemplary method of carrying out authentication using the authentication code, in accordance with an embodiment. As mentioned earlier, a user, through the application module 102 requests for an authentication code to enable a transaction. The request is received by the transaction module 106, which generates an authentication code. It shall be noted that the authentication code is now linked with the user's account. The transaction module 106 communicates the generated authentication code to the application module 102, at step 802. The user accesses the authentication code from the application module 102, and enters the same in the first third-party application 502 along with a second data set, which is associated with the user's account, at step 804. The first third-party application 502 communicates the received data to the transaction module 106, at step 806. The transaction module 106, at step 808, performs validation checks. For example, the transaction module 106 verifies whether the entered authentication code and the second data set match with the generated authentication code. If they do not match, then the authentication fails. On the other hand, if they match, then the transaction module 106 verifies whether a predefined time has elapsed since the generation of the code or has the code been used for a transaction earlier. It shall be noted that, essentially authentication rules, which may include verifying whether the authentication code has been used beyond a permissible limit, are checked before enabling the transaction.

[0072] In an embodiment, other constraints, as discussed earlier that may have been set by the system 100 or user are verified to enable the transaction.

IV. FIRST EXAMPLE

[0073] In this example a user uses the system 100 to make an e-commerce transaction. The user downloads and installs the application module 102 in his mobile device. Subsequently, the user creates an account by providing personal details and submits multiple billing addresses, shipping addresses and details corresponding to multiple financial instruments, to the application module 102. The user also selects default values for the data submitted to be used in a transaction. The application module 102 communicates the data to the transaction module 106, which stores the data. The user, while make a purchase on an e- commerce site, which can be interpreted as first third-party application 502, requests an authentication code to be generated using the application module 102. The user allows default values stored earlier to be used while making the request. The transaction module 106 receives the request and the selection, generates an authentication code and communicates it back to the application module 102. The user enters the authentication code and his mobile number associated with his account in the e-commerce site. The e-commerce site communicates the received data to the transaction module 106. Upon successful authentication, the transaction module 106 communicates the personal details, billing address and shipping address to the e-commerce site. Hence, the user will not have to enter the personal details, billing address and shipping address manually in the e-commerce site. Further, upon successful authentication, the transaction module 106 communicates details of the selected financial instrument to a payment gateway associated with the e-commerce site. Hence, the user will not have to enter the details corresponding to the financial instrument in an interface corresponding to the payment gateway.

[0074] In an embodiment, the user specifies a destination in the application module 102 or in the e-commerce site, to which the authentication code has to be sent. Subsequently, the authentication code is sent to the said destination and can be used as described earlier.

[0075] In another embodiment, merchant website can display a code, which may be a random number generated by it and asks the user to set that as temporary authentication code through his device to enable transaction. User can then enter the code in his device. The merchant website can initiate a call to system using temporary authentication code to fetch user's data when user confirms that the operation is completed from device. In an exemplary embodiment, merchant website can make continuous calls to system in background for certain duration without requiring user even to confirm completion of his operation in website.

V. SECOND EXAMPLE

[0076] In this example a user uses the system 100 to make an offline transaction, such as, paying for fuel at a gas station. The user downloads and installs the application module 102 in his mobile device. Subsequently, the user creates an account and submits multiple billing addresses, shipping addresses and details corresponding to multiple financial instruments, to the application module 102. The application module 102 communicates the data to the transaction module 106, which stores the data. The user, to make a payment at the gas station, requests an authentication code to be generated using the application module 102. The user selects a financial instrument while making the request. The transaction module 106 receives the request and the selection, generates an authentication code and communicates it back to the application module 102. The authentication code can be a matrix barcode. The barcode is scanned at the gas station. The data collected as a result of scanning is communicated to the transaction module 106. Upon successful authentication, the transaction module 106 provides details of the selected financial instrument to an application, such as a banking application, which can be interpreted as the first third-party application 502 or the second third-party application 602, thereby enabling the transaction. Hence, the user will not have to swipe the card at the gas station. Further, the user need not even carry cards for enabling the user to make payments using cards.

[0077] In an embodiment, the authentication code also includes the information to be transferred to the third-party application. The third party application may include library to decode the authentication code and use the same to enable transaction.

[0078] In an embodiment, the user specifies a destination in the application module 102 or a third-party application to which the authentication code has to be sent. Subsequently, the authentication code is delivered at the said destination and can be used as described earlier.

VI. THIRD EXAMPLE

[0079] In an embodiment, transaction can be enabled using an ATM. the ATM scans the authentication code from user device in form of bar code. As the ATM device is a trusted entity, unlike a merchant website, the authentication code generated in user device can include entire data in encoded form instead of a code mapping to user's data. The authentication code is then used by part of transaction module in ATM, which performs decoding of encoded data to extract the financial instrument details and details corresponding to the amount to be released without contacting any remote server. Upon successful authentication, the amount can be withdrawn from the ATM. Hence, ATM withdrawal is enabled without even using the card.

[0080] In an embodiment, the system 100 can be used to enable peer to peer transaction without even exchanging sensitive financial instrument details. For example, a first user can request authentication code to be generated using the authentication module 102, and also specify the amount to the transferred. The authentication code is subsequently generated and shared with a second user. The second user communicates the authentication code along with a second data set to the transaction module 106, through, for example, application module 102 present in the second user's device. Upon successful authentication, the transaction is completed.

VII. CONCLUSION

[0081] The embodiments enable carrying out secured and simplified online and offline transactions. Further, some embodiments enable carrying out secured and simplified online and offline transactions even in the absence of a card.

[0082] The processes described above is described as sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, or some steps may be performed simultaneously.

[0083] The example embodiments described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.

[0084] Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the system and method described herein. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

[0085] Many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. It is to be understood that the description above contains many specifications, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the personally preferred embodiments of this invention. Thus the scope of the invention should be determined by the appended claims and their legal equivalents rather than by the examples given.