[0001] The present invention relates generally to electronic transactions, and more particularly, to a method for processing transactions for purchases.
BACKGROUND
[0002] Due to advent of technology, transactions by way of transaction cards have witnessed an upward trend. These days users opt to pay for purchases by using the transaction cards. Further, for transactions involving large amounts, users typically prefer transaction cards over cash. Due to the increasing popularity of transaction cards, several merchants have installed point-of-sale (POS) or point-of-interaction (POI) devices at their merchant stores for enabling the users to carry out purchases.
[0003] As POS devices are expensive, small-time merchants may not prefer to install the POS device but instead make the products available for purchase through cash. If the users want to purchase products from such merchants, the users always have to ensure that they carry sufficient cash to perform the purchases. Some users may not prefer to carry the cash and hence would opt for a different merchant that accepts payments through transaction cards. Thus, small-time merchants would suffer a loss due to migration of the users to a different merchant and at the same time it causes great inconvenience to the users as they have to search for merchants, who have the POS device for transactions.
[0004] In light of the foregoing, there exists a need for a solution that facilitates performing transactions by way of transactions cards, without causing any inconvenience to the user or without having the need for the merchant to install the POS machine.
SUMMARY
[0005] In an embodiment of the present invention, a transaction processing method is provided. A first image of a transaction card and a second image of a purchase receipt of a purchase made by a user at a merchant is received by a server. Transaction card details of the transaction card are extracted from the first image by the server. The server further extracts
3
merchant details of the merchant from the second image. An authentication of the user is initiated by the server based on the transaction card details. A transaction associated with the purchase is initiated by the server based on the authentication of the user. When the transaction is approved, a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details.
[0006] In another embodiment of the present invention, a transaction processing system is provided. The system includes a payment network server that further includes a circuitry that performs various functions to process a transaction. The circuitry receives a first image of a transaction card and a second image of a purchase receipt of a purchase made by a user at a merchant. Transaction card details of the transaction card are extracted from the first image by the circuitry. The circuitry further extracts merchant details of the merchant from the second image. An authentication of the user is initiated by the circuitry based on the transaction card details. A transaction associated with the purchase is initiated by the circuitry based on the authentication of the user. When the transaction is approved, a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details.
[0007] In yet another embodiment of the present invention, a transaction processing method is provided. A graphical user interface (GUI) is presented on at least one of a user device of a user or a merchant device of a merchant by a server. The GUI displays one or more options for uploading a first image of a transaction card and a second image of purchase receipt of a purchase made by the user at the merchant. The first and second images are received by the server. Transaction card details of the transaction card are extracted from the first image by the server. The server further extracts merchant details of the merchant from the second image. An authentication of the user is initiated by the server based on the transaction card details. A transaction associated with the purchase is initiated by the server based on the authentication of the user. When the transaction is approved, a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details.
4
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The accompanying drawings illustrate various embodiments of systems, methods, and other aspects of the invention. It will be apparent to a person skilled in the art that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of one element may be implemented as an external component in another, and vice versa.
[0009] Various embodiments of the present invention are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements, and in which:
[0010] FIG. 1 is a block diagram that illustrates a communication environment for processing transactions, in accordance with an embodiment of the present invention;
[0011] FIG. 2 is a block diagram that illustrates a payment network server of the communication environment of FIG. 1, in accordance with an embodiment of the present invention;
[0012] FIG. 3 is a block diagram that illustrates an issuer server of the communication environment of FIG. 1, in accordance with an embodiment of the present invention;
[0013] FIG. 4 is a process flow diagram that illustrates processing of a transaction, in accordance with an embodiment of the present invention;
[0014] FIGS. 5A and 5B collectively represent a process flow diagram that illustrates processing of a transaction, in accordance with another embodiment of the present invention;
[0015] FIG. 6 is a process flow diagram that illustrates processing of a transaction, in accordance with yet another embodiment of the present invention;
[0016] FIGS. 7A – 7C collectively represent a flow chart that illustrates a method for processing a transaction, in accordance with an embodiment of the present invention;
5
[0017] FIGS. 8A – 8D collectively represent a flow chart that illustrates a method for processing a transaction, in accordance with another embodiment of the present invention;
[0018] FIG. 9 is a high-level flow chart that illustrates a method for processing transactions, in accordance with an embodiment of the present invention;
[0019] FIG. 10 is a high-level flow chart that illustrates a method for processing transactions, in accordance with another embodiment of the present invention; and
[0020] FIG. 11 is a block diagram that illustrates a system architecture of a computer system, in accordance with an embodiment of the present invention.
[0021] Further areas of applicability of the present invention 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 invention.
DETAILED DESCRIPTION
[0022] The present invention 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.
[0023] 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
6
limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
[0024] Various embodiments of the present invention provide a method and a system for performing transactions based on images of a transaction card of a user and a purchase receipt. At least one of the user and a merchant initiates a registration request by way of a user device or a merchant device, respectively, for registering with a service that facilitates processing of transactions. The registration request is received by a server (such as a payment network server, an issuer server, or an acquirer server) and at least one of the user and the merchant is registered for the service. When the user performs a purchase at the merchant, the merchant provides the purchase receipt to the user. One of the user and the merchant then provides an image of the transaction card (i.e., a first image) that the user wants to use for performing the transaction and an image of the purchase receipt (i.e., a second image) to the server. The server extracts transaction card details of the transaction card from the first image and merchant details from the second image. The server further retrieves merchant account details based on the merchant details and initiates an authentication of the user based on the transaction card details. When the user is successfully authenticated, the server initiates the transaction. A purchase amount of the transaction is debited from a user account that is linked to the transaction card and credited to a merchant account that is associated with the retrieved merchant account details. The user and the merchant are notified when the transaction is complete.
[0025] Thus, the method and the system, in accordance with various embodiments of the present invention, provide a facility to process transactions when the merchant does not possess a point-of-sale device.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
[0026] Server is a physical or cloud data processing system on which a server program runs. A server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server is implemented as a computer program that is executed on programmable computers, such as personal computers, laptops, or a network of computer
7
systems. The server may correspond to a merchant server, a payment gateway server, a digital wallet server, an acquirer server, a payment network server, or an issuer server.
[0027] Merchant is an entity that offers various products and/or services in exchange of payments. The merchant may establish a merchant account with a financial institution, such as a bank (hereinafter “acquirer bank”) to accept the payments from several users.
[0028] Issuer bank is a financial institution, such as a bank, where accounts of several users are established and maintained. The issuer bank ensures payment for authorized transactions in accordance with various payment network regulations and local legislation.
[0029] Payment networks are transaction card associations that act as intermediate entities between acquirer banks and issuer banks to authorize and fund transactions. Examples of various payment networks include MasterCard®, American Express®, VISA®, Discover®, Diners Club®, and the like. Payment networks settle transactions between various acquirer banks and issuer banks when transaction cards are used for initiating the transactions. The payment network ensures that a transaction card used by a user for initiating a transaction is authorized.
[0030] Transaction cards refer to cards, such as debit cards, credit cards, prepaid cards, gift cards, promotional cards, and/or other devices, such as contactless fobs or payment-enabled mobile devices, that may hold identification information of an account. Transaction cards can be used to perform transactions, such as deposits and withdrawals, credit transfers, purchase payments, and the like. A transaction card may also be radio frequency identification (RFID) or near field communication (NFC) enabled for contactless payments.
[0031] Purchase receipt is provided to a user by a merchant, when the user purchases a product or avails a service offered by the merchant. The purchase receipt may be a printed copy or a soft copy. The purchase receipt includes details of the product or service, a transaction date, a transaction time, a purchase amount, merchant details, or the like.
[0032] First and second images are digital images of a transaction card and a purchase receipt, respectively. The first and second images are processed by an image-processor to extract transaction card details and merchant details, respectively. The transaction card details are
8
extracted to identify a user account linked to the transaction card whereas the merchant details are extracted to identify a merchant account associated with the merchant details.
[0033] FIG. 1 is a block diagram that illustrates a communication environment 100 for processing transactions, in accordance with an embodiment of the present invention. The communication environment 100 includes a user 102 in possession of a user device 104, and a merchant 106 in possession of a merchant device 108. The communication environment 100 further includes an acquirer server 110, a payment network server 112, and an issuer server 114. The user device 104 communicates with the payment network server 112 and the issuer server 114 by way of a communication network 116. Similarly, the merchant device 108 communicates with the acquirer server 110 and the payment network server 112 by way of the communication network 116.
[0034] The user 102 is an individual, who is an account holder of a financial account (hereinafter referred to as “user account”). In one embodiment, the user account is a bank account maintained by a financial institution, such as an issuer bank. The user account is linked to various transaction cards, such that each transaction card stores identification information of the corresponding account (hereinafter referred to as “account identification information of the account”). In one embodiment, the transaction cards are physical cards, such that the account identification information may be stored in the form of an electronic chip or a machine readable magnetic strip embedded in each transaction card. The account identification information may include an account number of the account, a name of an account holder (i.e., the name of the user 102), or the like. Each transaction card has a unique card number, an expiry date, a card security code, and a card type associated to it. The card number, the expiry date, the card security code, and the card type constitute transaction card details of the corresponding transaction card. In another embodiment, the transaction cards are virtual cards that are stored electronically in a memory (not shown) of the user device 104. Examples of the transaction cards include credit cards, debit cards, membership cards, promotional cards, charge cards, prepaid cards, gift cards, or the like. In another embodiment, the user account is a digital wallet maintained by a third-party service provider or a merchant. If the user account is a digital wallet, the account identification information is stored in a memory or a cloud server of the third-party service
9
provider or the merchant. The user 102 may visit merchant stores of various merchants, such as the merchant 106, to purchase products or avail services offered at those merchant stores.
[0035] The user device 104 is a communication device of the user 102. The user 102 uses the user device 104 to access a mobile application or a website of the payment network server 112 or the issuer server 114. The mobile application may be installed on the memory of the user device 104. The website may be accessed by way of a web-browser installed on the memory of the user device 104. In one embodiment, the user device 104 may include an inbuilt camera for clicking various images. The images clicked by the camera are stored in the memory of the user device 104 or uploaded on a cloud server (not shown) by the user 102. In one embodiment, the memory of the user device 104 may have images (i.e., digital images) of the transaction cards of the user 102 stored therein. Examples of the user device 104 include, but are not limited to, a mobile phone, a smartphone, a laptop, a tablet, a phablet, a desktop computer, a personal digital assistant, or any other communication device.
[0036] The merchant 106 is an individual, who is an account holder of a financial account (hereinafter referred to as “merchant account”). In one embodiment, the merchant account is a bank account maintained by a financial institution, such as an acquirer bank. In another embodiment, the account is a digital wallet maintained by a third-party service provider. The merchant 106 offers various products and services to users (such as the user 102) in exchange of payment. The merchant 106 further provides a purchase receipt to the user 102, when the user 102 purchases product/s or avails service/s offered by the merchant 106. The purchase receipt may be at least one of a printed copy or a soft copy. The purchase receipt includes a purchase amount of the product/s, product details, merchant details of the merchant 106, and the like. The product details may include name of the product/s, unit of the product/s, and the like. The merchant details may include a name of the merchant 106, an address of the merchant 106, a phone number of the merchant 106, an identification number of the merchant 106, and the like. Examples of the identification number include, but are not limited to, a tax identification number (TIN), goods and services tax identification number (GSTIN), or a store number of the merchant 106.
[0037] The merchant device 108 is a communication device of the merchant 106. The merchant 106 uses the merchant device 108 to access a mobile application or a website of the
10
acquirer server 110 or the payment network server 112 for facilitating the transactions corresponding to the purchases made by various users. The mobile application may be installed on the memory of the merchant device 108. The website may be accessed by way of a web-browser installed on a memory of the merchant device 108. Examples of the merchant device 108 include, but are not limited to, a mobile phone, a smartphone, a laptop, a tablet, a phablet, a desktop computer, a personal digital assistant, or any other communication device.
[0038] The acquirer server 110 is a computing server that is associated with a financial institution, such as the acquirer bank. The acquirer bank maintains merchant accounts of various merchants, such as the merchant account of the merchant 106. The acquirer bank processes various transactions by using the acquirer server 110. The acquirer server 110 receives transaction requests from the payment network server 112 and transmits transaction approval requests to the issuer server 114, via the communication network 116. The acquirer server 110 credits or debits a merchant account in the acquirer bank based on the processing of the transactions that correspond to the merchant account. The acquirer server 110 includes circuity for performing functions related to the processing of the transactions.
[0039] The payment network server 112 is a computing server that is associated with a payment network of various transaction cards. The payment network server 112 represents an intermediate entity between the acquirer server 110 and the issuer server 114 for authenticating and funding the transactions performed by using the transaction cards. The payment network server 112 generates transaction requests based on the transactions performed by the users, such as the user 102. The transaction requests are communicated to the acquirer and issuer servers (for example, the acquirer server 110 and the issuer server 114) for crediting and/or debiting the accounts corresponding to the transactions. In one embodiment, the payment network server 112 may host a mobile application or a website to provide a service that enables the user 102 or the merchant 106 to perform a transaction for a purchase by way of an image of a transaction card of the user 102 and a purchase receipt associated with the purchase. The payment network server 112 includes circuity for performing functions related to the processing of the transactions. The components and functioning of the payment network server 112 are explained in conjunction with FIGS. 2 and 4. Examples of various payment networks include MasterCard, American Express, VISA, Discover, Diners Club, or the like.
11
[0040] The issuer server 114 is a computing server that is associated with the issuer bank. The issuer bank is a financial institution that manages accounts of multiple users. User-profiles of various users who have accounts in the issuer bank are stored in a memory (as shown in FIG. 3) of the issuer server 114 or on a cloud server associated with the issuer server 114. Each user-profile includes account details of a user account of the corresponding user. For example, the user-profile of the user 102 includes account details of the user account. The account details may include an account balance, a credit line, details of an account holder (such as the user 102), transaction history of the account holder, account identification information, or the like. The details of the account holder may include name, age, gender, physical attributes, registered phone number, alternate phone number, registered e-mail address, or the like of the account holder.
[0041] The issuer server 114 receives various credit and debit requests from the acquirer server 110 or the payment network server 112. Based on the credit and debit requests, the issuer server 114 credits or debits the accounts of the users (also referred to as user accounts). Methods for crediting and debiting accounts via the issuer server 114 will be apparent to persons having skill in the art and may include processing via the traditional four-party system or the traditional three-party system. In one embodiment, the issuer server 114 may host a mobile application or a website to provide a service that enables the user 102 to perform a transaction for a purchase from the merchant 106 by way of an image of a transaction card of the user 102 and an image of a purchase receipt associated with the purchase. The issuer server 114 includes circuity for performing functions related to the processing of the transactions. The components and functioning of the issuer server 114 are explained in conjunction with FIGS. 3 – 6.
[0042] It will be apparent to a person having ordinary skill in the art that the acquirer bank may be same as the issuer bank, when the user 102 and the merchant 106 have their accounts in the same financial institution.
[0043] Examples of the acquirer server 110, the payment network server 112, and the issuer server 114, include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that can execute a machine-readable code, cloud-based servers, distributed server networks, or a network of computer systems.
12
[0044] The communication network 116 is a medium through which content and messages are transmitted between various entities, such as the user device 104, the merchant device 108, the acquirer server 110, the payment network server 112, and the issuer server 114. Examples of the communication network 116 include, but are not limited to, a wireless fidelity (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 communication environment 100 may connect to the communication network 116 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), and 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, or any combination thereof.
[0045] FIG. 2 is a block diagram that illustrates the payment network server 112 of the communication environment 100 of FIG. 1, in accordance with an embodiment of the present invention. The payment network server 112 includes a first processor 202, a first image-processor 204, a first memory 206, and a first transceiver 208 that communicate with each other via a first bus 210. The first processor 202 includes a first authentication manager 212 and a first transaction manager 214.
[0046] The first processor 202 includes suitable logic, circuitry, and/or interfaces to execute operations for initiating a credit or debit of an amount to/from the user accounts or the merchant accounts that are maintained at partner issuer and acquirer banks, respectively. The first processor 202 further handles various requests for facilitating transactions performed by the use of transaction cards. The requests are received from one or more entities, such as the user device 104, the merchant device 108, the acquirer server 110, and the issuer server 114. Examples of the first processor 202 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
13
[0047] The first image-processor 204 includes suitable logic, circuitry, and/or interfaces to execute operations for processing images of transaction cards and purchase receipts to facilitate transactions. The first image-processor 204 may process the images to extract information or details from the images. The information or details include merchant details, transaction card details of the transaction card, the purchase amount, and the like. The first image-processor 204 may receive the images from one or more entities, such as the user device 104 or the merchant device 108. The first image-processor 204 extracts the information or details by performing optical character recognition (OCR) on the images. The first image-processor 204 may perform OCR on the images by implementing one or more image processing techniques that are known in the art. Examples of the first image-processor 204 include, but are not limited to, an ASIC processor, a digital signal processor (DSP), a RISC processor, a CISC processor, an FPGA, and the like.
[0048] The first memory 206 includes suitable logic, circuitry, and/or interfaces to store user-profiles and merchant-profiles of the users and merchants, who have accounts at partner issuer and acquirer banks of the payment network, respectively. A user-profile of a user (such as the user 102) may include registered contact information and account identification information of the user 102. A merchant-profile of a merchant (such as the merchant 106) may include registered contact information and the account identification information of the merchant 106. The first memory 206 stores transaction card details of various transaction cards that are associated with the payment network. The first memory 206 further stores a set of computer readable instructions for hosting a mobile application on the user device 104 or the merchant device 108. Examples of the first memory 206 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the first memory 206 in the payment network server 112, as described herein. In another embodiment, the first memory 206 may be realized in the form of a database server or a cloud storage working in conjunction with the payment network server 112, without departing from the scope of the invention.
[0049] The first transceiver 208 transmits and receives data over the communication network 116 using one or more communication network protocols. The first transceiver 208
14
transmits/receives various requests and messages to/from the user device 104, the acquirer server 110, the issuer server 114, or other entities that are pursuant to one or more standards for the interchange of transaction messages (such as the ISO8583 standard). Examples of the first transceiver 208 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.
[0050] The first authentication manager 212 includes suitable logic and/or interfaces for authenticating various users (such as the user 102), who perform transactions by way of the transaction card. The first authentication manager 212 may authenticate the users by implementing one or more authentication techniques known in the art. The first authentication manager 212 further authorizes the transactions cards that are used by the users for performing transactions. For authorizing a transaction card, the first authentication manager 212 determines whether the transaction card details of the transaction card used for performing the transaction match the transaction card details of any transaction card stored in the first memory 206. The first authentication manager 212 authorizes the transaction card based on a successful match.
[0051] The first transaction manager 214 includes suitable logic and/or interfaces for initiating transactions, based on the authentication and authorization performed by the first authentication manager 212. For example, if the first authentication manager 212 authenticates the user 102 and authorizes the transaction card used by the user 102 to perform the transaction, the first transaction manager 214 initiates the transaction, else the transaction is not initiated. The first transaction manager 214 initiates the transaction by transmitting a transaction request to the acquirer server 110. The functions performed by the first image-processor 204, the first authentication manager 212, and the first transaction manager 214 are explained in conjunction with FIGS. 4, 5A, 5B, and 6.
[0052] FIG. 3 is a block diagram that illustrates the issuer server 114 of the communication environment 100 of FIG. 1, in accordance with an embodiment of the present invention. The issuer server 114 includes a second processor 302, a second image-processor 304, a second memory 306, and a second transceiver 308 that communicate with each other via a second bus 310. The second processor 302 includes a second authentication manager 312 and a second transaction manager 314.
15
[0053] The second processor 302 includes suitable logic, circuitry, and/or interfaces to execute operations for initiating a credit or debit of an amount to/from the user accounts that are maintained at the issuer bank. The requests are received from the user device 104, the acquirer server 110, the payment network server 112, or other entities that are pursuant to one or more standards for the interchange of transaction messages (such as the ISO8583 standard). Examples of the second processor 302 include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, an FPGA, and the like.
[0054] The second image-processor 304 includes suitable logic, circuitry, and/or interfaces to execute operations for processing the images of transaction cards and purchase receipts to facilitate transactions. The second image-processor 304 may process the images to extract information or details from the images. The information or details include merchant details, transaction cards details of the transaction card, the purchase amount, and the like. The second image-processor 304 receives the images from the user device 104. The second image-processor 304 extracts the information or details by performing OCR on the images. The second image-processor 304 may perform OCR on the images by implementing one or more image processing techniques that are known in the art. Examples of the second image-processor 304 include, but are not limited to, an ASIC processor, a DSP, a RISC processor, a CISC processor, an FPGA, and the like.
[0055] The second memory 306 includes suitable logic, circuitry, and/or interfaces to store the user-profiles of the users, who have the user accounts maintained at the issuer bank. The second memory 306 further stores a set of computer readable instructions for hosting the mobile application on the user device 104. Examples of the second memory 306 include a RAM, a ROM, a removable storage drive, an HDD, and the like. It will be apparent to a person skilled in the art that the scope of the invention is not limited to realizing the second memory 306 in the issuer server 114, as described herein. In another embodiment, the second memory 306 may be realized in the form of a database server or a cloud storage working in conjunction with the issuer server 114, without departing from the scope of the invention.
[0056] The second transceiver 308 transmits and receives data over the communication network 116 using one or more communication network protocols. The second transceiver 308 transmits/receives various requests and messages to/from the user device 104, the payment
16
network server 112, or other entities that are pursuant to one or more standards for the interchange of transaction messages (such as the ISO8583 standard). Examples of the second transceiver 308 include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, a USB port, or any other device configured to transmit and receive data.
[0057] The second authentication manager 312 includes suitable logic and/or interfaces for authenticating various users (such as the user 102), who perform transactions from the user accounts maintained at the issuer bank. The second authentication manager 312 may authenticate the users by executing one or more authentication techniques known in the art.
[0058] The second transaction manager 314 includes suitable logic and/or interfaces for initiating transactions, based on the authentication performed by the second authentication manager 312. For example, if the second authentication manager 312 determines that the authentication of the user 102 is successful, the second transaction manager 314 initiates the transaction, else the transaction is not initiated. The functions performed by the second image-processor 304, the second authentication manager 312, and the second transaction manager 314 are explained in conjunction with FIGS. 3, and 5A and 5B.
[0059] FIG. 4 is a process flow diagram 400 that illustrates processing of a transaction, in accordance with an embodiment of the present invention. The process flow diagram 400 illustrates the user device 104, the merchant device 108, the acquirer server 110, the payment network server 112, and the issuer server 114. The user 102 accesses the mobile application or the website of the payment network server 112 to register for a service that enables the user 102 to perform transactions for various purchases based on images of a transaction card and purchase receipts of the purchases.
[0060] The user 102 initiates a registration request to register for the service by accessing the mobile application or the website of the payment network server 112. The registration request includes user login details (such as a user-id and a password) provided by the user 102. The first transceiver 208 receives the registration request (as shown by arrow 402). The first authentication manager 212 retrieves the user login details from the registration request and registers the user 102 (as shown by arrow 404) for the service. In one scenario, when the user-
17
profile of the user 102 is stored in the first memory 206, the first authentication manager 212 updates the user-profile to indicate that the user 102 is registered for the service. In one embodiment, the user 102 may be required to provide sample biometric information along with the registration request. Examples of the sample biometric information may include a sample fingerprint, a sample voiceprint, a sample faceprint, or the like. The first authentication manager 212 further updates the user-profile of the user 102 to include the sample biometric information.
[0061] The user 102 may wish to purchase a product or multiple products from the merchant 106, who does not possess a POS device. For the sake of simplicity of the ongoing discussion and without limiting the scope of the invention, it is assumed that the user 102 purchases a single product. When the user 102 purchases the product, the merchant 106 provides a purchase receipt associated with the purchase to the user 102. The purchase receipt includes a purchase amount of the product, the product details, the merchant details of the merchant 106, and the like. In one embodiment, the user 102 may click an image of the purchase receipt by using the user device 104 and store it in the memory of the user device 104.
[0062] Since the merchant 106 does not possess the POS device, the user 102 accesses the mobile application or the website through the user device 104 for performing a transaction for the purchase of the product. For the sake of simplicity of the ongoing discussion and without limiting the scope of the invention, it is assumed that the user 102 accesses the mobile application. The user 102 logs into the mobile application by providing the user login details, such as the user-id and the password. The mobile application presents a graphical user interface (GUI) on a display (not shown) of the user device 104. The GUI enables the user 102 to upload an image of the transaction card that the user 102 wishes to use for performing the transaction and an image of the purchase receipt provided by the merchant 106. In an exemplary scenario, the GUI presents a first option to the user 102 for uploading the image of the transaction card and a second option to upload the image of the purchase receipt (as shown by arrow 406). In one embodiment, the user 102 retrieves the image of the transaction card (hereinafter referred to as a “first image”) and the image of the purchase receipt (hereinafter referred to as a “second image”) from the memory of the user device 104. The user 102 uploads the retrieved first and second images by selecting the first and second options, respectively. In another embodiment, the first and second options provide a provision to scan the transaction card and the purchase receipt by
18
way of the user device 104, in real-time, for generating the first and second images. In another exemplary scenario, the GUI presents a single option to the user 102 to upload a combined image of the transaction card and the purchase receipt. The uploaded first and second images are communicated to the payment network server 112 by the mobile application over the communication network 116 (as shown by arrow 408).
[0063] The first transceiver 208 receives the first and second images. The first image-processor 204 performs OCR on the first image to extract the transaction card details, such as the unique card number, the expiry date, the card security code, and the card type (as shown by arrow 410). Further, the first image-processor 204 performs OCR on the second image to extract the merchant details (such as the name, the address, the phone number, and the identification number of the merchant 106) and the purchase amount (as shown by arrow 410). In a scenario where the first image-processor 204 determines that the first and second images are distorted, the first image-processor 204, in conjunction with the first transceiver 208, prompts the user 102 to upload the first and second images again.
[0064] The first authentication manager 212 utilizes the identification number of the merchant 106 to retrieve merchant account details (as shown by arrow 412) from a database that is maintained and stored by the payment network server 112 in at least one of the first memory 206 or on a cloud server. In another scenario, the first authentication manager 212 retrieves the merchant account details from another server that is maintained by a third-party data management organization. The first authentication manager 212 further authorizes the transaction card based on the extracted transaction card details. The first authentication manager 212 initiates an authentication of the user 102 based on the transaction card details (as shown by arrow 414). To authenticate the user 102, the first authentication manager 212, in conjunction with the first transceiver 208, communicates an authentication request to the user device 104 (as shown by arrow 416) of the user 102. The authentication request may be communicated to the user device 104 by way of an SMS on the phone number of the user 102, an e-mail on the e-mail ID of the user 102, an IVR call on the phone number of the user 102, a video call on the phone number of the user 102, a push notification through the mobile application, or the like. The user 102 may respond to the authentication request by providing an authentication response to the payment network server 112 (as shown by arrow 418). In one embodiment, the user 102 may be
19
required to provide biometric information as the authentication response. For example, the user 102 provides a fingerprint in response to the authentication request. In another example, the user 102 provides a voiceprint by way of the IVR call or a faceprint by way of the video call, as the authentication response.
[0065] The first transceiver 208 receives the authentication response provided by the user 102. Based on the authentication response, the first authentication manager 212 authenticates the user 102. To authenticate the user 102, the first authentication manager 212 determines whether the authentication response provided by the user 102 is valid or invalid. For example, the first authentication manager 212 may compare the fingerprint provided by the user 102 with the sample fingerprint that is stored in the user-profile of the user 102 to authenticate the user 102. In a scenario where both the fingerprints match, the first authentication manager 212 determines that the authentication response is valid, else the first authentication manager 212 determines that the authentication response is invalid. In a scenario, when the authentication response provided by the user 102 is valid, the first authentication manager 212 determines that the authentication of the user 102 is successful. In another scenario, when the authentication response provided by the user 102 is invalid, the first authentication manager 212 determines that the authentication of the user 102 is unsuccessful. The first authentication manager 212 may further inform a result of the authentication to the user 102.
[0066] The first transaction manager 214 initiates the transaction when the authentication of the user 102 is successful (as shown by arrow 420). For initiating the transaction, the first transaction manager 214, in conjunction with the first transceiver 208, submits a transaction request to the acquirer server 110 (as shown by arrow 422). The transaction request includes the purchase amount of the transaction, the merchant account details, and the account details of the user account of the user 102. Based on the transaction request, the acquirer server 110 transmits a transaction approval request (as shown by arrow 424) to the payment network server 112. The acquirer server 110 transmits the transaction approval request to ensure that the user account has sufficient funds to cover the purchase amount. The transaction approval request is pursuant to one or more standards for the interchange of transaction messages (such as the ISO8583 standard) and includes the purchase amount, the merchant account details, and the account details of the user account. The first transceiver 208 receives the transaction approval request.
20
The first transaction manager 214, in conjunction with the first transceiver 208, transmits the transaction approval request to the issuer server 114 (as shown by arrow 426) of the issuer bank that had issued the transaction card to the user 102.
[0067] The second transceiver 308 receives the transaction approval request. The second transaction manager 314 identifies the user account linked to the transaction card based on the account details included in the transaction approval request. Based on the transaction approval request, the second transaction manager 314 then determines whether the user account has sufficient funds to cover the purchase amount. In a scenario, when the user account does not have sufficient funds to cover the purchase amount, the second transaction manager 314 declines the transaction. In another scenario, when the user account has sufficient funds to cover the purchase amount, the second transaction manager 314 approves the transaction. In one embodiment, the second transaction manager 314, in conjunction with the second authentication manager 312, may verify whether the user 102 is authorized to perform the transaction from the user account. The second authentication manager 312 performs the verification of the user 102 based on one or more techniques known to a person skilled in the art. The second transaction manager 314 thus debits the purchase amount from the user account (as shown by arrow 428) based on the transaction approval request.
[0068] The second transaction manager 314, in conjunction with the second transceiver 308, transmits an approval notification to the payment network server 112 (as shown by arrow 430). The first transceiver 208 receives the approval notification. The approval notification indicates that the purchase amount is debited from the user account. The first transaction manager 214, in conjunction with the first transceiver 208, transmits the approval notification to the acquirer server 110 (as shown by arrow 432). Based on the approval notification, the acquirer server 110 credits the purchase amount in the merchant account (as shown by arrow 434). The acquirer server 110 generates a transaction ID (as shown by arrow 436) after crediting the merchant account with the purchase amount. The transaction ID is a unique identification number for the transaction performed by the user 102. The acquirer server 110 communicates transaction details of the transaction that includes the transaction ID by way of a transaction notification to the merchant device 108 and the payment network server 112 (as shown by arrow 438). The transaction details further include a date of the transaction, a time of the transaction,
21
and the purchase amount. The transaction notification that is sent to the merchant device 108 further includes an account balance of the merchant account that indicates the crediting of the purchase amount. Based on the transaction notification, the first transaction manager 214, in conjunction with the first transceiver 208, communicates a transaction approved notification to the user device 104 (as shown by arrow 440). The transaction approved notification includes the transaction details and an account balance of the user account that indicates the debiting of the purchase amount from the user account. The user 102 may utilize the transaction ID to communicate with the merchant 106 for any future grievances related to the purchase of the product.
[0069] In yet another scenario, the payment network server 112 provides an option to the user 102 for uploading images of multiple transaction cards, in an example two transaction cards, for paying for the purchase in parts. In an example, the user 102 wants to purchase a product worth $500 from the merchant 106. Thus, the user 102 provides images of first and second transaction cards that are linked to the payment network server 112. The first and second transaction cards may be linked to a single account of the user 102 or to multiple accounts of the user 102. Thus, the payment network server 112 retrieves the transaction card details from each of the first and second transaction cards by way of image processing techniques and sends the transaction request to the acquirer server 110. The acquirer server 110 may transmit a single approval request to the payment network server 112 if the first and second transaction cards are linked to a single account of the user 102 or transmit two approval requests if the first and second transaction cards are linked to two accounts of the user 102. The payment network server 112 thus receives the approval request/s from the acquirer server 110 and routes the approval request/s to the corresponding issuer banks for further processing of the transaction.
[0070] FIGS. 5A and 5B collectively represent a process flow diagram 500 that illustrates processing of a transaction, in accordance with another embodiment of the present invention. The process flow diagram 500 illustrates the user device 104, the merchant device 108, the acquirer server 110, the payment network server 112, and the issuer server 114. The merchant 106 may not possess any POS device. Thus, the merchant 106 accesses the mobile application or the website of the payment network server 112 to register for a service that enables the merchant 106 to carry out transactions for the purchases performed by users (such as the user
22
102) based on the images of the transaction cards of the users and the purchase receipts of the purchases.
[0071] The merchant 106 initiates the registration request to register for the service by accessing the mobile application or the website of the payment network server 112. The registration request includes merchant login details (such as a merchant-id and a password) and account details of the merchant 106. The first transceiver 208 receives the merchant login details and merchant account details by way of the registration request (as shown by arrow 502). In one embodiment, the merchant account details include a transaction card number linked to an account of the merchant 106, a card security code of the transaction card of the merchant 106, the identification number of the merchant 106, and the like. In another embodiment, the merchant account details include an account number of the merchant account of the merchant 106, the identification number of the merchant 106, and the like. The first authentication manager 212 verifies the transaction card number and the card security code by retrieving the merchant account details of the merchant 106 that are stored in the first memory 206. On identifying a match between the merchant account details provided by the merchant 106 and the merchant account details that may be stored in the first memory 206 or a database maintained by a third-party data management organization, the first authentication manager 212 registers the merchant 106 (as shown by arrow 504). The first authentication manager 212 further stores the merchant login details and the identification number of the merchant 106 in the first memory 206. The first authentication manager 212, in conjunction with the first transceiver 208, further notifies the merchant 106 that the registration is successful.
[0072] In one scenario, the user 102 may want to purchase a product from the merchant 106. The merchant 106 generates the purchase receipt of the product. Since the merchant 106 does not possess any POS device for carrying out the transaction for the purchase, the merchant 106 accesses the mobile application or the website through the merchant device 108 for initiating the transaction. For the sake of simplicity of the ongoing discussion and without limiting the scope of the invention, it is assumed that the merchant 106 accesses the mobile application. The merchant 106 logs into the mobile application by providing the merchant login details. The mobile application presents a GUI to the merchant 106 for uploading the image of a transaction card (i.e., the first image) which the user 102 possesses and the image of the purchase receipt
23
(i.e., the second image). In one embodiment, the GUI provides a provision to scan the transaction card and the purchase receipt by way of the merchant device 108 in real-time, for generating the first and second images, respectively. In another embodiment, the GUI provides a provision to the merchant 106 to click the first and second images. The merchant 106 thus uploads the first and second images on the GUI (as shown by arrow 506).
[0073] The first image-processor 204 receives the first and second images (as shown by arrow 508). On receiving the first and second images, the first image-processor 204 performs OCR on the first and second images for extracting transaction card details from the first image, and the merchant details and the purchase amount from the second image (as shown by arrow 510). In a scenario where the first image-processor 204 determines that the first and second images are distorted, the first image-processor 204, in conjunction with the first transceiver 208, prompts the merchant 106 through the GUI to upload the first and second images for a second time.
[0074] The first authentication manager 212 utilizes the merchant details extracted from the second image for retrieving the merchant account details of the merchant account (as shown by arrow 512) from at least one of the first memory 206, a cloud server, or a third-party data management organization. The first authentication manager 212 further authorizes the transaction card based on the transaction card details extracted from the first image.
[0075] The first authentication manager 212 initiates the authentication of the user 102 based on a phone number or an e-mail id that is included in the user-profile of the user 102 (as shown by arrow 514). In a scenario, the phone number and the e-mail id may be linked to the user device 104 of the user 102. To authenticate the user 102, the first authentication manager 212, in conjunction with the first transceiver 208, transmits a confirmation request to the user device 104 for receiving a confirmation to initiate the transaction (as shown by arrow 516). In other words, the first authentication manager 212, in conjunction with the first transceiver 208, communicates the confirmation request to the user 102. The confirmation request may be received by the user device 104 by way of an SMS on the phone number of the user 102, an IVR call on the phone number of the user 102, a video call on the phone number of the user 102, an e-mail on the e-mail id, or the like. The user 102 provides a confirmation response to the confirmation request (as shown by arrow 518). The confirmation response may be a binary
24
response (such as a ‘Yes’ or ‘No’, ‘1’ or ‘0’, ‘True’ or ‘False’, or the like) provided by the user 102. In a scenario, if the user 102 wants to initiate the transaction, the user 102 provides a first response as the confirmation response. The first response includes at least one of ‘Yes’, ‘1’, or ‘True’. In another scenario, if the user 102 does not want to initiate the transaction, the user 102 provides a second response as the confirmation response. The second response includes at least one of ‘No’, ‘0’, or ‘False’.
[0076] The first transceiver 208 receives the confirmation response. In an embodiment, the confirmation response is the first response. The first authentication manager 212, in conjunction with the first transceiver 208 transmits the authentication request to the user 102 based on the first response (as shown by arrow 520). The user 102 may respond to the authentication request by providing the authentication response (as shown by arrow 522).
[0077] The first transceiver 208 receives the authentication response. Based on the authentication response, the first authentication manager 212 authenticates the user 102. The first authentication manager 212 further generates a first transaction code and communicates the first transaction code to the user 102 by transmitting the first transaction code to the user device 104 by way of the first transceiver 208 (as shown by arrow 524). The first authentication manager 212 further transmits a first code request to the merchant device 108 (as shown by arrow 526) to provide the first transaction code for initiating the transaction. The merchant 106 may receive the first code request by way of an SMS on a phone number of the merchant 106, an e-mail on the e-mail ID of the merchant 106, or an IVR call on the phone number of the merchant 106, or a push notification presented through the mobile application. The user 102 provides the first transaction code to the merchant 106. In one embodiment, the user 102 may use the user device 104 to provide the first transaction code to the merchant 106 by way of an SMS on a phone number of the merchant 106, an e-mail on the e-mail ID of the merchant 106, or an IVR call on the phone number of the merchant 106. In another embodiment, the user 102 may verbally provide the first transaction code to the merchant 106. The merchant 106 receives the first transaction code and provides a second transaction code as a response to the first code request to the payment network server 112 (as shown by arrow 528).
[0078] The first transceiver 208 receives the second transaction code. The first authentication manager 212 compares the second transaction code with the first transaction code
25
(as shown by arrow 530) that was communicated to the user 102. The first authentication manager 212 initiates the transaction when the second transaction code matches the first transaction code. The first authentication manager 212 does not initiate the transaction when the second transaction code does not match the first transaction code. The first authentication manager 212 further communicates a result of the comparison to the merchant device 108 by way of a comparison notification (as shown by arrow 532). In one embodiment, the second transaction code matches the first transaction code, and hence the first transaction manager 214 initiates the transaction (as shown by arrow 534).
[0079] To initiate the transaction, the first transaction manager 214, in conjunction with the first transceiver 208, submits the transaction request to the acquirer server 110 (as shown by arrow 536). The acquirer server 110 receives the transaction request and generates the transaction approval request. The acquirer server 110 further transmits the transaction approval request to the payment network server 112 (as shown by arrow 538). The first transceiver 208 receives the transaction approval request and transmits the transaction approval request to the issuer server 114 (as shown by arrow 540) for determining whether the user account of the user 102 has sufficient funds to cover the purchase amount. The second transceiver 308 receives the transaction approval request. Based on the transaction approval request, the second transaction manager 314 determines whether the user account has sufficient funds to cover the purchase amount. The second transaction manager 314 debits the purchase amount from the user account (as shown by arrow 542) when the second transaction manager 314 determines that the user account has sufficient funds to cover the purchase amount.
[0080] The second transaction manager 314, in conjunction with the second transceiver 308, transmits the approval notification to the payment network server 112 (as shown by arrow 544). The first transceiver 208 further transmits the approval notification to the acquirer server 110 (as shown by arrow 546). On receiving the approval notification, the acquirer server 110 credits the purchase amount in the merchant account (as shown by arrow 548). The acquirer server 110 further generates the transaction ID after crediting the purchase amount (as shown by arrow 550). The acquirer server 110 communicates the transaction details that include the transaction ID by way of the transaction notification to the merchant device 108 and the payment network server 112 (as shown by arrow 552). The transaction details further include a date of the
26
transaction, a time of the transaction, and the purchase amount. The transaction notification that is sent to the merchant device 108 further includes an account balance of the merchant account that indicates the crediting of the purchase amount. Based on the transaction notification, the first transaction manager 214, in conjunction with the first transceiver 208, communicates the transaction approved notification to the user device 104 (as shown by arrow 554). The transaction approved notification includes the transaction details and an account balance of the user account that indicates the debiting of the purchase amount from the user account.
[0081] In another scenario, the merchant 106 may access the mobile application or the website of the acquirer server 110 to register for the service that enables the merchant 106 to carry out transactions for the purchases performed by the users (such as the user 102) based on the images of the transaction cards of the users and the purchase receipts of the purchases. In such a scenario, the acquirer server 110 facilitates the processing of the transaction as described in the foregoing in conjunction with FIGS. 5A and 5B.
[0082] FIG. 6 is a process flow diagram 600 that illustrates processing of a transaction, in accordance with yet another embodiment of the present invention. The process flow diagram 600 illustrates the user device 104, the merchant device 108, the acquirer server 110, the payment network server 112, and the issuer server 114. The user 102 accesses the mobile application or the website of the issuer server 114 to register for a service that enables the user 102 to perform transactions for various purchases based on images of a transaction card and purchase receipts of the purchases. The user 102 initiates the registration request by accessing the mobile application or the website of the issuer server 114. The second transceiver 308 receives the registration request (as shown by arrow 602). The second authentication manager 312 retrieves the user login details from the registration request and registers the user 102 (as shown by arrow 604) for the service. The second authentication manager 312 further updates the user-profile of the user 102 that is stored in the second memory 306 based on the registration.
[0083] The user 102 purchases a product from the merchant 106, who does not possess a POS device. When the user 102 purchases the product, the merchant 106 generates the purchase receipt of the product and provides it to the user 102. Since the merchant 106 does not possess the POS device, the user 102 accesses the mobile application or the website through the user device 104 for initiating the transaction for the purchase of the product. For the sake of
27
simplicity of the ongoing discussion and without limiting the scope of the invention, it is assumed that the user 102 accesses the mobile application. The user 102 logs into the mobile application by providing the user login details. The mobile application presents the GUI to the user 102, which enables the user 102 to upload the first and second images (as shown by arrow 606). The uploaded first and second images are communicated to the issuer server 114 by the mobile application over the communication network 116 (as shown by arrow 608).
[0084] The second transceiver 308 receives the first and second images. The second image-processor 304 performs OCR on the first image to extract the transaction card details of the transaction card (as shown by arrow 610). The second image-processor 304 further performs OCR on the second image to extract the merchant details and the purchase amount from the second image (as shown by arrow 610). In one embodiment, the issuer server 114 provides the merchant details to the payment network server 112 (as shown by arrow 612). In another embodiment, the issuer server 114 extracts the merchant account details based on the merchant details from a database that is maintained by a third-party organization. In yet another embodiment, the issuer server 114 extracts the merchant account details from the second memory 306.
[0085] The first transceiver 208 receives the merchant details. The first authentication manager 212 utilizes the identification number in the merchant details to retrieve the merchant account details (as shown by arrow 614) from a database that is maintained and stored by the payment network server 112. On retrieving the merchant account details, the first authentication manager 212 transmits a retrieval notification to the issuer server 114 (as shown by arrow 616).
[0086] The second transceiver 308 receives the retrieval notification. The second transaction manager 314 initiates the authentication (as shown by arrow 618) of the user 102 based on the retrieval notification. The second transaction manager 314, in conjunction with the second transceiver 308, transmits an authentication initiation request to the payment network server 112 (as shown by arrow 620). The first transceiver 208 receives the authentication initiation request. The first authentication manager 212, in conjunction with the first transceiver 208, communicates the authentication request to the user device 104 (as shown by arrow 622) of the user 102 to authenticate the user 102 based on the extracted transaction card details. The user
28
102 may respond to the authentication request by providing the authentication response to the payment network server 112 by way of the user device 104 (as shown by arrow 624).
[0087] The first transceiver 208 receives the authentication response. Based on the authentication response, the first authentication manager 212 authenticates the user 102. The first authentication manager 212, in conjunction with the first transceiver 208, communicates a result of the authentication of the user 102 to the issuer server 114 by way of an authentication notification (as shown by arrow 626). The second transceiver 308 receives the authentication notification. In an alternate embodiment, the issuer server 114 may authenticate the user 102 based on the authentication request.
[0088] The second transaction manager 314 initiates the transaction when the authentication of the user 102 is successful (as shown by arrow 628). The second transaction manager 314, in conjunction with the second transceiver 308, communicates a transaction initiation request to the payment network server 112 (as shown by arrow 630). The first transceiver 208 receives the transaction initiation request. Based on the transaction initiation request, the first transaction manager 214, in conjunction with the first transceiver 208, submits the transaction request to the acquirer server 110 (as shown by arrow 632). Based on the transaction request, the acquirer server 110 transmits the transaction approval request (as shown by arrow 634) to the payment network server 112. The first transceiver 208 receives the transaction approval request. The first transaction manager 214, in conjunction with the first transceiver 208, transmits the transaction approval request to the issuer server 114 (as shown by arrow 636). The second transceiver 308 receives the transaction approval request from the payment network server 112. The second transaction manager 314 debits the purchase amount from the user account (as shown by arrow 638) when the second transaction manager 314 determines that the user account has sufficient funds to cover the purchase amount.
[0089] The second transaction manager 314, in conjunction with the second transceiver 308 transmits the approval notification to the payment network server 112 (as shown by arrow 640). The first transceiver 208 receives the approval notification. The first transaction manager 214, in conjunction with the first transceiver 208, transmits the approval notification to the acquirer server 110 (as shown by arrow 642). Based on the approval notification, the acquirer server 110 thus credits the purchase amount in the merchant account (as shown by arrow 644).
29
The acquirer server 110 generates the transaction ID (as shown by arrow 646) after crediting the account of the merchant 106 with the purchase amount. The acquirer server 110 communicates the transaction details that includes the transaction ID by way of the transaction notification to the merchant device 108 and the payment network server 112 (as shown by arrow 648). Based on the transaction notification, the first transaction manager 214, in conjunction with the first transceiver 208, communicates the transaction approved notification to the user device 104 (as shown by arrow 650).
[0090] FIGS. 7A – 7C, collectively represent a flowchart 700 that illustrates a method for processing a transaction, in accordance with an embodiment of the present invention. The user 102 accesses the mobile application or the website of the payment network server 112 to register for the service that enables the user 102 to perform transactions for various purchases based on images of a transaction card and purchase receipts of the purchases. At step 702, the payment network server 112 receives the registration request from the user 102. At step 704, the payment network server 112 retrieves the user login details from the registration request and registers the user 102 for the service. The user 102 may wish to purchase a product or multiple products from the merchant 106, who does not possess a POS device. When the user 102 purchases the product, the merchant 106 provides the purchase receipt of the product to the user 102. Since the merchant 106 does not possess the POS device, the user 102 accesses the mobile application or the website of the payment network server 112 through the user device 104 for initiating a transaction for the purchase of the product. For the sake of simplicity of the ongoing discussion, it is assumed that the user 102 accesses the mobile application of the payment network server 112 without deviating from the scope of the invention. The user 102 logs into the mobile application of the payment network server 112 by providing the user login details. The user 102 uploads the first and second images (i.e., images of the transaction card and the purchase receipt, respectively) on the GUI presented by the mobile application.
[0091] At step 706, the payment network server 112 receives the first and second images provided by the user 102. At step 708, the payment network server 112 extracts transaction card details of the transaction card from the first image by performing OCR on the first image. The payment network server 112 further extracts the merchant details and the purchase amount from the second image by performing OCR on the second image. At step 710, the payment network
30
server 112 retrieves merchant account details from the database or the first memory 206 by utilizing the identification number included in the extracted merchant details.
[0092] At step 712, the payment network server 112 initiates the authentication of the user 102 based on the transaction card details. At step 714, the payment network server 112 communicates the authentication request to the user device 104 of the user 102. At step 716, the payment network server 112 receives the authentication response provided by the user 102. At step 718, the payment network server 112 determines whether the user details (such as the biometric information) in the authentication response match the user details (such as the sample biometric information) in the user-profile of the user 102. If at step 718, the payment network server 112 determines that the user details in the authentication response do not match the user details in the user-profile of the user 102, step 720 is executed. At step 720, the payment network server 112 declines the transaction and transmits a transaction denied notification to the user device 104. However, if at step 718, the payment network server 112 determines that the user details in the authentication response match the user details in the user-profile of the user 102, the payment network server 112 authenticates the user 102 and step 722 is executed.
[0093] At step 722, the payment network server 112 initiates the transaction, when the authentication of the user 102 is successful. At step 724, the payment network server 112 submits the transaction request to the acquirer server 110. Based on the transaction request, the acquirer server 110 transmits the transaction approval request to the payment network server 112. At step 726, the payment network server 112 receives the transaction approval request from the acquirer server 110. At step 728, the payment network server 112 transmits the transaction approval request to the issuer server 114. At step 730, the payment network server 112 receives the transaction approval notification from the issuer server 114, if the issuer server 114 approves the transaction. At step 732, the payment network server 112 transmits the transaction approval notification to the acquirer server 110. The acquirer server 110 credits the purchase amount in the merchant account and generates the transaction ID. At step 734, the payment network server 112 receives the transaction notification that includes the transaction details of the transaction from the acquirer server 110. At step 736, the payment network server 112 communicates the transaction approved notification to the user device 104 to indicate that the transaction is completed.
31
[0094] FIGS. 8A – 8D, collectively represent a flowchart 800 that illustrates a method for processing a transaction, in accordance with another embodiment of the present invention. The merchant 106 accesses the mobile application or the website of the payment network server 112 to register for the service that enables the merchant 106 to carry out transactions for the user 102 based on images of the transaction card and the purchase receipts of the purchases. At step 802, the payment network server 112 receives the registration request from the merchant 106. The merchant 106 initiates the registration request by accessing the mobile application or the website of the payment network server 112. At step 804, the payment network server 112 registers the merchant 106 based on the merchant login details in the registration request.
[0095] The user 102 purchases a product from the merchant 106, who does not possess a POS device. The merchant 106 generates the purchase receipt of the product. The merchant 106 uploads the first and second images (i.e., the images of the transaction card the user 102 wants to use for the transaction and the purchase receipt) by using the GUI presented by the payment network server 112. At step 806, the payment network server 112 receives the first and second images (i.e., images of transaction card and purchase receipt) from the merchant 106. At step 808, the payment network server 112 extracts transaction card details from the first image, and the merchant details and the purchase amount from the second image. At step 810, the payment network server 112 retrieves the merchant account details based on the extracted merchant details and the user-profile of the user 102 based on the extracted transaction card details.
[0096] At step 812, the payment network server 112 initiates the authentication of the user 102. At step 814, the payment network server 112 transmits the confirmation request to the user device 104. At step 816, the payment network server 112 receives the confirmation response provided by the user 102 in response to the confirmation request. At step 818, the payment network server 112 determines whether the confirmation response indicates initiating of the transaction. If at step 818, the payment network server 112 determines that the confirmation response does not indicate initiating of the transaction, step 820 is executed. At step 820, the payment network server 112 transmits the transaction denied notification to the merchant device 108. However, if at step 818, the payment network server 112 determines that the confirmation response indicates initiating of the transaction, step 822 is executed. At step 822, the payment network server 112 transmits the authentication request to the user 102.
32
[0097] At step 824, the payment network server 112 receives the authentication response from the user 102 in response to the authentication request. At step 826, the payment network server 112 determines whether the authentication response matches the authentication response that is stored in the user-profile of the user 102. If at step 826, the payment network server 112 determines that the authentication response does not match the authentication response that is stored in the user-profile, step 820 is executed. However, if at step 826, the payment network server 112 determines that the authentication response matches the authentication response in the user-profile, step 828 is executed. At step 828, the payment network server 112 communicates the first transaction code to the user 102. At step 830, the payment network server 112 transmits the first code request to the merchant 106 to provide the first transaction code.
[0098] At step 832, the payment network server 112 receives the second transaction code provided by the merchant 106 in response to the first code request. At step 834, the payment network server 112 determines whether the second transaction code matches the first transaction code. If at step 834, the payment network server 112 determines that the second transaction code does not match the first transaction code, the payment network server 112 does not initiate the transaction and step 820 is executed. However, if at step 834, the payment network server 112 determines that the second transaction code matches the first transaction code, step 836 is executed. At step 836, the payment network server 112 transmits the comparison notification to the merchant device 108. At step 838, the payment network server 112 initiates the transaction. At step 840, the payment network server 112 submits the transaction request to the acquirer server 110. At step 842, the payment network server 112 receives the transaction approval request from the acquirer server 110 in response to the transaction request. At step 844, the payment network server 112 transmits the transaction approval request to the issuer server 114.
[0099] At step 846, the payment network server 112 receives the transaction approval notification from the issuer server 114. At step 848, the payment network server 112 further transmits the transaction approval notification to the acquirer server 110. At step 850, the payment network server 112 receives the transaction details by way of the transaction notification. At step 852, the payment network server 112 transmits the transaction approved notification to the merchant device 108 to indicate that the transaction is completed.
33
[00100] FIG. 9 is a high-level flow chart 900 that illustrates a method for processing transactions, in accordance with an embodiment of the present invention. In one embodiment, the user 102 accesses the mobile application or the website of the payment network server 112 or the issuer server 114 to register for a service that enables the user 102 to perform transactions for various purchases based on the images of the transaction card and the purchase receipts of the purchases. In another embodiment, the merchant 106 accesses the mobile application or the website of the payment network server 112 or the acquirer server 110 to register for a service that enables the merchant 106 to carry out transactions for the user 102 based on the images of the transaction card of the user 102 and the purchase receipts of the purchases.
[00101] At step 902, the payment network server 112 receives the first and second images (i.e., images of the transaction card and the purchase receipt, respectively) provided by one of the user 102 or the merchant 106. At step 904, the payment network server 112 extracts the transaction card details of the transaction card from the first image and the merchant details of the merchant 106 from the second image. At step 906, the payment network server 112 initiates the authentication of the user 102 based on the transaction card details. At step 908, the payment network server 112 initiates the transaction associated with the purchase based on the authentication of the user 102. The purchase amount of the purchase is debited from the user account linked to the transaction card and credited to the merchant account associated with the extracted merchant details, when the transaction is approved.
[00102] It will be apparent to a person skilled in the art that the issuer server 114 performs the steps 904 – 908 when the issuer server 114 receives the first and second images from the user 102. It will further be apparent to a person skilled in the art that the acquirer server 110 performs the steps 904 – 908 when the acquirer server 110 receives the first and second images from the merchant 106.
[00103] FIG. 10 is a high-level flow chart 1000 that illustrates a method for processing transactions, in accordance with an embodiment of the present invention. In one embodiment, the user 102 accesses the mobile application or the website of the payment network server 112 or the issuer server 114 to register for a service that enables the user 102 to perform transactions for various purchases based on the images of the transaction card and the purchase receipts of the purchases. In another embodiment, the merchant 106 accesses the mobile application or the
34
website of the payment network server 112 or the acquirer server 110 to register for a service that enables the merchant 106 to carry out transactions for the user 102 based on the images of the transaction card and the purchase receipts of the purchases performed by the user 102.
[00104] At step 1002, the payment network server 112 presents a GUI on the user device 104 or the merchant device 108. The GUI displays one or more options for uploading the first and second images. At step 1004, the payment network server 112 receives the first and second images provided by one of the user 102 or the merchant 106. At step 1006, the payment network server 112 extracts the transaction card details of the transaction card from the first image and the merchant details of the merchant 106 from the second image. At step 1008, the payment network server 112 initiates the authentication of the user 102 based on the transaction card details. At step 1010, the payment network server 112 initiates the transaction associated with the purchase based on the authentication of the user 102. The purchase amount of the purchase is debited from the user account linked to the transaction card and credited to the merchant account associated with the extracted merchant details, when the transaction is approved.
[00105] It will be apparent to a person skilled in the art that the issuer server 114 performs the steps 1004 – 1010 when the issuer server 114 receives the first and second images from the user 102. It will further be apparent to a person skilled in the art that the acquirer server 110 performs the steps 1004 – 1010 when the acquirer server 110 receives the first and second images from the merchant 106.
[00106] The method and system of the present invention eliminate the need for merchants to possess a POS device, thus providing a convenient mechanism to the merchants for carrying out transactions and earning the purchase amount. The invention is advantageous for users as they can perform transactions from their preferred merchants without the need for carrying cash or having the merchants possess the POS device. The method and system further offer a facility to both the users and merchants by registering for the service to process transactions.
[00107] FIG. 11 is a block diagram that illustrates a system architecture of a computer system 1100, in accordance with an embodiment of the present invention. An embodiment of present invention, or portions thereof, may be implemented as computer readable code on the computer system 1100. In one example, the user device 104, the merchant device 108, the
35
acquirer server 110, the payment network server 112, and the issuer server 114, of FIG. 1 may be implemented in the computer system 1100 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of FIGS. 7 – 10.
[00108] The computer system 1100 includes a main processor 1102 that may be a special purpose or a general-purpose processing device. The main processor 1102 may be a single processor, multiple processors, or combinations thereof. The main processor 1102 may have one or more processor “cores.” In one example, the main processor 1102 is an octa-core processor. Further, the main processor 1102 may be connected to a communication infrastructure 1104, such as a bus, message queue, the first bus 210, the second bus 310, multi-core message-passing scheme, and the like. The computer system 1100 further includes a main memory 1106 and a secondary memory 1108. Examples of the main memory 1106 may include RAM, ROM, dynamic RAM (DRAM), and the like. The secondary memory 1108 may include a hard disk drive 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. Further, the removable storage drive may read from and/or write to a removable storage device in a manner known in the art. In one example, if the removable storage drive is a compact disc drive, the removable storage device may be a compact disc. In an embodiment, the removable storage unit may be a non-transitory computer readable recording media.
[00109] The computer system 1100 further includes an input/output (I/O) interface 1110 and a communication interface 1112. The I/O interface 1110 includes various input and output devices that are configured to communicate with the main processor 1102. 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 1112 may allow data to be transferred between the computer system 1100 and various devices that are communicatively coupled to the computer system 1100. Examples of the communication interface 1112 may include a modem, a network interface, i.e., an Ethernet card, a communications port, and the like. Data transferred via the
36
communication interface 1112 corresponds to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art. The signals may travel via a communication channel (not shown) which transmits the signals to devices that are communicatively coupled to the computer system 1100. Examples of the communication channel include, but are not limited to, a cable, fiber optics, a phone line, a cellular phone link, or a radio frequency link.
[00110] Computer program medium and computer usable medium may refer to a non-transitory computer readable medium, such as the main memory 1106 and the secondary memory 1108, which may be a semiconductor memory such as a DRAM. The computer program medium may provide data that enables the computer system 1100 to implement the methods illustrated in FIGS. 7 – 10. In an embodiment, the present invention is implemented using a computer implemented application, the computer implemented application may be stored in a computer program product and loaded into the computer system 1100 using the removable storage drive or the hard disc drive in the secondary memory 1108, the I/O interface 1110, or the communication interface 1112.
[00111] A person having ordinary skill in the art will appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device. For instance, at least one processor such as the main processor 1102 and a memory such as the main memory 1106 and the secondary memory 1108 implements the above described embodiments. Further, the operations may be described as a sequential process, however some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multiprocessor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
[00112] Techniques consistent with the present invention provide, among other features, systems and methods for processing transactions. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have
37
been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the invention to the precise form disclosed.
[00113] 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.
[00114] While various embodiments of the present invention have been illustrated and described, it will be clear that the present invention 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 invention, as described in the claims.

WE CLAIMS

1. A transaction processing method, comprising:
receiving, by a server, a first image of a transaction card and a second image of a purchase receipt of a purchase made by a user at a merchant;
extracting, by the server, transaction card details of the transaction card from the first image and merchant details of the merchant from the second image;
initiating, by the server, an authentication of the user based on the transaction card details; and
initiating, by the server, a transaction associated with the purchase based on the authentication of the user, wherein a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details, when the transaction is approved.
2. The transaction processing method of claim 1, further comprising:
retrieving, by the server, merchant account details of the merchant from a database based on the merchant details.
3. The transaction processing method of claim 1 or claim 2, wherein the server extracts the transaction card details from the first image, and the merchant details and the purchase amount from the second image by means of optical character recognition.
4. The transaction processing method of any one of claims 1 to 3, wherein the merchant details include a name of the merchant, an address of the merchant, a phone number of the merchant, and an identification number of the merchant.
5. The transaction processing method of any one of claims 1 to 4, further comprising:
receiving, by the server, transaction details when the transaction is approved, wherein the transaction details include a transaction identifier (ID), a transaction date, transaction time, and the purchase amount; and
communicating, by the server, the transaction details to the user.
39
6. The transaction processing method of any one of claims 1 to 5, further comprising:
receiving, by the server, a registration request from the merchant, wherein the registration request includes the merchant account details of the merchant; and
registering, by the server, the merchant based on the registration request, wherein the transaction is initiated for the purchase when the first and second images are provided by the registered merchant.
7. The transaction processing method of any one of claims 1 to 5, further comprising:
communicating, by the server, a confirmation request to the user for receiving a confirmation to initiate the transaction; and
receiving, by the server, a confirmation response from the user to initiate the transaction based on the confirmation request.
8. The transaction processing method of any one of claims 1 to 5, further comprising:
generating, by the server, a first transaction code for initiating the transaction;
communicating, by the server, the first transaction code to the user;
receiving, by the server, a second transaction code from the merchant, wherein the user provides the second transaction code to the merchant based on the first transaction code; and
determining, by the server, whether the second transaction code matches the first transaction code, wherein the transaction is initiated when the second transaction code matches the first transaction code.
9. The transaction processing method of any one of claims 1 to 5, further comprising:
receiving, by the server, a registration request from the user, wherein the registration request includes details of the user; and
registering, by the server, the user based on the registration request, wherein the transaction is initiated for the purchase when the first and second images are provided by the registered user.
10. A transaction processing system, comprising:
a payment network server comprising:
40
circuitry configured to:
receive a first image of a transaction card and a second image of a purchase receipt of a purchase made by a user at a merchant;
extract transaction card details of the transaction card from the first image and merchant details of the merchant from the second image;
initiate an authentication of the user based on the transaction card details; and
initiate a transaction associated with the purchase, based on the authentication of the user, wherein a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details, when the transaction is approved.
11. The transaction processing system of claim 10, wherein the circuitry is further configured to:
retrieve merchant account details of the merchant from a database based on the merchant details.
12. The transaction processing system of claim 10 or claim 11, wherein the circuitry extracts the transaction card details from the first image, and the merchant details and the purchase amount from the second image by means of optical character recognition.
13. The transaction processing system of any one of claims 10 to 12, wherein the merchant details include a name of the merchant, an address of the merchant, a phone number of the merchant, and an identification number of the merchant.
14. The transaction processing system of any one of claims 10 to 13, wherein the circuitry is further configured to:
receive transaction details when the transaction is approved, wherein the transaction details include a transaction identifier (ID), a transaction date, transaction time, and the purchase amount of the transaction; and
transmit the transaction details to the user.
41
15. The transaction processing system of any one of claims 10 to 14, wherein the circuitry is further configured to:
receive a registration request from the merchant, wherein the registration request includes the merchant account details of the merchant; and
register the merchant based on the registration request, wherein the transaction is initiated for the purchase when the first and second images are provided by the registered merchant.
16. The transaction processing system of any one of claims 10 to 14, wherein the circuitry is further configured to:
communicate a confirmation request to the user for receiving a confirmation to initiate the transaction; and
receive a confirmation response from the user to initiate the transaction based on the confirmation request.
17. The transaction processing system of any one of claims 11 to 14, wherein the circuitry is further configured to:
generate a first transaction code to initiate the transaction;
communicate the first transaction code to the user;
receive a second transaction code from the merchant, wherein the user provides the second transaction code to the merchant based on the first transaction code; and
determine whether the second transaction code matches the first transaction code, wherein the transaction is initiated when the second transaction code matches the first transaction code.
18. The transaction processing system of any one of claims 10 to 14, wherein the circuitry is further configured to:
receive a registration request from the user, wherein the registration request includes details of the user; and
register the user based on the registration request, wherein the transaction is initiated for the purchase when the first and second images are provided by the registered user.
42
19. A transaction processing method, comprising:
presenting, by a server, a graphical user interface (GUI) on at least one of a user device of a user or a merchant device of a merchant, wherein the GUI displays one or more options for uploading a first image of a transaction card and a second image of purchase receipt of a purchase made by the user at the merchant;
receiving, by the server, the first and second images;
extracting, by the server, transaction card details of the transaction card from the first image and merchant details of the merchant from the first and second images;
initiating, by the server, an authentication of the user based on the transaction card details; and
initiating, by the server, a transaction associated with the purchase based on the authentication of the user, wherein a purchase amount of the purchase is debited from a user account linked to the transaction card and credited to a merchant account associated with the merchant details, when the transaction is approved.
20. The transaction processing method of claim 19, wherein the server extracts the transaction card details from the first image, and the merchant details and the purchase amount from the second image by means of optical character recognition.