Claims:CLAIMS
We claim:

1. A computer-implemented method for configuring a payment terminal, comprising:
upon establishing a communication between a smart card associated with a merchant and the payment terminal, receiving, by a server system, a data packet from the payment terminal, the data packet comprising merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card;
decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key;
performing, by the server system, an authentication process to validate the payment terminal configured with the smart card and a merchant device associated with the merchant;
upon successful authentication, transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using a public key of the smart card, the symmetric cryptographic key transmitted for facilitating a secure communication channel between the payment terminal and the server system; and
transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.

2. The computer-implemented method as claimed in claim 1, wherein the authentication process comprises:
sending, by the server system, an authentication request message to the merchant device associated with the merchant based, at least in part, on the extracted merchant identifier; and
receiving, by the server system, an authentication response message from the payment terminal, the authentication response message being authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card, the authentication response message provided as an input to the payment terminal in response to the authentication request message.

3. The computer-implemented method as claimed in claim 2, further comprising:
upon sending the authentication response message by the payment terminal, receiving, by the server system, the authentication response message for authenticating validity of the payment terminal;
verifying, by the server system, the authentication response message based, at least in part, on the authentication request message; and
sending, by the server system, access grant message or access denied message to the payment terminal, the access grant message being sent to enable the payment terminal for conducting the payment transaction for the merchant upon successful verification of the authentication response message, the access denied message being sent to the payment terminal upon unsuccessful verification of the authentication response message.

4. The method as claimed in claim 3, wherein upon successful verification of the authentication response message, further comprises:
generating, by the server system, a symmetric key;
encrypting, by the server system, the symmetric key with the public key of the smart card for generating the symmetric cryptographic key; and
transmitting, by the server system, an authentication verified message to the payment terminal along with a payload, wherein the payload comprising the encrypted symmetric cryptographic key for establishing the secure communication channel between the payment terminal and the server system.

5. The computer-implemented method as claimed in claim 1, wherein the server system is an acquirer server associated with the merchant.

6. The computer-implemented method as claimed in claim 1, wherein the payment terminal is a Point-of-Sale terminal.

7. The computer-implemented method as claimed in claim 1, wherein the smart card is configured with a plurality of configuration parameters, the plurality of configuration parameters comprising the private key for the merchant, the first cryptographic key associated with the server system, the merchant identifier, merchant identification number, authentication credentials for the merchant, and provisioning uniform resource locator of the server system.

8. The computer-implemented method as claimed in claim 1, further comprising performing enrolment of the merchant at the server system, wherein the enrolment of the merchant is performed before establishing the communication between the smart card and the payment terminal, the enrolment comprising:
receiving, by the server system, one or more documents associated with the merchant for verifying identity of the merchant;
performing, by the server system, Know Your Customer (KYC) of the merchant for providing approval to the merchant and creating record of the merchant in the server system, the record comprising bank details of the merchant, authentication credentials of the merchant used for configuring the payment terminal, and security certificates for personalizing the smart card; and
issuing, by the server system, the smart card to the merchant for activating the payment terminal.

9. The computer-implemented method as claimed in claim 1, further comprising:
upon decrypting the data packet to extract the merchant identifier using the second cryptographic key, fetching, by the server system, the first cryptographic key for the corresponding private key of the merchant already stored in the smart card;
verifying, by the server system, data signature for validating authenticity of the merchant; and
loading, by the server system, data associated with the merchant from a repository connected with the server system.

10. The computer-implemented method as claimed in claim 1, further comprising:
upon facilitating the secure communication channel between the payment terminal and the server system, receiving, by the server system, a request from the payment terminal for downloading the configuration file data; and
transmitting, by the server system, the configuration file data to the payment terminal for activating the payment terminal for conducting the payment transaction.

11. The computer-implemented method as claimed in claim 1, wherein the configuration file data comprises merchant category code, supported currency by the payment terminal, supported CVM data, MCC data and offline verification enabled/disabled data.

12. A computer-implemented method for configuring a payment terminal, comprising:
upon establishing a communication between a smart card associated with a merchant and the payment terminal, receiving, by a server system, a data packet from the payment terminal, the data packet comprising merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card;
decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key;
sending, by the server system, an authentication request message to a merchant device associated with the merchant based, at least in part, on the extracted merchant identifier;
receiving, by the server system, an authentication response message from the payment terminal, the authentication response message being the authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card, the authentication response message provided as an input to the payment terminal in response to the authentication request message;
upon successful authentication, transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using a public key of the smart card, the symmetric cryptographic key transmitted for facilitating a secure communication channel between the payment terminal and the server system; and
transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.

13. A smart card for configuring a payment terminal, comprising:
a storage medium comprising a set of executable instructions comprising a private key, the storage medium configured to be read by the payment terminal upon establishing a communication with the payment terminal, the set of executable instruction, upon executed by the payment terminal, causing a method to be performed, the method comprising:
sending a data packet from the payment terminal to a server system, the data packet comprising merchant identifier encrypted by a first cryptographic key and signed by the private key associated with the smart card;
decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key;
sending, by the server system, an authentication request message to a merchant device associated with the merchant based, at least in part, on the extracted merchant identifier;
receiving, by the server system, an authentication response message from the payment terminal, the authentication response message being the authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card, the authentication response message provided as an input to the payment terminal in response to the authentication request message;
upon successful authentication, transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using a public key of the smart card, the symmetric cryptographic key transmitted for facilitating a secure communication channel between the payment terminal and the server system; and
transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR CONFIGURING PAYMENT TERMINALS WITH A SMART CARD

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

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

4. DESCRIPTION
(See next page)

 
METHODS AND SYSTEMS FOR CONFIGURING PAYMENT TERMINALS WITH A SMART CARD

TECHNICAL FIELD
[0001] The present disclosure generally relates to payment terminals and, more particularly to, methods and systems for configuring a payment terminal with a smart card.

BACKGROUND
[0002] In recent times, there is an increase in payment card (e.g., credit card, debit card, ATM card, and so on) based transactions occurring through payment terminals. Generally, payment card based transactions are performed using point-of-sale (POS) devices. A POS device is a hardware device for processing payment card based payments for a merchant. Merchants prefer use of the POS devices to allow customers to pay for goods or services though their payment card. In present time, the POS devices are very much controlled by an acquirer. The merchant does not have the freedom to choose brand or model of the POS device based on requirement of the merchant. The acquirer installs the brand or model of the POS device that is available with the acquirer and that has to be accepted by the merchant.
[0003] Additionally, the acquirer requires a big team of field staff to provision and configure the POS devices for the merchants. In case of any problems in the POS devices, the maintenance and repair of the POS devices is also the responsibility of the acquirer. If the POS machine gets damaged, the merchant must wait for a long period of time for repair or replacement of the POS machine. In that time, the merchant has no other option but to accept cash payments from the customers. In case the POS device provided by the acquirer does not support contactless card, then the merchant also cannot accept contactless card payments from the customers. This further impacts the business of the merchant.
[0004] Therefore, there exists a need to perform configuring of a payment terminal for a merchant, without any dependency on the acquirer. More specifically, there is need to provide a technological solution to configure any payment terminal purchased from any vendor in open market.

SUMMARY
[0005] Various embodiments of the present disclosure provide systems and methods for configuring a payment terminal with a smart card.
[0006] In an embodiment, a computer-implemented method for configuring a payment terminal is disclosed. The method includes receiving, by a server system, a data packet from the payment terminal upon establishing a communication between a smart card associated with a merchant and the payment terminal. The data packet includes merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card. The method includes decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key. The method includes performing, by the server system, an authentication process to validate the payment terminal configured with the smart card and a merchant device associated with the merchant. The method includes transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using the public key of the smart card upon successful authentication. The symmetric cryptographic key is transmitted for facilitating a secure communication channel between the payment terminal and the server system. The method further includes transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.
[0007] In another embodiment, a computer-implemented method for configuring a payment terminal is disclosed. The method includes receiving, by a server system, a data packet from the payment terminal upon establishing a communication between a smart card associated with a merchant and the payment terminal. The data packet includes merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card. The method includes decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key. The method includes sending, by the server system, an authentication request message to a merchant device associated with the merchant based, at least in part, on the extracted merchant identifier. The method includes receiving, by the server system, an authentication response message from the payment terminal. The authentication response message is authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card. The authentication response message is provided as an input to the payment terminal in response to the authentication request message. The method includes transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using the public key of the smart card upon successful authentication. The symmetric cryptographic key is transmitted for facilitating a secure communication channel between the payment terminal and the server system. The method further includes transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.
[0008] In yet another embodiment, a smart card for configuring a payment terminal is disclosed. The smart card includes a storage medium. The storage medium includes a set of executable instructions including a private key. The storage medium is configured to be read by the payment terminal upon establishing a communication with the payment terminal. The payment terminal executes the set of executable instructions to perform a method. The method includes sending a data packet from the payment terminal to a server system. The data packet includes merchant identifier encrypted by a first cryptographic key and signed by the private key associated with the smart card. The method includes decrypting, by the server system, the data packet to extract the merchant identifier using a second cryptographic key. The method includes sending, by the server system, an authentication request message to a merchant device associated with the merchant based, at least in part, on the extracted merchant identifier. The method includes receiving, by the server system, an authentication response message from the payment terminal. The authentication response message is authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card. The authentication response message is provided as an input to the payment terminal in response to the authentication request message. The method includes transmitting, by the server system, a symmetric cryptographic key to the payment terminal encrypted using the public key of the smart card upon successful authentication. The symmetric cryptographic key is transmitted for facilitating a secure communication channel between the payment terminal and the server system. The method further includes transmitting, by the server system, configuration file data via the secure communication channel to the payment terminal to enable the payment terminal for conducting a payment transaction.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates an example representation of an environment related to at least some example embodiments of the present disclosure;
[0012] FIG. 2 represents a sequence flow diagram of enrolment of a merchant at a server system, in accordance with an example embodiment of the present disclosure;
[0013] FIG. 3A and FIG. 3B represent a sequence flow diagram of provisioning a payment terminal by the merchant with a smart card, in accordance with an example embodiment of the present disclosure;
[0014] FIG. 4 represents a sequence flow diagram of provisioning the payment terminal by the merchant after establishing a secure communication channel between the payment terminal and the server system, in accordance with an example embodiment of the present disclosure;
[0015] FIG. 5 illustrates a flow diagram depicting a method for configuring the payment terminal by the server system with the smart card, in accordance with an example embodiment of the present disclosure;
[0016] FIG. 6 illustrates a flow diagram depicting a method for configuring the payment terminal by an acquirer server with the smart card, in accordance with another example embodiment of the present disclosure;
[0017] FIG. 7 is a simplified block diagram of the payment terminal for conducting a payment transaction, in accordance with an example embodiment of the present disclosure;
[0018] FIG. 8 is a simplified block diagram of the server system for real-time configuring of the payment terminal of the merchant with the smart card, in accordance with an example embodiment of the present disclosure;
[0019] FIG. 9 is a simplified block diagram of a payment server used for conducting the payment transactions at the payment terminal in real-time, in accordance with an example embodiment of the present disclosure; and
[0020] FIG. 10 represents a block diagram of the smart card to configure the payment terminal, in accordance with an example embodiment of the present disclosure.
[0021] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0022] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0023] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0024] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0025] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by wallet providers and the like.
[0026] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0027] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by Mastercard®, etc.
[0028] The term "payment terminal" used throughout the description, refer to point of sale (POS) terminals, computers or data processing devices for processing payment at merchant locations, payment gateways and/or merchant online interface for allowing customers, cardholders, or account holders to make offline and/or online purchases. The payment terminal may be construed as any virtual or physical electronic system that accepts the cardholder's payment transaction requests, and forwards such requests to any of the entities such as acquirer server, payment interchange servers (e.g., payment server) and/or issuer server for the purposes of carrying out the payment transaction.
OVERVIEW
[0029] Various example embodiments of the present disclosure provide systems and methods for configuring a payment terminal with a smart card associated with a merchant that overcome above-mentioned obstacles and provide additional advantages. More specifically, techniques disclosed herein enable activating any payment terminal (e.g., a POS machine) purchased from open market by the merchant.
[0030] In an example embodiment, the smart card is used for activating the payment terminal. The smart card is a pre-configured card on which information is stored in an electronic form. In an example, the smart card is a plastic card with an embedded integrated circuit chip for configuring the payment terminal. In one example embodiment, the smart card stores information required for configuring and activating the payment terminal.
[0031] In one example embodiment, the payment terminal is purchased from open market. The payment terminal may be purchased from any vendor in open market. Initially, the merchant sends a request to an acquirer server to apply for the payment terminal. In one example embodiment, the payment terminal is a point-of-sale (POS) device. In general, POS device is an advanced machine used for accepting payments from a cardholder. Additionally, the payment terminal accepts various kinds of credit card and debit card payments. The payment terminal further issues transaction receipts to maintain record of transactions.
[0032] The merchant sends a request to the acquirer server to apply for the payment terminal for the first time. The acquirer server further performs due diligence of the merchant. For example, the acquirer server performs KYC of the merchant. In general, KYC stands for “Know Your Customer” or “Know Your Client”. In addition, KYC is performed to identify and verify identity of a customer before providing services to the customer. The acquirer server may refuse to provide services to the merchant if KYC of the merchant is not successful.
[0033] After successful KYC of the merchant, the acquirer server performs enrolment of the merchant. The acquirer server issues the smart card to the merchant in place of the payment terminal. The merchant may purchase the payment terminal from any payment terminal vendor in open market. In addition, the payment terminal vendor performs the kernel verification and brand certification of the payment terminal.
[0034] The acquires server pre-configures the smart card with a plurality of configuration parameters. The plurality of configuration parameters includes, but may not be limited to, a private key for the merchant, a first cryptographic key associated with the acquirer server, the merchant identifier, merchant identification number, authentication credentials for the merchant, and uniform resource locator (URL) of the acquirer server.
[0035] The acquirer server issues the smart card to allow the merchant to configure the payment terminal. The merchant may further tap/insert the smart card in the payment terminal to activate the payment terminal. In this way, the smart card establishes a secured communication between the payment terminal purchased from an open vendor, and the acquirer server.
[0036] Upon establishing the secured connection between the payment terminal and the acquirer server, the payment terminal sends a data packet including a merchant identifier to the acquirer server. In one embodiment, the merchant identifier is already stored on the smart card during enrolment of the merchant at the acquirer server. The data packet includes the merchant identifier being encrypted with a first cryptographic key and signed with a private key. The private key is associated with the smart card. In general, encryption is the process of encoding information. The original representation of information (commonly known as 'plaintext') is converted into an alternative form of text (commonly known as 'ciphertext').
[0037] The acquirer server further decrypts the data packet to extract the merchant identifier. The acquirer server performs decryption of the data packet using a second cryptographic key. In general, decryption is the process of conversion of encrypted data back to its original form. In other words, decryption can be considered as a reverse process of encryption.
[0038] The acquirer server further fetches the public key for the corresponding private key of the merchant to establish the secured communication between the payment terminal and the acquirer server. The acquirer server verifies digital signature to verify that the smart card is tapped/dipped/inserted in the payment terminal by the genuine merchant.
[0039] The acquirer server further performs an authentication process to authenticate the smart card to create a secure communication channel for secured data exchange between the payment terminal and the acquirer server. In one example embodiment, the acquirer server sends an authentication request message to a merchant device associated with the merchant. The acquirer server sends the authentication request message to verify authenticity of both the smart card and the merchant device associated with the merchant.
[0040] In such scenario, the acquirer server sends the authentication request message to verify that both the smart card and the merchant device are associated with the merchant. In an example embodiment, the authentication request message is a one-time password (OTP). In general, OTP (also known as one-time pin or one-time authorization code (OTAC) or dynamic password) is a password valid for only one transaction or login session, on a computing device. Such mechanism obviates any possibility of a stolen smart card being used to configure any other payment terminal that does not belongs to the merchant.
[0041] The authentication request message (OTP) is sent to the merchant device associated with the merchant. The merchant further inputs the authentication request message in the payment terminal. In one example embodiment, the merchant may input the authentication request message through keypad of the payment terminal. In another example embodiment, the merchant may input the authentication request message using touchscreen display of the payment terminal. The payment terminal further sends an authentication response message to the acquirer server.
[0042] The authentication response message is securely encrypted with the first cryptographic key and signed by the private key associated with the smart card. The acquirer server receives the authentication response message from the payment terminal. The acquirer server performs verification of the authentication response message. Upon successful verification of the authentication response message, the acquirer server sends an 'access grant message' to the smart card. The payment terminal further sends a request to the acquirer server to download configuration file data. Alternatively, upon unsuccessful verification of the authentication response message, the acquirer server sends access denied message to the smart card to abort/cancel the communication channel created between the payment terminal and the acquirer server.
[0043] In one embodiment, the configuration file data includes, but may not be limited to, merchant category code, supported currency by the payment terminal, supported CVM data, MCC data, and offline verification enabled/disabled data. After downloading the configuration file data, the payment terminal is activated for conducting payment transactions for the merchant. The payment terminal connects with the acquirer server with the smart card.
[0044] In one example embodiment, the payment terminal is now ready for accepting payment transactions from the customer. The customer may visit merchant store to avail services offered by the merchant. The customer may further need to send payment for the availed services to the merchant. The customer may tap/swipe/dip payment card in the payment terminal. The payment card may include any one of debit card, credit card, or ATM card associated with the customer. The payment terminal sends an authentication request to the acquirer server. The acquire server may further follow regular payment flow for completing the payment transaction as known in the art.
[0045] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure allows remote configuration of the payment terminal with the smart card. In addition, the present disclosure provides the smart card pre-configured with the plurality of configuration parameters. Further, the smart card establishes the secure communication between the payment terminal and the acquirer server. Furthermore, the present disclosure performs the authentication process to validate the payment terminal configured with the smart card and the merchant device associated with the merchant.
[0046] Thus, the payment terminal is remotely activated with the smart card without any prior dependency between the smart card and the payment terminal. The authentication of the payment terminal with the smart card, is further explained in detail with reference to FIGS. 1 to 10.
[0047] FIG. 1 illustrates an example representation of an environment 100 related to at least some example embodiments of the present disclosure. The environment 100 is depicted to include a merchant 102 associated with a merchant device 104. The merchant device 104 may be a smartphone, a tablet, a laptop, a computer system or any computing device. In one example embodiment, the merchant device 104 may include a portable device such as laptop, smartwatch, personal digital assistant (PDA), smartphone, and the like. In another example embodiment, the merchant device 104 may include a fixed device such as desktop, workstation, and the like.
[0048] In addition, the environment 100 includes a payment terminal 106, a smart card 108, a network 110, a customer 112, a payment server 118, a server system 114, and a database 116. The basic information, such as details of the merchant 102 may be stored in the database, such as the database 116. In one example embodiment, the database 116 is associated with the server system 114.
[0049] The payment terminal 106 may communicate with the server system 114 via a network, such as the network 110. The network 110 may include wired networks, wireless networks and combinations thereof. Some non-limiting examples of the wired networks may include Ethernet, local area networks (LANs), fiber-optic networks, and the like. Some non-limiting examples of the wireless networks may include cellular networks like GSM/3G/4G/5G/LTE/CDMA networks, wireless LANs, Bluetooth, Wi-Fi or Zigbee networks, and the like. An example of the combination of wired and wireless networks may include the Internet.
[0050] The payment terminal 106 may include, but not limited to, a POS terminal, an ATM terminal, credit card terminal or any terminal equipped with a payment card reader for payment transactions. In an illustrative example scenario, the merchant 102 is associated with the payment terminal 106 (POS device). Examples of the merchant 102 may include any retail shop, restaurant, supermarket or establishment, government and/or private agencies, or any such place equipped with POS terminals, such as the payment terminal 106 (POS device) where customers visit for performing financial transaction in exchange for any goods and/or services or any transaction that requires financial transaction between customers and the merchant 102.
[0051] In one example embodiment, the payment terminal 106 is a POS terminal. In another example embodiment, the payment terminal 106 is a computing device (identical to the merchant device 104) configured to accept payment transactions for the merchant 102. In general, the payment terminal 106 includes a debit card reader and a credit card reader to accept payments. In addition, the payment terminal 106 provides receipts to both the customer 112 and the merchant 102 for payment transactions and maintains history of transactions. The payment terminal 106 enables the merchant 102 to accept payments from the customer 112. In one example embodiment, the customer 112 may pay the merchant 102 for availing one or more services offered by the merchant 102.
[0052] In one example embodiment, the payment terminal 106 includes a display panel to receive input from the merchant 102. In another example embodiment, the payment terminal 106 includes one or more buttons to receive input from the merchant 102. The smart card 108 is either inserted/tapped/dipped inside the payment terminal 106 by the merchant 102. The merchant 102 inserts/taps/dips the smart card 108 inside the payment terminal 106 to activate the payment terminal 106 for accepting payments from the customer 112.
[0053] In an embodiment, the payment terminal 106 (POS device) is provided via serial port connection. In another embodiment, the payment terminal 106 (POS device) is provided via dynamic port connection. In an embodiment, the payment terminal 106 includes a processor that runs one or more applications (mainly written in programming languages such as C, C++, and the like) on the payment terminal 106.
[0054] In one example embodiment, the server system 114 is an acquirer server 122 associated with the merchant 102. In one embodiment, the acquirer server 122 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0055] In another example embodiment, the server system 114 is the payment server 118. In a non-limiting example, the process of payment transactions using the payment card is facilitated by a combination of the payment server 118, an issuer server and the acquirer server 122. In one embodiment, a payment transaction request is sent to the payment server 118 associated with a payment network 120 by the payment terminal 106 using the network 110. The payment network 120 may be used by the payment cards issuing authorities as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transaction data between financial institutions that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0056] To accept payment using the payment card-based payment transaction, a merchant (e.g., the merchant 102) must normally establish an account with a financial institution that is part of a financial payment system. This financial institution is usually called a “merchant bank” or an “acquiring bank” or an “acquirer bank” or simply “acquirer”. In one example embodiment, the acquirer server 122 is associated with the acquirer bank.
[0057] The merchant 102 sends a request to the server system 114. In one example embodiment, the merchant 102 sends the request through the merchant device 104. The merchant 102 sends the request to the server system 114 for configuring and activating the payment terminal 106. In one example embodiment, the payment terminal 106 may be purchased by the merchant 102 from any POS machine vendor in open market. After receiving the request from the merchant 102, the server system 114 performs enrolment of the merchant 102 at the server system 114. The enrolment of the merchant 102 is performed before establishing a communication between the smart card 108 and the payment terminal 106.
[0058] The merchant 102 sends one or more documents to the server system 114. In one example embodiment, the merchant 102 utilizes the merchant device 104 to upload the one or more documents at the server system 114. The one or more documents are identification documents for verifying identity of the merchant 102. The server system 114 further performs KYC (“Know Your Customer” or “Know Your Client”) of the merchant 102. The server system 114 performs KYC of the merchant 102 for providing approval by the server system 114 for issuance of the smart card 108.
[0059] The server system 114 also creates a record of the merchant 102 in the database, such as the database 116 after performing KYC of the merchant 102. The record of the merchant 102 includes data such as bank details of the merchant 102, authentication credentials of the merchant 102 used for provisioning the payment terminal 106, security certificates for personalizing the smart card 108, and the like. The server system 114 further issues the smart card 108 to the merchant 102 for configuring and activating the payment terminal 106.
[0060] The server system 114 configures the smart card 108 before issuing to the merchant 102. The server system 114 configures the smart card 108 with a plurality of configuration parameters. The plurality of configuration parameters includes a private key for the merchant 102, a first cryptographic key associated with the server system 114, a merchant identifier, merchant identification number (MID), authentication credentials for the merchant 102, and provisioning uniform resource locator (URL) of the server system 114.
[0061] The merchant 102 receives the smart card 108 from the server system 114 for configuring the payment terminal 106. The merchant 102 taps/dips/inserts the smart card 108 in the payment terminal 106. The smart card 108 associated with the merchant 102 enables the payment terminal 106 to establish the communication (secured connection) with the server system 114 upon tapping/dipping/inserting the smart card 108 in the payment terminal 106 by the merchant 102.
[0062] The smart card 108 configures the payment terminal 106 for establishing the communication (secured data exchange) between the smart card 108 associated with the merchant 102 and the server system 114. In an embodiment, the smart card 108 utilizes the network 110 for establishing the communication between the payment terminal 106 and the server system 114. In another embodiment, the smart card 108 establishes the communication between the payment terminal 106 and the server system 114 without internet connectivity. In one example embodiment, the smart card 108 fetches authentication data from the payment terminal 106.
[0063] After fetching the authentication data, the smart card 108 reads the merchant identifier from the authentication data. The smart card 108 further fetches connection details from the payment terminal 106. The smart card 108 encrypts the merchant identifier by the first cryptographic key and signs the merchant identifier by the private key associated with the smart card 108. The merchant identifier is encrypted by the first cryptographic key on the server system 114 and signed by the private key associated with the smart card 108 of the merchant 102.
[0064] After reading the merchant identifier, the smart card 108 fetches connection details to establish the communication (secured data exchange) between the payment terminal 106 and the smart card 108. In one example embodiment, the connection details include provisioning uniform resource locator (URL) of the server system 114. The payment terminal 106 further queries the server system 114 with the encrypted merchant identifier. The server system 114 receives a data packet from the payment terminal 106. The data packet includes the encrypted merchant identifier.
[0065] The server system 114 decrypts the data packet to extract the merchant identifier using a second cryptographic key. In addition, the server system 114 fetches the first cryptographic key for corresponding private key of the merchant 102 already stored in the smart card 108. In an embodiment, the server system 114 scans the database 116 to find the merchant profile associated with the merchant identifier created at the time of KYC of the merchant 102 or issuance of the smart card 108. The server system 114 further verifies data signature for validating authenticity of the merchant 102. The data signature is verified to validate that the data signature is being received from the authorized smart card 108. Upon successful verification of the data signature, the server system 114 loads data of the merchant 102 from a repository connected with the server system 114. In general, repository is a central file storage location where data is stored in an organized way. In one example embodiment, the repository is associated with the server system 114.
[0066] The server system 114 performs an authentication process to validate both the payment terminal 106 configured with the smart card 108 and the merchant device 104 associated with the merchant 102. The server system 114 sends an authentication request message to the merchant device 104 associated with the merchant 102 based, at least in part, on the extracted merchant identifier. In one example embodiment, the authentication request message is a one-time password (OTP) sent on the merchant device 104 associated with the merchant 102.
[0067] The merchant 102 receives the authentication request message (OTP) on the merchant device 104. However, the merchant 102 enters/inputs the authentication request message (OTP) on the payment terminal 106. In other words, the payment terminal 106 receives the authentication request message from the merchant 102. In one example embodiment, the authentication request message is input in the payment terminal 106 by the merchant 102 using keypad/buttons of the payment terminal 106. In another example embodiment, the authentication request message is input in the payment terminal 106 by the merchant 102 using touchscreen display of the payment terminal 106.
[0068] The payment terminal 106 further sends the authentication request message to the smart card 108. The smart card 108 encrypts the authentication request message using the first cryptographic key and signs the authentication request message by the private key associated with the smart card 108. The payment terminal 106 further sends an authentication response message to the server system 114. In one example embodiment, the authentication response message is the authentication request message encrypted using the first cryptographic key and signed by the private key associated with the smart card 108. The authentication response message is provided as an input to the payment terminal 106 in response to the authentication request message.
[0069] In one example embodiment, the smart card 108 sends the authentication response message to the server system 114. In another example embodiment, the payment terminal 106 sends the authentication response message to the payment terminal 106. The payment terminal 106 sends the authentication response message to the server system 114 for authenticating validity of the payment terminal 106.
[0070] The server system 114 receives the authentication response message from the payment terminal 106. The server system 114 verifies the authentication response message based, at least in part, on the authentication request message. The server system 114 further sends access grant message or access denied message to the payment terminal 106. The server system 114 sends the access grant message to enable/activate the payment terminal 106 for conducting the payment transactions for the merchant 102. The server system 114 sends the access grant message to the payment terminal 106 upon successful verification of the authentication response message. Alternatively, the server system 114 sends the access denied message to the payment terminal 106 upon unsuccessful verification of the authentication response message. In one example embodiment, after successful verification of the authentication message, the server system 114 captures the merchant identification number (MID) of the merchant 102.
[0071] After successful verification of the authentication response message, the server system 114 generates a symmetric key. In general, symmetric key is a key that is used for both encryption and decryption in cryptography. The server system 114 further encrypts the symmetric key with a public key of the smart card 108 for generating a symmetric cryptographic key. The server system 114 further transmits the symmetric cryptographic key to the payment terminal 106 encrypted using the public key of the smart card 108.
[0072] The server system 114 transmits the symmetric cryptographic key for facilitating a secure communication channel between the payment terminal 106 and the server system 114. In addition, the sever system transmits an authentication verified message to the payment terminal 106 along with a payload. The payload includes the encrypted symmetric cryptographic key for establishing the secure communication channel between the payment terminal 106 and the server system 114.
[0073] The payment terminal 106 further sends the encrypted symmetric cryptographic key to the smart card 108. The smart card 108 further sends the decrypted symmetric cryptographic key to the payment terminal 106 to establish the secured communication channel. The communication channel between the smart card 108, the payment terminal 106, and the server system 114 is established with the symmetric cryptographic key.
[0074] Upon facilitating the secure communication channel between the payment terminal 106 and the server system 114, the server system 114 receives a request from the payment terminal 106 to download a configuration file data in the payment terminal 106. The server system 114 further transmits the configuration file data to the payment terminal 106 for activating the payment terminal 106 for conducting the payment transaction. In addition, the server system 114 transmits the configuration file data via the secure communication channel to the payment terminal 106 to enable the payment terminal 106 for conducting the payment transaction.
[0075] In one example embodiment, the configuration file data includes merchant category code, supported currency by the payment terminal 106, supported CVM data, MCC data and offline verification enabled/disabled data. However, the configuration file data is not limited to above mentioned data.
[0076] After successful download of the configuration file data, the payment terminal 106 sends a security key to the server system 114. The server system 114 further sends the security key to the payment terminal 106. The security key transmitted between the payment terminal 106 and the server system 114 facilitates to perform DUKPT (Derived unique key per transaction) transaction. In cryptography, DUKPT is a key management scheme in which a unique key is used for every transaction, wherein the unique key is derived from a fixed key.
[0077] The smart card 108 activates the payment terminal 106 with the downloaded configuration file data to accept payment transactions for the merchant 102. The merchant 102 may remove the smart card 108 from the payment terminal 106. The payment terminal 106 is activated for conducting the payment transactions for the merchant 102 in real-time.
[0078] In one example embodiment, the customer 112 may visit a facility in which the payment terminal 106 is installed by the merchant 102. In an example, the facility includes a building, shop, organization, restaurant, educational institution, mall, cinema, financial institutions, and the like. The customer 112 further avails any of the one or more services offered by the merchant 102. The customer 112 needs to pay for the service availed by the customer 112. The customer 112 taps/swipes/dips/inserts the payment card in the payment terminal 106. The payment card includes any one of credit card, debit card, ATM card, and the like.
[0079] The payment terminal 106 further sends an authentication request to the server system 114. In one example embodiment, the server system 114 sends the authentication request to the acquirer server 122. The server system 114 further conducts the regular payment flow of the payment transactions performed using the payment terminal 106 as known in the art.
[0080] After successfully executing the payment transaction, the merchant 102 settles the payment transaction by sending a payment request to the server system 114 via a payment network, such as the payment network 120. The network 110 may be used as the payment network 120 by the payment server 118, the server system 114 and the issuer server as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network.
[0081] Some non-exhaustive example embodiments of configuring the payment terminal 106, with the smart card 108, are described with reference to FIGS. 2 to 10.
[0082] FIG. 2 represents a sequence flow diagram 200 of enrolment of the merchant 102 at the server system 114, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 200, references may be made to elements described in FIG. 1. The enrolment may be performed when the merchant device 104 is connected to the server system 114 through the network 110.
[0083] At 202, the server system 114 receives a request from the merchant 102. The merchant 102 may send a request to the server system 114 (the acquirer server 122) for issuance of the new payment terminal 106. The merchant 102 sends the request for the first time to the server system 114. In one example embodiment, the merchant 102 may send the request using the merchant device 104 associated with the merchant 102.
[0084] At 204, the server system 114 receives the request for issuance of the payment terminal 106 from the merchant 102. In response to the request, the server system 114 asks for the one or more documents associated with the merchant 102 as per regulatory compliance. The one or more documents facilitates in verifying the identity of the merchant 102. In one example embodiment, the one or more documents includes, but may not be limited to, company proof of the merchant 102, PAN card details of proprietor, bank account details of the merchant 102, GST document, and LOB (line of business) declaration.
[0085] In addition, company proof of the merchant 102 may include registration proof, shop establishment act certificate, regional state registration certificate, municipal corporation department certificate, GST certificate, utility bill, and the like.
[0086] At 206, the server system 114 receives the one or more documents from the merchant 102. The merchant 102 sends the one or more documents requested by the server system 114. In one example embodiment, the merchant 102 may use the merchant device 104 to upload the one or more documents at the server system 114. In another example embodiment, the merchant 102 may send the one or more documents through mail to the server system 114.
[0087] At 208, the server system 114 performs verification of the one or more documents. In other words, the server system 114 performs KYC of the merchant 102 for verifying the identity. After performing KYC of the merchant 102, the server system 114 provides approval to the merchant 102 for issuance of the payment terminal 106. Additionally, the server system 114 performs enrolment of the merchant 102.
[0088] At 210, the server system 114 creates the record of the merchant 102. In one example embodiment, the record of the merchant 102 is stored in the repository associated with the server system 114. In another example embodiment, the record of the merchant 102 is stored in the database 116. The record of the merchant 102 includes, but may not be limited to, bank account details of the merchant 102, authentication credentials used for provisioning the payment terminal 106, and security certificates used while personalizing the smart card 108.
[0089] At 212, the server system 114 issues the smart card 108 to the merchant 102. The smart card 108 is pre-configured by the server system 114 with the plurality of configuration parameters. The plurality of configuration parameters includes but may not be limited to the private key for the merchant 102 generated and stored by the server system 114 while personalizing the smart card 108, the first cryptographic key associated with the server system 114, the merchant identifier, merchant identification number (MID), authentication credentials for the merchant 102 generated and stored by the server system 114 while personalizing the smart card 108, and provisioning uniform resource locator (URL) of the server system 114.
[0090] FIG. 3A and FIG. 3B represent a sequence flow diagram 300 of provisioning the payment terminal 106 by the merchant 102 with the smart card 108, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 300, references may be made to elements described in FIG. 1. The merchant 102 may connect the payment terminal 106 to the network 110 to access the provisioning uniform resource locator (URL) of the server system 114.
[0091] At 302, the merchant 102 buys the new payment terminal 106. In one embodiment, the payment terminal 106 is a POS device. In addition, the merchant 102 buys the new payment terminal 106 from any vendor in open market so that the payment terminal 106 is not limited to any vendor.
[0092] At 304, the merchant 102 taps/inserts/dips the smart card 108 in the payment terminal 106. In one example embodiment, the merchant 102 dips/inserts the smart card 108 until the payment terminal 106 downloads the configuration file data from the server system 114. In another example embodiment, the merchant 102 taps the smart card 108 on the payment terminal 106 until the configuration file data is downloaded from the server system 114.
[0093] At 306, the payment terminal 106 activates the smart card 108 for establishing the communication (secured data exchange). In one example embodiment, the communication is established between the smart card 108 and the payment terminal 106. In another example embodiment, the communication is established between the payment terminal 106 and the server system 114. In yet another embodiment, the communication is established between the smart card 108 and the server system 114.
[0094] At 308, the payment terminal 106 fetches the authentication data from the smart card 108. In one example embodiment, the authentication data includes the encrypted merchant identifier. The payment terminal 106 fetches the encrypted merchant identifier from the smart card 108.
[0095] At 310, the smart card 108 reads the encrypted merchant identifier to identify the corresponding merchant 102. The smart card 108 reads the encrypted merchant identifier to fetch connection details. In one example embodiment, the smart card 108 reads the encrypted merchant identifier to identify the merchant through merchant details stored at the server system 114 during enrolment of the merchant 102.
[0096] At 312, the payment terminal 106 fetches the connection details from the smart card 108. In one example embodiment, the connection details include provisioning uniform resource locator (URL) of the server system 114. The provisioning URL is uniform resource locator that connects to the server system 114. The payment terminal 106 fetches the connection details to connect to the server system 114.
[0097] At 314, the server system 114 receives a query with the encrypted merchant identifier from the payment terminal 106. The payment terminal 106 queries the server system 114 with the encrypted merchant identifier. As explained above in FIG. 1, the payment terminal 106 sends the data packet including the merchant identifier encrypted by the first cryptographic key and signed with the private key associated with the smart card 108.
[0098] At 316, the server system 114 decrypts the merchant identifier using the second cryptographic key. In one example embodiment, the server system 114 decrypts the data packet including the encrypted merchant identifier using the second cryptographic key.
[0099] At 318, the server system 114 fetches the first cryptographic key for corresponding private key of the merchant 102 already stored in the smart card 108.
[00100] At 320, the server system 114 verifies data signature to validate authenticity of the merchant 102. The data signature is verified to validate that the data signature is being received from the authorized smart card 108. In one example embodiment, the server system 114 verifies the data signature to validate that the smart card 108 is being used by the authorized/genuine merchant 102.
[00101] At 322, the server system 114 loads data of the merchant 102 from the repository connected with the server system 114. In one example embodiment, the repository is associated with the server system 114. In another example embodiment, the server system 114 loads data of the merchant 102 from the database 116.
[00102] At 324, the server system 114 sends the authentication request message to the merchant device 104 associated with the merchant 102 based, at least in part, on the extracted merchant identifier. In one example embodiment, the authentication request message is a one-time password (OTP) sent to the merchant device 104 by the server system 114. In another example, the server system 114 sends the authentication request message to registered contact number of the merchant 102.
[00103] At 326, the authentication request message is received on the registered contact number of the merchant 102. The merchant 102 enters/inputs the authentication request message (OTP) in the payment terminal 106. In one example embodiment, the authentication request message is entered through keypad/buttons of the payment terminal 106. In another example embodiment, the authentication request message (OTP) is entered through touchscreen display of the payment terminal 106.
[00104] At 328, the payment terminal 106 passes the authentication request message to the smart card 108.
[00105] At 330, the smart card 108 receives the authentication request message. The smart card 108 encrypts the authentication request message (OTP) with the first cryptographic key and signs the authentication request message (OTP) with the private key already stored on the smart card 108.
[00106] At 332, the smart card 108 sends the authentication response message (the encrypted and signed authentication request message) to the payment terminal 106.
[00107] At 334, the payment terminal 106 receives the authentication response message. The payment terminal 106 further sends the authentication response message (the encrypted and signed authentication request message) to the server system 114 for authentication. The server system 114 receives the authentication response message from the payment terminal 106.
[00108] At 336, the server system 114 verifies the authentication response message based, at least in part, on the authentication request message. The server system 114 sends access denied message to the payment terminal 106 upon unsuccessful/failed verification of the authentication response message. In one example embodiment, if the authentication response message is not verified at the server system 114, the server system 114 sends the access denied message to the payment terminal 106 and does not establish further connection with the payment terminal 106.
[00109] At 338, upon successful verification of the authentication response message, the server system 114 generates the symmetric key.
[00110] At 340, the server system 114 encrypts the symmetric key with the public key of the merchant 102. The server system 114 encrypts the symmetric key with the public key of the smart card 108 for generating a symmetric cryptographic key.
[00111] At 342, the server system 114 transmits the symmetric cryptographic key to the payment terminal 106 for facilitating the secure communication channel between the payment terminal 106 and the server system 114. In addition, the sever system transmits the authentication verified message to the payment terminal 106 along with the payload. In general, payload is carrying capacity of a transmission unit or a packet. The payload includes the encrypted symmetric cryptographic key for establishing the secure communication channel between the payment terminal 106 and the server system 114.
[00112] At 344, the payment terminal 106 sends the encrypted symmetric cryptographic key to the smart card 108 for establishing the secure communication channel. In other words, the smart card 108 receives the encrypted symmetric cryptographic key from the payment terminal 106.
[00113] At 346, the payment terminal 106 receives the decrypted symmetric cryptographic key from the smart card 108 and the secure communication channel is established between the payment terminal 106 and the server system 114. In one example embodiment, each data packet transmitting between the payment terminal 106 and the server system 114 is encrypted with the symmetric cryptographic key. The secure communication channel between the payment terminal 106 and the server system 114 is established.
[00114] FIG. 4 represents a sequence flow diagram 400 of provisioning the payment terminal 106 by the merchant 102 after establishing the secure communication channel between the payment terminal 106 and the server system 114, in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 400, references may be made to elements described in FIG. 1.
[00115] At 402, the server system 114 receives the request for downloading the configuration file data from the payment terminal 106. The payment terminal 106 sends the request to the server system 114 to download the configuration file data of the payment terminal 106. The payment terminal 106 requests the configuration file data after establishment of the secure communication channel between the payment terminal 106 and the server system 114.
[00116] At 404, the server system 114 transmits the configuration file data to the payment terminal 106 via the secure communication channel to enable the payment terminal 106 for conducting the payment transactions. In one example embodiment, the configuration file data includes, but may not be limited to, supported currency of the payment terminal 106, supported CVM of the payment terminal 106, MCC information, and offline verification enabled/disabled in the payment terminal 106.
[00117] At 406, the server system 114 receives the security key. The payment terminal 106 sends the security key to the server system 114.
[00118] At 408, the server system 114 sends the security key to the payment terminal 106. The security key discussed in 406 and 408 is used to perform DUKPT transaction. In general, DUKPT (Derived unique key per transaction) is a key management scheme used in cryptography. In DUKPT, for every transaction, a unique key is used which is further derived from a fixed key.
[00119] At 410, the server system 114 provisions the payment terminal 106 with the downloaded configuration file data to be used by the merchant 102 for conducting the payment transactions. The server system 114 activates the payment terminal 106 with the smart card 108.
[00120] At 412, the smart card 108 may be removed from the payment terminal 106. The payment terminal 106 is now ready to be used by the merchant 102 for accepting payments from the customer 112.
[00121] At 414, the customer 112 may tap/swipe/dip the payment card in the payment terminal 106. The payment card refers to any one of credit card, debit card, ATM card, and the like. In one example, the payment card belongs to the customer 112.
[00122] At 416, the server system 114 receives an authentication request from the payment terminal 106. The payment terminal 106 sends the authentication request to the server system 114 for conducting the payment transaction.
[00123] At 418, the server system 114 performs the regular payment flow process for conducting the payment transaction as known in the art.
[00124] FIG. 5 illustrates a flow diagram depicting a method 500 for configuring the payment terminal 106 by the server system 114 with the smart card 108, in accordance with an example embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by, for example, the acquirer server 122. Operations of the method 500, and combinations of operation in the method 500, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 500 are described herein may be performed by an application interface that is hosted and managed with help of the acquirer server 122. The method 500 starts at operation 502.
[00125] At operation 502, the method 500 includes receiving, by the server system 114, a data packet from the payment terminal 106 upon establishing a communication between a smart card 108 associated with the merchant 102 and the payment terminal 106. The data packet includes a merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card 108.
[00126] At operation 504, the method 500 includes decrypting, by the server system 114, the data packet to extract the merchant identifier using a second cryptographic key.
[00127] At operation 506, the method 500 includes performing, by the server system 114, an authentication process to validate the payment terminal 106 configured with the smart card 108 and the merchant device 104 associated with the merchant 102.
[00128] At operation 508, the method 500 includes transmitting, by the server system 114, a symmetric cryptographic key to the payment terminal 106 encrypted using the public key of the smart card 108 upon successful authentication. The symmetric cryptographic key is transmitted for facilitating a secure communication channel between the payment terminal 106 and the server system 114.
[00129] At operation 510, the method 500 includes transmitting, by the server system 114, configuration file data via the secure communication channel to the payment terminal 106 to enable the payment terminal 106 for conducting a payment transaction.
[00130] The sequence of operations of the method 500 need not to be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[00131] FIG. 6 illustrates a flow diagram depicting a method 600 for configuring the payment terminal 106 by the acquirer server 122 with the smart card 108, in accordance with another example embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the server system 114 or the payment server. Operations of the method 600, and combinations of operation in the method 600, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 600 starts at operation 602.
[00132] At operation 602, the method 600 includes receiving, by the acquirer server 122, a data packet from the payment terminal 106 upon establishing a communication between a smart card 108 associated with the merchant 102 and the payment terminal 106. The data packet includes the merchant identifier encrypted by a first cryptographic key and signed by a private key associated with the smart card 108.
[00133] At operation 604, the method 600 includes decrypting, by the acquirer server 122, the data packet to extract the merchant identifier using a second cryptographic key.
[00134] At operation 606, the method 600 includes sending, by the acquirer server 122, an authentication request message to the merchant device 104 associated with the merchant 102 based, at least in part, on the extracted merchant identifier.
[00135] At operation 608, the method 600 includes receiving, by the acquirer server 122, an authentication response message from the payment terminal 106. The authentication response message is encrypted using the first cryptographic key and signed by the private key associated with the smart card 108. The authentication response message is provided as an input to the payment terminal 106 in response to the authentication request message.
[00136] At operation 610, the method 600 includes transmitting, by the acquirer server 122, a symmetric cryptographic key to the payment terminal 106 encrypted using the public key of the smart card 108 upon successful authentication. The symmetric cryptographic key is transmitted for facilitating a secure communication channel between the payment terminal 106 and the server system 114.
[00137] At operation 612, the method 600 includes transmitting, by the acquirer server 122, configuration file data via the secure communication channel to the payment terminal 106 to enable the payment terminal 106 for conducting a payment transaction.
[00138] The sequence of operations of the method 600 need not to be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[00139] FIG. 7 is a simplified block diagram of the payment terminal 700 for conducting the payment transaction, in accordance with an embodiment of the present disclosure. The payment terminal 700 is an example of the payment terminal 106 shown in FIG. 1.
[00140] The payment terminal 700 includes a payment card interface 702, a card reader module 704, an input/output module 706, at least one processor 708, a memory 710, a communication interface 712, a printing module 714, a battery 716 and a centralized circuitry 718. The components of the payment terminal 700 provided herein may not be exhaustive and that the payment terminal 700 may include more or fewer components than those depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment terminal 700 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00141] The payment card interface 702 is configured to receive details of a payment card provided by a customer (e.g., the customer 112) for making payment for his/her purchases. In an embodiment, the payment card is inserted into (or swiped in) the payment terminal 700 for performing the payment transaction.
[00142] The card reader module 704 runs scripts such as or similar to EMV scripts (GET scripts) that allow reading of information from a chip of a payment card (credit card, debit card, ATM card, or any other card of the like). The card reader module 704 is also configured to read information stored within magnetic stripes provided in some payment cards. There may be as many as two card reader modules in the payment terminal 700 such that each of which may be configured to read information stored in different types of storages, such as chips and magnetic stripes.
[00143] In an embodiment, the input/output module 706 may include mechanisms configured to receive inputs from and provide outputs to a merchant (e.g., the merchant 102). To that effect, the I/O module 706 may include at least one input interface and/or at least one output interface. In at least one example embodiment, the input interface is configured to receive the PIN associated with the payment card as provided by the customer 112. Examples of the input interface may include, but are not limited to, a keypad, a touch screen, soft keys, a microphone, and the like. Examples of the output interface may include, but are not limited to, a display such as a light emitting diode display, a thin-film transistor (TFT) display, a liquid crystal display, an active-matrix organic light-emitting diode (AMOLED) display, a speaker, a ringer, a vibrator, and the like.
[00144] The processor 708 is configured to execute executable instructions stored in the memory 710 to cause the payment terminal 700 to fetch the authentication data from the smart card 108. The processor 708 is also configured to generate a payment transaction request to be sent to an acquirer server (e.g., the acquirer server 122) for facilitating payment settlement between the payment card of the user and a merchant account of the merchant 102.
[00145] The processor 708 is operatively coupled to the communication interface 712 such that the payment terminal 700 is capable of communicating with a server, such as the acquirer server 122, for sending the payment transaction request using a network (e.g., the network 110). The processor 708 is also configured to send operating instructions to the printing module 714 for initiating printing of a receipt for the merchant 102 as well as the user when the payment transaction is completed. The battery 716 is configured to power the payment terminal 700 so that the payment terminal 700 can be operated for making payments.
[00146] Moreover, the various components of the payment terminal 700, such as the payment card interface 702, the card reader module 704, the I/O module 706, the processor 708, the memory 710, the communication interface 712, the printing module 714 and the battery 716 may be configured to communicate with each other via or through the centralized circuitry 718. The centralized circuitry 718 may be various devices configured to, among other things, provide or enable communication between the components (702-716) of the payment terminal 700. In certain embodiments, the centralized circuitry 718 may be a central printed circuit board (PCB) such as a motherboard, a main board, a system board, or a logic board. The centralized circuitry 718 may also, or alternatively, include other printed circuit assemblies (PCAs) or communication channel media. In some embodiments, the centralized circuitry 718 may include appropriate storage interfaces to facilitate communication among the components (702-716). Some examples of the storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the payment terminal 700 with access to the data stored in a memory.
[00147] Additionally, the payment terminal 700 can include an operating system and various software applications that can provide various functionalities to the payment terminal 700. For example, in some embodiments, the payment terminal 700 is addressable with an Internet protocol and includes an application. In such embodiments, the processor 708 includes software adapted to support such functionality. In some embodiments, the processor 708 executes software to support network management. In particular, this capacity allows software to be downloaded to a plurality of such systems to provide new applications such as application for various possible payment methods using POS terminals and/or updates to existing applications. The operating system and software application upgrades are distributed and maintained through communication to the payment terminal 700 over the payment network 120 of FIG. 1.
[00148] FIG. 8 is simplified block diagram of a server system 800 for real-time configuring of the payment terminal 106 of the merchant 102 with the smart card 108, in accordance with an embodiment of the present disclosure. The server system 800 includes a computer system 802 and a database 804. In an embodiment, the server system 800 is integrated, but not limited to, in the acquirer server 122.
[00149] The computer system 802 includes at least one processor 806 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 808. The components of the computer system 802 provided herein may not be exhaustive and that the computer system 802 may include more or fewer components than that of depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 802 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00150] The processor 806 is operatively coupled to a communication interface 810 such that the computer system 802 is capable of communicating with a remote device 814 such as the merchant device 104, the payment terminal 106, the smart card 108, and the payment server 118, associated with the payment network 120 (shown in FIG. 1), respectively or communicated with any entity connected to the network 110 (shown in FIG. 1) or any constituents of the acquirer server 122. In an embodiment, the communication interface 810 is configured to receive a request from the merchant device 104 for issuance of the payment terminal 106. The server system 800 receives the one or more documents from the merchant 102. The one or more documents are stored in the repository connected with the server system 800. In one example embodiment, the one or more documents are stored in the database 804. In other embodiments, the database 804 is external to the computer system 802 and may be accessed by the computer system 802 using a storage interface 812.
[00151] The processor 806 may also be operatively coupled to the database 804. The database 804 is an example of the database 116. The database 804 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of the merchant 102, transaction data generated as part of sales activities conducted over the payment network 120 including data relating to merchants, payees, or customers, and purchases. The database 804 may also store the one or more documents, bank details of the merchant 102, authentication credentials of the merchant 102 used for provisioning the payment terminal 106, security certificates, and the like. The database 804 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 804 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00152] In some embodiments, the database 804 is integrated within computer system 802. For example, the computer system 802 may include one or more hard disk drives as the database 804. The storage interface 812 is any component capable of providing the processor 806 with access to the acquirer database 804. The storage interface 812 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 806 with access to the acquirer database 804.
[00153] The processor 806 is configured to receive the data packet including the merchant identifier encrypted by the first cryptographic key and signed by the private key associated with the smart card (e.g., 108 of FIG. 1). Upon receiving the data packet, the processor 806 is configured to decrypt the data packet to extract the merchant identifier using the second cryptographic key at the server system (i.e., “server system 114”). In addition, the processor 806 is configured to perform the authentication process to validate the payment terminal (e.g., 106 of FIG. 1) configured with the smart card (e.g., 108 of FIG. 1) and the merchant device (e.g., 104 of FIG. 1) associated with the merchant (e.g., 102 of FIG. 1). Further, the processor 806 is configured to send the authentication request message to the merchant device (e.g., 104 of FIG. 1) associated with the merchant (e.g., 102 of FIG. 1) based, at least in part, on the extracted merchant identifier. Thereafter, the processor 806 is configured to receive the authentication response message from the payment terminal (e.g., 106 of FIG. 1). Upon successful authentication, the processor 806 is configured to transmit the symmetric cryptographic key to the payment terminal (e.g., 106 of FIG. 1) encrypted using the public key of the smart card (e.g., 108 of FIG. 1). The processor 806 is also configured to transmit the configuration file data via the secure communication channel to the payment terminal (e.g., 106 of FIG. 1) to enable the payment terminal (e.g., 106 of FIG. 1) for conducting the payment transaction.
[00154] FIG. 9 is a simplified block diagram of a payment server 900 used for conducting the payment transactions at the payment terminal 106 of FIG. 1 in real-time, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 118 of FIG. 1. The payment server 900, and the server system 114 of FIG. 1 may use the payment network 120 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network.
[00155] The payment server 900 includes a processing system 905 configured to extract programming instructions from a memory 910 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and that the payment server 900 may include more or fewer components than that of depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 900 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00156] Via a communication interface 915, the processing system 905 receives request from a remote device 920, such as the acquirer server 122 the payment terminal 700, the merchant device 104 (e.g., the merchant interface device) associated with the merchant 102, or a customer device hosting a payment gateway application. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 900 includes a database 925. The database 925 also includes transaction processing data such as, Issuer ID, POS ID, country code, acquirer ID, merchant identification number (MID), among others.
[00157] When the payment server 900 receives a payment transaction request from the acquirer server 122 or the payment terminal 700, the payment server 900 may route the payment transaction request to an issuer server (not shown in figure). The database 925 stores transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00158] In one example embodiment, the acquirer server 122 is configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request.
[00159] The processing system 905 further sends the payment transaction request to the issuer server (not shown in figure) for facilitating payment transaction from the remote device 920 (e.g., the payment terminal 700). The processing system 905 is further configured to notify the remote device 920 of the transaction status in form of an authorization response message via the communication interface 915. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server. Alternatively, in one embodiment, the processing system 905 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 915, to the acquirer server 122.
[00160] FIG. 10 represents a block diagram 1000 of the smart card 108 to configure the payment terminal 106, in accordance with an embodiment of the present disclosure. The smart card 108 includes a plurality of components such as a storage medium 1002, a communication interface 1004, and a file system 1006. The storage medium 1002 may further include components such as an application module 1002a and a security module 1002b.
[00161] In an embodiment, the storage medium 1002 includes an EMV chip and/or a magnetic stripe. The storage medium 1002 includes a set of executable instructions including the private key associated with the smart card 108. The storage medium 1002 is configured to be read by the payment terminal 106 upon establishing the communication with the payment terminal 106.
[00162] The application module 1002a is configured to maintain the application required to configure and activate the payment terminal 106. Further, the acquirer server 122 is also configured to provide permissions to the storage medium 1002 or in particular to the application module 1002a to access the security module 1002b and the file system 1006.
[00163] In an embodiment, the server system 114 may store the encrypted merchant identifier in the security module 1002b or the file system 1006 of the smart card 108. In an embodiment, the server system 114 may store the private key in the security module 1002b or the file system 1006 of the smart card 108. In an embodiment, the security module 1002b may encrypt the authentication request message using the first cryptographic key and sign by the private key associated with the smart card 108. In an embodiment, the security module 1002b may decrypt the encrypted symmetric cryptographic key to establish the secure communication channel between the payment terminal 106 and the server system 114. In an embodiment, the security module 1002b may store the security key to perform DUKPT transaction.
[00164] The file system 1006 may store the plurality of configuration parameters. The plurality of configuration parameters includes, but may not be limited to, the private key for the merchant 102, the first cryptographic key associated with the acquirer server 122, the merchant identifier, merchant identification number (MID), authentication credentials for the merchant 102, and provisioning uniform resource locator (URL) of the acquirer server 122. The smart card 108 may be provided by the acquirer server 122, the server system 114, or the payment server 118. The smart card 108, and the acquirer server 122 may communicate with each other through the network 110 of FIG. 1.
[00165] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for configuring any payment terminal to accept payment transactions with a smart card. More specifically, the smart card is used for activating the payment terminal manufactured by any vendor in open market. The merchant may purchase the payment terminal from any vendor in open market. The acquirer server performs KYC of the merchant for the first time when the merchant applies for the payment terminal. The acquirer server further issues the smart card to the merchant in place of the payment terminal. The smart card is pre-configured with the plurality of configuration parameters such as connection details (provisioning uniform resource locator (URL)) of the acquirer server, security keys of the acquirer server, the merchant identifier, merchant identification number (MID), authentication details of the merchant, and the like. The merchant may further tap/insert/dip the smart card in the payment terminal. The smart card enables the payment terminal to establish a secure communication channel between the payment terminal and the acquirer server. The acquirer server also performs the authentication of the payment terminal with the smart card. In no time, the smart card configures and activates the payment terminal to receive payment transactions for the merchant.
[00166] The disclosed methods with reference to FIGS. 1 to 10, or one or more operations of the method 500 and the method 600 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00167] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00168] Particularly, the server system 800 (e.g., the server system 114) and its various components such as the computer system 802 and the database 804 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00169] Various embodiments of the disclosure, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the disclosure has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the disclosure.
[00170] Although various exemplary embodiments of the disclosure are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.