Claims:We claim:
1. A system (100) for processing payments, the system (100) comprising:
a payment terminal (102) comprising a personal area network module (214), wherein the payment terminal (102) is configured to cause the personal area network module (214) to broadcast identifier; and
a portable communication device (104b) configured to:
receive identifier broadcasted by the payment terminal (102);
send a request automatically to establish a communication channel with the personal area network module (214) of the payment terminal (102), if signal strength of the broadcasted identifier is over a first threshold; and
continue to retain communication with the personal area network module (214) of the payment terminal (102), once the communication channel is established, even if signal strength between the portable communication device (104b) and the personal area network module (214) of the payment terminal (102) falls below the first threshold, till a transaction is concluded.

2. The system (100) according to claim 1, wherein the first threshold is configured such that the portable communication device (104b) and the payment terminal (102) are within 20 centimetres of each other to establish the communication channel.

3. The system (100) according to claim 1, wherein the first threshold is configured such that the portable communication device (104b) and the payment terminal (102) are within 10 centimetres of each other to establish the communication channel.

4. The system (100) according to claim 1, wherein the first threshold is configured such that the portable communication device (104b) and the payment terminal (102) are within a preconfigured distance of each other to establish the communication channel.

5. The system (100) according to claim 1, wherein at least one of the payment terminal (102) or the portable communication device (104b) is configured to terminate the established communication channel, if the signal strength between the portable communication device (104b) and the personal area network module (214) of the payment terminal (102) falls below a second threshold.

6. The system (100) according to claim 5, wherein the second threshold is remotely reconfigurable.

7. The system (100) according to claim 1, wherein the payment terminal (102) is configured to:
receives at least data identifying a user attempting to make a payment connected to the transaction, up on establishing the communication channel; and
communicate at least the data identifying the user, data identifying a merchant and data identifying payment amount to a server (106) to process the transaction, thereby enabling the portable communication device (104b) to make payment without using internet.

8. The system (100) according to claim 1, wherein the payment terminal (102) is further configured to:
receive, from a server (106), data corresponding to account balance of a user making a payment using the portable communication device (104b); and
communicate the data corresponding to the account balance to the portable communication device (104b) via the communication channel.

9. The system (100) according to claim 8, wherein the payment terminal (102) is further configured to:
receive, from a server (106), data corresponding to transaction information; and communicate at least a part of the data corresponding to the transaction information to the portable communication device (104b) via the communication channel.

10. The system (100) according to claim 8, wherein,
the payment terminal (102) is incapable of displaying the account balance of the user; and
the portable communication device (104b) is configured to display the account balance of the user post the transaction.

11. The system (100) according to claim 1, wherein the identifier comprises data identifying compatibility, wherein the portable communication device (104b) is configured to consider the payment terminal (102) for automatically requesting to establish the communication channel, if the identifier received by the portable communication device (104b) comprises the data identifying compatibility.

12. The system (100) according to claim 1, wherein payment terminal (102) is configured to:
receive an input indicating an amount to be transferred;
receive an input to begin broadcasting of the identifier, after the input indicating the amount is received; and
communicate data corresponding to the amount and a merchant connected to the payment terminal (102), to the portable communication device (104b), once the communication channel is established, wherein the amount and information corresponding to the merchant are displayed on the portable communication device (104b).

13. The system (100) according to claim 1, wherein the first threshold is remotely reconfigurable.

14. The system (100) according to claim 1, wherein the personal area network module (214) is a BLUETOOTH low energy module.

15. The system (100) according to claim 1, wherein the personal area network module (214) is a BLUETOOTH module.

16. A method for processing payments, the method comprising:
broadcasting identifier by a personal area network module (214) of a payment terminal (102);
receiving, by a portable communication device (104b), identifier broadcasted by the payment terminal (102);
sending automatically, by the portable communication device (104b), a request to establish a communication channel with the personal area network module (214) of the payment terminal (102), if signal strength of the broadcasted identifier is over a first threshold; and
retaining communication between the portable communication device (104b) and the personal area network module (214) of the payment terminal (102), once the communication channel is established, even if signal strength between the portable communication device (104b) and the personal area network module (214) of the payment terminal (102) falls below the first threshold, till a transaction is concluded.

, Description:BACKGROUND
[001] Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted being prior art by inclusion in this section.
Field of the invention:
[002] The subject matter in general relates to digital payments. More particularly, but not exclusively, the subject matter relates to digital payments via point of sale payment terminals used by merchants.

Discussion of the related art:
[003] Cashless payments have become the need of the hour and is slowly but steadily replacing cash-based payments in every nook and corner of the world. Cashless payments are done using cards and mobile phones. Internet connectivity is one of the foremost limitation while using mobile phones as a means for completing electronic transactions.
[004] Even though the reach of internet is undeniable, it is not certain that the user using a mobile device is connected to internet all the time. Also, internet may not also be affordable to large sections of the society in developing and under-developed nations. In such scenarios, completing an electronic transaction over mobile phones may not be feasible.
[005] Further, conventionally, a merchant may have to deploy different types of payment terminals for enabling different types of digital payments. As an example, the merchant may have to deploy a payment terminal to accept payment using cards. Additionally, the merchant may have to deploy yet another terminal to support payment via mobile phones. Even if an additional terminal is deployed, the terminal may only support mobile phones that use a specific type of communication technology, such as NFC.
[006] In light of the foregoing discussion, there is a need for an improved technique to facilitate digital payments at a merchant’s location.
SUMMARY
[007] In one aspect, a system is provided for processing payments. The system comprises a payment terminal comprising a first wireless communication module and a second wireless communication module. The first module is capable of establishing proximity communication using a first communication channel that is different from a second communication channel, which the second module is capable of establishing. The payment terminal is configured to receive an input to initiate a transaction; cause the first module and the second module to attempt establishment of a communication channel with an external entity; and establish the communication channel with the external entity using one of the first module and the second module, based on which one of the communication modules is successful in establishing the communication channel with the external entity.
[008] In another aspect, a method is provided for processing payments. The method comprises receiving an input to initiate a transaction at a payment terminal. Thereafter, a first wireless communication module and a second wireless communication module, provided in the payment terminal, attempt to establish a communication channel with an external entity. The first wireless communication module is capable of establishing proximity communication using a first communication channel that is different from a second communication channel, which the second wireless communication module is capable of establishing. The method further comprises, establishing the communication channel with the external entity using one of the first wireless communication module and the second wireless communication module, based on which one of the communication modules is successful in establishing the communication channel with the external entity.
[009] In yet another aspect, a system is provided for processing payments. The system comprises a payment terminal comprising a personal area network (PAN) module. The payment terminal is configured to cause the PAN module to broadcast identifier. The system further comprises a portable communication device. The device is configured to receive identifier broadcasted by the payment terminal; send a request automatically to establish a communication channel with the PAN module of the payment terminal, if signal strength of the broadcasted identifier is over a first threshold; and continue to retain communication with the PAN module of the payment terminal, once the communication channel is established, even if signal strength between the device and the PAN module of the payment terminal falls below the first threshold, till a transaction is concluded.
[0010] In still another aspect, a method is provided for processing payments. The method comprises broadcasting identifier by a personal area network module of a payment terminal; receiving, by a portable communication device, identifier broadcasted by the payment terminal; sending automatically, by the portable communication device, a request to establish a communication channel with the personal area network module of the payment terminal, if signal strength of the broadcasted identifier is over a first threshold. The method further includes, retaining communication between the portable communication device and the personal area network module of the payment terminal, once the communication channel is established, even if signal strength between the portable communication device and the personal area network module of the payment terminal falls below the first threshold, till a transaction is concluded.
BRIEF DESCRIPTION OF DIAGRAMS
[0011] Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
[0012] FIG. 1 illustrates a system 100 for processing payments, in accordance with an embodiment;
[0013] FIG. 2 is a block diagram of a payment terminal 102 of the system 100, in accordance with an embodiment;
[0014] FIGs. 3A-3F, are flow charts of an exemplary method of processing payments by the system 100, in accordance with an embodiment;
[0015] FIG. 4A illustrates an amount entered in the payment terminal 102, in accordance with an embodiment;
[0016] FIG. 4B illustrates a user interface of an application of a smartphone 104b that is opened by the user to make payment, in accordance with an embodiment;
[0017] FIG. 4C illustrates a user interface of the application of the smartphone 104b searching for payment terminals 102, in accordance with an embodiment;
[0018] FIG. 4D illustrates a smartphone 104b paired with the payment terminal 102 via BLE channel after having the smartphone 104b brought close to the payment terminal 102, in accordance with an embodiment;
[0019] FIG. 4E illustrates a user interface of the application of the smartphone 104b, where the user is providing input to approve payment, in accordance with an embodiment;
[0020] FIG. 4F illustrates a user interface of the application of the smartphone 104b, where it is shown that the transaction is being processed, in accordance with an embodiment; and
[0021] FIG. 4G illustrates a user interface of the application of the smartphone 104b, where transaction information is displayed after successful transaction, in accordance with an embodiment.
DETAILED DESCRIPTION
[0022] The following detailed description includes references to the accompanying drawings, which form part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments are described in enough details to enable those skilled in the art to practice the present subject matter. However, it may be apparent to one with ordinary skill in the art that the present invention may be practised without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. The embodiments can be combined, other embodiments can be utilized or structural and logical changes can be made without departing from the scope of the invention. The following detailed description is, therefore, not to be taken as a limiting sense.
[0023] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a non-exclusive “or”, such that “A or B” includes “A but not B”, “B but not A”, and “A and B”, unless otherwise indicated.
[0024] It should be understood, that the capabilities of the invention described in the present disclosure and elements shown in the figures may be implemented in various forms of hardware, firmware, software, recordable medium or combinations thereof.
OVERVIEW
[0025] Disclosed is a system that is capable of processing payments, without the need for internet usage by a user making the payment. The payment may be made using a near field communication (NFC) enabled card or a smartphone with NFC or BLUETOOTH low energy (BLE) technology.
[0026] The payment is facilitated by a payment terminal deployed at a merchant location. The payment terminal may include a personal area network module (BLE module) and a NFC module. At the initiation of a transaction, the payment terminal attempts to establish communication using both the BLE module and the NFC module, with an external entity presented by the consumer/user to make the payment. The external entity can be a NFC enabled card or a smartphone with NFC or BLUETOOTH low energy (BLE) technology, with an application installed therein to transact with payment terminals.
[0027] Once the payment terminal is successful in establishing a communication channel with the external entity via any one of BLE module or the NFC module, the payment terminal is configured to disable (from attempting to establish communication with any other external entity) the other module, until the initiated transaction is concluded.
[0028] In an embodiment, a communication channel with the payment terminal may be established via NFC, wherein the user brings a card or an NFC enabled smartphone in proximity to the payment terminal. The payment terminal may read data from the card/NFC module of the phone and communicate it to the backend server to process the initiated payment transaction. Note that, the merchant is not instructing the payment terminal regarding which communication means to use, rather the payment terminal is automatically deciding on its own.
[0029] In an embodiment, a communication channel with the payment terminal may be established via BLE, wherein the user brings a BLE enabled smartphone in proximity to the payment terminal. The payment terminal may receive data from the BLE module of the phone and communicate it to the backend server to process the initiated payment transaction. Note that, even in this case, the merchant is not instructing the payment terminal regarding which communication means to use, rather the payment terminal is automatically deciding on its own.
[0030] In case of BLE, the payment terminal communicates transaction information (received from a backend server), such as amount deducted and balance in the user’s account, to the user’s smartphone via the communication channel established via BLE. Hence, the user is not only able to make payment, but also get an update on the transaction and account without using internet or relying on SMS or similar alternatives.
SYSTEM FOR PROCESSING PAYMENTS
[0031] Referring to the figures, and more particularly to FIG. 1, a system 100 for processing payments is provided. The system 100 comprises a payment terminal 102 which can receive payments via external entities such as NFC enabled cards 104a and portable communication devices 104b. The payment terminal 102 communicates with a server 106 via a communication network 108.
[0032] The payment terminal 102 may be, for example, card readers, smartphones, POS systems, tablets, phablets, computers and laptops, among other computing devices.
[0033] Now referring more specifically to FIG. 2, an exemplary block diagram of the payment terminal 102 is disclosed, in accordance with an embodiment. The payment terminal 102 may include a processing module 202, a memory module 204, input modules 206, output modules 208, a WIFI module 210, a communication module 212, a security module 213, a first wireless communication module 214 and a second wireless communication module 216.
[0034] The processing module 202 is implemented in the form of one or more processors and may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processing module 202 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.
[0035] The memory module 204 may include a permanent memory such as hard disk drive, may be configured to store data, and executable program instructions that are implemented by the processor 202. The memory module 204 may be implemented in the form of a primary and a secondary memory. The memory module 204 may store additional data and program instructions that are loadable and executable on the processor 202, as well as data generated during the execution of these programs. Further, the memory module 204 may be volatile memory, such as random-access memory and/or a disk drive, or non-volatile memory. The memory module 204 may comprise of removable memory such as a Compact Flash card, Memory Stick, Smart Media, Multimedia Card, Secure Digital memory, or any other memory storage that exists currently or may exist in the future.
[0036] The input modules 206 may provide an interface for input devices such as keypad, touch screen, mouse, microphone and stylus among other input devices.
[0037] The output modules 208 may provide an interface for output devices such as display screen, speakers, printer and haptic feedback devices, among other.
[0038] The input modules 206 and output modules 208 may also be used to exchange data between the payment terminal 102, NFC enabled cards 104a, portable communication devices 104b and the server 106.
[0039] The WIFI module 210 may be used by the payment terminal 102 to communicate with the server 106 via the communication network 108.
[0040] Alternatively, or in addition, the communication module 212 may be used by the payment terminal 102 to communicate with the server 106 via the communication network 108. The communication module 212, as an example, may be a GPRS module, or other modules that enable telecommunication. The communication module 212 may include a modem, a network interface card (such as Ethernet card), a communication port, or a Personal Computer Memory Card International Association (PCMCIA) slot, among others. The communication module 212 may include devices supporting both wired and wireless protocols. Data in the form of electronic, electromagnetic, optical, among other signals may be transferred via the communication module 212.
[0041] The security module 213 may safeguard and manage the digital keys that may be used for encrypting, decrypting and authenticating data that may be exchanged between the payment terminal 102 and external entities 104. The security module 213 may be deployed in the form of software, firmware, hardware or combination thereof.
[0042] In an embodiment, the first wireless communication module 214 may be a personal area network module (hereinafter, referred to as PAN module). Among the various available PAN modules, the PAN module is preferable a BLUETOOTH module, and more preferably a BLUETOOTH low energy (BLE) module. In an embodiment, technologies that are analogous to BLE in the current context, may be used.
[0043] In an embodiment, the second wireless communication module 216 may be a near filed communication module (hereinafter, referred to as NFC module). In an embodiment, technologies that are analogous to NFC in the current context, may be used.
[0044] Therefore, it may be noted that the payment terminal 102 comprises the first wireless communication module 214, which is capable of establishing proximity communication with external entities 104, using a first communication channel (e.g., BLE) that is different from a second communication channel (e.g., NFC), which the second wireless communication module 216 is capable of establishing.
[0045] Now referring to FIGs. 3A-3F, the tasks carried out by the payment terminal 102, the external entity 104 (types of external entities 104a, 104b are referred to as external entity 104 in some instances to facilitate easier reading of this document) and the server 106, in accordance with an embodiment, are discussed.
[0046] At step 302, the payment terminal 102 receives an input indicating amount to be charged. As an example, merchant may use the physical or digital keypad provided in the payment terminal 102 to receive the input indicating the amount to be charged. As an example, referring to FIG. 4A, the merchant has entered an amount of Rs. 350, which the merchant intends to receive from the user/customer.
[0047] At step 304, the payment terminal 102 receives an input to initiate a transaction with the external entity 104. As an example, again referring to FIG. 4A, after entering the amount, the user of the payment terminal 102 presses the return key to provide the instant input. It may be noted that, pressing of the return key may be interpreted as a confirmation of the amount discussed in the previous step, and the input discussed in the current step.
[0048] At step 306, the payment terminal 102 (e.g. processing module 202 of the payment terminal 102) causes the first wireless communication module 214 (hereinafter referred to a BLE module 214 to facilitate easier reading of this document) and the second wireless communication module 216 (hereinafter referred to a NFC module 216 to facilitate easier reading of this document) to attempt establishment of a communication channel with an external entity 104. As an example, both the modules 214, 216 may be switched on and thereafter attempt to establish the communication channel. Alternatively, both the modules 214, 216 may already be on (but in “sleep” or “power saving” mode), but at this instance, begin attempting to establish the communication channel with the external entity 104.
[0049] At step 308, both the BLE module 214 and the NFC module 216 attempt to establish the communication channel. As an example, in the case of the BLE module 214, the BLE module 214 may begin broadcasting its identifier. On the other hand, in case of NFC module 216, the NFC module 216 generates electromagnetic field. It may be noted that, the merchant is not specifying which of the modules 214, 216 should be used, rather the payment terminal 102 is configured to use both the modules 214, 216 to attempt establishing of a communication channel, but establish the communication channel eventually via one of the suitable modules 214, 216.
[0050] Referring to the step 310 in FIG. 3B, it may be noted that, although it appears as if the external entity 104 is deciding whether the external entity 104 is NFC or BLE enabled, it would be well understood that the step 310 is presented only for the sake of explanation. It may be appreciated that, external entity 104, as discussed earlier, may be a NFC enabled card 104a (such as credit card, debit card, access card, corporate card or food card) or a portable communication device 104b (e.g., smartphone) with one or more of BLE or NFC capabilities. We will discuss the transaction flow in case of BLE enabled portable communication device 104b later. Now we discuss a scenario wherein the external entity 104 is a NFC enabled card 104a or a NFC enabled portable communication device 104b. It may be noted that, in case of portable communication device 104b with NFC and BLE capabilities, which one of those should be used may be defined by default application settings, user defined settings in the application or availability of the module.
[0051] Referring to step 312, external entity 104 is in close proximity to the payment terminal 102 for detection. As an example, once the merchant has the payment terminal 102 ready to accept payment, the user/customer may bring the NFC card 104a or NFC device 104b close (to the extent required for NFC) to the payment terminal 102.
[0052] Referring to step 314, the payment terminal 102 detects and attempts to unlock external entity 104. Therefore, by way of detecting the NFC card 104a or NFC device 104b, the payment terminal 102 has established the communication channel with the external entity 104 using one of the first wireless communication module 214 and the second wireless communication module 216, based on which one of the communication modules 214, 216 is successful in establishing the communication channel with the external entity 104. In this case, payment terminal 102 has established the communication channel with the external entity 104 using the second wireless communication module 216 (NFC module 216). Hence the communication channel thus established may be referred to as NFC channel.
[0053] Once the communication channel is established, the payment terminal 102 terminates attempt to establish communication channel with any other external entity using the first wireless communication module 214 and the second wireless communication module 216 till said transaction is concluded.
[0054] Using the NFC channel that is established, the payment terminal 102 coordinates with the external entity 104 to unlock external entity 104. Known (or that may be developed in future) security technologies deployed at the card/device level and at the payment terminal 102 may be used for unlocking the NFC card 104a or NFC device 104b. In case the payment terminal 102 fails to unlock, then the transaction may be terminated (transaction concluded).
[0055] Referring to step 316, once unlocking is successful, the payment terminal 102 reads a user token. The user token may be data identifying a user attempting to make a payment connected to the transaction.
[0056] In addition to reading the user token, the external entity 104 may include data that is used as a one-time verifier. The one-time verifier may be understood as data that needs to be unique for each transaction that is attempted. It may be further noted that, in case of NFC card 104a, a new one-time verifier may be written to the card 104a each time the exiting one-time verifier is read by a payment terminal 102 to process a transaction. It may be further noted that, some smartphone may not allow writing this data to its NFC module, in which case the provision of one-time verifier as implemented in the foregoing example may not be provided.
[0057] In an embodiment, the data read from the NFC card 104a or NFC module of a mobile device 104b (or data communicated via BLE) includes data that enables the payment terminal 102 identify whether the data it is gathering is from a NFC card 104a or a NFC module of a mobile device 104b (or via BLE of a mobile device). Therefore, the payment terminal 102 (or the server 106, or both) is capable of identifying whether the communication established is with one of a near field communication tag of the card 104a, a near filed communication module of the portable communication device 104b or a personal area network module 214 of the portable communication device 104b. It may be noted that, such a provision enables the server 106 establish the data sets that are required to process the transaction. As an example, in case of NFC card 104a, a one-time verifier is required, whereas in case of NFC module from a mobile device 104b, the one-time verifier may not be required (due to the constraints discussed earlier) to process the transaction.
[0058] In an embodiment, the data read from the NFC card/device 104a, 104b or received via BLE includes location validation data. In other words, the payment terminal 102 receives location validation data from the external entity 104. The location validation data is used to verify whether payment can be accepted using the payment terminal 102. In case it is determined that payment cannot be accepted, then transaction is declined. On the other hand, if verified that payment can be accepted, then transaction is processed. The verification that is being discussed may be carried out by the payment terminal 102. Alternatively, the verification can be carried out by the server 106. As an implementation example, a company may have issued NFC cards 104a to its employees for use within the food court deployed in their campus. In case the card 104a is used to make a payment at a payment terminal 102 outside the campus, the payment terminal 102 (or server 106), upon reading the location validation data, may decline the transaction.
[0059] Now referring to step 318, the payment terminal 102 writes a new one-time verifier to the external entity 104. As an example, the new one-time verifier is written to the NFC card 104a. In case NFC module of the mobile device 104b allows such writing, then even in case of NFC enabled mobile device 104b, the new one-time verifier may be written to the NFC module of the mobile device 104b. The new one-time verifier is used for the next transaction. The new-one time verifier may be a per-configured increment/decrement in comparison to the existing one-time verifier. Alternatively, the one-time verifiers may be a randomly generated code, which may be based on known logic. In an embodiment, the new one-time verifier is generated by the payment terminal 102. At step 320, the new one-time verifier is recorded in the NFC card 104a or NFC module of the mobile device 104b (if such provision is provided).
[0060] It should be noted that, the one-time verifier adds freshness to the data gathered from the external entity 104 for each transaction. As an example, in case only user token was to be gathered (as done conventionally), which is also constant, then a rogue system with access to the user token can misuse the user token to carryout transactions.
[0061] Referring to step 322, the payment terminal 102 bundles the user token, one-time verifier (if any), merchant ID, terminal ID, one-time verifier of payment terminal 102, source (NFC card/mobile or BLE) used to get user data and transaction information. In an embodiment, the payment terminal 102 may bundle the new one-time verifier as well. It may be noted that, apart from the one-time verifier corresponding to the external entity 104, there can be a one-time verifier for the payment terminal 102 as well. Hence, a rogue system with information (e.g., merchant ID or terminal ID) about the payment terminal 102 may still be presented with resistance in case of misuse. In an embodiment, the user may have to communicate a PIN as well to the payment terminal 102 to authorise the transaction. In some embodiment, PIN may be required only for transactions beyond a certain preconfigured amount.
[0062] Additionally, the payment terminal 102 may bundle authentication and security data along with other data to enhance the security features.
[0063] Referring to step 324, the payment terminal 102 sends the bundled information to the server 106. The payment terminal 102 may use WIFI module 210 to send the information to the server 106. Alternatively, the payment terminal 102 may use GPRS module to send the information to the server 106. Alternatively, the payment terminal may encrypt the bundled information using the security module 213 for security purposes before communicating it to the server 106.
[0064] Referring to step 326, the server 106 receives the bundled information from the payment terminal 102.
[0065] Referring to step 328, the server 106 processes the transaction. The conventional steps involved in processing the transaction are not discussed, to prevent obscuring attention from steps that may be unconventional. The one-time verifier of the external entity 104 and one-time verifier of the payment terminal 102 are used to decide whether the payment request should be declined or further processed. The one-time verifier (corresponding to payment terminal 102) is used to verify whether the one-time verifier is what is expected from the payment terminal 102 for the current transaction to either reject the transaction or proceed with the transaction. Likewise, the one-time verifier (corresponding to external entity 104) is used to verify whether the one-time verifier is what is expected from the external entity 104 for the current transaction to either reject the transaction or proceed with the transaction.
[0066] In an embodiment, the payment terminal 102 may even communicate the new one-time verifier corresponding to the external entity 104 to the server 106, so that the server 106 knows what to expect from the external entity 104 in the next transaction.
[0067] In an embodiment, the new one-time verifier of the external entity 104 or the payment terminal 102 is a known change compared to the previous one-time verifier. Hence, the server 106 may just have to verify the one-time verifier with the previous one to either decline or proceed with the transaction.
[0068] In an embodiment, the server 106 communicates a new one-time verifier for the payment terminal 102 for use in the next transaction.
[0069] In case of absence of one-time verifier from the external entity 104, where it was expected, or wrong one-time verifier, the server 106 may block the external entity 104 from carrying out transaction, till the issue is resolved. Likewise, for the payment terminal 102.
[0070] Referring to step 330, the server 106 sends transaction information to the payment terminal 102. The transaction information may include information corresponding to successful payment or payment being declined. The transaction information may also include information corresponding to the amount being credited to the merchant’s account and/or selected information about the user/customer who made the payment, among other information.
[0071] Referring to step 332, the payment terminal 102 receives the transaction information from the server 106. Some of the information that is received may be outputted (e.g., display) by the payment terminal 102. In some embodiment, some of the transaction information may be prevented from being outputted by the payment terminal 102, whereas such information may be outputted on the external device 104 (e.g., phone).
[0072] Referring to step 334, once the transaction is concluded, the payment terminal 102 may be ready for the next transaction (e.g., start at 302).
[0073] Now referring to block 310, as may be recollected, we had previously provided the description considering that the user/customer may be using a NFC card 104a or NFC enabled smartphone 104b to make payment. Now we refer to a scenario wherein the user is using a portable communication device 104b (e.g., smartphone) with BLE capabilities to make the payment. We may now also refer to FIG. 3E, along with other figures in the FIG. 3 series. As explained earlier, with reference with step 308, both NFC module 216 and BLE module 214 may be attempting to establish a communication channel. As explained earlier, in the case of the BLE module 214, the BLE module 214 may begin broadcasting its identifier. The identifier may comprise data identifying compatibility.
[0074] Referring to step 30, the portable communication device 104b of the user searches for payment terminals 102. As an example, referring to FIG. 4B as well, the user opens a payment application in the portable communication device 104b and activates “pay now” icon. The application causes the BLE module of the BLE enabled smartphone 104b to search (refer FIG. 4C) for payment terminals 102. In an embodiment, the application of the smartphone 104b is looking for compatible payment terminals 102 by looking at the data identifying compatibility present in the identifier. For example, there may be several BLE or BLUETOOTH devices that may be advertising, however, the application is only interested in identifying payment terminals 102 which may be considered for making payment (therefore be considered for sending a request to pair).
[0075] Referring to step 31, the smartphone 104b sends a request to the payment terminal 102 to pair, if strength of signal from the payment terminal 102 is beyond a first threshold. As an example, consider a merchant location with multiple compatible payment terminals 102. The application of the smartphone 104b would identify and shortlist all of these payment terminals 102, however it has to decide to which one among those a request to pair has to be sent. The application selects the payment terminal 102 to which request to pair has to be sent based on, from which one among the payment terminal 102 signal beyond the first threshold is first received. Even in a scenario wherein a single payment terminal 102 is identified, the request to pair is not sent unless the signal strength is beyond the first threshold. In practice, the user experience would be similar to “tap-and-pay” even when using BLE as a channel to make payment. The user takes the smartphone 104b close (refer FIG. 4D) to the payment terminal 102 resulting in increase in the signal strength, and thereby causing the application to request pairing with the payment terminal 102. Hence, it is to be understood that the smartphone 104b sends a request automatically to establish a communication channel with the personal area network module 214 of the payment terminal 102, if signal strength of the broadcasted identifier is over the first threshold.
[0076] The first threshold is configured such that the portable communication device 104a and the payment terminal 102 are within a preconfigured distance of each other to establish the communication channel. The first threshold may be reconfigured remotely via a software update, or may be configured at the payment terminal 102.
[0077] In an embodiment, the first threshold is configured such that the portable communication device 104b and the payment terminal 102 are within approximately 20 centimetres of each other to establish the communication channel.
[0078] In another embodiment, the first threshold is configured such that the portable communication device 104b and the payment terminal 102 are within approximately 10 centimetres of each other to establish the communication channel.
[0079] It is to be understood that, with the configuration of the first threshold, we are able to set an approximate distance between the portable communication device 104b and the payment terminal 102 to proceed with pairing.
[0080] Referring to step 32, the payment terminal 102 receives the request to pair. The payment terminal 102, on receiving the request, co-ordinates with the smartphone 104b using well known protocol, to successfully pair or decline request. In case pairing is successful, the payment terminal 102 has established the communication channel (BLE channel) with the external entity 104 using the first wireless communication module 214 (BLE module 214). Hence the communication channel thus established may be referred to as BLE channel.
[0081] Once communication channel is established (paired), the smartphone 104b continues to retain communication with the personal area network module 214 of the payment terminal 102 even if signal strength between the smartphone 104b and the personal area network module 214 of the payment terminal 102 falls below the first threshold, till the transaction is concluded. In practice, the user brings the smartphone 104b close to the payment terminal 102, causing the smartphone 104b to pair with the payment terminal 102. Thereafter, the user may pull back the smartphone 104b, but still communication channel will be retained.
[0082] In an embodiment, at least one of the payment terminal 102 or the smartphone 104b is configured to terminate the established communication channel, if the signal strength between the smartphone 104b and the personal area network module 214 of the payment terminal 102 falls below a second threshold. The second threshold may be reconfigured. The second threshold may be reconfigured remotely or at the device.
[0083] Referring to step 33, the payment terminal 102 sends transaction information to the smartphone 104b. The information is sent via the BLE channel. Such information may include amount to be transferred and merchant information, among others.
[0084] Referring to step 34 and FIGs. 4D and 4E, the smartphone 104b receives the transaction information sent by the payment terminal 102.
[0085] Referring to step 35 and FIG. 4E, the user may activate an icon, thereby causing the smartphone 104b to send approval for payment and communicate data to facilitate the transaction. The data that is communicated (in addition to relevant data that was discussed in the context of NFC) may include real time data as well. Real time data may include data corresponding to time. The one-time verifier may be generated by the smartphone 104b. In an embodiment, the user may have to communicate a PIN as well to authorise the transaction. In some embodiment, PIN may be required only for transactions beyond a certain preconfigured amount.
[0086] Referring to step 36, the payment terminal 102 receives the approval and the data, and steps discussed earlier in connection with step 322 and subsequent steps may be carried out, as may be adapted for this mode of transaction.
[0087] Now specifically referring the steps 332, 37 and 38, the payment terminal 102 receives transaction information from the server 106. It may be noted that, as discussed earlier, the server 106, based on the data received knows that the data was received by the payment terminal 102 via BLE channel. Hence, the BLE channel can be used to provide an update, corresponding to the transaction, to the user. Therefore, apart from the typical data sent by the server 106, the server 106 sends and the payment terminal 102 receives data corresponding to account balance of the user making a payment using the smartphone 104b. The payment terminal 102, via the BLE channel, communicates the data corresponding to the account balance to the smartphone 104b (refer FIG. 4G). Therefore, the user is not only able to make the payment without using internet, but also get an update on the transaction, without using internet.
[0088] In an embodiment, the payment terminal 102 is further configured to receive, from the server 106, data corresponding to transaction information, and communicate at least a part of the data corresponding to the transaction information to the smartphone 104b via the communication channel.
[0089] In an embodiment, the payment terminal 102 is incapable of displaying the account balance of the user, however, the portable communication device 104b is configured to display the account balance of the user post the transaction. Data corresponding to the account balance may be encrypted such that only the user’s smartphone 104b is capable of decrypting said data.
[0090] It shall be noted that, some of the encryption, decryption, authentication and security technologies that are typically used at different steps are not discussed, so as not to unnecessarily obscure aspects of the embodiments.
[0091] The processes described above is described as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, or some steps may be performed simultaneously.
[0092] The example embodiments described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.
[0093] Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the system and method described herein. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
[0094] Many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. It is to be understood that the description above contains many specifications, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the personally preferred embodiments of this invention.