Claims:CLAIMS
We claim:

1. A computer-implemented method, the method comprising:
sending, by a diagnostic device, a communication request to a payment terminal via a diagnostic application running on the diagnostic device using a communication protocol, wherein the diagnostic application is used for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction;
sending, by the diagnostic device, a response to a command received from the payment terminal via the diagnostic application, the response comprising at least one unique identifier for a request to retrieve a configuration data of the payment terminal;
receiving, by the diagnostic device, the configuration data comprising a corresponding value associated with the at least one unique identifier; and
applying, by the diagnostic device, at least one rule of a plurality of rules to determine an inference via the diagnostic application based on the configuration data retrieved from the payment terminal.

2. The method as claimed in claim 1, wherein the diagnostic device is a Near Field Communication (NFC) technology enabled smartphone and wherein the communication protocol for sending the communication request is NFC.

3. The method as claimed in claim 1, wherein the communication request comprises a selection of a diagnostic widget of a plurality of diagnostic widgets present on a User Interface (UI) of the diagnostic application, and wherein each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnostic category for identifying the cause of the payment card not being accepted by the payment terminal.
4. The method as claimed in claim 3, wherein upon selection of the diagnostic widget, the diagnostic device is kept in a predefined range of proximity of the payment terminal to establish the communication.

5. The method as claimed in claim 1, wherein steps of sending the response and receiving the configuration data are performed in iteration prior to applying at least one rule of the plurality of rules to determine at least one inference via the diagnostic application based on the configuration data retrieved from the payment terminal.

6. The method as claimed in claim 5, further comprising:
preparing an analysis report comprising a log of a plurality of inferences, a command-response Application Protocol Data Unit (APDU) raw data, and the configuration data.

7. The method as claimed in claim 6, further comprising:
sending the analysis report to a payment terminal provider server for correction of the payment terminal, the payment terminal provider server configured to send one or more corrective configuration information to the payment terminal over a communication network.

8. The method as claimed in claim 7, further comprising:
sending the analysis report to a payment server configured to send the analysis report to the payment terminal provider server to facilitate the correction of the payment terminal.

9. The method as claimed in claim 1, wherein the payment terminal is a contactless tap and pay Point of Sale (POS) terminal.

10. The method as claimed in claim 1, wherein the payment terminal comprises a contact interface for inserting the payment card and wherein the diagnostic device is configured to communicate with the payment terminal via a hardware interface.

11. A diagnostic device, comprising:
a communication interface configured to:
send a communication request to a payment terminal via a diagnostic application running on the diagnostic device using a communication protocol, wherein the diagnostic application is used for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction;
a memory comprising executable instructions; and
a processor communicably coupled to the communication interface and configured to execute the instructions to cause the diagnostic device to at least:
send a response to a command received from the payment terminal via the diagnostic application, the response comprising at least one unique identifier for a request to retrieve a configuration data of the payment terminal;
receive the configuration data comprising a corresponding value associated with the at least one unique identifier; and
apply at least one rule of a plurality of rules to determine an inference via the diagnostic application based on the configuration data retrieved from the payment terminal.

12. The diagnostic device as claimed in claim 11, wherein the diagnostic device is a Near Field Communication (NFC) technology enabled smartphone and wherein the communication protocol for sending the communication request is NFC.

13. The diagnostic device as claimed in claim 11, wherein the communication request comprises a selection of a diagnostic widget of a plurality of diagnostic widgets present on a User Interface (UI) of the diagnostic application, and wherein each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnostic category for identifying the cause of the payment card not being accepted by the payment terminal.

14. The diagnostic device as claimed in claim 11, wherein upon selection of the diagnostic widget, the diagnostic device is kept in a predefined range of proximity of the payment terminal to establish the communication.

15. The diagnostic device as claimed in claim 11, wherein steps of sending the response and receiving the configuration data are performed in iteration prior to applying at least one rule of the plurality of rules to determine at least one inference via the diagnostic application based on the configuration data retrieved from the payment terminal.

16. The diagnostic device as claimed in claim 15, wherein the diagnostic device is further caused to:
prepare an analysis report comprising a log of a plurality of inferences, a command-response Application Protocol Data Unit (APDU) raw data, and the configuration data.

17. The diagnostic device as claimed in claim 16, wherein the diagnostic device is further caused to:
send the analysis report to a payment terminal provider server for correction of the payment terminal, the payment terminal provider server configured to send one or more corrective configuration information to the payment terminal over a communication network.

18. The diagnostic device as claimed in claim 17, wherein the diagnostic device is further caused to:
send the analysis report to a payment server configured to send the analysis report to the payment terminal provider server to facilitate correction of the payment terminal.

19. A server system in a payment network, the server system comprising:
a communication module configured to:
display a User Interface (UI) of a diagnostic application running on a diagnostic device, the UI comprising a plurality of diagnostic widgets, wherein each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnosis category for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction; and
receive an analysis report prepared by the diagnostic application, the analysis report comprising an inference determined based at least in part on applying at least one rule of a plurality of rules on a configuration data retrieved from the payment terminal, wherein the configuration data is retrieved by the diagnostic application upon establishing a communication with the payment terminal based on a selection of a diagnostic widget;
a memory comprising executable instructions; and
a processing module communicably coupled to the communication module and configured to execute the instructions to cause the server system to at least:
facilitate correction of the payment terminal based on the analysis report wherein the payment card is accepted by the payment terminal to process the payment transaction upon the correction.

20. The server system as claimed in claim 19, wherein for facilitating correction of the payment terminal, the server system is further caused to:
send the analysis report to a payment terminal provider server, wherein the payment terminal provider server is configured to review the analysis report and wherein the payment terminal provider server is configured to send one or more corrective configuration information to the payment terminal, the payment terminal configured to update the one or more corrective configuration information.
, 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 DIAGNOSING MALFUNCTIONS OF A PAYMENT TERMINAL

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 DIAGNOSING MALFUNCTIONS OF A PAYMENT TERMINAL

TECHNICAL FIELD
[0001] The present disclosure relates to facilitating diagnostic services for financial transactions and, more particularly to, methods and systems for diagnosing malfunctions in scenarios when a payment terminal is not able to accept a payment card to process a payment transaction.

BACKGROUND
[0002] Nowadays, most users use several banking cards, such as credit cards, debit cards, prepaid cards, etc., for performing financial transactions (e.g., payment transaction). The various banking cards are herein referred to as payment cards. Different types of payment cards are increasingly used for making payments through various channels such as physical card swipe at point-of-sale (POS) terminals, contactless payments, Quick Response (QR) code payments etc. A traditionally used magnetic stripe card has information stored on the back of the card. A chip and Personal Identification Number (PIN) card or a chip and signature card contain embedded microprocessors that provide strong transaction security features and other application capabilities that are generally not possible with traditional magnetic stripe cards. Moreover, a contactless card or payment-enabled contactless device uses short-range wireless technology to make secure contactless payments through a contactless-enabled checkout terminal (e.g., a Point of Sale (PoS) terminal with a contactless symbol). The contactless card comes with Near Field Communication (NFC) chip that allows short-range data transfer without the need to touch the PoS terminal. Further, a high-end payment terminal / PoS terminal includes features, such as, but not limited to, colour display, Wi-Fi connectivity, touch screen, camera, barcode reader, speaker, GPS, security, and the like. Moreover, a payment terminal may be enabled to support all forms of electronic payments including chip and PIN, chip and signature, magnetic stripe, signature capture, NFC/contactless and the like.
[0003] Deployment of contactless technology in the new Europay®, Mastercard® and Visa® (EMV) markets has raised a lot of issues / malfunctions related to acceptance devices (e.g., a contactless PoS terminal) and their configurations. For example, a payment terminal is shown and configured to accept each contactless card from three different enterprises at a merchant facility. However, a payment transaction conducted using one of the contactless cards gets failed. Normally, if a merchant is facing problems with an acceptance device at a very high volume, then only he may take the issue forward for resolving. Currently, to diagnose such acceptance related issues, the payment terminal has to be inspected by a terminal vendor, an acquirer or an actual terminal provider to identify the problem. As many entities are involved only for raising the issue with the terminal, the process of identifying the cause and correction of the cause also takes a longer time. Since payment terminals are well secured from the perspective of retrieval of data present in them, it is difficult to debug the payment terminals in the field (i.e., at merchant facility) and identify the wrong or missing configuration which caused the payment terminals to behave in an unacceptable fashion.
[0004] Accordingly, there is a need for techniques that enable detection of malfunctions of the payment terminal quickly at a merchant facility itself and facilitate correction of the payment terminal based on identification of the root cause.

SUMMARY
[0005] Various embodiments of the present disclosure provide systems, methods, electronic devices and computer program products for diagnosing malfunctions of a payment terminal.
[0006] In an embodiment, a computer-implemented method is disclosed. The method includes sending, by a diagnostic device, a communication request to a payment terminal via a diagnostic application running on the diagnostic device using a communication protocol. The diagnostic application is used for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction. The method includes sending, by the diagnostic device, a response to a command received from the payment terminal via the diagnostic application. The response includes at least one unique identifier for a request to retrieve a configuration data of the payment terminal. The method includes receiving, by the diagnostic device, the configuration data including a corresponding value associated with the at least one unique identifier. The method includes applying, by the diagnostic device, at least one rule of a plurality of rules to determine an inference via the diagnostic application based on the configuration data retrieved from the payment terminal.
[0007] In another embodiment, a diagnostic device is provided. The diagnostic device includes a communication interface configured to send a communication request to a payment terminal via a diagnostic application running on the diagnostic device using a communication protocol, wherein the diagnostic application is used for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction. The diagnostic device includes a memory including executable instructions and a processor communicably coupled to the communication interface. The processor is configured to execute the instructions to cause the diagnostic device to at least to send a response to a command received from the payment terminal via the diagnostic application. The response includes at least one unique identifier for a request to retrieve a configuration data of the payment terminal. The diagnostic device is caused to receive the configuration data including a corresponding value associated with the at least one unique identifier. The diagnostic device is caused to apply at least one rule of a plurality of rules to determine an inference via the diagnostic application based on the configuration data retrieved from the payment terminal.
[0008] In yet another embodiment, a server system in a payment network is provided. The server system includes a communication module configured to display a UI of a diagnostic application running on a diagnostic device. The UI includes a plurality of diagnostic widgets. Each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnosis category for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction. The communication module is further configured to receive an analysis report prepared by the diagnostic application. The analysis report includes an inference determined based at least in part on applying at least one rule of a plurality of rules on a configuration data retrieved from the payment terminal. The configuration data is retrieved by the diagnostic application upon establishing a communication with the payment terminal based on a selection of a diagnostic widget. The server system includes a memory including executable instructions and a processing module communicably coupled to the communication module. The processing module is configured to execute the instructions to cause the server system to at least facilitate correction of the payment terminal based on the analysis report. The payment card is accepted by the payment terminal to process the payment transaction upon the correction.

BRIEF DESCRIPTION OF THE FIGURES
[0009] 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:
[0010] FIG. 1 illustrates an example representation of an environment, in which at least some example embodiments of the present disclosure can be implemented;
[0011] FIG. 2 illustrates a command - response APDU flow between a payment card and a payment terminal during a payment transaction, in accordance with an example embodiment;
[0012] FIG. 3A represents a format of a command-APDU, in accordance with an example embodiment;
[0013] FIG. 3B represents a format of a response-APDU, in accordance with an example embodiment;
[0014] FIG. 4A represents a structure of a data object, in accordance with an example embodiment;
[0015] FIG. 4B illustrates a sequence flow diagram representing a command – response APDU exchange between the payment card and the payment terminal using a Data Object List (DOL), in accordance with an example embodiment;
[0016] FIG. 5 represents a User Interface (UI) of a diagnostic application for selecting a diagnosis category to identify a cause of the payment card not being accepted by the payment terminal to process the payment transaction, in accordance with an example embodiment;
[0017] FIG. 6 represents raw data retrieved by a diagnostic device from the payment terminal using the diagnostic application, in accordance with an example embodiment;
[0018] FIG. 7 represents raw data retrieved by the diagnostic device from the payment terminal using the diagnostic application, in accordance with another example embodiment;
[0019] FIG. 8 illustrates a chart representing a plurality of rules applied to make a plurality of inferences on the values retrieved by the diagnostic application in FIG. 7, in accordance with an example embodiment;
[0020] FIG. 9 represents raw data retrieved by the diagnostic device from the payment terminal using the diagnostic application, in accordance with yet another example embodiment;
[0021] FIG. 10 is a schematic representation of an analysis report prepared after diagnosing one or more malfunctions of the payment terminal, in accordance with an example embodiment;
[0022] FIG. 11 is a sequence flow diagram representing correction of a payment terminal, in accordance with an example embodiment;
[0023] FIG. 12 is a sequence flow diagram representing correction of the payment terminal, in accordance with another example embodiment;
[0024] FIG. 13 illustrates a flow diagram of a method for diagnosing malfunctions of a payment terminal, in accordance with an example embodiment;
[0025] FIG. 14 is a simplified block diagram of a server system, in accordance with one embodiment of the present disclosure;
[0026] FIG. 15 is a simplified block diagram of a payment server, in accordance with one embodiment of the present disclosure;
[0027] FIG. 16 is a simplified block diagram of the payment terminal used for the payment transaction, in accordance with one embodiment of the present disclosure; and
[0028] FIG. 17 shows simplified block diagram of a diagnostic device capable of implementing the various embodiments of the present disclosure.
[0029] 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
[0030] 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.
[0031] 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” at various places in the specification is 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.
[0032] 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.
[0033] 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" or “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 digital wallet or other payment application.
[0034] 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 operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard®.
[0035] 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 used to fund a financial transaction to a merchant or any such facility 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 and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. A payment card may be magnetic stripe card, a chip and PIN card, a chip and signature card, or a Near Field Communication (NFC) enabled contactless card. Alternatively, or additionally, the payment card may be embodied in form of data (e.g., a digital token) stored in a user device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0036] The term “payment terminal”, used throughout the description, refers to a transaction device such as a Point of Sale (PoS) terminal (alternatively referred to as “PoS terminal” or “terminal”) which interfaces with the payment cards to make electronic fund transfers. A typical payment terminal may include a secure keypad (e.g., a PIN pad) for entering PIN, a screen, a means of capturing information from the payments cards (i.e., contact or contactless) and a network connection to access the payment network for authorization. The contact interface of the payment terminal allows the payment card to be inserted into / dipped into (e.g., a chip and PIN card) or swiped through (e.g., a magnetic stripe card) the payment terminal. The contactless interface of the payment terminal allows the payment card to be tapped on the payment terminal and communicate via Near Field Communication (NFC) technology. Moreover, a transaction device such as an NFC enabled smartphone with a payment terminal application installed therein can also communicate with the NFC enabled payment card in contactless manner. Further, a dedicated hardware reader can be connected to an NFC enabled smartphone with a payment terminal application installed therein to allow the payment card to be inserted into / dipped into or swiped through the smartphone.
[0037] The term “diagnostic device” used throughout the description, refers to any electronic device capable of communicating with the payment terminal in a contactless manner or with a contact interface. The electronic device may be equipped with a diagnostic application capable of diagnosing one or more malfunctions of the payment terminal. The electronic device may be an NFC enabled smartphone with the diagnostic application installed therein to support a contactless communication. An appropriate hardware such as a Universal Serial Bus (USB) or a Bluetooth connected card emulator may be used along with the smartphone for communicating with the payment terminal via the contact interface.

OVERVIEW
[0038] Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for diagnosing malfunctions of a payment terminal.
[0039] In various example embodiments, the present disclosure provides a diagnostic device including a diagnostic application for identifying a cause of a payment card not being accepted by a payment terminal to process a payment transaction. The diagnostic application includes a plurality of rules to be applied via a selection of a diagnostic widget of a plurality of diagnostic widgets present on a User Interface (UI) of the diagnostic application. Each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnosis category for identifying a cause of the payment card not being accepted by the payment terminal to process the payment transaction.
[0040] The diagnostic device is an electronic device (e.g., smartphone) capable of sending a communication request to the payment terminal via the diagnostic application. The communication request may be sent via a contactless or a contact interface. For example, an NFC enabled smartphone with the diagnostic application running therein can be tapped on the payment terminal having the NFC protocol enabled. Alternatively, USB or Bluetooth protocol can be used to connect the smartphone with the payment terminal via the contact interface.
[0041] Upon establishing the communication, an Application Protocol Data Unit (APDU) based data exchange occurs between the diagnostic device and the payment terminal. There are two categories of APDUs, namely, command-APDUs and response-APDUs. Accordingly, a command is received from the payment terminal by the diagnostic device via the diagnostic application. A response to the command (e.g., an application selection command) is sent by the diagnostic application that includes at least one unique identifier (e.g., a tag accompanied by a length) for a request to retrieve a configuration data (e.g., a value associated with the tag) of the payment terminal based on the selected diagnostic widget.
[0042] A subsequent command that includes the requested configuration data is sent to the diagnostic application from the payment terminal. The configuration data includes a corresponding value (of the length) associated with the at least one unique identifier (i.e., tag). At least one rule of the plurality of rules is applied by the diagnostic application to determine an inference based on the configuration data received from the payment terminal. The process of retrieving the configuration data is iteratively performed (repeated) until the diagnostic application has required data to determine a plurality of inferences by applying the plurality of rules. The plurality of inferences is logged in an analysis report prepared for enlisting the cause of the payment card not being accepted at the payment terminal.
[0043] The diagnostic device is configured to send the analysis report to a payment terminal provider server for correction of the payment terminal. From the analysis report, the payment terminal provider server is enabled to recognise and review the malfunction (e.g., missing or wrong configuration in the payment terminal) of the payment terminal and is configured to send corrective configuration information to the payment terminal over a communication network. In some scenarios, the payment terminal may be required to be physically sent to the payment terminal provider for the fault corrections. Alternatively, the analysis report is sent to a payment server configured to send the analysis report to the payment terminal provider server via an acquirer server to facilitate correction of the payment terminal. Various example embodiments of present disclosure are described hereinafter with reference to FIGS. 1 to 17.
[0044] FIG. 1 illustrates an example representation of an environment 100, in which at least some example embodiments of the present disclosure can be implemented. In an example scenario, a user (not shown) performs a financial transaction using a payment card 104. The payment card 104 is a contactless payment card i.e., a symbol that denotes Wi-Fi is printed on the payment card 104. The user is provided with the payment card 104 (hereinafter alternatively referred to as “card 104”) by a card issuer such as an issuer bank. A corresponding issuer server 135 is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which the user may have an account, which issues a payment card, such as a credit card or a debit card with a chip and PIN and contactless payment facility. In various embodiments, the payment card 104 is a magnetic stripe card or a chip and PIN card or a chip and signature card that needs to be inserted or dipped into a PoS terminal via a contact interface.
[0045] The user can use the payment card 104 to tender payment for a purchase from a merchant via a tap and pay transaction device 102. The tap and pay transaction device 102 is an NFC enabled PoS terminal and is hereinafter referred to as “payment terminal 102” or “terminal 102”. Contactless payment is a secure method for consumers to purchase products or services using a debit, credit, or smartcard / a chip card, or a key fob or a smartphone by using RFID technology or near-field communication (NFC) technology. To make a contactless payment, the card 104 is tapped on the terminal 102. The main advantage of contactless payment is that it speeds up transactions by eliminating the need for a customer to enter a PIN or provide a signature. Further, the check-out line waiting period is lessened, therefore, both the merchant and customer save time when contactless payment is used. Another benefit of contactless payment cards for banks and credit card issuers is that consumers who tap tend to use their cards more frequently. In various embodiments, the payment terminal 102 is capable of facilitating electronic payment via a contact interface from the payment card 104.
[0046] To accept payment, a merchant establishes an account with a financial institution that is part of the financial payment system. This financial institution is usually called the “merchant bank” or the “acquiring bank” or “acquirer bank” or simply “acquirer”. The acquirer server 130 is associated with the acquirer bank.
[0047] A payment network 145 may be used by the payment cards issuing authorities as a payment interchange network. Using the payment network 145, the computers of the acquirer bank / the acquirer server 130 or the merchant processor will communicate with the computers of the issuer / the issuer server 135 to determine whether the customer’s account is in good standing and whether the purchase is covered by the customer’s available account balance. Based on these determinations, authorization of the payment transaction is declined or accepted. When the payment transaction is authorized, the available balance of the customer’s account is decreased.
[0048] However, there are many situations when a contactless payment gets failed due to the terminal 102 not being able to accept a payment from the card 104 even if the terminal 102 is shown to be configured to accept the payment. In such cases, the terminal 102 needs to be manually taken to the terminal provider facility for fixing the malfunction or getting a replacement. This requires a lot of time for the correction to happen. Many times, it is only a missing or a wrong configuration inside the terminal 102 that needs to be fixed. For such a small correction, if the terminal 102 needs to be sent to the terminal provider facility, it becomes a trouble for the merchant as well.
[0049] Various embodiments of the present disclosure provide mechanisms such that malfunctions of the terminal 102 are detected at the merchant facility itself and a detailed analysis report is prepared that can be sent to the terminal provider for review. Thereafter, only if the need arises, the terminal 102 is sent to the terminal provider facility. Otherwise, a payment terminal provider server 125 associated with payment terminal provider of the terminal 102 sends one or more corrective configuration information over a communication network 150 (e.g., via Internet or offline).
[0050] In at least one embodiment, detection of malfunctions of the terminal 102 is facilitated via a diagnostic application 110 running on a diagnostic device 106 (e.g., a smartphone 106). The diagnostic application 110 is facilitated by a payment server 140 associated with the payment network 145. In various embodiments, the diagnostic application 110 may be facilitated by the payment terminal provider server 125 or a third-party server. The diagnostic device 106 is any electronic device with an inbuilt NFC chip that enables the electronic device to communicate with the terminal 102 for diagnosing malfunctions of the terminal 102 in a contactless manner. For a contact interface, a USB or Bluetooth enabled card emulator may be used to connect the diagnostic device 106 to the terminal 102.
[0051] Some non-exhaustive examples of the diagnostic device 106 include, but are not limited to, a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a voice activated assistant, a Virtual Reality (VR) device, a laptop and the like. The diagnostic application 110 (hereinafter alternatively referred to as “application 110”) can be a pre-installed debug application on the diagnostic device 106 or can be downloaded by a user. In one embodiment, the user is a field agent authorized to use the application 110 at a merchant facility. Alternatively, a volunteer, (who is entitled to get rewards for using the application 110), employees of the payment network 145, employees or field testers of the payment terminal provider, merchant etc. may be the user to use the application 110 for diagnosing the malfunctions of the terminal 102.
[0052] A User Interface 108 (UI 108) of the diagnostic application 110 is shown to display a plurality of diagnostic widgets 112a, 112b and 112c. Each diagnostic widget (i.e., 112a, 112b, and 112c) corresponds to a selectable diagnosis category (e.g., cardholder verification) for identifying a cause of the payment card 104 not being accepted by the payment terminal 102 to process the payment transaction. Once a diagnostic category is selected, corresponding APDU exchange starts between the diagnostic device 106 and the terminal 102. Alternatively, the APDU exchange starts automatically without the need of selecting a diagnostic category using a corresponding diagnostic widget. The configuration data retrieved from the terminal 102 by the application 110 is logged in an analysis report that is shared with the payment terminal provider server 125 for understanding the malfunction of the terminal 102.
[0053] The diagnostic device 106, the issuer server 135, the acquirer server 130, the payment terminal provider server 125, the payment server 140, the payment terminal 102, and the payment card 104 communicate with one another using the communication network 150. Examples of the communication network 150 may include any type of wired network, wireless network, or a combination of wired and wireless networks. A wireless network may be a wireless local area network (“WLAN”), a wireless wide area network (“WWAN”), or any other type of wireless network now known or later developed. Additionally, the network 150 may be or include the Internet, intranets, extranets, microwave networks, satellite communications, cellular systems, personal communication services (“PCS”), infrared communications, global area networks, or other suitable networks, etc., or any combination of two or more such networks. Some non-exhaustive example embodiments of diagnosing one or more malfunctions of the payment terminal 102 and facilitating correction of the malfunctions are described with reference to the following description, particularly with reference to FIG. 2 to FIG. 17.
[0054] FIG. 2 illustrates a command–response APDU flow 200 between a payment card and a payment terminal during a payment transaction, in accordance with an example embodiment. An Application Protocol Data Unit (APDU) is a data unit transferred between the terminal 102 and card 104 when the card 104 is tapped on the terminal 102 for processing the payment transaction. Every transaction consists of multiple APDU exchanges to read the data from the card 104 and perform the necessary processing steps. Any exchange of data is initiated by the terminal 102 by sending a command-APDU, to which the card 104 replies with a response-APDU. A command-APDU is an APDU that is sent from the terminal 102 to the card 104 whenever the terminal 102 needs to communicate with the card 104. A response-APDU is an APDU that is sent from the card 104 to the terminal 102 in response to a command-APDU received from the terminal 102.
[0055] The terminal 102 is required to select a contactless application, and activation of the appropriate kernel for processing the payment transaction. Different kernels are used for different Application Definition File (ADF) names. For example, for a payment interchange network 1 ADF name, Kernel 2 is used; and for a payment interchange network 2 ADF name, Kernel 3 is used. Based on the chosen Kernel, different procedures run to complete a payment transaction.
[0056] The card 104 includes a list of supported applications 202. Proximity Payment System Environment (PPSE) is an optional mechanism for the card 104 to store a directory structure that holds records containing the list of applications that are supported by the card 104. For multi-brand acceptance, this allows the terminal 102 to quickly obtain all the available brands and applications with a single command and to make an immediate choice based on priority and kernel availability. A set of SELECT command-response exchange 205 occurs for application selection 204 as shown in FIG. 2. The terminal 102 attempts to obtain the directory listing of all the card applications from the card's PPSE. The terminal 102 is configured to select an application on the card 104, so that the card 104 can supply the correct data records for the payment transaction.
[0057] To select an application, Application Identifier - AID is used. The terminal 102 also includes a list containing an Application Identifier (AID) of every application that it is configured to support. The terminal 102 sends a SELECT (AID) command. For example, the AID of a Mastercard Standard credit/debit card is A0000000041010. If several such AIDs come in a response from the card 104 and the terminal 102 is able to work with several applications, the terminal 102 displays a list and prompts to provide a priority to select the needed application. If the terminal 102 does not support any of the applications, the operation is rejected by the terminal 102. The terminal 102 generates a candidate list of applications that are supported by both the terminal 102 and the card 104. Sometimes, the application selection 204 is performed after the candidate list has been created by the terminal 102 and the application to use has been selected.
[0058] After receiving a SELECT (AID) command, the card 104 sends a response to the terminal 102 that includes a Processing Options Data Object List (PDOL) to request a data from the terminal 102. Accordingly, a set of GET PROCESSING OPTIONS (GPO) command-response exchange 215 occurs between the terminal 102 and the card 104 to read application data 208. In this stage, the terminal 102 provides the card 104 with any data that the card 104 requests in PDOL and gets the processing options (i.e., GPO). The PDOL is a list of data required by the card 104 at the beginning of the read application data 208 stage from the terminal 102. The terminal 102 uses the DOL processing rules to format the requested data and sends it to the card 104 in the GPO command.
[0059] The card 104 supplies Application File Locator (AFL), which is used by the terminal 102 to read the application data records (see, 206) from the card 104. These records include the card Primary Account Number (PAN) and expiry date, tags of information that are used for transaction processing such as cardholder verification and card authentication. The AFL is a list of application data records (see, 206) present on the card 104, and the terminal 102 uses the AFL to read application data 208 from the card 104. The AFL also indicates which, if any, of the data records should be used by the terminal 102 as part of the input to the data authentication process.
[0060] Next, a set of INTERNAL AUTHENTICATE command-response exchange 225 occurs between the terminal 102 and the card 104 to perform offline data authentication 212. There are three types of offline data authentication that can be performed, but the method to be used depends on the capabilities of the card 104 and terminal 102. Online-only terminals are not required to support data authentication, but all other terminals support both Static Data Authentication (SDA) and Dynamic Data Authentication (DDA) and may also support Combined Data Authentication (CDA). SDA is simply signed data on the private key of the issuing bank. For DDA, the terminal 102 sends a random number and the card 104 signs it using its private key (see, generate dynamic cryptogram 210), and the terminal 102 verifies this signature using the card certificate obtained earlier by making sure that the card 104 does have a private key. CDA is a combination of SDA and DDA.
[0061] Next, a set of GET DATA command-response exchange 235 and a set of VERIFY command-response exchange 245 are performed between the terminal 102 and the card 104 for a cardholder verification 218. The card 104 includes a list of cardholder verification methods that it supports, and the conditions under which they are required to be applied. A Cardholder Verification Method (CVM) is a means of checking that the user of a card is the genuine cardholder. The terminal 102 navigates through this list and attempts the first method it finds for which the condition is met. If a method fails, the terminal 102 checks whether additional methods are allowed. Some examples of the methods of cardholder verification include signature checking and PIN entry (see, 214). The set of VERIFY command-response exchange 245 is used to verify the PIN (see, 216).
[0062] Next, the terminal 102 performs analysis of terminal actions (see, 220). At this stage, the terminal 102 analyses the results of the previous steps such as the offline data authentication 212, the cardholder verification 218, processing restrictions (optional) and terminal risk management (optional) of the transaction. Based on the results of the analysis, the terminal 102 informs the card 104 that the terminal 102 proposes whether to conduct the operation online, allow it to be conducted offline or reject the operation. This is achieved by considering Terminal Verification Results (TVR) that is a collection of indicators that the terminal sets to show which incidents have occurred whilst processing the current transaction (e.g., card is expired, cardholder verification has failed, etc.). Together with Transaction Status Information (TSI), TVR enables the card 104 to manage risk and determine the correct outcome for the transaction. The TSI is a collection of indicators that the terminal sets to show which processing steps have been performed on the current transaction (e.g., cardholder verification 218, offline data authentication 212 etc.).
[0063] Next, A GENERATE APPLICATION CRYPTOGRAM (FIRST) command 255 is sent by the terminal 102 to the card 104. The card 104, having received the command data relating to the transaction, the terminal 102 and the results of the terminal analysis, in turn, performs its own risk management procedures known as card action analysis. Based upon the type of cryptogram requested by the terminal 102, and the result of any additional risk analysis that the card 104 chooses to perform, the card 104 decides which type of cryptogram to generate, subject to certain logic rules (e.g., the card is not permitted to request offline acceptance of the transaction if the terminal requested an online authorization). If the card 104 decides to authorize or decline the transaction, then the terminal 102 proceeds directly to transaction completion.
[0064] The outcome of the terminal action analysis 220 is used as an input during the first card action analysis 222. During the first card action analysis 222, the card 104 sends a GENERATE APPLICATION CRYPTOGRAM (FIRST) response 265 to the terminal 102. A Card Risk Management Data Object List (CDOL) is a list of data that the card 104 requires during the card action analysis. CDOL1 is used during the first card action analysis 222. The CDOL1 includes a list of data objects (e.g., tag and length) to be passed to the terminal 102 in the response 265 to the GENERATE APPLICATION CRYPTOGRAM (FIRST) command 255. The card 104 may further propose that online authorization 224 is required. The terminal 102 must perform the action that the card 104 requested during card action analysis by either performing online processing 226 or proceeding directly to transaction completion (see, 230).
[0065] The online processing 226 enables the card issuer to analyse the transaction details and then decide whether it wishes to authorise or reject the transaction. This allows the issuer to check the account status and apply criteria based upon acceptable limits of risk defined by the card issuer, the payment scheme and the acquirer. The result of the online processing 226 is used as an input during the second card action analysis 228. A GENERATE APPLICATION CRYPTOGRAM (SECOND) command 275 is sent by the terminal 102 to the card 104. CDOL2 is used during the second card action analysis 228. The CDOL2 includes list of data objects (e.g., tag and length) to be passed to the terminal 102 in a GENERATE APPLICATION CRYPTOGRAM (SECOND) response 285.
[0066] When the card action analysis and online processing 226 have been completed, the card 104 is removed. If the transaction has been authorized, the payment is submitted for settlement, any goods or services are provided and the transaction gets completed (see, 230).
[0067] FIG. 3A represents a format of a command-APDU 300A, in accordance with an example embodiment. An APDU is a data unit transferred between the terminal 102 and card 104. Any exchange of data is started by the terminal 102 sending a command-APDU (hereinafter alternatively referred to as “command”), to which the card 104 replies with a response-APDU (hereinafter alternatively referred to as “response”). Without limiting the scope of the present disclosure, there are four different cases of APDU. First case is where the command includes a header and the response includes a trailer. Second case is where the command includes a header plus number of data bytes expected in the response (Le) and the response includes data plus trailer. Third case is where the command includes header plus data and the response includes a trailer. Fourth case is where the command includes a header plus data plus number of data bytes expected in the response (Le) and the response includes data plus trailer. The fourth case command-APDU 300A is represented in FIG. 3A.
[0068] A Command is an APDU that is sent from the terminal 102 to the card 104 whenever the terminal 102 needs to communicate with the card 104. The command-APDU 300A includes a mandatory header 308 and an optional trailer 310 as shown in a row 304. A plurality of fields 306a, 306b, 306c, 306d, 306e, 306f and 306g are represented in a row 302. The mandatory header 308 further includes the fields 306a to 306d namely, CLA 306a, INS 306b, P1 306c and P2 306d. CLA 306a is a class byte (e.g., 0x00). INS 306b is an instruction byte (e.g., 0xA4 is a SELECT command and 0xB2 is READ RECORD command). P1 306c is a Parameter 1 byte and the value and meaning depends on the instruction code (INS). P2 306d is a Parameter 2 byte and the value and meaning depends on the instruction code (INS). The optional trailer 310 includes the fields 306e to 306g, namely, Lc 306e, data 306f, and Le 306g. Lc 306e is a number of data bytes sent to the card (i.e., length of command data). Data 306f is a data byte. Le 306g is a number of data bytes expected in the response (i.e., length of expected response data). Examples of command-APDU 300A include select file, read record, get response, get processing operations, generate cryptogram, get data and the like.
[0069] FIG. 3B represents a format of a response-APDU 300B, in accordance with an example embodiment. The card 104 executes the command-APDU 300A and sends the response-APDU 300B back to the terminal 102. The response-APDU 300B includes an optional body 318 consisting of data 316a and a mandatory trailer 320 with two status bytes SW1 316b and SW2 316c. This is shown in corresponding rows 312 and 314. SW1 and SW2, in combination, are the status word (SW). If the status word has the value 0x9000 (i.e., SW1 = 0x90, SW2=0x00), the command is successfully executed by the card 104. Further, if the status word has the value 0x61XX (i.e., SW1 = 0x61, SW2=0xXX), it means the response has more data and the length of the data is SW2. Other examples of the response-APDU 300B include a warning response and an error response. For example, if the status word has the value 0x6281 (i.e., SW1 = 0x62, SW2=0x81), it means the return data is corrupted. Further, if the status word has the value 0x6A82 (i.e., SW1 = 0x6A, SW2=0x82), it is an error response denoting the file is not found.
[0070] FIG. 4A represents a structure of a data object 400A, in accordance with an example embodiment. An EMV debit/credit payment application in the terminal 102 includes a set of data elements that can be accessed by the terminal 102 after a successful selection of the application (i.e., application selection 204 stage of FIG. 2). A data element is the smallest information unit that can be identified by a name, a description of its logical content, and a format. Data elements are mapped onto data objects, which are Basic Encoding Rules - Tag Length Value (BER-TLV) encoded, as defined in the ISO/IEC 8825 standard. Such a data object 400A is shown that includes a tag 402, a length 406 and a value 408. The tag 402 (i.e., unique identifier) is used to uniquely identify the data object 400A from the list of tags defined in EMV specification. All tags defined in the EMV specification are generally encoded over either 1 or 2 bytes. The length 406 is used to indicate the length of data associated with the tag 402. The value 408 (i.e., configuration data associated with the unique identifier) contains the data associated with the tag 402.
[0071] FIG. 4B illustrates a sequence flow diagram 400B representing a command – response APDU exchange between a payment card and a payment terminal using a Data Object List (DOL), in accordance with an example embodiment. At several key stages of a transaction, the card 104 requires data to be supplied from the terminal 102. Each of these stages has a specific DOL (e.g., PDOL and CDOL as explained with reference to FIG. 2) which is a list containing one or more pairs of tags and lengths (both encoded according to BER-TLV rules as explained with reference to FIG. 4A) but not values. When required, the terminal 102 processes this list in order, appending each of the requested values (without tags or lengths) into a buffer for sending to the card 104. The card 104 then extracts the value of each of these tags by using the DOL.
[0072] At 410, the card sends a DOL 412 that includes the tag 402 and the length 406. A explained with reference to FIG. 3B, the DOL 412 is the data (e.g., data 316a) part of the plurality of the fields of the response-APDU 300B sent by the card 104 to the terminal 102. Additionally, the mandatory trailer 320 is appended to the DOL 412 before sending the response.
[0073] At 415, the terminal 102 retrieves the value 408 associated with the tag 402 as stored in its database.
[0074] At 420, the terminal sends the value 408 to the card 104. The value 408 is the data (e.g., data 306f) part of the plurality of the fields of the command-APDU 300A sent by the terminal 102 to the card 104. Additionally, the mandatory header 308 is appended to the value 408 before sending the command. The process completes at step 425. In various embodiment, the process of retrieval of the configuration data / values goes on at various stages of the transaction.
[0075] As explained with reference to foregoing figures and specifically with reference to FIG. 2, there happens a lot of data exchange between the terminal 102 and the card 104 for completion of a payment transaction. Accordingly, a payment transaction may fail during any stage of the communication happening between the terminal 102 and the card 104. When the payment transaction gets failed because the terminal 102 is unable to process / accept the card 104 of the user presented for processing the payment transaction, the terminal configuration plays a major role. As explained with reference to FIG. 1, the payment server 140 is configured to facilitate the diagnostic application 110 that is configured to diagnose / debug malfunctions related to terminal configurations at the merchant facility itself such that an analysis report prepared based on retrieval of the configuration data helps in correction of the terminal 102. In at least one embodiment, when the smartphone 106 is in the predefined range of proximity of the payment terminal 102 to establish the communication, the diagnostic application 110 is configured to retrieve the configuration data from the payment terminal 102 without user intervention (e.g., selection of the diagnostic widget) for initiating the diagnosis process. Based on detection of the diagnostic device 106 as being tapped on the terminal 102, the terminal 102 sends a command to the diagnostic device 106 and the APDU exchange initiates.
[0076] FIG. 5 represents a User Interface 500 (UI 500) of a diagnostic application for selecting a diagnosis category to identify a cause of a payment card not being accepted by a payment terminal to process a payment transaction, in accordance with an example embodiment. The UI 500 is displayed by the diagnostic application 110 running on the diagnostic device 106 / smartphone 106. In order to initiate a communication with the terminal 102, the smartphone 106 needs to have NFC turned ON (see, 502). The smartphone 106 needs to be in a predefined range (e.g., four and a half centimetres) of proximity of the payment terminal 102 to establish the communication. Further, a plurality of diagnostic widgets such as an application selection command 504, an offline only terminal 506, a cardholder verification 508, an online only terminal 510 and an offline data authentication 512 are displayed on the UI 500 of the diagnostic application 110. Each widget corresponds to a diagnostic category that can be selected for further diagnosis and retrieval of configuration data for the selected category. The application selection command 504 is shown to be selected by the user.
[0077] In an example scenario, the user being a field agent carries the smartphone 106 with the pre-installed diagnostic application 110 at a merchant facility. To make a payment transaction for purchasing a product from the merchant, the user provides the card 104 at the terminal 102. A display sticker (not shown) on the terminal 102 shows that the terminal 102 is already configured to accept the card 104. However, when the user taps the card 104 on the terminal 102, an error message is displayed on the terminal 102 as “transaction failed due to card not accepted” (not shown). This is when the user also being the field agent takes out his smartphone 106 which has NFC turned ON (see, 502) and selects the application selection command 504 widget using the UI 500 of the diagnostic application 110. Then the user taps the smartphone 106 on the terminal 102 to send a communication request. The diagnosis process based on selection of the widget application selection command 504 is explained hereinafter with reference to FIG. 6.
[0078] FIG. 6 represents raw data 600 retrieved by a diagnostic device from a payment terminal using a diagnostic application, in accordance with an example embodiment. During APDU exchange, as explained with reference to foregoing figures, the terminal 102 sends the command and the card 104 i.e. the diagnostic application 110 running on the diagnostic device 106, in this case, sends the response to the command. Further, each command and response include mandatory fields and optional fields. Based on detection of the diagnostic device 106 as being tapped on the terminal 102, the terminal 102 sends a command 602 as shown. The command 602 includes an instruction byte 00A4 (see, 602a) that represents a SELECT command as explained with reference to FIG. 3A. The command 602 also includes a data byte called Directory Definition File (DDF) shown as 325041592E5359532E4444463031 (see, 602b) that represents 2PAY.SYS.DDF01. Entry Point is designed around the use of a Proximity Payment System Environment (PPSE) as the selection mechanism. For this purpose, the contactless card has a PPSE that contains a list of products and applications selectable over the contactless interface. The PPSE begins with a DDF given the name ‘2PAY.SYS.DDF01. It is assumed that this DDF is present in the contactless card. To recover the list of products and applications, Entry Point sends a SELECT (PPSE) command (i.e., command 602).
[0079] The File Control Information (FCI) in the response to the SELECT command 602 contains a list of directory entries identifying a product supported by the card, the kernel identifier of the kernel required for the specific application underpinning the product and the priority of the combination. As shown, the response 604 includes a list of Application Identifiers (AIDs) A0000000041010 (see, 604a), A0000000043060 (see, 604b) and B012345678 (see, 604c) supported by the card 104 with a priority indicator given to each. The AID A0000000041010 (see, 604a) (hereinafter referred to as “AID 604a”) representing Mastercard credit/debit card is given first priority indicator. In this scenario, the terminal 102 did not accept the payment card 104. Therefore, the terminal 102 does not return a next SELECT AID command being an application selection command for the given AID 604a. This is represented as ‘none’ (see, 606a) for a next command 606.
[0080] Accordingly, the diagnostic application 110 applies a corresponding rule on the malfunction of the terminal 102. For example, if the terminal 102 sends a SELECT AID command for the requested AID 604a from the list given in the response 604, C2 Kernel is present on the terminal 102. Because, the terminal 102 did not give a SELECT AID command for the requested AID 604a, an inference is made that the terminal 102 is missing C2 Kernel and therefore, the terminal 102 does not accept the card 104. There is one more possibility that the terminal 102 has turned off the reader and that is the cause of terminal 102 not accepting the card 104.
[0081] In various embodiments, the command-response APDU exchange between the terminal 102 and the card 104 is iteratively preformed / continuously repeated by selecting a corresponding diagnostic widget displayed on the UI 500 until the diagnostic application 110 has acquired enough data to make a diagnosis of a malfunction of the terminal 102. Each diagnostic widget (card behaviour) displayed on the UI 500 of diagnostics application 110 enables the user to perform a specific diagnosis based on a selected diagnostic category. The interaction data (command-response APDU) from the selected diagnostic widget is used for making inferences by applying a plurality of rules. Depending on the analysis of the terminal configuration data received, there could be a chance that more configuration data needs to be fetched from the terminal 102 using a different diagnostic widget selected for the same session, and therefore corresponding command-response APDU is performed to continue to diagnose the malfunction. FIG. 7 and FIG. 9 collectively represent selection of the widgets, for instance, the offline only terminal 506, the cardholder verification 508, the online only terminal 510 and the offline data authentication 512 present on the UI 500 of FIG. 5, and retrieval of corresponding configuration data through command-response APDU exchange.
[0082] FIG. 7 represents raw data 700 retrieved by a diagnostic device from a payment terminal using a diagnostic application, in accordance with another example embodiment. More specifically, FIG. 7 represents configuration data retrieved by the diagnostic application 110 using PDOL command-response APDU. Once application selection is successfully completed by the terminal 102, next stage during a transaction is read application data using PDOL and GPO command-response APDU as explained with reference to FIG. 2. Considering a different scenario with reference to FIG. 6, if C2 Kernel is present on the terminal 102, the terminal 102 sends a SELECT AID command for the requested AID 604a from the list given in the response 604 after the first set of command 602 and response 604 exchange. A corresponding command 608 is shown in FIG. 7. The command 608 includes the instruction byte 00A4 (see, 602a) representing select command and A0000000041010 (see, 604a) representing selection of the application.
[0083] A next response 702 includes the PDOL. The PDOL is a list of data from the terminal 102 that is required by the card 104 at the beginning of the read application data stage. As explained with reference to FIG. 4B, a DOL includes a tag and a length in a response. The response 702 includes the AID 604a, a tag 702a (i.e., 9F38), a length 702b (i.e., 08) and a value 702c (i.e., 9F7E019F33039C01). When the value field of a data object recursively encapsulates one or more other data objects, it is called a constructed data object. It means that the value 702c further includes a combination of tags and lengths represented as T1 (i.e., 9F7E), L1 (i.e., 01), T2 (i.e., 9F33), L2 (i.e., 03), T3 (i.e., 9C) and L3 (i.e., 01).
[0084] The terminal 102 uses the DOL processing rules to format the requested data and the corresponding value is returned by the terminal 102 in the next command to the card 104 in the Get Processing Options (GPO) request. A next command 704 is shown to include an instruction byte 80A8 (see, 704a) that represents GET PROCESSING OPTIONS command. The command 704 further includes a data 704b as values V1 (i.e., 01), V2 (i.e., 000008) and V3 (i.e., 23) returned for the corresponding tags T1, T2 and T3. Further, value V1 may be retrieved separately based on selection of the cardholder verification 508 widget. Value V2 may be retrieved separately based on selection of the offline data authentication 512 widget. Value V3 may be retrieved separately based on selection of the offline only terminal 506 widget. A next response 706 is sent by the card 104 upon receiving the command 704. The exchange goes on until the diagnostic application 110 has enough data to apply rules for making inferences and thereby identify the cause of the card 104 not being accepted at the terminal 102.
[0085] FIG. 8 illustrates a chart 800 representing a plurality of rules applied to make a plurality of inferences on the values retrieved by the diagnostic application 110 in FIG. 7, in accordance with an example embodiment. The chart 800 includes a plurality of columns with titles such name 802, tag 804, length 806, value 808, rule 810, and inference 812. The corresponding information presented in a row 814 is explained hereinafter. Tag T1 (i.e., 9F7E), Length L1 (i.e., 01), and Value V1 (i.e., 01) as retrieved by the diagnostic application 110 as explained with reference to FIG. 7 are shown in the row 814. The name of the tag T1 is mobile support indicator. A corresponding rule for On-Device Cardholder Verification Method (ODCVM) is applied as shown. If the value is “01”, a terminal is able to delegate cardholder verification to a digital payment instrument. Further, if the value is “00”, a terminal is unable to delegate cardholder verification to a digital payment instrument. An inference is made based on application of the rule that the terminal 102 does support delegating the cardholder verification to the digital payment instrument because terminal returned value V1 as “01” for the requested tag 9F7E.
[0086] The corresponding information presented in a row 816 is explained hereinafter. Tag T3 (i.e., 9C), Length L3 (i.e., 01), and Value V3 (i.e., 23) as retrieved by the diagnostic application 110 as explained with reference to FIG. 7 are shown in the row 816. The name of the tag T3 is transaction type. A corresponding rule is applied as shown. If the value is “23”, a terminal is an offline only terminal. Further, If the value is “24”, a terminal is an online only terminal. Value “24” may be retrieved base on selection of the online only terminal 510 widget displayed on the UI 500. An inference is made based on application of the rule that the terminal 102 is an offline only terminal because terminal 102 returned value V3 as “23” for the requested tag “9C”. Moreover, a combined inference from above two rules is also made that if a digital payment instrument is presented on the terminal 102, the transaction will be declined. This is an example of a scenario where multiple rules are applied to generate multiple inferences from which a combined inference is made.
[0087] The corresponding information presented in a row 818 is explained hereinafter. Tag T2 (i.e., 9F33), Length L2 (i.e., 03) and Value V2 (i.e., 000008) as retrieved by the diagnostic application 110 as explained with reference to FIG. 7 are shown in the row 818. The name of the tag T2 is terminal capabilities. A corresponding rule as shown is applied. Mask Terminal Capabilities with “000008”. If the resultant value is “000008”, a terminal can perform offline data authentication, otherwise not. An inference is made based on application of the rule that the terminal 102 can perform offline data authentication, because terminal returned a value V2 as “000008”. Thus, the diagnostic application 110 continues to retrieve retrievable configuration data (i.e., value associated with the tags) from the terminal 102 to apply corresponding rules in order to make inferences.
[0088] FIG. 9 represents raw data 900 retrieved by a diagnostic device from a payment terminal using a diagnostic application, in accordance with yet another example embodiment. After retrieving configuration data through PDOL as explained with reference to FIG. 7, the diagnostic application 110 may further be interested in retrieving values associated with the card action analysis stage. Accordingly, one more set of command-response APDU exchange is performed between the diagnostic device 106 and the terminal 102 to retrieve corresponding configuration data from the terminal 102. A prime example of two files that should be present for every financial application are the Card Risk Management Object Data List 1 and 2. CDOL1 and CDOL2 data object lists are important as they provide most of the transaction data to be used as input to the final cryptogram. The format of the data sent to the terminal 102 is sometimes not in its usual TLV format, but instead in a concatenated format defined by the CDOLs.
[0089] More specifically, FIG. 9 represents configuration data retrieved by the diagnostic application 110 using CDOL1 command-response APDU. CDOL1 is used during first card analysis action and includes a list of data objects (tag and length) to be passed to the terminal 102 as a response. CDOL1 is readable through a READ RECORD command. A command 902 includes an instruction byte 00B2 (see, 902a), and it represents READ RECORD command to instruct the diagnostic application 110 to read and return a file record. A next response 904 from the diagnostic application 110 includes a CDOL1 represented as 95059F02069F34039F33039F3704 (see, 904a). A tag T4 (i.e., 95) and a length L4 (i.e., 05) are further represented as a data 904b.
[0090] The terminal 102 uses the DOL processing rules to format the requested data and the corresponding value is returned by the terminal 102 in the next command to the card. A next command 906 is a GENERATE APPLICATION CRYPTOGRAM command represented using 80AE (see, 906a). The command 906 sends transaction-related data to the diagnostic application 110 i.e., value associated with the tag T4 which is computed to generate a cryptogram. A value V4 (i.e., 0400000001) in a data 906b is shown in the command 906. A next response 908 is sent by the card 104 upon receiving the command 906.
[0091] Tag T4 as “95” is identified for Terminal Verification Results (TVR) and the terminal 102 returns the value V4 as “0400000001”. A rule is applied to mask the TVR with “0400000000”; if the resultant value is “0400000000”, a terminal is unable to perform offline data authentication, otherwise the terminal is able to perform the offline data authentication. Based on application of the rule, an inference is made that the terminal 102 is unable to perform offline data authentication because terminal returned a value V4 as “0400000001”. It means that configuration for offline data authentication in the terminal 102 is not correct. For example, certification authority public key index is missing in the terminal 102.
[0092] In an example embodiment, the terminal 102 provides the data requested by the appropriate DOL in a command appropriate to the DOL being processed. For example, for a GENERATE APPLICATION CRYPTOGRAM command, the cryptogram is generated by the card 104. However, the data for generating the cryptogram is provided by the terminal 102. The data that needs to be provided by the terminal 102 to the card 104 is mentioned in one of the DOLs, in one of the commands, and in one of the responses back to the terminal 102. When the terminal 102 is ready to retrieve the cryptogram from the card 104, the terminal 102 identifies the particular DOL, formats the values that DOL has requested, and provides the values in the command for generating the cryptogram. Therefore, unlike receiving a DOL, and responding immediately to the DOL, there may be a scenario like above, where receiving a DOL and responding to the appropriate command with the values requested in the DOL is a possibility.
[0093] FIG. 10 is a schematic representation 1000 of an analysis report prepared after diagnosing one or more malfunctions of a payment terminal, in accordance with an example embodiment. As explained with reference to FIGS. 6 to FIGS. 9, the diagnostic application 110 is configured to retrieve configuration data from the terminal 102 by iteratively performing command-response APDU exchange. Further, a plurality of rules is applied to the retrieved configuration data. The diagnostic application 110 at the end of a transaction checks the configurations and makes appropriate conclusions / inferences about terminal configuration. A plurality of inferences 1006 is logged in an analysis report 1002. The diagnostic application 110 is further configured to prepare a log of the tabulated configuration data 1010 that can be included in the analysis report 1002. The diagnostic application 110 logs the command-response APDU raw data 1004 exchanged between the terminal 102 and the card in the analysis report 1002. The analysis report 1002 also includes a location data 1008 of the merchant facility where the terminal 102 is diagnosed with malfunctions.
[0094] FIG. 11 is a sequence flow diagram 1100 representing correction of a payment terminal, in accordance with an example embodiment. More specifically, FIG. 11 represents a sequence flow diagram 1100 for sending of the analysis report 1002 by the diagnostic device 106 to the payment server 140 configured to facilitate correction of the payment terminal 102.
[0095] At 1105, the diagnostic application 110 running on the diagnostic device 106 prepares the analysis report 1002. As explained with reference to FIG. 10, the analysis report 1002 at least includes a plurality of inferences 1006 made based on applying a plurality of rules on the configuration data retrieved from the terminal. The analysis report 1002 is prepared for identifying a cause of the payment card 104 not being accepted by the payment terminal 102 to process the payment transaction.
[0096] At 1110, the diagnostic device 106 sends the analysis report 1002 to the payment server 140. In an embodiment, the diagnostic application 110 is facilitated by the payment server 140 associated with the payment network 145.
[0097] At 1115, the payment server 140 sends the analysis report 1002 to the acquirer server 130.
[0098] At 1120, the acquirer server 130 sends the analysis report 1002 to the payment terminal provider server 125. The payment terminal provider server 125 is associated with the payment terminal provider of the payment terminal 102.
[0099] At 1125, the payment terminal provider server 125 reviews the analysis report 1002. As the analysis report 1002 includes all the command-response APDU raw data 1004, and the plurality of inferences 1006 made for a selected diagnosis category for identifying the cause of the payment terminal not accepting the payment card, it becomes easier for the payment terminal provider server 125 to analyse the analysis report 1002 and identify the exact missing or wrongly present configuration inside the terminal 102.
[00100] At 1130, the payment terminal provider server 125 sends a corrective configuration information to the payment terminal 102. For example, there is a missing configuration data in the terminal 102 that is causing the terminal 102 to act in an unacceptable manner. The payment terminal provider server 125 comes to know about the missing configuration data from the analysis report 1002. The payment terminal provider server 125 is configured to send the missing configuration data to the payment terminal 102 via the communication network 150 (e.g., Internet).
[00101] At 1135, the payment terminal 102 updates the correct configuration data received from the payment terminal provider server 125. Once the missing configuration data is updated in the terminal 102, the terminal malfunction gets corrected and the terminal 102 becomes capable of accepting the payment card. In an example embodiment, the payment terminal provider server 125 comes to know that the fault or the malfunction of the terminal 102 is not capable of being corrected online. Accordingly, the payment terminal provider server 125 sends a scheduled pick-up message (not shown) to the acquirer server 130 about scheduling a pick-up of the faulty terminal 102 from the merchant facility and getting it corrected or replaced based on the type of malfunction at the payment terminal provider facility. The acquirer server 130 further forwards this message to the merchant on his electronic device. The process of correcting the terminal 102 ends at operation 1140.
[00102] FIG. 12 is a sequence flow diagram 1200 representing correction of a payment terminal, in accordance with another example embodiment. More specifically, FIG. 12 represents the sequence flow diagram 1200 for sending of the analysis report 1002 by the diagnostic device 106 to the payment terminal provider server 125 configured to facilitate correction of the payment terminal 102.
[00103] At 1205, the diagnostic application 110 running on the diagnostic device 106 prepares the analysis report 1002. As explained with reference to FIG. 10, the analysis report 1002 at least includes a plurality of inferences 1006 made based on applying a plurality of rules on the configuration data retrieved from the terminal. The analysis report 1002 is prepared for identifying a cause of the payment card 104 not being accepted by the payment terminal 102 to process the payment transaction.
[00104] At 1210, the diagnostic device 106 sends the analysis report 1002 to the payment terminal provider server 125. In an embodiment, the diagnostic application 110 is facilitated by the payment terminal provider server 125.
[00105] At 1215, the payment terminal provider server 125 reviews the analysis report 1002.
[00106] At 1220, the payment terminal provider server 125 sends a corrective configuration information to the payment terminal 102. For example, there is a wrong configuration data in the terminal 102 that is causing the terminal 102 to act in an unacceptable manner. The payment terminal provider server 125 comes to know about the wrong configuration data from the analysis report 1002. The payment terminal provider server 125 is configured to send the correct configuration data to the payment terminal 102 via the communication network 150 (e.g., Internet).
[00107] At 1225, the payment terminal 102 updates the configuration data received from the payment terminal provider server 125. Once the correct configuration data is updated in the terminal 102, the terminal 102 becomes capable of accepting the payment card 104. The process of correcting the terminal 102 ends at operation 1230.
[00108] Thus, various embodiments of the present disclosure provide various means to identify a cause of a payment card not being accepted at a payment terminal during a payment transaction. Currently, (not in accordance with embodiments of the present disclosure) to diagnose acceptance issues, the terminal needs to be inspected by terminal vendor and acquirer to pinpoint the problem. The diagnostic device with the diagnostic application proves to be an invaluable asset to the payment network’s field testers and marketing employees to quickly identify the malfunctions of a payment terminal and suggest corrective actions. The various embodiments seamlessly enable contactless payment acceptance by providing a dedicated customer-facing NFC card reader zone for faster transaction flows. Although various embodiments are explained with reference to the payment terminal being a PoS terminal, malfunctions of an Automated Teller Machine (ATM) may also be diagnosed using various features of the diagnostic application running on the diagnostic device. Apart from the retrieval of the configuration data of the terminal to understand the malfunction of the terminal, various embodiments also facilitate identification of problems with the network messages such as from the terminal to the acquirer server 130 and the like using the diagnostic application. A hardware malfunction such as no detection of a standard NFC field may also be identified by the diagnostic application. If such a field is not detected, the application is able to identify that no contactless field is detected.
[00109] Further, an advantage of using a smartphone as a diagnostic device is that the diagnostic application can be customized over the air without any hassle. The customization includes introduction of new rules as per the updated configuration of the payment terminal. Only an NFC chip inbuilt with the smartphone enables the smartphone to communicate exactly in the same way as the NFC enabled contactless payment card would communicate with the contactless NFC readers (PoS terminals). Rather than having encrypted information like the card, it is the diagnostic application which communicates with the terminal using the smartphone that helps in identifying the malfunctions of the terminal. Moreover, the diagnostic application is able to perform first level of analysis whether the terminal is accepting the card. The analysis can be sent to the payment server 140 or the payment terminal provider server 125. Second level of analysis includes retrieving by the diagnostic application the specific configuration data associated with the unique identifiers from the terminal by performing command-response APDU exchange, analyzing them and preparing a detailed analysis report about the exact cause of the terminal’s malfunction.
[00110] FIG. 13 illustrates a flow diagram of a method 1300 for diagnosing malfunctions of a payment terminal, in accordance with an example embodiment. More specifically, the method 1300 for retrieving configuration data of a payment terminal and analysing the configuration data to determine a cause of a payment card not being accepted at the payment terminal is disclosed. The method 1300 depicted in the flow diagram may be executed by, for example, any electronic device / diagnostic device such as the diagnostic device 106 explained with reference to FIG. 1. Operations of the method 1300, and combinations of operation in the method 1300, 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 1300 are described herein with help of the diagnostic device 106. It is noted that the operations of the method 1300 can be described and/or practiced by using an electronic device other than the diagnostic device 106. The method 1300 starts at operation 1302.
[00111] At 1302, the method 1300 includes sending, by a diagnostic device, a communication request to a payment terminal via a diagnostic application running on the diagnostic device using a communication protocol. The diagnostic application is used for identifying a cause of a payment card not being accepted by the payment terminal to process a payment transaction. The diagnostic device is a Near Field Communication (NFC) technology enabled smartphone and the communication protocol for sending the communication request is NFC. The payment terminal includes a contact interface for inserting the payment card and the diagnostic device is configured to communicate with the payment terminal via a hardware interface (e.g., USB).
[00112] At 1304, the method 1300 includes, sending, by the diagnostic device, a response to a command received from the payment terminal via the diagnostic application. The response includes at least one unique identifier for a request to retrieve a configuration data of the payment terminal.
[00113] At 1306, the method 1300 includes, receiving, by the diagnostic device, the configuration data including a corresponding value associated with the at least one unique identifier.
[00114] At 1308, the method 1300 includes, applying, by the diagnostic device, at least one rule of a plurality of rules to determine an inference via the diagnostic application based on the configuration data retrieved from the payment terminal. In one embodiment, a plurality of inferences is determined by iteratively performing steps 1304 and 1306. The plurality of inferences, a command-response APDU raw data, and a tabulated configuration data are logged in an analysis report. The method 1300 stops at 1308.
[00115] Thus, instead of performing a normal transaction with the terminal, the diagnostic application has a different set of commands, and data objects which force the terminal to reveal its configuration. During normal transactions, configuration of the terminal is not exposed to the card, but using this diagnostic tool / diagnostic device, when asked for the configuration to the terminal, the terminal returns the configuration. Further, certain rules are defined in the diagnostic application which help to analyze those configuration data and identify what exactly is causing a malfunction in the acceptance device.
[00116] FIG. 14 is a simplified block diagram of a server system 1400, in accordance with one embodiment of the present disclosure. Examples of the server system 1400 include, but are not limited to, the acquirer server 130, the issuer server 135, the payment terminal provider server 125, and the payment server 140. The server system 1400 includes a computer system 1405 and a database 1410. The computer system 1405 includes at least one processor 1415 for executing instructions. Instructions may be stored in, for example, but not limited to, a memory 1420. The processor 1415 may include one or more processing units (e.g., in a multi-core configuration). The processor 1415 is operatively coupled to a communication interface 1425 such that the computer system 1405 is capable of communicating with a remote device such as a diagnostic device 1435 (e.g., the diagnostic device 106), a payment terminal 1440 or communicating with any entity within the payment network 145.
[00117] The processor 1415 may also be operatively coupled to the database 1410. The database 1410 is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, transaction data generated as part of sales activities conducted over the bankcard network including data relating to merchants, account holders or customers, and purchases. The database 1410 may also store information related to a plurality of users’ payment accounts. Each user account data includes at least one of a user name, a user address, an account number, a contact information, PIN, and other account identifiers. The database 1410 may also store device identifiers, platform IDs of the users etc.
[00118] The database 1410 may also store PoS terminal IDs, Application Identifiers (AIDs), and the like. The database 1410 may also store a merchant identifier that identifies each merchant registered to use the payment network 145, and instructions for settling transactions including merchant bank account information (e.g., a plurality of payment accounts related to the merchant interfaces associated with merchants). The database 1410 may further include issuer account information, BINs, human agent information, virtual agent information, biometric information of the users, authentication data, transaction identifier data etc. The database 1410 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 1410 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00119] In some embodiments, the database 1410 is integrated within the computer system 1405. For example, the computer system 1405 may include one or more hard disk drives as the database 1410. In other embodiments, the database 1410 is external to the computer system 1405 and may be accessed by the computer system 1405 using a storage interface 1430. The storage interface 1430 is any component capable of providing the processor 1415 with access to the database 1410. The storage interface 1430 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 1415 with access to the database 1410.
[00120] The processor 1415 is configured to facilitate a diagnostic application capable of diagnosing malfunctions of the payment terminal 1440 based on application of a plurality of rules. The diagnostic application runs on the diagnostic device 1435 and is configured to apply the plurality of rules on the configuration data retrieved from the payment terminal 1440. The processor 1415 is configured to update the diagnostic application at a pre-determined time period for updating new rules according to the updates in the payment terminal 1440. Via the communication interface 1425, the processor 1415 is configured to receive an analysis report from the diagnostic device 1435 that includes a plurality of inferences made by the diagnostic application based on application of the plurality of rules. The processor 1415 is configured to review the analysis report. The processor 1415 is further configured to send one or more corrective configuration information to the payment terminal 1440 via the communication interface 1425.
[00121] FIG. 15 is a simplified block diagram of a payment server 1500, in accordance with one embodiment of the present disclosure. The payment server 1500 may correspond to the payment server 140 of FIG. 1. The payment server 140 is associated with the payment network 145. The payment server 1500 includes a processing module 1505 configured to extract programming instructions from a memory 1510 to provide various features of the present disclosure. The components of the payment server 1500 provided herein may not be exhaustive, and that the payment server 1500 may include more or fewer components than those depicted in FIG. 15. 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 1500 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00122] In an embodiment, the processing module 1505 may be embodied as one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.
[00123] The memory 1510 is configured to store machine executable instructions of a diagnostic application 1535 to be accessed by the processing module 1505. The memory 1510 can be any type of storage accessible to the processing module 1505. For example, the memory 1510 may include volatile or non-volatile memories, or a combination thereof. In some non-limiting examples, the memory 1510 can be four to sixty-four Gigabytes (GB) of Dynamic Random Access Memory (“DRAM”) or Static Random Access Memory (“SRAM”). In addition, some examples may include supplementary flash memory installed via a PCMCIA slot.
[00124] Via the communication module 1520, the processing module 1505 is configured to facilitate display of one or more User Interfaces (UIs) of the diagnostic application 1535 on a remote device 1540 (e.g., the diagnostic device 1435). At least one UI of the diagnostic application 1535 includes a plurality of diagnostic widgets. Each diagnostic widget of the plurality of diagnostic widgets corresponds to a selectable diagnosis category for identifying a cause of a payment card not being accepted by the payment terminal 1440 to process a payment transaction. A selection of a specific diagnostic widget results in retrieving a corresponding configuration data from the payment terminal 1440 on which the diagnostic application 1535 applies a corresponding rule. Alternatively, a rule is applied on the configuration data as collectively retrieved from the payment terminal 1440 without a selection of a specific diagnostic widget. The processing module 1505 is further configured to receive an analysis report prepared by the diagnostic application 1535 via the communication module 1520. The processing module 1505 is configured to facilitate correction of the terminal by sending the analysis report to a payment terminal provider server for review and taking corrective actions.
[00125] The processing module 1505 is further configured to communicate with one or more remote devices such as the remote device 1540 using the communication module 1520 over a network such as the network 150 or the payment network 145 of FIG. 1. The examples of the remote device 1540 include, the issuer server 135, the diagnostic device 1435, the acquirer server 130, the payment terminal provider server 125, other computing systems of issuer and the payment network 145 and the like. The communication module 1520 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication may be achieved through API calls, without loss of generality.
[00126] FIG. 16 is a simplified block diagram of a payment terminal 1600 used for a payment transaction, in accordance with one embodiment of the present disclosure. The payment terminal 1600 is an example of the payment terminal 102 / PoS terminal 102 of FIG. 1 in terms of functionalities and features. In one embodiment, the payment terminal 1600 is a contactless tap and pay Point of Sale (POS) terminal. In the architecture of a payment terminal accepting contactless payment instruments, each payment brand has a unique Kernel application with its dedicated database (known as kernel database). The kernel database holds the information about the configurations related to the payment brand specific to the terminal, region and the merchant.
[00127] The payment terminal 1600 includes at least one processor 1605 communicably coupled to a database 1610, an Input / Output (I/O) interface 1615, a communication interface 1620 and a memory 1625. The components of the payment terminal 1600 provided herein may not be exhaustive, and that the payment terminal 1600 may include more or fewer components than those depicted in FIG. 16. 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 1600 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00128] The I/O interface 1615 is configured to receive inputs from and provide outputs to the end-user (i.e. the merchant and/or the customer) of the payment terminal 1600. For instance, the I/O interface 1615 may include at least one input interface and/or at least one output interface. Examples of the input interface may include, but are not limited to, a keyboard, a mouse, a joystick, 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 UI 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, etc.), a speaker, a ringer, a vibrator, and the like.
[00129] The memory 1625 can be any type of storage accessible to the processor 1605. For example, the memory 1625 may include volatile or non-volatile memories, or a combination thereof. The memory 1625 includes machine executable instructions of one or more EMV applications 1625a supported by the payment terminal 1600. The EMV applications 1625a are accessed and executed by the processor 1605 from the memory 1625 to provide various capabilities to the payment terminal 1600.
[00130] The database 1610 is capable of storing and/or retrieving data, such as, but not limited to, smart card insertions, user/customer information, merchant information, card swipes, touch-screen key depressions, keypad key depressions, number of dots printed by the slip and roll printers, check read errors, and the like. Such information can be accessed by the processor 1605 using the communication interface 1620 to determine potential future failures and the like. Additionally, the database 1610 includes Application Identifiers (AIDs) 1610a and data objects 1610b. An AID is used to uniquely identify each EMV application that a terminal supports, and every AID has an associated card scheme and parameters relating to how the EMV application needs to be processed. A terminal may contain any number of such applications, and the list of each supported AID is used during candidate list creation to generate a list of applications that are mutually supported by both the terminal and the card. Each entry of the most entries in the database 1610 is made using data object 1610b. The data object 1610b includes a Tag (according to ISO 7816 standards), a length and has a value associated to the tag.
[00131] The payment terminal 1600 is capable of communicating with one or more POS peripheral devices such as the POS peripheral device 1635 and external server system such as a remote device 1630 (e.g., the acquirer server 130, the payment card 104, the diagnostic device 1435 etc.) via the communication interface 1620 over a communication network such as the network 150 of FIG. 1. The POS peripheral device 1635 can provide functionality which is used by a consumer at a merchant facility, such as PIN entry, payment string entry, clear text entry, signature capture, tap and pay (via NFC) and the like. Some non-exhaustive examples of the POS peripheral device 1635 include barcode scanner, cash drawer, magnetic stripe reader, receipt printer, PIN pad, signature capture device, touchscreen, keyboard, portable data terminal, card reader, customer pole display and the like. In some embodiments, the payment terminal 1600 may be mounted near a cash register at a check-out counter in merchant facility, while the POS peripheral device 1635 may be mounted on the check-out counter such that it is accessible to the users. In this way, both the merchant and the user/customer can interact with similar devices to process the payment transaction.
[00132] The communication interface 1620 is further configured to cause display of user interfaces on the payment terminal 1600. In one embodiment, the communication interface 1620 includes a transceiver for wirelessly communicating information to, or receiving information from, the remote device 1630 or other suitable display device, and/or another type of remote processing device. In another embodiment, the communication interface 1620 is capable of facilitating operative communication with the remote devices and a cloud server using Application Program Interface (API) calls. The communication may be achieved over a communication network, such as the network 150.
[00133] The processor 1605 is capable of performing command-response APDU exchange with a payment card during a payment transaction via the communication interface 1620. The processor 1605 is also capable of performing command-response APDU exchange with the diagnostic device 1435 via the diagnostic application 1535. For example, the processor 1605 receives a response from the diagnostic device 1435 via the communication interface 1620. The response includes a DOL with tags and length for which an associated value is requested from the payment terminal 1600. The processor 1605 retrieves the request value from the data object 1610b and sends in a next command to the diagnostic device 1435. Additional modules such as a cardholder verification module 1640 and a data authentication module 1645 are utilized by the processor 1605 to perform cardholder verification and data authentication respectively.
[00134] The processor 1605 is capable of receiving one or more corrective configuration data from the remote device 1630 such as the payment terminal provider server 125. Additionally, the payment terminal 1600 may include selectable kernel configurations. Selectable kernel configurations are optional terminal features that allow the payment terminal 1600 to support different capabilities for different transactions. For example, if allowed by the payment system, a terminal might support only ‘No CVM Required’ for low value transactions and support Signature and Offline PIN for higher value transactions.
[00135] Additionally, the payment terminal 1600 can include an operating system and various software applications that can provide various functionalities to the payment terminal 1600. For example, in some embodiments, the payment terminal 1600 is addressable with an Internet protocol and includes a browser application. In such embodiments, the processor 1605 includes software adapted to support such functionality. In some embodiments, the processor 1605 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 enabling corrective configuration data and/or updates to existing applications. The operating system and software application upgrades are distributed and maintained through communication to the payment terminal 1600 over the communication network 150.
[00136] FIG. 17 shows simplified block diagram of a diagnostic device 1700 capable of implementing the various embodiments of the present disclosure. For example, the diagnostic device 1700 may correspond to the NFC enabled diagnostic device 106 of FIG. 1 or the diagnostic device 1435 of FIG. 14. The diagnostic device 1700 is depicted to include one or more applications, such as a diagnostic application. The diagnostic application is capable of communicating with any of the servers 125, 130, 135, and 140.
[00137] It should be understood that the diagnostic device 1700 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with the diagnostic device 1700 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 17. As such, among other examples, the diagnostic device 1700 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00138] The illustrated diagnostic device 1700 includes a controller or a processor 1702 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing tasks such as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1704 controls the allocation and usage of the components of the diagnostic device 1700 and supports for one or more application programs (see, applications 1706), that implements one or more of the innovative features as described herein. In addition, the applications 1706 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00139] The illustrated diagnostic device 1700 includes one or more memory components, for example, a non-removable memory 1708 and/or a removable memory 1710. The non-removable memory 1708 and/or the removable memory 1710 may be collectively known as database in an embodiment. The non-removable memory 1708 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1710 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1704 and the applications 1706. The diagnostic device 1700 may further include a user identity module (UIM) 1712. The UIM 1712 may be a memory device having a processor built in. The UIM 1712 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1712 typically stores information elements related to a mobile subscriber. The UIM 1712 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA9000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00140] The diagnostic device 1700 can support one or more input devices 1720 and one or more output devices 1730. Examples of the input devices 1720 may include, but are not limited to, a touch screen / a display screen 1722 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1724 (e.g., capable of capturing voice input), a camera module 1726 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1728. Examples of the output devices 1730 may include but are not limited to a speaker 1732 and a display 1734. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1722 and the display 1734 can be combined into a single input/output device.
[00141] A wireless modem 1740 can be coupled to one or more antennas (not shown in the FIG. 17) and can support two-way communications between the processor 1702 and external devices, as is well understood in the art. The wireless modem 1740 is shown generically and can include, for example, a cellular modem 1742 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1744 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1746. The wireless modem 1740 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the diagnostic device 1700 and a public switched telephone network (PSTN).
[00142] The diagnostic device 1700 can further include one or more input/output ports 1750, a power supply 1752, one or more sensors 1754 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the diagnostic device 1700 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1756 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1760, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00143] The disclosed method with reference to FIG. 13, or one or more operations of the method 1300 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 non-volatile memory or storage components (e.g., hard drives or solid-state non-volatile 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 includes, 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.
[00144] Although the invention 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 invention. 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).
[00145] Particularly, the diagnostic device 106, the servers 125, 130, 135, 140 and its various components such as the computer system 1405 and the database 1410 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 invention 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.
[00146] Various embodiments of the invention, 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 invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and are well within the spirit and scope of the invention.
[00147] Although various exemplary embodiments of the invention 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.