Embedded card reader security

Abstract

To provide a method for improving embedded card reader security.SOLUTION: Provided is a method that includes temporally and / or spatially separating personal account number (PAN) data read from a payment instrument such as a credit card or debit card from personal identification number (PIN) data utilized to complete a payment transaction. Temporal separation includes removing the PAN data from a merchant device 102 before requesting the PIN data. Spatial separation includes utilizing trusted execution environments, separated embedded card reader (ECR) applications, intermediary applications, and / or trust routines of trust applications to enable different components of a merchant device and / or components of other devices and systems to handle the PAN data and the PIN data.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims priority to U.S. Patent Application No. 17 / 183,149, titled "Embedded Card Reader Security," filed on February 23, 2021, and U.S. Patent Application No. 17 / 183,129, titled "Embedded Card Reader Security," filed on February 23, 2021, the entire contents of which are incorporated herein by reference.

[0002] (Technical Field) This disclosure generally relates to embedded card readers and embedded card reader security.

[0003] Payment instruments are used to purchase goods. In some examples, a reader is embedded in a point - of - sale device associated with a payment processing service. In other examples, the reader is separate from such a point - of - sale device. In still other examples, an embedded card reader may be configured to operate on a personal device such as a mobile phone or a tablet. In these and other examples, security of the information obtained by the reader and / or other information associated with a transaction is desirable. In particular, the problem to be solved includes how to effectively prevent malicious actors from obtaining data associated with a payment transaction in order to keep the payment transaction and payment instruments such as payment cards secure.

Brief Description of the Drawings

[0004] The features, nature, and various advantages of this disclosure will become clearer when considered in conjunction with the attached drawings. The detailed description below is given with reference to the attached drawings. In the drawings, the leftmost digit of the reference number identifies the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical items. The systems depicted in the attached drawings are not to scale, and components within the drawings may not be depicted to scale relative to one another.

[0005] [Figure 1A] This document describes an exemplary environment for embedded card reader (ECR) security.

[0006] [Figure 1B] This document illustrates a conceptual diagram of the components used to implement software personal identification numbers (PINs) on consumer off-the-shelf device technologies and ECR technologies.

[0007] [Figure 2] This document describes an exemplary process associated with using ECR to secure payments without generating a default PIN.

[0008] [Figure 3] This section describes an exemplary process associated with using ECR to secure payments, where a point-of-sale (POS) application communicates directly with the ECR.

[0009] [Figure 4] This describes an exemplary process associated with securing payments using a POS application and an intermediate application configured to communicate with an ECR.

[0010] [Figure 5] This describes an exemplary process associated with using ECR to protect payments, where the ECR application performs security actions associated with the payment.

[0011] [Figure 6] The diagram illustrates the conceptual components used to protect payments, and the process involves obtaining a Personal Account Number (PAN) and a Personal Identification Number (PIN), with the PIN being isolated.

[0012] [Figure 7] This diagram illustrates the conceptual components used to protect payments, showing that PAN data is handled by an isolated service, while the POS application handles PIN data.

[0013] [Figure 8] This diagram illustrates the conceptual components used to protect payments, showing how Europay, Mastercard, and Visa (EMV) data processing is handled by payment processing services instead of merchant devices.

[0014] [Figure 9] This diagram illustrates the conceptual components used to protect payments, and explains that EMV data processing is handled by the vendor's data center.

[0015] [Figure 10] This illustrates a conceptual diagram of exemplary components used to protect payments by utilizing a Trusted Execution Environment (TEE).

[0016] [Figure 11] This document describes an exemplary process for ECR security.

[0017] [Figure 12] This section describes another exemplary process for ECR security.

[0018] [Figure 13] To support ECR security, an exemplary process for temporally separating PAN data and PIN data on a merchant device is described.

[0019] [Figure 14] To assist ECR security, an exemplary process for spatially separating PAN data and PIN data on a merchant device is described.

[0020] [Figure 15] An exemplary merchant ecosystem is shown to facilitate, inter alia, the techniques described in this book.

[0021] [Figure 16] Additional details associated with the individual components of the merchant ecosystem described in FIG. 15 are explained.

Best Mode for Carrying Out the Invention

[0022] The techniques described in this book are directed, inter alia, to embedded card reader (ECR) security configured to improve data security during payment transactions. Payment transactions typically involve a flow of information between a customer, a merchant, and a payment processing service and / or a bank. In particular, account information associated with a particular customer or user, including a personal account number (PAN), is used to identify the user and the payment account associated with that user. Often, a personal identification number (PIN) is also used in the transaction to enable the use of a particular payment instrument, such as a payment card. For example, the input of a PIN code may enable the PAN to be obtained from the payment instrument, and then the PAN may be transmitted to a payment processing service or bank along with other transaction information to facilitate the transaction.

[0023] Merchants are increasingly choosing not to use specific POS devices to handle such payment transactions, but instead to use consumer off-the-shelf (COTS) devices to execute the transactions. Exemplary COTS devices include typical mobile (computing) devices such as mobile phones (typically smartphones) and tablets. COTS devices may belong to the merchant or customer involved in the transaction. When such COTS devices are used, PAN and / or PIN data may originate from or be transmitted / received by the COTS device. Therefore, these COTS devices may be used to install one or more applications that enable the COTS device to be used to obtain PAN data, PIN data and / or other information to fulfill a payment. To do so, in one example, the near-field communication (NFC) component of the COTS device may be used by one or more applications on the device to read PAN data from a payment instrument such as a payment card, and the applications may use such PAN data to complete the transaction. Such technology in which a card reader is housed or embedded within a COTS device may be described as embedded card reader (ECR) technology.

[0024] In some examples, COTS devices and other devices may be configured to acquire PIN data in addition to, or instead of, acquiring PAN data, in order to authorize a transaction. Techniques for acquiring PIN data include “PIN-on-glass” techniques, where a PIN pad or other user interface is displayed on a COTS device configured to receive user input representing a PIN. The COTS device may be a merchant device or a customer device. Corresponding PIN data is generated on the COTS device and used for comparison with reference PIN data associated with a given payment instrument to complete the payment. Furthermore, techniques for acquiring PIN data may include software-based PIN input on COTS (SPoC), where a secure reader PIN, PIN application, merchant device, and backend monitoring and authentication system are used to acquire PIN data using the COTS device. Where “card reader” and / or “reader” are used herein, these terms should be understood to include components configured to acquire data from a payment instrument, which may be a physical card and / or another device and / or an electronic device that stores payment account information, or any object other than a card. Thus, wherever "card" is listed as an example, it should be understood that this is merely an example, and generally any payment instrument may be used.

[0025] The use of embedded card readers in COTS devices for conducting transactions offers many significant advantages. Payment transactions can be more versatile because everything required is a COTS device, such as a mobile phone. Other dedicated payment hardware, like traditional payment card readers, is not needed. This means payments can be made almost anywhere, anytime. The elimination of complex setup or pairing processes between the merchant device and the card reader reduces complexity, increases reliability, and increases the potential transaction throughput. Furthermore, the use of embedded card readers is more environmentally friendly because dedicated card reader devices do not need to be manufactured. Instead, everything required is a COTS device. That said, the use of such COTS devices for conducting transactions is not without its challenges. In particular, the use of COTS devices, or other devices not specifically configured as POS devices with typical security mechanisms, represents an increased risk of unauthorized exposure of PAN and / or PIN data by malicious actors. For example, the inventors recognized that if a malicious actor gains access to a given COTS device, the simultaneous presence of both PAN data and PIN data on the COTS device and / or for the same application increases the risk that the malicious actor can obtain both pieces of information that will later be used in fraudulent transactions. This technical drawback could potentially limit the feasibility of using COTS devices in payment transactions.

[0026] This technical drawback in the security of transaction flows using COTS or other non-proprietary POS devices is addressed by the systems and methods described in this disclosure. As a result, the systems and methods described in this disclosure facilitate the use of COTS devices in transaction flows and enable a more versatile payment infrastructure that does not rely on purpose-specific, dedicated POS devices or payment readers, and therefore provides the aforementioned advantages. This advancement is achieved while maintaining the security of transaction flows and payment data.

[0027] In further detail, the technologies described herein enable the separation of PAN and PIN data through various mechanisms described below, such as two-phase server messaging and other spatial or temporal separation technologies. Alternatively, other technologies described herein also enable secure PIN data input and PAN collection by devices without such spatial or temporal separation, as described in detail below. In other words, this disclosure describes, among other things, technologies for ensuring the temporal and / or spatial separation of PAN and PIN data, such as those used by COTS devices to complete payments associated with transactions, in addition to technologies for securely collecting unseparated PAN and PIN data.

[0028] In one example, a COTS device may include one or more components to ensure the temporal and / or spatial separation of PAN data and PIN data on the COTS device. In some examples, the ECR may be integrated into the card reader library of the POS application, and in these examples, the ECR may communicate directly with the POS application and NFC components of the COTS device. In this example, the ECR may be used to retrieve PAN data from the payment instrument and provide the PAN data to the POS application. The POS application may then be configured to associate the default PIN with the PAN data and send the payment request, along with the PAN data and default PIN, to the payment processing service. Once the PAN data and default PIN have been sent to the payment processing service, the POS application may be configured to delete or otherwise remove the PAN data from the COTS device before requesting the buyer's account PIN. By doing so, the PAN data and PIN data for the account PIN do not exist simultaneously on the COTS device. This temporal separation of PAN data and PIN data may also prevent a malicious actor from obtaining both pieces of information required to use the payment instrument to make a payment. This significantly improves the security of the COTS device for executing transactions. In some cases, once the PAN data is removed, a PIN entry dialog may be displayed to the buyer, who may provide user input representing the account PIN, and the PIN data may be sent to a payment processing service, which may then send an authorization request for payment to the issuer of the payment instrument. By utilizing the process described above, the security of the payment instrument is enhanced through technical means implemented on the computing device associated with the transaction. This enhancement of transaction security is achieved on the fly, in a time-sensitive manner, in other words, in a way that does not negatively impact the speed of the transaction. Thus, enhanced security is provided without making the transaction process unacceptably slow or inefficient.

[0029] From the perspective of the POS application and the payment processing service, the above process may be viewed as follows: Upon receiving a PIN input request, the POS application may return a default PIN without showing the buyer a PIN input dialog, so that the payment kernel can proceed to create the PIN result. The PIN result may be stored in relation to the payment processing service without the actual PIN, and the PIN may then be collected by the POS application and sent to the service. In the payment processing service, a repayment request or transaction request may be stored, and upon receiving the actual account PIN, the default PIN may be replaced. The payment processing service may then send an authorization request to the issuer of the payment instrument used for the transaction.

[0030] In addition to the temporal separation achieved by the processes described above, spatial separation between PAN and PIN data may also be implemented in the form of separate process services. Examples of this may include using separate applications for handling PAN and PIN data, introducing intermediate applications, using trusted execution environments, and / or using encryption schemes that enable PAN data processing to occur in a vendor data center separate from the payment processing service and / or the payment processing service.

[0031] In other examples, the ECR may be isolated from the POS application and / or the card reader library, and the ECR may be used as an isolated service. In these examples, an intermediate application may exist between the ECR and the POS application, and the card reader library may be standalone, integrated into the POS application, or integrated into the intermediate application. This spatial isolation of the ECR from the POS application may give a smaller attack surface for the payment kernel, ensuring that the ECR operates outside the POS application, which may be the most likely attack point for a malicious actor. This further improves the data security of the COTS device in which the card reader is incorporated.

[0032] In some examples, multiple trust applications may be used to determine whether the COTS device is still a trusted device at the time of payment. In yet another embodiment, the ECR may be deployed on the COTS device as a separate application that utilizes the card reader library as a separate application. In these examples, the ECR may be responsible for performing the default PIN addition process. In yet another embodiment, data encryption may be used on the COTS device such that decryption of at least the PAN data and, in some examples, the PIN data is performed outside the COTS device. In this example, the POS application may receive encrypted data from the NFC component and send the encrypted data to a payment processing service. The payment processing service may manage keys and / or other decryption mechanisms and decrypt the encrypted data to identify the PAN data and / or PIN data. In another embodiment, instead of sending the encrypted data to the POS application, the encrypted data is sent to a vendor data center, which may be operated by the device's original equipment manufacturer (OEM). The OEM may have keys and / or other decryption mechanisms to decrypt the encrypted data and identify the PAN data and / or PIN data. In further examples, TEE may be used to enhance ECR security on COTS devices.

[0033] By implementing one or more of the techniques described in this book, spatial and / or temporal separation of PAN data from other data used for transactions, such as PIN data, enhances transaction security and makes it difficult to obtain unauthorized access to all the information necessary to misuse the payment instrument. These techniques are specific to computer-centric technical problems concerning how to best handle digital payment transactions securely on COTS devices, which assume that such devices are more commonly or easily compromised and subject to unauthorized access than conventional dedicated POS devices that typically have built-in security features. For integrity, it should be noted that the techniques disclosed are also specific to computer-centric solutions that utilize specifically configured applications, application configurations, encryption / decryption schemes, TEEs, and other components that cannot be performed by humans, whether as mental processes or through physical means. This added security is also implemented in a time-sensitive manner (i.e., in terms of seconds) between the time a transaction is initiated and the time it is completed, minimizing delays in the payment process and thus providing security without adversely impacting the speed or efficiency of the payment transaction.

[0034] In at least one example, the operations performed by a payment processing service may leverage a multi-party merchant ecosystem. That is, in some examples, a payment processing service (e.g., its associated servers) may communicate with end users (e.g., customers and / or merchants) via individual user computing devices and through one or more networks. Such a remote, network-connected multi-party merchant ecosystem may enable a payment processing service to access data associated with multiple different merchants and / or customers, and in some examples, to use such data to enhance ECR security in real time or near real time. Having a payment processing service, which may have access to multiple heterogeneous merchants and multiple heterogeneous platforms, perform the processes associated with the processes described herein enables the unique generation and use of merchant-related data to enhance ECR security for any given merchant.

[0035] This disclosure provides an overall understanding of the structure, function, manufacturing and use principles of the systems and methods disclosed herein. One or more examples of this disclosure are shown in the accompanying drawings. Those skilled in the art will understand that the systems and methods specifically described herein and illustrated in the accompanying drawings are non-limiting embodiments. Features described or mentioned in relation to one embodiment may be combined with features of other embodiments, including between systems and methods. Such modifications and changes are intended to be included within the scope of the accompanying claims.

[0036] Additional details are provided below with reference to several exemplary embodiments.

[0037] An exemplary environment for embedded card reader security is described below. In Figure 1A, server 106 can be associated with a payment processing service, which can communicate with user computing devices such as merchant device 102 (also referred to herein as merchant device and / or merchant system) and buyer device 104 via network 108. That is, merchant device 102 and buyer device 104 are network-connected devices that enable end users to access services provided by the payment processing service (e.g., via server 106). Additional details associated with server 106, user computing devices (e.g., 102, 104), and network 108 are described below with reference to Figures 15 and 16.

[0038] In at least one example, the server 104 may include a payment processing component 152. The payment processing component 152 may, among other things, process transactions. That is, in at least one example, the payment processing component 152 may access payment data associated with a user, send a request to a payment processing service for permission to access the payment data, and process a transaction based on the response from the payment processing service. In other examples, the payment processing component 152 may have access to an account maintained by the payment processing service and may use the funds associated with the account to process a transaction.

[0039] In at least one example, the payment processing service may expose functions and / or services through one or more APIs 150, thereby enabling the functions and / or services described herein to be integrated into various functional components of environment 100. APIs 150 that may be associated with server 106 may expose the functions described herein and / or enable the payment processing service to be used by various functional components associated with environment 100. At least one of the APIs 150 may be a private API, thereby enabling the services and / or functions to be used by functional components (e.g., applications) developed internally (e.g., by developers associated with the payment processing service). At least one of the APIs 150 may be an open or public API, which is a publicly available API that provides programmatic access to the payment processing service provider's proprietary software applications or web services to third-party developers (e.g., OEMs described herein). In other words, an open or public API may enable the functions and / or services of the payment processing service to be integrated into other platforms. APIs 150 may include a set of requirements governing how applications or other functional components may interact with each other.

[0040] In some cases, the payment processing service may provide a third-party entity with a software developer kit ("SDK") that allows it to utilize the functionality exposed by API 150. The SDK may include software development tools that enable third-party developers (i.e., developers separate from the payment processing service) to use the functionality and / or services described herein. The SDK and / or API 150 may include one or more libraries, programming code, executables, other utilities, and documentation that enable developers to directly utilize the functionality and / or services described herein within the applications described herein.

[0041] In at least one example, server 106 may include or otherwise access data store 146. Data store 146 may store merchant data, user profiles, and payment records, among other types of data. For example, a buyer's user profile may store payment data associated with the buyer's payment instruments. In some examples, an account maintained by a payment processing service on behalf of the buyer may be mapped to or otherwise associated with the buyer's user profile. Such an account may store funds received from peer-to-peer payment transactions, deposits from employers, transfers from other accounts of the buyer, etc. In addition to or instead of this, a merchant's user profile may be mapped to or otherwise associated with a merchant's account (which may be maintained by a payment processing service, a bank, or another payment service). Further details are provided below.

[0042] As illustrated in Figure 1A, the merchant device 102 is associated with a user interface that enables the buyer to interact with the merchant device 102. The user interface may be presented via a web browser, an application (e.g., a desktop, or other proprietary software provided by a third party, such as a payment processing provider) or similar, to enable the buyer to access the functions and / or services as described herein. Similarly, the buyer device 104 may be associated with a user interface that may be presented via a web browser, an application (e.g., a desktop, or other proprietary software provided by a third party, such as a payment processing service) to enable the buyer to interact with the buyer device 104 and access the functions and / or services as described herein.

[0043] As described above, environment 100 may include a merchant device 102, a server 106, and / or a buyer device 104. In addition to the components described above, merchant device 102 may include one or more components such as one or more processors 110, one or more network interfaces 112, memory 114, one or more microphones 116, one or more speakers 118, one or more displays 120, and / or an NFC component 122. The microphone 116 may be configured to receive audio from environment 100 and may generate corresponding audio data, which may be used as discussed herein. The speaker 118 may be configured to output audio. The display 120 may be configured to display images (which may be described as video). The NFC component 122 may be used to wirelessly obtain data from an NFC-enabled payment device. Memory 114 may include one or more components such as a POS application 124, an ECR application 126, an intermediate application 128, an EMV kernel 130, one or more trust applications 132, a PIN application 134, and / or TEE 136. These components are described in detail below. Note that, as with other devices and systems described in this document, the merchant device 102 may take one or more forms, such as a computing device, a laptop computer, a telephone, and / or components thereof.

[0044] In some examples, the reader device 175 may be coupled to the merchant device 102 via a wired or wireless connection, such as via Bluetooth®, BLE, etc. Additional details are provided below with reference to Figures 15 and 16. In some examples, the reader device 175 may read information from a payment instrument. In some examples, the reader device 175 may physically interact with a payment instrument such as a magnetic stripe payment card, an EMV payment card, and / or a short-range communication (e.g., Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth®, Bluetooth® Low Energy (BLE), etc.) payment instrument (e.g., a card or device configured for tapping). In some examples, the POS device and the reader device may be configured in a one-to-one pairing. In other examples, the POS device and the reader device may be configured in a many-to-one pairing (e.g., one POS device coupled to multiple reader devices, or multiple POS devices coupled to one reader device). In some cases, for example, there may be multiple POS devices connected to multiple other devices, such as back-of-the-house systems, printers, line buster devices, and POS readers, to enable information from secondary terminals to be shared between primary and secondary POS terminals via short-range communication technology.

[0045] The server 106, also referred to as payment processing service 106 in this document, may include one or more components, such as one or more processors 138, one or more network interfaces 140, and / or memory 142. The memory 142 may include one or more components, such as an EMV kernel 144, one or more data stores 146 (as described above), one or more machine learning models 148, one or more APIs 150 (as described above), and / or payment processing components 152 (as described above). Examples of these components are given below.

[0046] For example, the COTS device 102 may include one or more of the above-described components to ensure the temporal and / or spatial separation of the PAN data and PIN data on the COTS device 102. In some examples, the ECR 126 may be integrated into a card reader library, in which case the ECR 126 may communicate directly with the POS application 124 and NFC component 122 of the COTS device 102. In this example, the ECR 126 may be used to retrieve PAN data from the payment instrument and provide the PAN data to the POS application 124. The POS application 124 may then be configured to associate the default PIN with the PAN data and send the payment request along with the PAN data and default PIN to the payment processing service 106. By sending the PAN data and default PIN to the payment processing service 106, the payment processing service 106 may have the information necessary to start the payment process, but may not be able to complete the process because the account PIN has not yet been received. The default PIN may be a predefined PIN configured to be recognized by the payment processing service 106 in order to enable the processes described herein to enhance the security of COTS device transactions.

[0047] Once the PAN data and default PIN are sent to the payment processing service 106, the POS application 124 may be configured to delete or otherwise remove the PAN data from the COTS device 102 before requesting the buyer's account PIN. By doing so, the PAN data and PIN data for the account PIN do not exist simultaneously on the COTS device 102. This temporal separation of the PAN data and PIN data may prevent a malicious actor from obtaining both pieces of information required to use the payment instrument to make a payment. Once the PAN data has been removed, a PIN entry dialog may be displayed to the buyer, who may provide user input representing the account PIN. In the example, the PIN application 134 may be configured to receive user input and generate PIN data. In some examples, the POS application 124 and the PIN application 134 may be the same application. In other examples, the POS application 124 and the PIN application 134 may be separate applications, which may increase the spatial separation between the application handling the PAN data and the application handling the PIN data. The PIN data may be sent to payment processing service 106, which may then send an authorization request to the issuer of the payment instrument requesting payment. The issuer may compare the entered account PIN with a reference PIN associated with the PAN and determine whether the entered account PIN is authorized for the PAN. If authorized, the issuer may return an authorization response to payment processing service 106. Payment processing service 106 may provide the authorization indication to the COTS device 102, which may complete the transaction. By utilizing the process described above, payment instrument security is improved in a computer-centric manner that is performed on the fly and in a time-sensitive manner.

[0048] In other examples, the ECR126 and the card reader library may be separated, and the ECR126 may be used as an isolated service. In these examples, the card reader library may function as an intermediate application 128 between the ECR126 and the POS application 124. This spatial separation of the ECR126 and the POS application 124 may give a smaller attack surface for the payment kernel and ensure that the ECR126 operates outside of the POS application 124, which may be the most likely attack point for a malicious actor. In these examples, multiple trust applications 132 may be used to determine whether the COTS device 102 is still a trusted device at the time of payment. Additional details regarding the use of trust applications 132 are provided herein, but generally, trust applications 132 may be used to determine whether one or more conditions of the COTS device 102 indicate that the COTS device 102 has been compromised or is not a trusted device for obtaining PAN and / or PIN data in any other way. In examples where the intermediate application 128 is used, the trusted application 132 may be used to determine whether the POS application 124 has been compromised, and another trusted application 132 may be used to determine whether the intermediate application 128 has been compromised. In these examples, the POS application 124 may still perform the default PIN addition process described above.

[0049] In other examples, spatial and / or temporal separation of PIN data and PAN data is not required; instead, an encryption scheme may be used to facilitate the security of PIN data and PAN data. This encryption-based scheme is described in more detail below with reference to Figure 2. In these examples, encryption of PIN data may be performed using one encryption technique and / or a first encryption credential (e.g., a key), and encryption of PAN data may be performed using a different encryption technique and / or a second encryption credential. In other examples, encryption of PIN data and PAN data may be performed using the same encryption technique.

[0050] Trust Application 132 may consist of extended tamper and fraud detection methods (e.g., trust routines) described in detail in U.S. Patent Applications 15 / 199917 and 15 / 199933, which are incorporated herein by reference. In some examples, one or more trust commands may be initiated on one or more target devices (e.g., user devices and / or merchant devices). Trust commands may include varying levels of specificity and granularity, such as hashing a portion of software code, scanning the memory of a payment entity, checking for jailbreaking of software code, or collecting metadata of a mounted file system. Trust commands may be based on reliably measured data, or test criteria collected across a population of payment platforms, or pre-configured values ​​determined by security experts. After incorporating trust routines, the service may assign user devices and / or merchant devices as trusted devices for a predetermined period. In various examples, the service may assign certification tickets to trusted devices for future interactions. In such an example, the certification routine may be reinitialized and re-executed to certify a trusted device after a period of time has elapsed. Thus, a trusted device may be used to securely transfer transaction data, payment instrument data, and / or verification data between the transaction server and user devices and / or merchant devices in order to execute secure transactions and reduce instances of fraud.

[0051] In further other embodiments, ECR126 may be deployed on the COTS device 102 as a separate application that utilizes the card reader library as a separate application. In these examples, ECR126 may be responsible for performing the default PIN addition process. Again, this embodiment allows for a smaller attack surface over the payment kernel and improves the spatial isolation of processes performed between the POS application 124 and the ECR application 126. Another advantage of this embodiment is that NFC communication is isolated from the POS application 124 because the ECR application 126 handles much of the operation that would have been performed on the POS application 124. Since an intermediate application 128 is utilized in this embodiment, two trusted applications 132 may be utilized as described above.

[0052] In further examples, data encryption may be used in the COTS device 102 such that decryption of at least PAN data and, in some cases, PIN data is performed on the COTS device 102, and the payment processing service 106 uses the encrypted data sent to the payment processing service 106 to identify the PAN data and / or PIN data. For example, an encryption API may be used to encrypt PAN data read from the NFC component 122. The COTS device 102 does not have to include the keys or other decryption mechanisms necessary to decrypt the encrypted data. In this example, the POS application 124 may receive the encrypted data from the NFC component 122, and the POS application 124 may send the encrypted data to the payment processing service 106. The payment processing service 106 may manage the keys and / or other decryption mechanisms and decrypt the encrypted data to identify the PAN data and / or PIN data. The encrypted data may be described as encrypted EMV data when the EMV protocol is used to retrieve data from the payment instrument. In this example, EMV kernel 130 and / or EMV kernel 144 may be isolated from other components to minimize vulnerabilities in the EMV parser used during processing. EMV kernel 144 may parse the EMV data to identify the PAN data, as described in this document.

[0053] In further other examples, data encryption may be utilized in the COTS device 102 such that decryption of at least PAN data and, in some examples, PIN data is performed on the COTS device 102, and the payment processing service 106 uses the encrypted data sent to the payment processing service 106 to identify the PAN data and / or PIN data. For example, an encryption API may be used to encrypt the PAN data read from the NFC component 102. The COTS device 102 does not have to include the keys or other decryption mechanisms necessary to decrypt the encrypted data. In this example, instead of sending the encrypted data to the POS application 102, the encrypted data is sent to a vendor data center 154 which may be operated by the OEM of the COTS device 102. The OEM may have keys and / or other decryption mechanisms to decrypt the encrypted data and identify the PAN data and / or PIN data. The payment processing service 106 may query the OEM about the PAN data and / or an encrypted version of the PAN data that can be decrypted by the payment processing service 106 to complete the transaction. In this example, the POS application 124 simply receives payment status indications from other components of the COTS device 102 and / or from the payment processing service 106, but the PAN data is always spatially isolated from the POS application 124 during the transaction.

[0054] In further examples, TEE 136 may be used to enhance ECR security on the COTS device 102. For example, when PAN data is read by the NFC component 122, the PAN data may be sent to TEE 136, which may be isolated from other components of the COTS device 102. TEE 136 may provide higher security than the POS application 124 by restricting access to TEE 136 without appropriate authorization. In this example, TEE 136 may communicate with the payment processing service 106 to transmit the PAN data and / or an encrypted version of the PAN data. The payment processing service 106 may use this data to determine whether the payment is authorized, and may send a payment transaction indication from the payment processing service 106 to the POS application 124 indicating whether the payment is authorized. In this way, the POS application 124 does not need to have access to the PAN data and instead may proceed with the transaction based at least in part on the indication received from the payment processing service 106.

[0055] By implementing one or more of the techniques described in this book, spatial and / or temporal separation of PAN data from other data used for transactions, such as PIN data, enhances transaction security and makes it difficult to obtain unauthorized access to all the information necessary to misuse the payment instrument. These techniques are specific to computer-centric problems dealing with digital transactions on COTS devices 102, such devices may be compromised and subject to unauthorized access. These techniques are also specific to computer-centric solutions that utilize specifically configured applications, application configurations, encryption / decryption schemes, TEEs, and other components that cannot be performed by humans, whether as a mental process or through physical means. This added security is also implemented in a time-sensitive manner (i.e., in terms of seconds) between the time a transaction is initiated and the time it is completed, minimizing delays in the payment process.

[0056] In at least one example, the operations performed by a payment processing service may leverage a multi-party merchant ecosystem. That is, in some examples, a payment processing service (e.g., its associated servers) may communicate with end users (e.g., customers and / or merchants) via individual user computing devices and through one or more networks. Such a remote, network-connected multi-party merchant ecosystem may enable a payment processing service to access data associated with multiple different merchants and / or customers, and in some examples, to use such data to enhance ECR security in real time or near real time. Having a payment processing service, which may have access to multiple heterogeneous merchants and multiple heterogeneous platforms, perform the processes associated with the processes described herein enables the unique generation and use of merchant-related data to enhance ECR security for any given merchant.

[0057] It should be noted that the exchange of data and / or information described herein may only be performed if the user has provided consent for such exchange of information. For example, during device setup and / or application startup, the user may be given the opportunity to opt in and / or opt out of the data exchange and / or execution of functions between devices described herein. In addition, if one of the devices is associated with a first user account and the other device is associated with a second user account, user consent may be obtained before any or all of the actions and / or processes described herein are performed. Furthermore, actions performed by the system components described herein may only be performed if the user has given consent for the action to be performed.

[0058] In addition, Model 148 may be trained based on transaction information and / or other information associated with payment transactions. For example, transaction information for transactions conducted between multiple merchants and multiple buyers may be received by the payment processing service 106. This information may be received from merchant computing devices associated with the merchants. In these examples, the merchant computing devices may have separate instances of the installed merchant application to configure each merchant computing device as a point-of-sale (POS) terminal. The separate instances of the merchant application may be configured as POS terminals to communicate transaction information to the payment processing service 106 over one or more networks. In some examples, the POS terminals may be online terminals. Using the transaction information, the payment processing service 106 may generate a profile using a model trained with at least one of the merchant information, buyer information and / or transaction information.

[0059] In some implementations, the methods and systems described herein may be integrated with voice services (e.g., Amazon's ALEXA®, Apple's SIRI®, or Microsoft's CORTANA®) through specific API calls to such services from within a multimedia interface. The methods and systems may be integrated with “wake language” to invoke those individual voice services, e-commerce, and fulfillment channels. For example, speaker recognition technology may be used to determine a user profile associated with a user who provides user utterances to a user device to perform one or more of the actions described herein. The determined user profile may be used to customize the security protocols described herein. Furthermore, the voice interface may be associated with an online platform, which may be used to fulfill merchant commands as described herein.

[0060] Figure 1B illustrates a conceptual diagram of the components used to implement SPoC and ECR technologies. Figure 1B is used in this document to provide an exemplary process flow of a PIN transaction in a software-based PIN entry solution. As shown in Figure 1B, a COTS device, such as merchant device 102, may exist, which may include an installed PIN cardholder verification method (CVM) application, such as POS application 124 and / or PIN application 134. The COTS device may be associated with a PIN pad entry screen, a certification component, and a secure session component. In addition, a Secure Card Reader-PIN (SCRP) may exist. The SCRP may include a physical card reader, such as reader device 175, and may include a PCR assessed to be compliant. In the examples, the SCRP may be coupled to the merchant device via a wired or wireless connection, such as via Bluetooth®, BLE, etc. Additional details are provided below with reference to Figures 15 and 16. In some examples, the SCRP may read information from the payment instrument. In some examples, the SCRP may physically interact with payment instruments such as magnetic stripe payment cards, EMV payment cards, and / or short-range communication (e.g., Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth®, Bluetooth® Low Energy (BLE), etc.) payment instruments (e.g., cards or devices configured for tapping). In some examples, the POS device and reader device may consist of a one-to-one pairing. In other examples, the POS device and reader device may consist of a many-to-one pairing (e.g., one POS device coupled to multiple reader devices, or multiple POS devices coupled to one reader device).In some examples, there may be multiple POS devices connected to multiple other devices, such as back-of-the-house systems, printers, line buster devices, and POS readers, to enable information from secondary terminals to be shared between primary and secondary POS terminals via short-range communication technology, for example. In the examples, the card reader library and / or intermediate applications described herein may be configured to help establish and / or facilitate secure data exchange between the SCRP and POS applications 124 and / or ECR126.

[0061] The SCRP may include components used for PIN conversion and for retrieving PAN data and tracking equivalent data encryption. A buyer device and / or payment instrument may also exist to implement the SPoC technology described herein. In addition to or instead of the SCRP, an ECR such as ECR126 may exist. The ECR does not have to be a separate physical card reader like the SCRP, and instead may include components built into a COTS device. The ECR may be configured to encrypt PAN data and monitor data encryption associated with payments. In the example, the ECR may also be configured to encrypt Application Protocol Data Units (APDUs) communicated by the ECR to other components such as a POS application like POS application 124 and / or other components of a COTS device.

[0062] One or more devices and / or systems may communicate with a COTS device and may include a monitoring and certification component, an instance of a PIN CVM application, a COTS component, an SCRP component, a certification component, and / or other components that may be used for PIN CVM application key management and / or certification. The device and / or system may include a card data decryption environment and / or a Payment Card Industry (PCI) PIN environment. Within the card data decryption environment, a key management process may be performed in the same manner as the PIN transaction security hardware security module (HSM) security requirements. In addition, the payment processing process may also be performed as described herein. When ECR is used in contrast to SCRP, the PIN / PAN encryption component of the COTS device may be used for encryption of PIN and / or PAN data, as described more fully herein. In some examples, keys may be used for PIN and / or PAN encryption.

[0063] Using some or all of the components described in this document, the following SPoC techniques may be implemented to utilize a software PIN for securing and / or authorizing transactions. First, the PIN CVM application on the COTS device and SCRP may be initialized with a key. This process may be asynchronous with any unresolved transactions. Subsequently, a secure communication channel may be established between the PIN CVM application and the backend monitoring system. To do this, the secure session components of the COTS device and the secure session components of other devices may communicate to establish a secure session.

[0064] Subsequently, the backend monitoring system may use the certification components described herein to determine the security status of the mobile payment acceptance platform. During this process, the SCRP, ECR, COTS platform, and PIN CVM application may communicate to determine the security status of devices and components, and certification may be performed. Certification may include operations between a server-based verifier and a client-based verifier to determine the current security state / behavior of the verifier based on predetermined measurements and thresholds provided by the verifier.

[0065] Subsequently, a payment card and / or other device capable of transmitting card data, such as a buyer device, may be presented to the SCRP. The PIN CVM application PIN entry component may render a PIN entry screen on the COTS platform, and the cardholder may enter their PIN using the rendered PIN pad from the PIN CVM application. The resulting data may be encrypted and transmitted to the SCRP by the PIN CVM application. The SCRP may encrypt the PAN data using a preloaded data encryption key, utilizing an online or offline PIN verification process. The payment transaction may then be processed using the payment processing components described herein.

[0066] Alternatively, to collect SCRP data, a payment card and / or other device capable of transmitting card data, such as a buyer device, may be presented to the ECR. For example, a POS application may send a payment initiation request to the ECR. The ECR may send an Application Protocol Data Unit (APDU) command to the POS application. The APDU command may initiate the process of causing a reader to retrieve data from the payment instrument. For example, the ECR may generate and / or utilize a stored APDU command and send the command to the POS application so that the POS application and the NFC component can communicate directly to retrieve the PAN associated with the buyer's payment instrument. The POS application may send an instance of the APDU command to the NFC component. The NFC component may then send an APDU response to the POS application. The APDU response may contain the PAN data read from the payment instrument. The ECR may send a PIN entry request to the POS application. Generally, for PIN-on-glass and SPoC transactions, the request for PIN entry is made to collect the account PIN necessary to associate it with the PAN data. However, in this example, to facilitate the temporal separation of PAN data and PIN data on the merchant device, the response to the PIN input request may not trigger the display of a PIN input user interface or otherwise cause the device to retrieve the PIN data. Instead, the POS application may send a default PIN to the ECR, which may send an authorization request to the POS application. At this point, the POS application may have all the data necessary to request authorization from the payment processing service for payment using the payment instrument. Once the PAN data has been removed from the device as described herein, a request for the actual PIN may be made.The PIN CVM application PIN entry component may render a PIN entry screen on the COTS platform, and the cardholder may enter their PIN using the rendered PIN pad from the PIN CVM application.

[0067] In other examples, spatial and / or temporal separation of PIN data and PAN data is not required; instead, an encryption scheme may be used to facilitate the security of PIN data and PAN data. This encryption-based scheme is described in more detail below with reference to Figure 2. PAN data may be obtained using ECR as described in this document. The PIN CVM application PIN input component may render a PIN input screen on the COTS platform, and the cardholder may enter their PIN using the rendered PIN pad from the PIN CVM application. In these examples, encryption of PIN data may be performed using one encryption technique and / or a first encryption credential (e.g., a key), and encryption of PAN data may be performed using a different encryption technique and / or a second encryption credential. In other examples, encryption of PIN data and PAN data may be performed using the same encryption technique.

[0068] In further examples, a POS application, upon receiving an indication that the payment process is about to begin, may generate a payment initiation request and send it to an intermediate application. This spatial separation between the ECR and the POS application may give a smaller attack surface for the payment kernel, ensuring that the ECR operates outside the POS application, which may be the most likely attack point for a malicious actor. In these examples, multiple trust applications may be used to determine whether the merchant device is still a trusted device at the time of payment. Additional details regarding the use of trust applications are provided in this document, but generally, a trust application may be used to determine whether one or more conditions of the merchant device indicate that the merchant device has been compromised or is not a trusted device for obtaining PAN and / or PIN data in any other way. In examples where an intermediate application is used, a trust application may be used to determine whether the POS application has been compromised, and another trust application may be used to determine whether the intermediate application has been compromised. In these examples, the POS application may still perform the default PIN addition process described above. When an actual PIN is requested, the PIN CVM application PIN entry component may render a PIN entry screen on the COTS platform, and the cardholder may enter their PIN using the rendered PIN pad from the PIN CVM application.

[0069] In further examples, the ECR application may perform security actions associated with payment. In these examples, in addition to the use of an intermediate application, the intermediate application may send an instance of a payment initiation request to the ECR application. For example, if a trust routine indicates that the intermediate application has not been compromised, the intermediate application may send an instance of a payment initiation request to the ECR application. The ECR application may also send APDU commands to the NFC component, and further communication between the NFC component and the POS application may utilize the ECR application.

[0070] In some examples, the PIN is entered on the touchscreen of the COTS device. However, in some examples, a buyer device is used to enter the PIN, and the certification, monitoring, and other operations associated with SPoC technology are performed in relation to the buyer device.

[0071] Figure 2 illustrates an exemplary process associated with protecting payments using ECR without generating a default personal identification information (PIN). Figure 2 provides a sequence diagram showing an exemplary sequence of the process. It should be understood that the sequence provided in Figure 2 is provided as an example and not an limitation, and some or all of the actions described in Figure 2 may be performed in a different order and / or in parallel.

[0072] In block 202, the POS application 124 may send a payment initiation request to the ECR 126. For example, a merchant may add products to a transaction so that they can be purchased by a buyer, and once all the products that the buyer wishes to purchase have been added, the merchant may initiate the payment process to fulfill the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate a payment initiation request and send it to the ECR 126.

[0073] In block 204, ECR126 may send an Application Protocol Data Unit (APDU) command to POS application 124. The APDU command may initiate the process of causing the reader to retrieve data from the payment instrument. For example, ECR126 may generate and / or use a stored APDU command and send the command to POS application 124 so that POS application 124 and NFC component 122 can communicate directly to retrieve the PAN associated with the buyer's payment instrument.

[0074] In block 206, the POS application 124 may send an instance of the APDU command to the NFC component 122. Sending the APDU command to the NFC component 122 may cause the NFC component 122 to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0075] In block 208, the NFC component 122 may send an APDU response to the POS application 124. The APDU response may include PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used.

[0076] In block 210, the POS application 124 may send an APDU response and / or an indication of an APDU response to the ECR 126. For example, the POS application 124 may indicate to the ECR 126 that response data has been received from the NFC component 122 and that payment processing will proceed.

[0077] In block 212, ECR126 may send a PIN input request to POS application 124. Generally, for PIN-on-glass and SPoC transactions, the request for PIN input is made to collect the account PIN necessary to associate it with PAN data.

[0078] In block 214, the POS application 124 may be configured to present a PIN entry dialog to the buyer. In other embodiments where SPoC is utilized, the POS application 124 may query one or more devices, such as the buyer device 104 and / or a remote system, for a software PIN, as described more fully in this document. For example, the user interface of the merchant device may display a PIN entry dialog, such as a PIN pad, configured to accept user input corresponding to an account PIN. In embodiments of SPoC, the merchant device may query one or more devices to receive a software PIN, as described more fully in this document.

[0079] In block 216, user input data representing the account PIN and / or software PIN may be received by the POS application 124. At this point, the POS application 124 may store the account PIN and / or software PIN and the PAN data in association.

[0080] In block 218, the POS application 124 may perform encryption of the PIN data and the PAN data. In the example, encryption of the PIN data may be performed using one encryption technique and / or a first encryption credential (e.g., a key), and encryption of the PAN data may be performed using a different encryption technique and / or a second encryption credential. In other examples, encryption of the PIN data and the PAN data may be performed using the same encryption technique.

[0081] In block 220, the POS application 124 may send a payment request to the payment processing service 106. The payment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and an account PIN.

[0082] In block 222, payment processing service 106 may send an authorization request indicating PAN data and account PIN to the issuer of the payment instrument used to fulfill the payment. The issuer may use the PAN data and account PIN to determine whether to authorize the payment. The issuer may authorize the payment if the payment instrument is associated with an account that has sufficient funds to fulfill the payment and the account PIN is the PIN associated with the payment instrument.

[0083] In block 224, the issuer may return an authorization response which may indicate whether the instrument of payment has been accepted or rejected to fulfill the payment. In the example, the authorization response may not include PAN data and / or account PIN, but instead may include an indication of payment acceptance or rejection.

[0084] In block 226, the payment processing service 106 may send a payment response to the POS application 124. The payment response may indicate to the POS application 124 that the payment request has been received but the account PIN is still required.

[0085] In block 228, the POS application 124 may send a billing completion request to the payment processing service 106. For example, if the issuer authorizes the use of payment instruments to fulfill a payment, the POS application 124 may generate a billing completion request indicating that the requirements for completing the payment have been met and that any outstanding bills associated with the payment have been completed. The payment processing service 106 may use the billing completion request to update its system to indicate that the payment status is complete.

[0086] Figure 3 illustrates an exemplary process 300 associated with protecting payments using an ECR, in which the POS application communicates directly with the ECR. Figure 3 provides a sequence diagram showing an exemplary sequence of the process. The sequence provided in Figure 3 is provided as an example and not as an limitation, and it should be understood that some or all of the actions described in Figure 3 may be performed in a different order and / or in parallel.

[0087] In block 302, the POS application 124 may send a payment initiation request to the ECR 126. For example, a merchant may add products to a transaction so that they can be purchased by a buyer, and once all the products that the buyer wishes to purchase have been added, the merchant may initiate the payment process to fulfill the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate a payment initiation request and send it to the ECR 126.

[0088] In block 304, ECR126 may send an Application Protocol Data Unit (APDU) command to POS application 124. The APDU command may initiate the process of causing the reader to retrieve data from the payment instrument. For example, ECR126 may generate and / or use a stored APDU command and send the command to POS application 124 so that POS application 124 and NFC component 122 can communicate directly to retrieve the PAN associated with the buyer's payment instrument.

[0089] In block 306, the POS application 124 may send an instance of the APDU command to the NFC component 122. Sending the APDU command to the NFC component 122 may cause the NFC component 122 to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0090] In block 308, the NFC component 122 may send an APDU response to the POS application 124. The APDU response may include PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used.

[0091] In block 310, the POS application 124 may send an APDU response and / or an indication of an APDU response to the ECR 126. For example, the POS application 124 may indicate to the ECR 126 that response data has been received from the NFC component 122 and that payment processing will proceed.

[0092] In block 312, ECR126 may send a PIN input request to POS application 124. Generally, for PIN-on-glass and SPoC transactions, the request for PIN input is made to collect the account PIN necessary to associate it with PAN data. However, here, in order to facilitate the temporal separation of PAN data and PIN data on the merchant device, the response to the PIN input request may not trigger the display of a PIN input user interface or otherwise cause the device to retrieve the PIN data.

[0093] Alternatively, in block 314, the POS application 124 may send a default PIN to the ECR 126. The default PIN may be any number, alphabet, and / or alphanumeric code predetermined as a default code to satisfy the requirement that the PAN data includes a PIN when sent to the payment processing service 106. However, since the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be used to complete a transaction.

[0094] In block 316, ECR126 may send an authorization request to POS application 124. At this point, POS application 124 may have all the data necessary to request authorization from payment processing service 106 for a payment using the payment instrument. In addition, it may also have the data necessary to satisfy ECR126's requirements in order to proceed with the payment process.

[0095] In block 318, the POS application 124 may send a payment request to the payment processing service 106. The payment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and a default PIN. The payment processing service 106 receives the payment request and may identify the included PIN as the default PIN. Based at least in part on the payment request containing the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. It should be understood that although one default PIN is listed, the default PIN may be dynamic and may change, for example, over time and / or based on the characteristics of any other factors associated with the merchant, buyer, transaction and / or payment. At this point, the POS application 124 may remove the PAN data from the merchant device so that the PAN data does not exist on the merchant device before the account PIN is provided to the merchant device.

[0096] In block 320, the payment processing service 106 may send a payment response to the POS application 124. The payment response may indicate to the POS application 124 that the payment request has been received but the account PIN is still required.

[0097] In block 322, the POS application 124 may be configured to present a PIN entry dialog to the buyer. In other embodiments where SPoC is utilized, the POS application 124 may query one or more devices, such as the buyer device 104 and / or a remote system, for a software PIN, as described more fully in this document. For example, the user interface of the merchant device may display a PIN entry dialog, such as a PIN pad, configured to accept user input corresponding to an account PIN. In embodiments of SPoC, the merchant device may query one or more devices to receive a software PIN, as described more fully in this document.

[0098] In block 324, user input data representing the account PIN and / or software PIN may be received by the POS application 124. At this point, the POS application 124 may store the account PIN and / or software PIN in association, but the PAN data is not stored, assuming that the PAN data was previously removed from the merchant device as described above.

[0099] In block 326, a PIN addition request may be sent to the payment processing service 106. The PIN addition request may include the account PIN and, in this example, the identifier of the unresolved payment. At this point, the payment processing service 106 may associate the account PIN with the PAN data for payment.

[0100] In block 328, payment processing service 106 may send an authorization request indicating PAN data and account PIN to the issuer of the payment instrument to be used to fulfill the payment. The issuer may use the PAN data and account PIN to determine whether to authorize the payment. The issuer may authorize the payment if the payment instrument is associated with an account that has sufficient funds to fulfill the payment and the account PIN is the PIN associated with the payment instrument.

[0101] In block 330, the issuer may return an authorization response which may indicate whether the instrument of payment has been accepted or rejected to fulfill the payment. In the example, the authorization response may not include PAN data and / or account PIN, but instead may include an indication of payment acceptance or rejection.

[0102] In block 332, the payment processing service 106 may send a PIN addition response to the POS application 124. The PIN addition response may be a response to the PIN addition request described above and may indicate that the payment instrument has been approved or rejected to fulfill the payment.

[0103] In block 334, the POS application 124 may send a billing completion request to the payment processing service 106. For example, if the issuer authorizes the use of payment instruments to fulfill a payment, the POS application 124 may generate a billing completion request indicating that the requirements for completing the payment have been met and that any outstanding bills associated with the payment have been completed. The payment processing service 106 may use the billing completion request to update its system to indicate that the payment status is complete.

[0104] Figure 4 illustrates an exemplary process 400 associated with securing payments using an intermediate application configured to communicate with POS applications 124 and ECR 126. Figure 4 provides a sequence diagram showing an exemplary sequence of the process. The sequence provided in Figure 4 is provided as an example and not as an limitation, and it should be understood that some or all of the actions described in Figure 4 may be performed in a different order and / or in parallel.

[0105] In block 402, the POS application 124 may send a payment initiation request to the intermediate application 128, which may be referred to herein as the card reader library application. For example, a merchant may add products to a transaction for purchase by a buyer, and once all products that the buyer wishes to purchase have been added, the merchant may initiate a payment process to fulfill the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate a payment initiation request and send it to the intermediate application 128. This spatial separation between the ECR 126 and the POS application 124 may give a smaller attack surface for the payment kernel, ensuring that the ECR 126 operates outside of the POS application 124, which may be the most likely attack point for a malicious actor. In these examples, multiple trust applications may be used to determine whether the merchant device is still a trusted device at the time of payment. While further details regarding the use of trusted applications are provided in this document, trusted applications may generally be used to determine whether one or more conditions of a merchant device indicate that the merchant device has been compromised or is not a trusted device for obtaining PAN and / or PIN data in any other way. In examples where intermediate application 128 is used, a trusted application may be used to determine whether POS application 124 has been compromised, and another trusted application may be used to determine whether intermediate application 128 has been compromised. In these examples, POS application 124 may still perform the default PIN addition process described above.

[0106] In block 404, the intermediate application 128 may send an instance of the payment initiation request to the ECR 126. For example, if the trust routine indicates that the intermediate application 128 has not been compromised, the intermediate application 128 may send an instance of the payment initiation request to the ECR 126.

[0107] In block 406, ECR126 may send an APDU command to intermediate application 128. The APDU command may initiate the process of causing the reader to retrieve data from the payment instrument. For example, ECR126 may generate and / or use a stored APDU command and send the command to intermediate application 128 so that it is sent to POS application 124.

[0108] In block 408, the intermediate application 128 may send an instance of the APDU command to the POS application 124. For example, if the trust routine indicates that the intermediate application 128 has not been compromised, the intermediate application 128 may send an instance of the APDU command to the POS application 124.

[0109] In block 410, the POS application 124 may send an APDU command to the NFC component 122. Sending an APDU command to the NFC component 122 may cause the NFC component 122 to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0110] In block 412, the NFC component 122 may send an APDU response to the POS application 124. The APDU response may include PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used.

[0111] In block 414, the POS application 124 may send an instance of the APDU response to the intermediate application 128. The POS application 124 may send an instance of the APDU response to the intermediate application 128, rather than directly to the ECR 126, in order to maintain spatial isolation of the data transmitted between the POS application 124 and the ECR 126.

[0112] In block 416, the intermediate application 128 may send an instance of the APDU response to the ECR 126. For example, if the trust routine indicates that the intermediate application 128 has not been compromised, the intermediate application 128 may send an instance of the APDU response to the ECR 126.

[0113] In block 418, ECR126 may send a PIN input request to intermediate application 128. Generally, for PIN-on-glass and SPoC transactions, the request for PIN input is made to collect the account PIN necessary to associate it with PAN data. However, here, in order to facilitate the temporal separation of PAN data and PIN data on the merchant device, the response to the PIN input request may not trigger the display of a PIN input user interface or otherwise cause the device to acquire the PIN data.

[0114] In block 420, the intermediate application 128 may send an instance of a PIN input request to the POS application 124. Upon receiving a PIN input request from the intermediate application 128, the POS application 124 may suppress the display of the PIN input dialog.

[0115] In block 422, the POS application may generate a default PIN and transmit the default PIN to the intermediate application 128. The default PIN may be any number, letter, and / or alphanumeric code predetermined as a default code to satisfy the requirement that the PAN data includes a PIN when transmitted to the payment processing service 106. However, since the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be used to complete a transaction.

[0116] In block 424, the intermediate application 130 may send a default PIN to the ECR 126. For example, if the trust routine indicates that the merchant device has not been compromised, the intermediate application 130 may send a default PIN to the ECR 126.

[0117] In block 426, ECR126 may generate an authorization request and send it to intermediate application 128. The authorization request may indicate that the data required to satisfy ECR126's requirements in order to advance the payment process has been met.

[0118] In block 428, the intermediate application 128 may send an instance of the authorization request to the POS application 124. For example, if the trust routine indicates that the merchant device has not been compromised, the intermediate application 130 may send an instance of the authorization request to the POS application 124. At this point, the POS application 124 may have all the data necessary to request authorization from the payment processing service 106 for a payment using the payment instrument.

[0119] In block 430, the POS application 124 may send a payment request to the payment processing service 106. The payment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and a default PIN. The payment processing service 106 receives the payment request and may identify the included PIN as the default PIN. Based at least in part on the payment request containing the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. It should be understood that although one default PIN is listed, the default PIN may be dynamic and may change, for example, over time and / or based on the characteristics of any other factors associated with the merchant, buyer, transaction and / or payment. At this point, the POS application 124 may remove the PAN data from the merchant device so that the PAN data does not exist on the merchant device before the account PIN is provided to the merchant device.

[0120] In block 432, the payment processing service 106 may send a payment response to the POS application 124. The payment response may indicate to the POS application 124 that the payment request has been received but the account PIN is still required.

[0121] In block 434, the POS application 124 may be configured to present a PIN entry dialog to the buyer. In other embodiments where SPoC is utilized, the POS application 124 may query one or more devices, such as the buyer device 104, for a software PIN, as described more fully in this document. For example, the user interface of the merchant device may display a PIN entry dialog, such as a PIN pad, configured to accept user input corresponding to an account PIN. In embodiments of SPoC, the merchant device may query one or more devices to receive a software PIN, as described more fully in this document.

[0122] In block 436, user input data representing the account PIN and / or software PIN may be received by the POS application 124. At this point, the POS application 124 may store the account PIN and / or software PIN in association, but the PAN data is not stored, assuming that the PAN data was previously removed from the merchant device as described above.

[0123] In block 438, a PIN addition request may be sent to the payment processing service 106. The PIN addition request may include the account PIN and, in this example, the identifier of the unresolved payment. At this point, the payment processing service 106 may associate the account PIN with the PAN data for payment.

[0124] In block 440, payment processing service 106 may send an authorization request indicating PAN data and account PIN to the issuer of the payment instrument to be used to fulfill the payment. The issuer may use the PAN data and account PIN to determine whether to authorize the payment. The issuer may authorize the payment if the payment instrument is associated with an account that has sufficient funds to fulfill the payment and the account PIN is the PIN associated with the payment instrument.

[0125] In block 442, the issuer may return an authorization response which may indicate whether the instruments of payment have been accepted or rejected to fulfill the payment. In the example, the authorization response may not include PAN data and / or account PIN, but instead may include an indication of payment acceptance or rejection.

[0126] In block 444, the payment processing service 106 may send a PIN addition response to the POS application 124. The PIN addition response may be a response to the PIN addition request described above and may indicate that the payment instrument has been approved or rejected to fulfill the payment.

[0127] In block 446, the POS application 124 may send a billing completion request to the payment processing service 106. For example, if the issuer authorizes the use of payment instruments to fulfill a payment, the POS application 124 may generate a billing completion request indicating that the requirements for completing the payment have been met and that any outstanding bills associated with the payment have been completed. The payment processing service 106 may use the billing completion request to update its system to indicate that the payment status is complete.

[0128] Figure 5 illustrates an exemplary process 500 associated with protecting a payment using ECR, where the ECR application performs security actions associated with the payment. Figure 5 provides a sequence diagram showing an exemplary sequence of the process. The sequence provided in Figure 5 is provided as an example and not an limitation, and it should be understood that some or all of the actions described in Figure 5 may be performed in a different order and / or in parallel.

[0129] In block 502, the POS application 124 may send a payment initiation request to the intermediate application 128, which may be referred to herein as the card reader library. For example, a merchant may add products to a transaction for purchase by a buyer, and once all products that the buyer wishes to purchase have been added, the merchant may initiate a payment process to fulfill the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate a payment initiation request and send it to the intermediate application 128. This spatial separation between the ECR application 126 and the POS application 124 may give a smaller attack surface for the payment kernel, ensuring that the ECR application 126 operates outside of the POS application 124, which may be the most likely attack point for a malicious actor. In these examples, multiple trust applications may be used to determine whether the merchant device is still a trusted device at the time of payment. While further details regarding the use of trusted applications are provided in this document, trusted applications may generally be used to determine whether one or more conditions of a merchant device indicate that the merchant device has been compromised or is not a trusted device for obtaining PAN and / or PIN data in any other way. In examples where intermediate application 128 is used, a trusted application may be used to determine whether POS application 124 has been compromised, and another trusted application may be used to determine whether intermediate application 128 has been compromised. In these examples, POS application 124 may still perform the default PIN addition process described above.

[0130] In block 504, the intermediate application 128 may send an instance of the payment initiation request to the ECR application 126. For example, if the trust routine indicates that the intermediate application 128 has not been compromised, the intermediate application 128 may send an instance of the payment initiation request to the ECR application 126.

[0131] In block 506, the ECR application 126 may send an APDU command to the NFC component 122. The APDU command may initiate the process of causing the reader to retrieve data from the payment device. For example, the ECR application 126 may generate and / or use a stored APDU command and send the command to the NFC component 122.

[0132] In block 508, the NFC component 122 may send an APDU response to the ECR application 126. The APDU response may include PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used.

[0133] In block 510, the ECR application 126 may initiate the PIN entry process within itself without requesting the POS application 124 to initiate such a process. For example, instead of querying the POS application 124 to initiate the PIN entry process in the example in Figure 4, the ECR application 126 may initiate the PIN entry process.

[0134] In block 512, the ECR application 126 may generate a default PIN. The default PIN may be any number, letter, and / or alphanumeric code predetermined as a default code to satisfy the requirement that PAN data includes a PIN when transmitted to the payment processing service 106. However, since the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be used to complete a transaction.

[0135] In block 514, the ECR application 126 may send an authorization request to the intermediate application 128. The authorization request may indicate that the data required to satisfy the requirements of the ECR application 126 in order to advance the payment process has been met.

[0136] In block 516, the intermediate application 128 may send an instance of the authorization request to the POS application 124. For example, if the trust routine indicates that the merchant device has not been compromised, the intermediate application 128 may send an instance of the authorization request to the POS application 124. At this point, the POS application 124 may have all the data necessary to request the payment processing service 106 to authorize a payment using the payment instrument.

[0137] In block 518, the POS application 124 may send a payment request to the payment processing service 106. The payment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and a default PIN. The payment processing service 106 receives the payment request and may identify the included PIN as the default PIN. Based at least in part on the payment request containing the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. It should be understood that although one default PIN is listed, the default PIN may be dynamic and may change, for example, over time and / or based on the characteristics of any other factors associated with the merchant, buyer, transaction and / or payment. At this point, the POS application 124 may remove the PAN data from the merchant device so that the PAN data does not exist on the merchant device before the account PIN is provided to the merchant device.

[0138] In block 520, the payment processing service 106 may send a payment response to the POS application 124. The payment response may indicate to the POS application 124 that the payment request has been received but the account PIN is still required.

[0139] In block 522, the POS application 124 may be configured to present a PIN entry dialog to the buyer. In other embodiments where SPoC is utilized, the POS application 124 may query one or more devices, such as the buyer device 104, for a software PIN, as described more fully in this document. For example, the user interface of the merchant device may display a PIN entry dialog, such as a PIN pad, configured to accept user input corresponding to an account PIN. In embodiments of SPoC, the merchant device may query one or more devices to receive a software PIN, as described more fully in this document.

[0140] In block 524, user input data representing the account PIN and / or software PIN may be received by the POS application 124. At this point, the POS application 124 may store the account PIN and / or software PIN in association, but the PAN data is not stored, assuming that the PAN data was previously removed from the merchant device as described above.

[0141] In block 526, a PIN addition request may be sent to the payment processing service 106. The PIN addition request may include the account PIN and, in this example, the identifier of the unresolved payment. At this point, the payment processing service 106 may associate the account PIN with the PAN data for payment.

[0142] In block 528, payment processing service 106 may send an authorization request indicating PAN data and account PIN to the issuer of the payment instrument to be used to fulfill the payment. The issuer may use the PAN data and account PIN to determine whether to authorize the payment. The issuer may authorize the payment if the payment instrument is associated with an account that has sufficient funds to fulfill the payment and the account PIN is the PIN associated with the payment instrument.

[0143] In block 530, the issuer may return an authorization response which may indicate whether the instrument of payment has been accepted or rejected to fulfill the payment. In the example, the authorization response may not include PAN data and / or account PIN, but instead may include an indication of payment acceptance or rejection.

[0144] In block 532, the payment processing service 106 may send a PIN addition response to the POS application 124. The PIN addition response may be a response to the PIN addition request described above and may indicate that the payment instrument has been approved or rejected to fulfill the payment.

[0145] In block 534, the POS application 124 may send a billing completion request to the payment processing service 106. For example, if the issuer authorizes the use of payment instruments to fulfill a payment, the POS application 124 may generate a billing completion request indicating that the requirements for completing the payment have been met and that any outstanding bills associated with the payment have been completed. The payment processing service 106 may use the billing completion request to update its system to indicate that the payment status is complete.

[0146] Figure 6 illustrates a conceptual diagram of exemplary components used to protect payments, separating the processes associated with obtaining the PAN and PIN. For example, the merchant device 102 shown in Figure 6 may be a COTS device for executing a transaction. These devices may be used to install one or more applications that enable the COTS device to be used to obtain PAN data and / or other information to fulfill the payment. To do so, the NFC component of the COTS device may be used by one or more applications on the device to read the PAN data from the payment instrument, and the applications may use such PAN data to complete the transaction. In some examples, the COTS device and other devices may be configured to obtain PIN data in addition to obtaining PAN data to authorize the transaction. The requirement for PIN data can add a layer of security to the transaction, as a malicious actor must not only obtain the physical payment instrument but also the PIN associated with the payment instrument. Techniques for obtaining PIN data include "PIN-on-glass" techniques in which a PIN pad or other user interface is displayed on a merchant device configured to receive user input representing the PIN. Corresponding PIN data is generated on the merchant device and used for comparison with reference PIN data associated with a given payment instrument to complete the payment. Furthermore, the technology for obtaining PIN data includes a secure reader PIN, PIN application, merchant device, and SPoC where a backend monitoring and authentication system is used to obtain the PIN data.

[0147] As shown in Figure 6, the merchant device 102 may communicate with a payment instrument and / or customer device 104 which may store PAN data that may be read by the NFC components of the merchant device 102. In the example in Figure 6, different components are involved in obtaining the PAN data than those involved in obtaining the PIN data. For example, the NFC driver 602 may be stored in the kernel components of the merchant device 102 and may communicate with an NFC daemon 604 stored in relation to system user space. The NFC daemon 604 may communicate with the NFC driver 602 and the POS application 124 to obtain the PAN data, as described herein. The card reader library payment component 612 of the POS application may be configured to receive the PAN data and utilize the PAN data for payment processing as described herein.

[0148] In addition, the screen driver 606 stored in relation to the kernel may be configured to display input means for obtaining PIN data on the screen of the merchant device 102, such as by displaying a PIN dialog and requesting that the buyer provide user input indicating the account PIN. The screen driver 606 may be configured to communicate with a touch input component 608 in the user space of the system. The touch input component 608 may be configured to request the screen driver 606 to display a PIN input dialog, as described herein. User input data representing the PIN may be sent from the touch input component 608 to the PIN handler 610 of the POS application 124. The PIN handler 610 may be configured to receive the PIN data and provide the PIN data to the payment processing service 106. In these examples, the POS application 124 may receive both PAN data and PIN data, but the PAN data may be received by a different component of the POS application 124 than the PIN data. In addition, at the kernel and system level of the merchant device 102, the PAN data and PIN data do not have to be handled by the same component. This may facilitate spatial separation between PAN data and PIN data in the merchant device 102.

[0149] Figure 7 illustrates a conceptual diagram of exemplary components used to protect payments, where PAN data is handled by an isolated service and PIN data is handled by a POS application. Figure 7 may include some of the same components as those described in Figure 6. For example, the merchant device 102 in Figure 7 may include an NFC driver 602, an NFC daemon 604, a screen driver 606, a touch input component 608, a PIN handler 610, a card reader library payment component 612, and / or a POS application 124. However, instead of the POS application 124 including both the card reader library payment component 612 and the PIN handler 610 as shown in Figure 7, the POS application 124 may include only the PIN handler 610, while the isolated service 702 may include the card reader library payment component 612 and handle the PAN data.

[0150] For example, the merchant device 102 may communicate with a payment instrument and / or customer device 104 which may store PAN data that may be read by the NFC component of the merchant device 102. In the example in Figure 7, different components are involved in obtaining the PAN data than those involved in obtaining the PIN data. For example, the NFC driver 602 may be stored in the kernel component of the merchant device 102 and may communicate with an NFC daemon 604 stored in relation to the system user space. The NFC daemon 604 may communicate with the NFC driver 602 and the POS application 124 to obtain the PAN data, as described herein. The card reader library payment component 612 of the isolated service 702 may be configured to receive data from the POS application 124, which may utilize the PAN data for payment processing, as described herein. The isolated service 702 may be configured to communicate PAN data and / or an encrypted version of the PAN data to the POS application 124 for transmission to the payment processing service 106 and / or directly from the isolated service 702 to the payment processing service 106.

[0151] In addition, the screen driver 606, stored in relation to the kernel, may be configured to display input means for obtaining PIN data on the screen of the merchant device 102, such as by displaying a PIN dialog and requesting that the buyer provide user input indicating the account PIN. The screen driver 606 may be configured to communicate with a touch input component 608 in the system's user space. The touch input component 608 may be configured to request the screen driver 606 to display a PIN input dialog, as described herein. User input data representing the PIN may be transmitted from the touch input component 608 to the PIN handler 610 of the POS application 124. The PIN handler 610 may be configured to receive the PIN data and provide the PIN data to the payment processing service 106. In these examples, further separation of PAN data and PIN data may be implemented at the application level of the merchant device 102.

[0152] Figure 8 illustrates a conceptual diagram of exemplary components used to protect payments, where EMV data processing is handled by a payment processing service instead of the merchant device. Figure 8 may include some of the same components as those described in Figure 6. For example, the merchant device 102 in Figure 8 may include an NFC driver 602, an NFC daemon 604, and / or a POS application 124. However, as shown in Figure 8, instead of the POS application 124 handling PAN data, EMV data is sent through the POS application 124 to the payment processing service 106 for processing.

[0153] For example, the merchant device 102 may communicate with a payment instrument and / or customer device 104 which may store PAN data that may be read by the NFC components of the merchant device 102. In the example in Figure 8, the NFC driver 602 may be stored in the kernel components of the merchant device 102 and may communicate with an NFC daemon 604 stored in relation to the user space portion of the system. In the example in Figure 8, an encryption API 802 may be used at the kernel level to encrypt the PAN data received from the NFC driver 602. In other examples, instead of the encryption API 802 being used at the kernel level, encryption may occur in user space. The PAN data may be encrypted before being sent to the POS application 124. This encrypted data may include encrypted EMV data. In this example, the POS application 124, like other components of the merchant device 102, may not have a key and / or other decryption means for decrypting the EMV data. Alternatively, the NFC daemon 604 may send encrypted EMV data to the POS application 124, which may send encrypted EMV data to the payment processing service 106. When encryption occurs as described in these examples, encryption keys may be used, and these encryption keys may be symmetric AES keys that are generated and sent by the POS application 124. The POS application 124 may derive an encryption key from one or more public keys sent to the POS application 124 from the payment processing service 106.

[0154] The payment processing service 106 may store the EMV data received from the merchant device 102 in association with a security key and / or other decryption means for decryption. In these examples, the payment processing service 106 may decrypt the EMV data to identify the PAN data. Additional security processes may be performed, such as obtaining PIN data and / or comparing said PIN data with a reference PIN associated with the payment instrument, and the payment processing service 106 may determine whether the use of the payment instrument is permitted to settle outstanding payments. If permitted, the payment processing service 106 may send an indication of permission to the POS application 124, which may complete the transaction at least in part on receiving the indication.

[0155] Figure 9 illustrates a conceptual diagram of exemplary components used to protect payments, where EMV data processing is handled by the vendor data center. Figure 9 may include some of the same components as those described in Figure 6. For example, the merchant device 102 in Figure 9 may include an NFC driver 602 and / or a POS application 124. However, as shown in Figure 9, instead of the POS application 124 handling PAN data, EMV data is sent to the vendor data center for processing.

[0156] For example, the merchant device 102 may communicate with a payment instrument and / or customer device 104 which may store PAN data that may be read by the NFC component of the merchant device 102. In the example in Figure 9, the NFC driver 602 may be stored in the kernel component of the merchant device 102 and may communicate with an NFC EMV daemon 902 stored in relation to the user space portion of the system. In the example in Figure 9, an encryption API 802 may be used at the kernel level to encrypt the PAN data received from the NFC driver 602. This encrypted data may include encrypted EMV data. In other examples, instead of the encryption API 802 being used at the kernel level, encryption may occur in user space. The PAN data may be encrypted before being sent to the POS application 124. In these examples, the POS application 124, like other components of the merchant device 102, may not have a key and / or other decryption means for decrypting the EMV data. Alternatively, the NFC EMV daemon 902 may send encrypted EMV data to the vendor data center 904. The vendor data center 904 may be associated with the OEM of the merchant device 102.

[0157] The vendor data center 904 may store the EMV data received from the merchant device 102 in association with a security key and / or other decryption means for decryption. In these examples, the vendor data center 904 may decrypt the EMV data to identify the PAN data. The vendor data center 904 may send the PAN data and / or payment status indications (e.g., acquired PAN data) to the payment processing service 106 for further processing. The vendor data center 904, the POS application 124, and / or the payment processing service 106 may communicate the payment status to each other so that the PAN data is primarily handled by the vendor data center 904, while the POS application 124 and the payment processing service 106 receive appropriate authorization indications to proceed with the transaction.

[0158] Figure 10 illustrates a conceptual diagram of exemplary components used to secure payments using a TEE. The environment in Figure 10 may include, for example, some of the same components described with respect to Figure 1, including a customer device 104 and / or customer payment instrument, a POS application 124, a TEE 136, and / or a payment processing service 106. Figure 10 shows the use of TEE 136 to facilitate ECR security as described herein. For example, TEE 136 may be used to enhance ECR security on a COTS device. For example, if PAN data is read by an NFC component of a COTS device, the PAN data may be sent to TEE 136, which may be isolated from other components of the COTS device. TEE 136 may provide higher security than the POS application 124 by restricting access to TEE 136 without appropriate authorization. In this example, TEE 136 may communicate with the payment processing service 106 to transmit the PAN data and / or an encrypted version of the PAN data. The payment processing service 106 may use this data to determine whether a payment is authorized, and may send a payment transaction indication from the payment processing service 106 to the POS application 124 to indicate whether a payment is authorized. In this way, the POS application 124 does not need to have access to the PAN data and instead may proceed with the transaction based at least in part on the indication received from the payment processing service 106.

[0159] By implementing one or more of the techniques described in this book, spatial and / or temporal separation of PAN data from other data used for transactions, such as PIN data, enhances transaction security and makes it difficult to obtain unauthorized access to all the information necessary to misuse the payment instrument. These techniques are specific to computer-centric problems dealing with digital transactions on COTS devices, which may be compromised and subject to unauthorized access. These techniques are also specific to computer-centric solutions that utilize specifically configured applications, application configurations, encryption / decryption schemes, TEEs, and other components that cannot be performed by humans, whether as a mental process or through physical means. This added security is also implemented in a time-sensitive manner (i.e., in terms of seconds) between the time a transaction is initiated and the time it is completed, minimizing delays in the payment process.

[0160] Figures 11-14 illustrate the process for embedded card reader security. The processes described in this document are described as a collection of blocks in a logical flow diagram, representing a sequence of actions, some or all of which may be implemented in hardware, software, or a combination thereof. In a software context, a block may represent a computer-executable instruction stored on one or more computer-readable media that, when executed by one or more processors, programs a processor to perform the enumerated actions. Generally, a computer-executable instruction includes routines, programs, objects, components, data structures, etc., that perform a specific function or implement a specific data type. The order in which blocks are listed should not be interpreted as limiting unless otherwise noted. Any number of listed blocks may be combined in any order and / or in parallel to implement a process, or alternative process, and not all blocks need to be executed. For illustrative purposes, the processes are described with reference to the environments, architectures, and systems described in the examples in this book, such as those shown in Figures 1A-10, 15, and 16; however, the processes may be implemented in a wide variety of other environments, architectures, and systems.

[0161] Figure 11 illustrates an exemplary process 1100 for ECR security. The order in which the operations or steps are described is not intended to be construed as limiting, and any number of the described operations may be combined in any order and / or in parallel to perform process 1100.

[0162] In block 1102, process 1100 may include receiving an indication in the POS application that a payment has been received using the NFC reader of a mobile device. For example, a merchant may add products to a transaction to be purchased by a buyer, and once all the products the buyer wishes to purchase have been added, the merchant may initiate a payment process to fulfill the payment for the products. The POS application may receive an indication that the merchant has initiated a payment process to fulfill the payment for the products.

[0163] In block 1104, process 1100 may include sending a request from the POS application to the NFC reader to initiate payment. For example, the ECR may send an APDU command to the POS application. The APDU command may initiate a process that causes the reader to retrieve data from the payment instrument. For example, the ECR may generate and / or use a stored APDU command and send the command to the POS application so that the POS application and the NFC component can communicate directly to retrieve the PAN associated with the buyer's payment instrument. The POS application may send an instance of the APDU command to the NFC component. Sending the APDU command to the NFC component may cause the NFC component to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0164] In block 1106, process 1100 may include receiving a PAN associated with the payment instrument from an NFC reader in a POS application. The NFC component may send an APDU response to the POS application. The APDU response may include the PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used. The POS application may send an APDU response and / or an indication of the APDU response to the ECR. For example, the POS application may indicate to the ECR that response data has been received from the NFC component and that payment processing will proceed.

[0165] In block 1108, process 1100 may include sending the PAN, a default PIN, and an identifier for the transaction associated with the payment from the POS application to the payment processing service. For example, the POS application may send the default PIN to the ECR. The default PIN may be any number, letter, and / or alphanumeric code predetermined as a default code to satisfy the requirement that the PAN data includes a PIN when sent to the payment processing service. However, since the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be used to complete the transaction. The ECR may send an authorization request to the POS application. At this point, the POS application may have all the data necessary to request the payment processing service to authorize a payment using the payment instrument. In addition, it may also have the data necessary to satisfy the ECR's requirements to advance the payment process. The POS application may send a repayment request to the payment processing service. The repayment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and the default PIN. The payment processing service may receive the repayment request and identify the included PIN as the default PIN. Based at least in part on the payment request including the default PIN, the payment processing service may determine whether the received default PIN corresponds to a predefined default PIN. It should be understood that while one default PIN is listed, the default PIN may be dynamic and may change, for example, over time and / or based on the characteristics of any other factors associated with the merchant, buyer, transaction and / or payment.

[0166] In block 1110, process 1100 may include removing the PAN from the mobile device after the POS application has (i) sent the PAN to the payment processing service and (ii) requested the account PIN associated with the payment instrument. For example, to facilitate the temporal separation of the PAN and PIN on the merchant device, the PAN may be removed as a whole from the POS application and / or the merchant device.

[0167] In block 1112, process 1100 may include requesting an account PIN associated with the payment instrument. For example, the POS application may cause a PIN entry dialog to be presented to the buyer. In other embodiments where SPoC is utilized, the POS application may query one or more devices, such as a buyer device, for a software PIN, as described more fully in this document. For example, the user interface of a merchant device may display a PIN entry dialog, such as a PIN pad, configured to accept user input corresponding to an account PIN. In embodiments of SPoC, the merchant device may query one or more devices to receive a software PIN, as described more fully in this document.

[0168] In block 1114, process 1100 may include receiving an account PIN using touchscreen input from a mobile device. For example, user input data representing the account PIN and / or software PIN may be received in the POS application. At this point, the POS application may store the account PIN and / or software PIN in association, but the PAN data is not stored, assuming that the PAN data was previously removed from the merchant device as described above.

[0169] In block 1116, process 1100 may include sending the account PIN and transaction identifier to the payment processing service. For example, the POS application may send the account PIN to the payment processing service, whether or not it is in an encrypted format, in response to the payment processing service requesting the account PIN.

[0170] In block 1118, process 1100 may include completing a payment based on having received an indication that an account PIN has been accepted. For example, a payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with a payment instrument, and that the payment instrument is otherwise authorized to fulfill the payment.

[0171] In addition to or instead of the above, process 1100 may include sending requests from the POS application to an intermediate application configured to communicate with the POS application and the NFC reader. Process 1100 may also include receiving a PAN from the intermediate application in the POS application.

[0172] In addition to or instead of the above, process 1100 may include, in the POS application, receiving EMV data associated with the payment instrument from an NFC reader, wherein the EMV data is not encrypted by the NFC reader. Process 1100 may also include, by the POS application, using the EMV data to determine the PAN.

[0173] In addition to or instead of the above, process 1100 may include, in a POS application, receiving EMV data associated with a payment instrument from an NFC reader, the EMV data being encrypted by the NFC reader. Process 1100 may also include the POS application decrypting the EMV data so that decrypted EMV data is generated. Process 1100 may also include the POS application using the decrypted EMV data to determine the PAN.

[0174] In addition to or instead of the above, process 1100 may include, upon receipt in the POS application, encryption of the PAN as EMV data and transmission of the EMV data to the payment processing service. Process 1100 may also include, at least in part, completing the payment based on the fact that the decrypted PAN and the account PIN have been accepted by the payment processing service.

[0175] In addition to or instead of the above, process 1100 may include the encryption of the PAN as EMV data configured to be decrypted by the OEM associated with the device. Process 1100 may also include sending the EMV data to the OEM along with a request to decrypt the EMV data and provide the PAN to the payment processing service. Process 1100 may also include completing the payment, at least in part, based on the OEM's acceptance of the decrypted PAN and the account PIN.

[0176] In addition to or instead of the above, process 1100 may include receiving EMV data containing an encrypted version of the PAN at the TEE. Process 1100 may also include decrypting the EMV data at the TEE so that the PAN is identified. In these examples, completing the payment may include completing the payment at the TEE using the decrypted PAN.

[0177] In addition to or instead of the above, process 1100 may include the execution of a trust routine in relation to the device before receiving the PAN, the trust routine being configured to determine whether the device has been tampered with in a manner indicating that the device is not secure for completing the payment. Process 1100 may also include determining that the trust routine indicates that the device has not been tampered with. Process 1100 may also include requesting the PAN from the POS application in response to the trust routine indicating that the device has not been tampered with.

[0178] Figure 12 illustrates another exemplary process 1200 for ECR security. The order in which the operations or steps are described is not intended to be construed as limiting, and any number of the described operations may be combined in any order and / or in parallel to perform process 1200.

[0179] In block 1202, process 1200 may include receiving an indication that a payment has been received using an NFC reader on a mobile device. For example, a merchant may add products to a transaction to be purchased by a buyer, and once all the products the buyer wishes to purchase have been added, the merchant may initiate a payment process to fulfill the payment for the products. The POS application may receive an indication that the merchant has initiated a payment process to fulfill the payment for the products.

[0180] In block 1204, process 1200 may include sending a request to initiate payment from the POS application to an intermediate application configured to communicate with the POS application and the NFC reader. For example, the intermediate application may send an instance of the payment initiation request to the ECR. For example, if the trust routine indicates that the intermediate application has not been compromised, the intermediate application may send an instance of the payment initiation request to the ECR. The ECR may send an APDU command to the intermediate application. The APDU command may initiate a process that causes the reader to retrieve data from the payment instrument. For example, the ECR may generate and / or use a stored APDU command and send the command to the intermediate application so that it may be sent to the POS application. The intermediate application may send an instance of the APDU command to the POS application. For example, if the trust routine indicates that the intermediate application has not been compromised, the intermediate application may send an instance of the APDU command to the POS application. The POS application may send the APDU command to the NFC component. Sending an APDU command to an NFC component may cause the NFC component to initiate and / or read PAN data from the payment instrument and / or transmit the read PAN data to one or more components of the merchant device.

[0181] In block 1206, process 1200 may include receiving a PAN associated with the payment instrument from an intermediate application in the POS application. For example, an NFC component may send an APDU response to the POS application. The APDU response may include PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining data from the payment instrument, such as encryption-related data when encryption is used.

[0182] In block 1208, process 1200 may include sending the PAN and a default PIN from the POS application to the payment processing service. For example, the POS application may send a default PIN to the ECR. The default PIN may be any number, letter, and / or alphanumeric code predetermined as a default code to satisfy the requirement that the PAN data includes a PIN when sent to the payment processing service. However, since the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be used to complete a transaction. The ECR may send an authorization request to the POS application. At this point, the POS application may have all the data necessary to request the payment processing service to authorize a payment using the payment instrument. In addition, it may also have the data necessary to satisfy the ECR's requirements to advance the payment process. The POS application may send a payment request to the payment processing service. The payment request may include an identifier for the unresolved payment, PAN data which may be encrypted in certain examples, and a default PIN. The payment processing service receives the payment request and may identify the included PIN as the default PIN. Based at least in part on the payment request including the default PIN, the payment processing service may determine whether the received default PIN corresponds to a predefined default PIN. It should be understood that while one default PIN is listed, the default PIN may be dynamic and may change, for example, over time and / or based on the characteristics of any other factors associated with the merchant, buyer, transaction and / or payment.

[0183] In block 1210, process 1200 may include removing the PAN from the mobile device before requesting the account PIN associated with the payment instrument. For example, to facilitate a temporal separation of the PAN and PIN on the merchant device, the PAN may be removed entirely from the POS application and / or the merchant device.

[0184] In block 1212, process 1200 may include receiving an account PIN using touchscreen input from a mobile device. For example, user input data representing the account PIN and / or software PIN may be received in the POS application. At this point, the POS application may store the account PIN and / or software PIN in association, but the PAN data is not stored, assuming that the PAN data was previously removed from the merchant device as described above.

[0185] In block 1214, process 1200 may include completing a payment based at least in part on an indication that an account PIN has been accepted. For example, the payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with a payment instrument, and that the payment instrument is otherwise authorized to fulfill the payment.

[0186] In addition to or instead of the above, process 1200 may include the encryption of the PAN as EMV data when received in the POS application. Process 1200 may also include sending the EMV data to a payment processing service. Process 1200 may also include completing the payment at least in part on the fact that the PAN, when decrypted, and the account PIN have been accepted by the payment processing service.

[0187] In addition to or instead of the above, process 1200 may include the encryption of the PAN as EMV data configured to be decrypted by the OEM associated with the device. Process 1200 may also include sending the EMV data to the OEM along with a request to decrypt the EMV data and provide the PAN to the payment processing service. Process 1200 may also include completing the payment, at least in part, based on the fact that the PAN, as decrypted, and the account PIN have been accepted by the OEM.

[0188] In addition to or instead of the above, process 1200 may include receiving EMV data containing an encrypted version of the PAN in the mobile device's TEE. Process 1200 may also include decrypting the EMV data in the TEE so that the PAN is identified. In these examples, completing the payment may be performed in the TEE using the decrypted PAN.

[0189] In addition to or instead of the above, process 1200 may include the execution of a trust routine in relation to the mobile device before receiving the PAN, the trust routine being configured to determine whether the device has been tampered with. Process 1200 may also include determining that the trust routine indicates that the mobile device has not been tampered with. Process 1200 may also include requesting the PAN by the POS application in response to the trust routine indicating that the mobile device has not been tampered with.

[0190] In addition to or instead of the above, process 1200 may include sending a request to initiate payment from the POS application to an intermediate application which causes an embedded card reader application to query the NFC reader for the PAN. Process 1200 may also include receiving the PAN from the intermediate application, which includes receiving the PAN from the embedded card reader application and sending the PAN to the POS application.

[0191] In addition to or instead of the above, process 1200 may include, in the POS application, receiving EMV data associated with the payment instrument from an NFC reader, wherein the EMV data is not encrypted by the NFC reader. Process 1200 may also include, by the POS application, using the EMV data to determine the PAN.

[0192] In addition to or instead of the above, process 1200 may include, in a POS application, receiving EMV data associated with a payment instrument from an NFC reader, the EMV data being encrypted by the NFC reader. Process 1200 may also include the POS application decrypting the EMV data so that decrypted EMV data is generated. Process 1200 may also include the POS application using the decrypted EMV data to determine the PAN.

[0193] Figure 13 illustrates an exemplary process 1300 for temporally separating PAN data and PIN data on a merchant device to support ECR security. The order in which operations or steps are described is not intended to be construed as limiting, and any number of described operations may be combined in any order and / or in parallel to perform process 1300.

[0194] In block 1302, process 1300 may include configuring a point-of-sale (POS) application installed on a mobile device to utilize the mobile device's built-in card reader (ECR). For example, some merchants choose not to use a specific POS device to handle transactions, but instead to use a COTS device to execute those transactions. Illustrative COTS devices include typical mobile devices such as mobile phones (typically smartphones) and tablets. These devices may be used to install one or more applications that enable the COTS device to be used to obtain PAN data and / or other information to fulfill a payment. To do so, the NFC component of the COTS device may be used by one or more applications on the device to read PAN data from the payment instrument, and the applications may use such PAN data to complete the transaction. In some examples, the COTS device and other devices may be configured to obtain PIN data in addition to obtaining PAN data to authorize the transaction. The requirement for PIN data can add a layer of security to the transaction, as a malicious actor must not only obtain the physical payment instrument but also the PIN associated with the payment instrument. The technology for obtaining PIN data includes "PIN-on-glass" technology, where a PIN pad or other user interface is displayed on a merchant device configured to receive user input representing a PIN. Corresponding PIN data is generated on the merchant device and used for comparison with reference PIN data associated with a given payment instrument to complete the payment. Furthermore, the technology for obtaining PIN data includes SPoC, where a secure reader PIN, PIN application, merchant device, and backend monitoring and authentication system are used to obtain the PIN data.

[0195] In block 1304, process 1300 may include configuring the POS application to utilize the touchscreen display of a mobile device. For example, the POS application may be configured to prompt for user input via the touchscreen display of a mobile device when such input is requested.

[0196] In block 1306, process 1300 may include configuring the POS application to receive a PAN from the ECR and a PIN from a touchscreen display. For example, the POS application may be configured to communicate with an NFC component of a mobile device to read and obtain PAN data from a payment instrument. Alternatively, a routine for obtaining PIN data via SPoC technology may be enabled to allow the mobile device to communicate with the customer device and / or another device to receive a software PIN.

[0197] In block 1308, process 1300 may include receiving a PAN for a transaction in a POS application. For example, an APDU command may initiate a process that causes a reader to retrieve data from a payment instrument. The POS application may send an instance of the APDU command to an NFC component. Sending an APDU command to an NFC component may cause the NFC component to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0198] In block 1310, process 1300 may include removing the PAN from the mobile device by the POS application before requesting a PIN. For example, to facilitate a temporal separation between the PAN and the PIN on the merchant device, the PAN may be removed entirely from the POS application and / or from the merchant device.

[0199] In block 1312, process 1300 may include requesting a PIN using a touchscreen display. For example, the software PIN may be obtained from the customer device and / or one or more other devices. The process for obtaining the software PIN may include, for example, monitoring and / or managing the platform security status, ensuring PIN security requirements, certification procedures, and / or key management procedures.

[0200] In block 1314, process 1300 may include receiving a PIN in a POS application. For example, a touchscreen display may be used to receive user input representing a PIN, and the PIN data may be received in a POS application.

[0201] In block 1316, process 1300 may include completing a payment based on having received an indication that an account PIN has been accepted. For example, a payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with a payment instrument, and that the payment instrument is otherwise authorized to fulfill the payment.

[0202] In addition to or instead of this, process 1300 may include sending the PAN to a payment processing service. In these examples, removing the PAN from the mobile device may correspond to sending the PAN to the payment processing service.

[0203] In addition to or instead of this, process 1300 may include receiving a request for a PIN from the payment processing service. In these examples, removing the PAN from the mobile device may be in response to receiving a request for a PIN.

[0204] In addition to or instead of this, process 1300 may include requesting an account PIN in response to the removal of the PAN from the mobile device.

[0205] In addition to or instead of the above, process 1300 may include, after receiving the PAN, executing a trust routine in relation to the mobile device, the trust routine being configured to determine whether the device has been tampered with. Process 1300 may also include determining that the trust routine indicates that the mobile device has not been tampered with. In these examples, requesting an account PIN may be in response to the trust routine indicating that the mobile device has not been tampered with.

[0206] In addition to or instead of the above, process 1300 may include receiving the PAN in the mobile device's TEE. Process 1300 may also include receiving the account PIN outside of the mobile device's TEE.

[0207] In addition to or instead of this, process 1200 may include receiving an indication that user input corresponding to the account PIN has been received, in response to having requested the account PIN. In these examples, completing the payment may be based at least in part on the indication.

[0208] In addition to or instead of the above, process 1300 may include transmitting the first encrypted data to a payment processing service. Process 1300 may also include receiving the second encrypted data representing the account PIN. Process 1300 may also include transmitting the second encrypted data to a payment processing service.

[0209] In addition to or instead of this, process 1300 may include receiving encrypted data representing the account PIN. Process 1300 may also include transmitting the encrypted data to the payment processing system. Process 1300 may also include receiving an indication from the payment processing system that the decrypted account PIN is authorized in relation to the PAN. In these examples, completing the payment may be at least in part based on the fact that the account PIN is authorized in relation to the PAN.

[0210] In addition to or instead of the above, process 1300 may include receiving an account PIN in a second application configured to suppress communication between the second application and the first application. Process 1300 may also include sending a PAN from the first application to the payment processing service. These processes 1300 may also include sending an account PIN from the second application to the payment processing service.

[0211] Figure 14 illustrates an exemplary process 1400 for spatially separating PAN data and PIN data on a merchant device to support ECR security. The order in which operations or steps are described is not intended to be construed as limiting, and any number of described operations may be combined in any order and / or in parallel to perform process 1400.

[0212] In block 1402, process 1400 may include configuring a POS application to utilize ECR. For example, some merchants choose not to use a specific POS device to handle transactions, but instead to use a COTS device to execute transactions. Exemplary COTS devices include typical mobile devices such as mobile phones (typically smartphones) and tablets. These devices may be used to install one or more applications that enable the COTS device to be used to obtain PAN data and / or other information to fulfill a payment. To do so, the NFC component of the COTS device may be used by one or more applications on the device to read PAN data from the payment instrument, and the applications may use such PAN data to complete the transaction. In some examples, the COTS device and other devices may be configured to obtain PIN data in addition to obtaining PAN data to authorize the transaction. The requirement for PIN data can add a layer of security to the transaction, as a malicious actor must not only obtain the physical payment instrument but also the PIN associated with the payment instrument. The technology for obtaining PIN data includes "PIN-on-glass" technology, where a PIN pad or other user interface is displayed on a merchant device configured to receive user input representing a PIN. Corresponding PIN data is generated on the merchant device and used for comparison with reference PIN data associated with a given payment instrument to complete the payment. Furthermore, the technology for obtaining PIN data includes SPoC, where a secure reader PIN, PIN application, merchant device, and backend monitoring and authentication system are used to obtain the PIN data.

[0213] In block 1404, process 1400 may include configuring a POS application to receive a PAN from the ECR. For example, the POS application may be configured to communicate with an NFC component of a mobile device to read and obtain PAN data from a payment device.

[0214] In block 1406, process 1400 may include configuring a PIN application to receive a PIN using a touchscreen, and the PIN application is configured to suppress communication with the POS application. For example, a routine for obtaining PIN data via SPoC technology may be enabled so that a mobile device can communicate with a customer device and / or another device to receive a software PIN.

[0215] In block 1408, process 1400 may include receiving a PAN for a transaction in a POS application. For example, an APDU command may initiate a process that causes a reader to retrieve data from a payment instrument. The POS application may send an instance of the APDU command to an NFC component. Sending an APDU command to an NFC component may cause the NFC component to initiate and / or read PAN data from the payment instrument and / or send the read PAN data to one or more components of the merchant device.

[0216] In block 1410, process 1400 may include requesting a PIN using a touchscreen. For example, a PIN may be obtained, and certification and / or verification operations may be performed by the server-side device and / or system. The process for obtaining the PIN may include, for example, monitoring and / or managing the platform security status, ensuring PIN security requirements, certification procedures, and / or key management procedures.

[0217] In block 1412, process 1400 may include receiving a PIN in the PIN application. For example, the PIN application may receive the PIN from a customer device and / or one or more other devices. In this example, the software PIN may be encrypted, and the PIN application may be configured to decrypt the PIN.

[0218] In block 1414, process 1400 may include completing a transaction based on having received an indication that the account PIN is accepted in connection with the PAN. For example, a payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with a payment instrument, and that the payment instrument is otherwise authorized to fulfill the payment.

[0219] In addition to or instead of the above, process 1400 may include sending the PAN to a payment processing service. Process 1400 may also include removing the PAN from the device in response to sending the PAN to the payment processing service.

[0220] In addition to or instead of the above, process 1400 may include receiving a request from the payment processing service for an account PIN. Process 1400 may also include removing the PAN from the device in response to receiving a request for a PIN.

[0221] In addition to or instead of this, process 1400 may include removing the PAN from the device, and requesting the account PIN may be in response to removing the PAN from the device.

[0222] In addition to or instead of the above, process 1400 may include, after receiving the PAN, executing a trust routine related to the device, the trust routine being configured to determine whether the device has been tampered with. Process 1400 may also include determining that the trust routine indicates that the device has not been tampered with. In these examples, requesting an account PIN may be in response to the trust routine indicating that the device has not been tampered with.

[0223] In addition to or instead of the above, process 1400 may include receiving the PAN at the device's TEE. Process 1400 may also include receiving the account PIN outside the device's TEE.

[0224] In addition to or instead of this, process 1400 may include receiving an indication that user input corresponding to an account PIN has been received, in response to having requested an account PIN. In these examples, completing the payment may be at least in part based on the user input corresponding to an account PIN.

[0225] In addition to or instead of the above, process 1400 may include receiving a PAN, which includes receiving first encrypted data representing the PAN from the ECR. Process 1400 may also include receiving second encrypted data representing the account PIN.

[0226] In addition to or instead of this, process 1400 may include transmitting encrypted data to a payment processing system. Process 1400 may also include receiving an indication from the payment processing system that the decrypted account PIN is authorized in connection with the PAN. In these examples, completing the payment may be at least in part based on the fact that the account PIN is authorized in connection with the PAN.

[0227] In addition to or instead of this, process 1400 may include removing the PAN from the device by the POS application before requesting the account PIN.

[0228] Figure 15 illustrates an exemplary merchant ecosystem to support the technologies described in this book, in particular. Environment 1500 includes a server computing device 1502 that can communicate with a user device 1506 via a network 1504 (which, in some examples, may be a merchant device 1508 (individually, 1508(A) to 1508(N)) and / or a server computing device 1510 associated with a third-party service provider). Server computing device 1502 may be associated with a service provider 1512 that can provide one or more services for the benefit of user 1514, as described below. Actions originating from service provider 1512 may be performed by server computing device 1502.

[0229] In at least one example, service provider 1512 may correspond to the payment processing service provider described above. In at least one example, server computing device 1502 may correspond to server 104, and network 1504 may correspond to network 108 described above with reference to Figure 1A. In at least one example, the multimedia content service provider described above with reference to Figure 1A may be associated with server computing device 1510 associated with a third-party service provider.

[0230] Environment 1500 can facilitate enhanced security measures associated with embedded card readers, as described herein. As stated above, techniques for spatially and / or temporally separating PAN data and PIN data on on-shelf devices used for making payments may be employed using System 1500 as described herein. For example, PAN data may be removed from the merchant device before a request for PIN data is made and / or before the PIN data is received by the device. Other methods include using different applications to handle PAN data and PIN data, using intermediate applications in addition to trust routines to determine whether the merchant device has been compromised, using various encryption schemes, and processing EMV data in a remote system.

[0231] As described above, users of a platform (e.g., websites, applications, and other network-based communication tools provided by service providers) leverage tools for online commerce ("e-commerce"). However, current technologies have the limitations mentioned above. In some cases, a malicious actor gaining access to merchant devices, particularly COTS devices, may gain access to both PAN and PIN data. Environment 1500, described in this document, enables a more secure transaction environment without causing excessive delays in payment processing, while operating within the scope of a typical transaction. Therefore, the technology described in this document represents an improvement over existing technologies.

[0232] Environment 1500 may include multiple user devices 1506, as described above. Each of the user devices 1506 may be any type of computing device, such as a tablet computing device, smartphone or mobile communication device, laptop, netbook or other portable or semi-portable computer, desktop computing device, terminal computing device or other semi-stationary or stationary computing device, dedicated device, wearable computing device or other body-worn computing device, augmented reality device, virtual reality device, Internet of Things (IoT) device, etc. In some examples, each of the user devices may be operated by a user 1514. A user 1514 may be called a buyer, customer, seller, merchant, borrower, employee, employer, payer, recipient, courier, etc. A user 1514 may interact with user device 1506 through a user interface presented via user device 1506. In at least one example, the user interface may be presented via a web browser, etc. In other examples, the user interface may be provided by a service provider 1512 or presented through an application such as a mobile or desktop application, which may be a separate dedicated application. In some examples, each user device 1506 may have an instance or versioned instance of an application, which may be downloaded from an application store, for example, that can present the user interface described herein. In at least one example, user 1514 may interact with the user interface via touch input, voice input, or any other type of input.

[0233] In at least one example, the merchant device 102 and other merchant devices 106 described above in Figure 1 may include a user device 1506 as described herein. Similarly, the merchant and buyer may include a user 1514 as used herein.

[0234] In at least one example, user 1514 may include merchants 1516 (individually, 1516(A) to 1516(N)). In one example, merchant 1516 may operate each merchant device 1508, which may be a user device 1506 configured for use by merchant 1516. For the purposes of this discussion, “merchant” may be any entity that provides items (e.g., goods or services) for purchase or other means of acquisition (e.g., rental, borrowing, negotiation, etc.). Merchant 1516 may provide items for purchase or other means of acquisition through physical stores, mobile stores (e.g., pop-up shops, food trucks, etc.), online stores, combinations of the aforementioned, etc. In some examples, at least some of merchants 1516 may be associated with the same entity but may have different merchant locations and / or franchise relationships. In additional or alternative examples, merchant 1516 may be different merchants. In other words, in at least one example, merchant 1516(A) is a different merchant from merchant 1516(B) and / or merchant 1516(C).

[0235] For the purposes of this discussion, “different merchants” can refer to two or more unrelated merchants. Therefore, “different merchants” can refer to two or more merchants that are different legal entities (e.g., natural persons and / or legal entities) that do not share accounting, employees, branding, etc. As used in this text, “different merchants” have different names, Employer Identification Numbers (EINs), (in some examples) business lines, inventory (or at least a portion thereof), and / or similar. Thus, the use of the term “different merchants” does not refer to merchants with various merchant locations or franchise / franchise relationships. Such merchants with various merchant locations or franchise / franchise relationships may be referred to as merchants with different merchant locations and / or different commerce channels.

[0236] Each merchant device 1508 may have an instance of the POS application 1518 stored on it. The POS application 1518 can configure the merchant device 1508 as a POS terminal, which allows merchant 1516(A) to interact with one or more buyers 1520. As described above, user 1514 may include buyers such as buyer 1520, which are shown to interact with merchant 1516(A). For the purposes of this discussion, “buyer” can be any entity that takes items from a merchant. Although only two buyers 1520 are shown in Figure 15, any number of buyers 1520 can interact with merchant 1516. Furthermore, although Figure 15 shows buyer 1520 interacting with merchant 1516(A), buyer 1520 can interact with any of merchants 1516.

[0237] In at least one example, an interaction between Buyer 1520 and Merchant 1516, involving the exchange of funds (from Buyer 1520) for items (from Merchant 1516), may be referred to as a “POS transaction” and / or “deal.” In at least one example, POS application 1518 may determine transaction data associated with a POS transaction. Transaction data may include payment information, user authentication data, purchase amount information, and information at the time of purchase (e.g., items purchased, date of purchase, time of purchase, etc.), which may be obtained from a reader device 1522 associated with the merchant device 1508(A). POS application 1518 may transmit the transaction data to a server computing device 1502. Furthermore, POS application 1518 may present a UI to enable Merchant 1516(A) to interact with POS application 1518 and / or service provider 1512 via POS application 1518.

[0238] In at least one example, the merchant device 1508(A) may be a dedicated computing device configured as a POS terminal (via the execution of the POS application 1518). In at least one example, the POS terminal may be connected to a reader device 1522 that can accept various payment instruments, such as credit cards, debit cards, gift cards, and near-field communication-based payment instruments, as described below. In at least one example, the reader device 1522 may plug into a port in the merchant device 1508(A), such as a microphone port, headphone port, audio jack, data port, or other suitable port. In additional or alternative examples, the reader device 1522 may be coupled to the merchant device 1508(A) via another wired or wireless connection, such as via Bluetooth®, BLE, etc. Further details are described below with reference to Figure 16. In some examples, the reader device 1522 may read information from alternative payment instruments, including but not limited to wristbands.

[0239] In some examples, the reader device 1522 may physically interact with payment instruments such as magnetic stripe payment cards, EMV payment cards, and / or near-field communication (e.g., Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth®, Bluetooth® Low Energy (BLE), etc.) payment instruments (e.g., cards or devices configured for tapping). The POS terminal may provide a rich user interface and communicate with the reader device 1522 and with the server computing device 1502, which may provide payment processing services among other services. The server computing device 1502 associated with the service provider 1512 may communicate with the server computing device 1510, as described below. In this way, the POS terminal and reader device 1522 may process transactions between the merchant 1516 and the buyer 1520 in a batch. In some examples, the POS terminal and reader device may consist of a one-to-one pairing. In other examples, POS terminals and reader devices may consist of many-to-one pairings (e.g., one POS terminal coupled to multiple reader devices or multiple POS terminals coupled to one reader device). In some examples, there may be multiple POS terminals connected to multiple other devices, such as back-of-the-house systems, printers, line buster devices, and POS readers, to allow information from the secondary terminal to be shared between the primary and secondary POS terminals, for example, via short-range communication technology. This type of configuration may also function to allow one device (e.g., a secondary terminal) to continue receiving user input in an offline-online scenario and to synchronize data with another device (e.g., a primary terminal) when the primary or secondary terminal switches to online mode. In other examples, such data synchronization may occur periodically or at randomly selected time intervals.

[0240] In the example, the POS application described herein may be configured to communicate with the reader device 1522 and / or ECR to receive PAN data from the reader device 1522 and / or ECR. The card reader library and / or intermediate application described herein may be configured to help establish and / or facilitate secure communication between the reader device 1522 and the POS application and / or the ECR and the POS application.

[0241] Although the POS terminal and reader device 1522 of POS system 1524 are shown as separate devices, in additional or alternative examples, the POS terminal and reader device 1522 may be part of a single device. In some examples, the reader device 1522 may have an integrated display for presenting information to the buyer 1520. In additional or alternative examples, the POS terminal may have an integrated display for presenting information to the buyer 1520. A POS system like POS system 1524 may be mobile so that the POS terminal and reader device can process transactions at different locations around the world. The POS system may be used to process card presence transactions and card absence (CNP) transactions, as described below.

[0242] A card presence transaction is a transaction in which both Buyer 1520 and his or her payment instrument are physically present at the time of the transaction. A card presence transaction may be processed by swiping, diping, tapping, or any other interaction between the physical payment instrument (e.g., a card) or otherwise present payment instrument and the reader device 1522, thereby enabling the reader device 1522 to retrieve payment data from the payment instrument. A swipe is a card presence transaction in which Buyer 1520 slides a card or other payment instrument having a magnetic strip through the reader device 1522, which captures the payment data contained in the magnetic strip. A dip is a card presence transaction in which Buyer 1520 initially inserts a payment instrument having an embedded microchip (i.e., a chip) into the reader device 1522. The dipped payment instrument remains in the payment reader until the reader device 1522 prompts Buyer 1520 to remove the card or other payment instrument. While the payment instrument is inside the reader device 1522, the microchip may generate a one-time code to be transmitted from the POS system 1524 to the computing device server 1510 (which may be associated with an acquiring bank, issuer, and / or a third-party service provider providing payment services, including but not limited to Mastercard®, VISA®, etc.) and matched with the same one-time code. A tap is a card presence transaction in which the buyer 1520 may tap or hover his or her payment instrument (e.g., a card, an electronic device such as a smartphone running a payment application) on the reader device 1522 to complete the transaction via short-range communication (e.g., NFC, RFID, Bluetooth®, BLE, etc.). Short-range communication allows the payment instrument to exchange information with the reader device 1522. A tap may also be called a contactless payment.

[0243] A CNP transaction is a transaction in which a card or other payment instrument is not physically present at the POS, and as a result, payment data must be manually key-entered (e.g., by the merchant, buyer, etc.) or retrieved from the card-on-file data store in order to complete the transaction.

[0244] The POS system 1524, the server computing device 1502, and / or the server computing device 1510 may exchange payment information and transaction data to determine whether a transaction is authorized. For example, the POS system 1524 may provide encrypted payment data, user authentication data, purchase amount information, purchase time information, etc. (collectively, transaction data) to the server computing device 1502 via the network 1504. The server computing device 1502 may transmit the transaction data to the server computing device 1510. As described above, in at least one example, the server computing device 1510 may be associated with an acquiring bank, issuer, and / or a third-party service provider that provides payment services, including but not limited to card payment networks (e.g., Mastercard®, VISA®, etc.).

[0245] For the purposes of this discussion, a “payment service provider” could be an acquiring bank (“acquirer”), an issuing bank (“issuer”), a card payment network, etc. In one example, an acquirer is a bank or financial institution that can process payments (e.g., credit or debit card payments) and assume risk on behalf of the merchant. An acquirer may be a registered member of a card association (e.g., Visa®, MasterCard®) and may be part of a card payment network. An acquirer (e.g., its associated server computing device 1510) may send a fund transfer request to a server computing device of a card payment network (e.g., Mastercard®, VISA®, etc.) to determine whether the transaction is authorized or not. In at least one example, a service provider 1512 may function as an acquirer and be directly connected to a card payment network.

[0246] The card payment network (e.g., its associated server computing device 1510) may forward the fund transfer request to the issuing bank (e.g., the "Issue"). The Issuer is a bank or financial institution that provides users with financial accounts (e.g., credit or debit card accounts). The Issuer may issue payment cards to users, and the issuing bank may pay the acquirer for purchases made by cardholders who have been issued payment cards. The Issuer (e.g., its associated server computing device 1510) may determine whether the buyer has the ability to bear the associated fees associated with the payment transaction. In at least one example, a service provider 1512 may act as the Issuer and / or partner with the Issuer. Transactions are approved or rejected by the Issuer and / or the card payment network (e.g., its associated server computing device 1510), and payment authorization messages are communicated from the Issuer to the POS device via the reversed route described above, or via an alternative route.

[0247] As described above, a server computing device 1510, which may be associated with a payment service provider, may determine whether a transaction is permitted based on transaction data and information about the parties to the transaction (e.g., buyer 1520 and / or merchant 1516(A)). The server computing device 1510 may send an authorization notice to server 1502 via network 1504, which may send an authorization notice to POS system 1524 via network 1504 to indicate whether the transaction is permitted. The server computing device 1502 may also send additional information, such as a transaction identifier, to POS system 1524. In one example, server 1502 may include a merchant application and / or other functional components for communicating with POS system 1524 and / or server computing device 1510 to authorize or deny a transaction.

[0248] Based on an authentication notice received by the POS system 1524 from the server computing device 1502, merchant 1516(A) may indicate to buyer 1520 whether the transaction has been approved. In some examples, the approval may be indicated in the POS system 1524, for example, on the display of the POS system 1524. In other examples, information about the approved transaction may be provided to a near-field payment instrument, such as a smartphone or watch acting as a near-field payment instrument, for presentation via the display of the smartphone or watch. In some examples, additional or alternative information may be further presented along with the approved transaction notice, including but not limited to receipts, special offers, coupons, or loyalty program information.

[0249] As described above, service provider 1512 may offer, among other services, payment processing services, inventory management services, catalog management services, business banking services, financial services, lending services, reservation management services, web development services, payroll services, employee management services, promise services, loyalty tracking services, restaurant management services, order management services, fulfillment services, peer-to-peer payment services, onboarding services, and identity verification (IDV) services. In some examples, user 1514 may have access to all of service provider 1512's services. In other examples, user 1514 may have tiered access to services, which may be based on risk tolerance, IDV output, subscriptions, etc. In at least one example, access to such services may be made available to merchant 1516 via POS application 1518. In additional or alternative examples, each service may be associated with its own access point (e.g., application, web browser, etc.).

[0250] As described above, service provider 1512 may provide payment processing services to process payments on behalf of merchant 1516. For example, service provider 1512 may provide merchant 1516 with payment processing software, payment processing hardware, and / or payment processing services, as described above, to enable merchant 1516 to receive payments from buyer 1520 when merchant 1516 conducts a POS transaction with buyer 1520. For example, service provider 1512 may enable merchant 1516 to receive cash payments, payment card payments, and / or electronic payments from buyer 1520 for POS transactions, and service provider 1512 may process the transactions on behalf of merchant 1516.

[0251] When service provider 1512 processes a transaction on behalf of merchant 1516, service provider 1512 may maintain accounts or balances for merchant 1516 in one or more ledgers. For example, service provider 1512 may analyze transaction data received for a transaction to determine the amount of funds to be paid to merchant 1516(A) for the transaction. In at least one example, such an amount may be the total purchase price minus the fees charged by service provider 1512 for providing payment processing services. Based on determining the amount of funds to be paid to merchant 1516(A), service provider 1512 may deposit funds into merchant 1516(A)'s account. The account may have a retained balance, which may be managed by service provider 1512. The account may differ from a traditional bank account in that, at the very least, the stored balance is managed by the service provider 1512's ledger, and the associated funds are accessible through a variety of withdrawal channels, including but not limited to scheduled deposits, same-day deposits, instant deposits, and linked payment instruments.

[0252] A scheduled deposit may occur when service provider 1512 transfers funds associated with merchant 1516(A)'s memory balance to merchant 1516(A)'s bank account held at a bank or other financial institution (e.g., associated with server computing device 1510). A scheduled deposit may occur at a scheduled time after the POS transaction has been funded, i.e., on a business day after the POS transaction occurred, or before or after. In some examples, merchant 1516(A) may have access to funds prior to the scheduled deposit. For example, merchant 1516(A) may have access to a same-day deposit (e.g., service provider 1512 deposits funds from the memory balance into merchant's linked bank account on the same day as the POS transaction, and in some embodiments before the POS transaction is funded), or to an immediate deposit (e.g., service provider 1512 deposits funds from the memory balance into merchant's linked bank account on demand, such as upon request). Furthermore, in at least one example, merchant 1516(A) may have a memory balance-linked payment instrument that allows the merchant to access funds without first transferring funds from an account managed by service provider 1512 to merchant 1516(A)'s bank account.

[0253] In at least one example, service provider 1512 may provide inventory management services, namely, inventory tracking and reporting. The inventory management services may enable merchant 1516(A) to access and manage a database that stores data associated with the quantity (i.e., inventory) of each item available to merchant 1516(A). Furthermore, in at least one example, service provider 1512 may provide catalog management services to enable merchant 1516(A) to maintain a catalog, which may be a database that stores data associated with items available for merchant 1516(A) to acquire (i.e., catalog management services). In at least one example, the catalog may contain multiple data items, some of which may represent items available for merchant 1561(A) to acquire. Service provider 1512 may provide recommendations related to item pricing, item placement in the catalog, and multi-party fulfillment of inventory.

[0254] In at least one example, service provider 1512 can provide business banking services that enable merchant 1516(A) to track deposits into merchant 1516(A)'s account (from payment processing and / or other sources of funds), payroll payments from the account (e.g., payments to merchant 1516(A)'s employees), payments to other merchants directly from the account or from linked debit cards (e.g., business-to-business), withdrawals made via scheduled deposits and / or instant deposits, etc. Furthermore, Business Banking Services enables Merchant 1516(A) to acquire customized payment tools (e.g., credit cards), check how much money they are earning (e.g., through presentation of available earned balances), understand where their money is going (e.g., through deposit reports, expenditure reports, etc., which may include a breakdown of fees), access / use earned money (e.g., through scheduled deposits, instant deposits, linked payment tools, etc.), and feel in control of their money (e.g., through deposit schedule management, deposit speed, linked tools, etc.). In addition, Business Banking Services enables Merchant 1516 to visualize their cash flow to track their financial health, set aside money for upcoming obligations (e.g., savings), organize their money in line with their goals, etc.

[0255] In at least one example, service provider 1512 may offer financing services and products through business loans, customer loans, fixed-term loans, variable-term loans, etc. In at least one example, service provider 1512 may utilize one or more risk signals to determine whether to extend the financing offer and / or term associated with such financing offer.

[0256] In at least one example, service provider 1512 may provide financial services for providing and / or lending loans to borrowers to be used to finance the borrower's short-term operational needs (e.g., capital loans). For example, a potential borrower, a merchant, may take out a capital loan through a capital loan product to finance various operating costs (e.g., rent, salaries, inventory, etc.). In at least one example, service provider 1512 may offer different types of capital loan products. For example, in at least one example, service provider 1512 may offer a daily repayment loan product, in which the capital loan is repaid daily, for example, from a portion of a transaction processed on behalf of the borrower by a payment processing service. In addition to and / or instead of this, service provider 1512 may offer a monthly repayment loan product, in which the capital loan is repaid monthly, for example, through a debit from a bank account linked to a payment processing service. A merchant's credit risk may be assessed using a risk model that takes into account factors such as the amount payable, the credit risk of merchants in similar circumstances, past transaction history, seasonality, and credit history.

[0257] In addition to and / or instead thereof, Service Provider 1512 may, in some examples, provide and / or lend loans to borrowers to finance the borrower's customer purchases (e.g., consumer loans). In at least one example, the borrower may submit a loan request to enable the borrower to purchase an item from a merchant which may be one of the merchants 1516. Service Provider 1512 may create the loan based at least in part on determining that the borrower has purchased or intends to purchase an item from the merchant. The loan may be associated with a balance based on the actual purchase price of the item, and the borrower may repay the loan over time. In some examples, the borrower may repay the loan in installments which may be paid through funds managed and / or held by Service Provider 1512 (e.g., from payments made to the merchant from payments processed on behalf of the merchant, funds transferred to the merchant, etc.). Service Provider 1512 may provide certain financial instruments, such as payment instruments, which are particularly tied to loan products. For example, in one implementation, the service provider 1512 associates capital with a merchant's or buyer's debit card, and the use of the debit card is governed by the loan terms. In some examples, the merchant may use only the debit card to make certain purchases. In other examples, the "installment payments" associated with the loan product are credited directly through the payment instrument. Thus, the payment instrument is customized to suit the loan and / or the parties associated with the loan.

[0258] Service provider 1512 may offer web development services that enable users 1514 who are not familiar with HTML, XML, Javascript, CSS, or other web design tools to create and maintain professional and aesthetically pleasing websites. Some of these web page editing applications may enable users to build and / or modify web pages (e.g., change, add, or delete content associated with the web page). Furthermore, web development services may create and maintain other online omnichannel presences in addition to websites, such as social media posts. In some examples, the resulting web pages and / or other content items may be used to offer items for sale through online / e-commerce platforms. That is, the resulting web pages and / or other content items may be associated with an online store or offering by one or more merchants 1516. In at least one example, service provider 1512 may recommend and / or create content items to complement merchant 1516's omnichannel presence. In other words, if merchant 1516 has a web page, service provider 1512 may recommend and / or create additional content items to be presented via other channels such as social media, email, etc., through web development or other services.

[0259] Furthermore, Service Provider 1512 may provide payroll services that enable employers to pay employees for work performed on their behalf. In at least one example, Service Provider 1512 may receive data including hours worked by employees, sales made by employees, and tips received by employees (e.g., through imported time cards and / or POS interactions). Based on such data, Service Provider 1512 may pay employees on behalf of employers through payroll services. For example, Service Provider 1512 may assist in the transfer of the total amount to be paid for employee salaries from the employer's bank to Service Provider 1512's bank, which should be used to make payroll payments. In at least one example, once the funds are received at Service Provider 1512's bank, Service Provider 1512 may often pay employees by check or direct deposit, etc., one day, one week, or more after the work has actually been performed by the employee. In an additional or alternative example, service provider 1512 may enable employees to receive payment via same-day or immediate deposit based on at least part of the risk and / or reliability analysis performed by service provider 1512.

[0260] Furthermore, in at least one example, service provider 1512 may provide employee management services for managing employee schedules. In addition, service provider 1512 may provide appointment services for user 1514 to set schedules for scheduling appointments and / or enable user 1514 to schedule appointments.

[0261] In some examples, service provider 1512 may provide restaurant management services to enable user 1514 to make and / or manage reservations, monitor front-of-house and / or back-of-house operations, etc. In such examples, merchant device 1508 and / or server computing device 1502 may be configured to communicate with one or more other computing devices that may be located in the front-of-house (e.g., POS device) and / or back-of-house (e.g., kitchen display system (KDS)). In at least one example, service provider 1512 may provide order management services and / or fulfillment services to enable the restaurant to manage open tickets, split tickets, etc., and / or manage fulfillment services. In some examples, such services may be associated with a restaurant merchant, as described above. In additional or alternative examples, such services may be any type of merchant.

[0262] In at least one example, service provider 1512 can provide a fulfillment service that may use couriers for delivery, and couriers may travel between multiple locations to provide delivery services, photo services, etc. The courier may be user 1514 who can travel between locations to perform services for requesting user 1514 (e.g., item delivery, image capture, etc.). In some examples, the courier may receive payment from service provider 1512. The courier may use one or more vehicles such as a car, bicycle, scooter, motorcycle, bus, aircraft, helicopter, boat, skateboard, etc. However, in other examples, the courier may travel without a vehicle, on foot, or in some other way. Some of the examples discussed in this document enable people to participate as couriers in a certain type of crowdsourced service economy. Here, essentially, any person with a mobile device can immediately become a courier, or cease to be a courier, in a network of couriers providing the services described in this document. In at least one example, the delivery driver may be an unmanned aerial vehicle (e.g., a drone), an autonomous vehicle, or any other type of vehicle capable of receiving commands to travel between locations. In some examples, the service provider 1512 may receive requests for delivery driver services via a user interface (e.g., an application, a web browser, or other access point) presented through each device 1506, automatically assign the requests to active delivery drivers, and communicate delivery instructions to the delivery drivers.

[0263] In some cases, service provider 1512 may provide omni-channel fulfillment services. For example, if a buyer places an order with a merchant and the merchant is unable to fulfill the order because one or more items are out of stock or otherwise unavailable, service provider 1512 may leverage other merchants and / or sales channels that are part of service provider 1512's platform to fulfill the buyer's order. That is, another merchant may provide one or more items to fulfill the buyer's order. Furthermore, in some cases, another sales channel (e.g., online, physical store, etc.) may be used to fulfill the buyer's order.

[0264] In some examples, service provider 1512 may enable conversational commerce through a conversational commerce service, which may use one or more machine learning mechanisms to analyze messages exchanged between two or more users 1514, voice input to a virtual assistant, etc., to determine the intent of user 1514. In some examples, service provider 1512 may leverage the determined intent to automate buyer services, provide promotions, offer recommendations, or otherwise interact with the buyer in real time. In at least one example, service provider 1512 may integrate goods and services, as well as payment mechanisms, into a communication platform (e.g., messaging) to enable the buyer to make a purchase or otherwise conduct a transaction without having to make a phone call, send an email, visit the merchant's web page, or visit other channels. In other words, conversational commerce reduces the need for the buyer to switch back and forth between conversations and web pages to gather information and make a purchase.

[0265] In at least one example, service provider 1512 may provide a peer-to-peer payment service that enables peer-to-peer payments between two or more users 1514. In at least one example, service provider 1512 may communicate with an instance of a payment application (or other access point) installed on a device 1506 configured for operation by user 1514. In one example, an instance of a payment application running on a first device operated by the payer may send a request to service provider 1512 to transfer an amount of funds (e.g., fiat currency or non-fiat currency such as cryptocurrency, securities, and associated assets) from the payer's account to the recipient's account (e.g., peer-to-peer payment). Service provider 1512 may send a notification to an instance of a payment application running on a second mobile device operated by the recipient, which can assist with the transfer and where the transfer is in progress (or completed). In some embodiments, the service provider 1512 may send additional or alternative information (e.g., a low balance to the payer, a current balance to the payer or recipient) to an instance of the payment application. In some embodiments, the payer and / or recipient may be automatically identified based on, for example, context, proximity, prior transaction history, etc. In other embodiments, the recipient may send a request to the payer for funds before the payer initiates the transfer of funds. The funds to be transferred may be associated with any type of digital currency, including but not limited to cash or cryptocurrency. In some embodiments, the service provider 1512 funds the request to the recipient on behalf of the payer to speed up the transfer process and compensate for any delays that may be caused by the payer's financial network.

[0266] In some embodiments, the service provider 1512 may initiate a peer-to-peer payment process via identification information of a “payment proxy” having a specific syntax. For example, the syntax may include a currency indicator prefixed with one or more alphanumeric characters (e.g., $Cash). The currency indicator acts as a tagging mechanism that tells the computer system to treat the input as a request from a sender to transfer cash, and detection of the syntax (containing one or more alphanumeric characters tagged by the currency indicator) triggers the transfer of cash. The currency indicator may support a variety of currencies, including but not limited to the dollar ($), euro (euro symbol), pound (pound symbol), rupee (rupee symbol), and yuan (¥). While the use of the dollar currency indicator ($) is used herein, it should be understood that any currency symbol may be used equally. The peer-to-peer process may be initiated through a specific application running on the user device 1506.

[0267] In some embodiments, a peer-to-peer process may be implemented within a forum context. As used herein, the term “forum” refers to a content provider’s media channel (e.g., social networking platforms, microblogs, blogs, video sharing platforms, music sharing platforms, etc.) that enables user interaction and engagement through comments, posts, messages on electronic bulletin boards, messages on social networking platforms, and / or any other type of message. A forum may be employed by a content provider to enable users of the forum to interact with each other (e.g., through composing messages, posting comments, etc.). In some embodiments, “forum” may also refer to an application or web page of an e-commerce or retail organization providing goods and / or services. Such a website may provide an online “form” to be completed before or after goods or services are added to a virtual cart. The online form may include one or more fields for receiving user interaction and engagement. Specific examples include the user’s name and other identifying information, the user’s shipping address, etc. Some of these fields may be configured to receive payment information, such as payment proxies, instead of other types of payment mechanisms, such as credit cards, debit cards, prepaid cards, gift cards, or virtual wallets.

[0268] In some embodiments, the peer-to-peer process may be implemented within a communication application context, such as a messaging application context. As used herein, the term “messaging application” refers to any messaging application that enables communication between users (e.g., message senders and receivers) over a wired or wireless network through the use of communication messages. A messaging application may be available to a service provider 1512. For example, a service provider 1512 may provide a messaging service that provides communication services to users via a messaging application (e.g., chat or messaging capability). A messaging application may include, for example, a text messaging application for communication between telephones (e.g., conventional mobile phones or smartphones), or a cross-platform instant messaging application for smartphones and telephones that use the Internet for communication. A messaging application may run on a user device 1506 (e.g., a mobile device or conventional personal computer (PC)) based on instructions sent to or from a server computing device 1502 (which in such an example may be called a “messaging server”). In some examples, a messaging application may include a payment application that has messaging capabilities that allow users of the payment application to communicate with each other. In such examples, the payment application may run on a user device 1506 based on instructions sent to or from a server computing device 1502 (e.g., the payment service discussed in this document, or another payment service that supports payment transactions).

[0269] In at least some embodiments, a peer-to-peer process may be implemented within a landing page context. The term “landing page,” as used herein, refers to a virtual location identified by a personalized location address that is dedicated to collecting payments on behalf of recipients associated with that personalized location address. The personalized location address identifying the landing page may include the payment proxy described above. A service provider 1512 may create a landing page to enable a recipient to conveniently receive one or more payments from one or more senders. In some embodiments, the personalized location address identifying the landing page is a uniform resource locator (URL) incorporating the payment proxy. In such embodiments, the landing page is a web page, e.g., www.cash.me / $cash.

[0270] In at least one example, user 1514 may be new to service provider 1512, such that user 1514 is not registered with service provider 1512 (for example, not subscribed to receive access to one or more services provided by service provider 1512). Service provider 1512 may provide an onboarding service to register potential user 1514 with service provider 1512. In some examples, onboarding may involve presenting potential user 1514 with a variety of questions, prompts, etc., to obtain information that can be used to create a profile of potential user 1514. In at least one example, service provider 1512 may provide limited or short-term access to its services before or during onboarding (for example, a user of a peer-to-peer payment service may be able to transfer and / or receive funds before being fully onboarded, or a merchant may be able to process payments before being fully onboarded, etc.). In at least one example, in response to the potential user 1514 providing all the necessary information, the potential user 1514 may be onboarded to the service provider 1512. In such an example, any limited or short-term access to the service provider 1512's services may be transitioned to a more permissive (e.g., less limited) or longer-term access to such services.

[0271] Service provider 1512 may be associated with IDV services that may be used by service provider 1512 for compliance purposes and / or may be provided as a service to, for example, a third-party service provider (e.g., associated with server computing device 1510). That is, service provider 1512 may provide IDV services to verify the identity of user 1514 who is using or intending to use those services. Identity verification requires the buyer (or potential buyer) to provide information that will be used by the compliance department to prove that the information is associated with the identity of a real person or entity. In at least one example, service provider 1512 may perform a service to determine whether the identification information provided by user 1514 accurately identifies the buyer (or potential buyer) (i.e., is the buyer the person they are talking about?).

[0272] Service provider 1512 may provide additional or alternative services, the services described above being offered as a sample of the services. In at least one example, service provider 1512 may exchange data with a server computing device 1510 associated with a third-party service provider. Such a third-party service provider may provide information that enables service provider 1512 to provide the services described above. In additional or alternative examples, such a third-party service provider may have access to service provider 1512's services. That is, in some examples, a third-party service provider may be a subscriber or otherwise have access to service provider 1512's services.

[0273] The technologies described in this book can be configured to operate in both real-time / online and offline modes. “Online” mode refers to the mode in which a device is able to communicate with service provider 1512 (e.g., server computing device 1502) and / or server computing device 1510 via network 1504. In some examples, merchant device 1508 is unable to connect with service provider 1512 (e.g., server computing device 1502) and / or server computing device 1510, for example, due to network connectivity issues. In additional or alternative examples, server computing device 1502 is unable to communicate with server computing device 1510, for example, due to network connectivity issues. In such an example, the device may operate in an "offline" mode in which at least some payment data is stored on (e.g., merchant device 1508) and / or server computing device 1502 until connectivity is restored and the payment data can be sent to server computing device 1502 and / or server computing device 1510 for processing.

[0274] In at least one example, service provider 1512 may be associated with a hub such as an order hub, inventory hub, or fulfillment hub, which may enable integration with one or more additional service providers (e.g., associated with an additional server computing device 1510). In some examples, such additional service providers may provide additional or alternative services, and service provider 1512 may provide an interface or other computer-readable instruction for integrating the functions of service provider 1512 with one or more additional service providers.

[0275] The technology described in this book concerns services delivered via a distributed system of user devices 1506 communicating with one or more server computing devices 1512 of a service provider 1512. That is, the technology described in this book concerns specific implementations or practical applications that utilize a distributed system of user devices 1506 communicating with one or more server computing devices 1502 of a service provider 1512 to perform various services, as described above. The unconventional configuration of the distributed system described in this book enables server computing devices 1502, located remotely from an end-user (e.g., user 1514), to intelligently deliver services, in some examples near real-time, based on aggregated data associated with end-users such as user 1514 (e.g., data associated with multiple, different merchants and / or multiple different buyers). Therefore, the technology described in this book concerns specific configurations of elements that offer technological improvements over conventional technologies for performing payment processing services, etc. In particular, for small business owners, the business environment is typically fragmented, reliant on unrelated tools and programs, making it difficult for owners to manually integrate and view such data. The technology described in this document tracks the business status of merchants (accounts receivable, accounts payable, salaries, invoices, promises, capital, etc.) by continuously or periodically monitoring heterogeneous and separate merchant accounts, such as accounts under the control of service provider 1512 and accounts outside the control of service provider 1512. The technology in this document provides an integrated view of merchant cash flows, anticipates needs, proactively provides recommendations or services such as capital and coupons, and / or enables the movement of money between heterogeneous accounts (merchant, other merchants, or payment services) in a frictionless and transparent manner.

[0276] As described in this book, artificial intelligence, machine learning, and other technologies can be used to dynamically make decisions, recommendations, etc., thereby adding intelligence and context awareness to the payment processing services and / or additional or alternative services described in this book, in a one-size-fits-all manner. In some implementations, distributed systems can apply intelligence derived from the existing user base to new users, thereby personalizing and reducing friction in the new user onboarding experience compared to traditional onboarding methods. Thus, the technologies described in this book improve existing technology processes.

[0277] As described above, various graphical user interfaces (GUIs) may be presented to support the technologies described in this book. Some of the technologies described in this book concern user interface features presented via a GUI to improve the interaction between user 1514 and user device 1506. Furthermore, such features are dynamically modified based on the user profile involved in interacting with the GUI. As such, the technologies described in this book concern improvements to computing systems.

[0278] As will become clear through the following discussion, any of the methods discussed herein may be implemented by a computer. In other words, a data processing device, device, or system may include means for performing any step of the methods disclosed herein. A computer program may include instructions that, when executed by a computer, cause the computer to perform any step of the methods disclosed herein. Finally, a computer-readable medium may include instructions that, when executed by a computer, cause the computer to perform any step of the methods disclosed herein.

[0279] Figure 16 illustrates additional details associated with the individual components of the merchant ecosystem described in Figure 15. System 1600 includes a user device 1602 that communicates with a server computing device (e.g., server 1604) via a network 1606 (e.g., the Internet, cable networks, cellular networks, cloud networks, wireless networks (e.g., Wi-Fi), and wired networks, as well as short-range communications such as Bluetooth®, Bluetooth® Low Energy (BLE)). Although a single user device 1602 is shown, in additional or alternative examples, System 1600 may have multiple user devices as described above with reference to Figure 15.

[0280] Environment 1600 can facilitate enhanced security measures associated with embedded card readers, as described herein. As stated above, techniques for spatially and / or temporally separating PAN data and PIN data on on-shelf devices used for making payments may be employed using System 1600 as described herein. For example, PAN data may be removed from the merchant device before a request for PIN data is made and / or before the PIN data is received by the device. Other methods include using different applications to handle PAN data and PIN data, using intermediate applications in addition to trust routines to determine whether the merchant device has been compromised, using various encryption schemes, and processing EMV data in a remote system.

[0281] As described above, users of a platform (e.g., websites, applications, and other network-based communication tools provided by service providers) leverage tools for online commerce ("e-commerce"). However, current technologies have the limitations mentioned above. In some cases, a user interested in selling a product may begin selling it using a given unit of measurement. Such systems do not provide insight into the best unit of measurement for purchasing, storing, and / or selling products. Furthermore, current infrastructure does not allow for automatic filtering of transaction data associated with unit of measurement, leaving merchants responsible for collecting and interpreting this information. Thus, current technologies are inefficient and not user-friendly. Environment 1600, described in this document, enables frictionless (or nearly frictionless) unit conversion recommendations through interactions between merchants and merchant devices. Therefore, the technology described in this document represents an improvement over existing technologies.

[0282] In at least one example, user device 1602 may be any suitable type of computing device, such as portable, semi-portable, semi-stationary, or stationary. Some examples of user device 1602 may include, but are not limited to, tablet computing devices, smartphones or mobile communication devices, laptops, netbooks or other portable or semi-portable computers, desktop computing devices, terminal computing devices or other semi-stationary or stationary computing devices, dedicated devices, wearable computing devices or other body-worn computing devices, augmented reality devices, virtual reality devices, Internet of Things (IoT) devices, etc. In other words, user device 1602 may be any computing device capable of transmitting communications and performing functions in accordance with the technologies described herein. User device 1602 may include devices such as payment card readers or components capable of accepting payments, as described below.

[0283] In the illustrated example, the user device 1602 includes one or more processors 1608, one or more computer-readable media 1610, one or more communication interfaces 1612, one or more input / output (I / O) devices 1614, a display 1616, and a sensor 1618.

[0284] In at least one example, each processor 1608 may comprise one or more processors or processing cores. For example, processor 1608 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operational instructions. In some examples, processor 1608 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to perform the algorithms and processes described herein. Processor 1608 may be configured to fetch and execute computer-readable processor-executable instructions stored in computer-readable medium 1610.

[0285] Depending on the configuration of the user device 1602, the computer-readable medium 1610 may be an example of a tangible, non-temporary computer storage medium, and may include volatile and non-volatile memory and / or removable and non-removable media, implemented with any type of technology for storing information such as computer-readable processor-executable instructions, data structures, program modules, or other data. The computer-readable medium 1610 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable medium technologies. Furthermore, in some examples, the user device 1602 may access external storage devices such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other media that can be used to store information and can be accessed directly by the processor 1608 or via another computing device or network. Thus, the computer-readable medium 1610 may be a computer storage medium capable of storing instructions, modules, or components that can be executed by the processor 1608. Furthermore, where mentioned, non-temporary computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and the signals themselves. Instead, computer-readable media can be temporary.

[0286] The computer-readable medium 1610 can be used to store and hold any number of functional components executable by the processor 1608. In some embodiments, these functional components are executable by the processor 1608 and, when executed, comprise instructions or programs that implement the operational logic for performing actions and services on the user device 1602 due to the above. The functional components stored on the computer-readable medium 1610 can include a user interface 1620 to enable the user to interact with the user device 1602, thus the server 1604 and / or other networked devices. In at least one example, the user interface 1620 can be presented via a web browser or the like. In other examples, the user interface 1620 can be presented via an application such as a mobile application or a desktop application that can be provided by the service provider 1612 associated with the server 1604 or can be another dedicated application. In some embodiments, the user interface 1620 can be one of the user interfaces described above with reference to FIG. 1A. In at least one example, the user can interact with the user interface via touch input, voice input, gesture, or any other type of input. The term "input" is also used to describe "context" input that may not be directly provided by the user via the user interface 1620. For example, the user's interaction with the user interface 1620 can be analyzed using, for example, natural language processing techniques to determine the user's context or intent, which can be processed in a similar manner as "direct" user input.

[0287] Depending on the type of user device 1602, computer-readable medium 1610 may optionally include other functional components and data, such as other modules and data 1622 that may include programs, drivers, etc., as well as data used or created by functional components. Further, computer-readable medium 1610 may also store data, data structures, etc. used by functional components. Further, user device 1602 may include many other logical, program, and physical components, and those described are merely examples relevant to the discussion in this book.

[0288] In at least one example, computer-readable medium 1610 may include additional functional components, such as an operating system 1624, to control and manage various functions of user device 1602 and enable basic user interaction.

[0289] The communication interface 1612 may include one or more interfaces and hardware components to enable communication with various other devices, either via or directly through the network 1606. For example, the communication interface 1612 may enable communication via one or more networks 1606, which may include, but are not limited to, any type of network known in the art, such as a local area network or a wide area network such as the Internet, wireless networks such as cellular networks, cloud networks, local wireless networks such as Wi-Fi, and / or near-field communication such as Bluetooth®, BLE, NFC, RFID, wired networks, or any other such networks, or any combination thereof. Thus, the network 1606 may include both wired and / or wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as wired or optical fiber technologies. The components used for such communication may depend on the type of network, the environment chosen, or at least part of both. Protocols for communicating via such networks are well known and are not described in detail herein.

[0290] Embodiments of this disclosure may be provided to users through a cloud computing infrastructure. Cloud computing refers to the provision of scalable computing resources as a service over a network, enabling convenient on-demand network access to a shared pool of configurable computing resources that can be rapidly provided and released with minimal administrative effort or service provider interaction. Thus, cloud computing enables users to access virtual computing resources in the “cloud” (e.g., storage, data, applications, and full virtualized computing systems) regardless of the underlying physical systems (or the location of those systems) used to provide the computing resources.

[0291] The user device 1602 may further include one or more input / output (I / O) devices 1614. The I / O devices 1614 may include speakers, microphones, cameras, and various user controls (e.g., buttons, joysticks, keyboards, keypads, etc.), haptic output devices, etc. The I / O devices 1614 may also include attachments that utilize accessories (e.g., audio jacks, USB-C, Bluetooth) to connect to the user device 1602.

[0292] In at least one example, the user device 1602 may include a display 1616. Depending on the type of computing device used as the user device 1602, the display 1616 may use any suitable display technology. For example, the display 1616 may be a liquid crystal display, a plasma display, a light-emitting diode display, an OLED (organic light-emitting diode) display, an electronic paper display, or any other suitable type of display on which digital content can be presented. In at least one example, the display 1616 may be an augmented reality display, a virtual reality display, or any other display on which digital content can be presented and / or projected. In some examples, the display 1616 may have a touch sensor associated with the display 1616 to provide a touchscreen display configured to receive touch input to enable interaction with a graphic interface presented on the display 1616. Thus, the implementation of this document is not limited to any particular display technology. Alternatively, in some examples, the user device 1602 may not include a display 1616, and information may be presented by other means such as auditory or tactile.

[0293] In addition, the user device 1602 may include a sensor 1618. The sensor 1618 may include a GPS device capable of indicating location information. Furthermore, the sensor 1618 may include, but is not limited to, an accelerometer, gyroscope, compass, proximity sensor, camera, microphone, and / or switch.

[0294] In some examples, a GPS device may be used to identify a user's location. In at least one example, a user's location may be used by the aforementioned service provider 1412 to provide one or more services. That is, in some examples, the service provider 1412 may implement geofencing to provide a specific service to a user. For example, using a lending service, location may be used to verify that the stated purpose of the loan corresponds to evidence of use (e.g., does it match what the user using the loan said they intend to use the loan?). Furthermore, in some examples, location may be used for payroll purposes. For example, once a contractor has completed a project, the contractor may provide geotagged images (e.g., tagged based on location information available by a GPS device). In some examples, location may be used to facilitate peer-to-peer payments between nearby users 1414 and / or to send notifications to user 1414 about available promises with merchants located close to user 1414. In at least one example, location can be used to receive payment from a nearby buyer when leaving a geofence, or location can be used to initiate an action in response to user 1414 entering a merchant's real-world store. Location can also be used in additional or alternative ways.

[0295] In addition, the user device 1602 may include various other components not shown, such as removable storage, power supplies like batteries and power control units, barcode scanners, printers, and cash drawers.

[0296] In addition, in some examples, the user device 1602 may include, be connectable to, or otherwise coupled to a reader device 1626 for reading payment instruments and / or identifiers associated with payment objects. In some examples, as described above, the reader device 1626 may plug into a port on the user device 1602, such as a microphone port, headphone port, audio jack, data port, or other suitable port. In additional or alternative examples, the reader device 1626 may be coupled to the user device 1602 via another wired or wireless connection, such as via Bluetooth®, BLE, etc. The reader device 1626 may include a reading head for reading the magnetic strip of a payment card, and further may include encryption technology for encrypting the information read from the magnetic strip. As additional or alternative, the reader device 1626 may be an EMV payment reader that can be embedded in the user device 1602 in some examples. Furthermore, depending on the type and configuration of user device 1602, numerous other types of readers may be used in conjunction with user device 1602 described in this document.

[0297] The reader device 1626 may be a portable magnetic stripe card reader, optical scanner, smart card (card with an embedded IC chip) reader (e.g., an EMV-compliant card reader or a near-field communication reader), RFID reader, etc., configured to detect and acquire data from any payment instrument. Therefore, the reader device 1626 may include hardware implementations such as slots, magnetic tracks, and rails having one or more sensors or electrical contacts to assist in the detection and acceptance of the payment instrument. In other words, the reader device 1626 may include a hardware implementation that allows the reader device 1626 to interact with payment instruments via swipe (i.e., a card presence transaction in which the buyer slides a card having a magnetic strip through a payment reader to capture payment data contained in the magnetic strip), dip (i.e., a card presence transaction in which the buyer initially inserts a card having an embedded microchip (i.e., a chip) into the payment reader until the payment reader prompts the buyer to remove the card), or tap (i.e., a card presence transaction in which the buyer completes the transaction via short-range communication by tapping or hovering his or her electronic device, such as a smartphone running a payment application). Furthermore or optionally, the reader device 1626 may include a biometric sensor to receive and process biometric characteristics and process them as payment instruments, provided that the biometric characteristics are registered with a payment processing service provider and connected to a financial account using a bank server. It will be understood that the reader device may also be an ECR.

[0298] The reader device 1626 may include a processing unit, a computer-readable medium, a reader chip, a transaction chip, a timer, a clock, a network interface, a power supply, and the like. The processing unit of the reader device 1626 may run one or more modules and / or processes to cause the reader device 1626 to perform various functions, as described above and further described in the following disclosures. In some examples, the processing unit may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU, or a processing unit or component known in the art. Furthermore, each of the processing units may have its own local memory, which may also store program modules, program data, and / or one or more operating systems. Depending on the exact configuration and type of the reader device 1626, the computer-readable medium may include volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, small hard drives, memory cards, etc.), or any combination thereof. In at least one example, the computer-readable medium of the reader device 1626 may include at least one module for performing the various functions described herein.

[0299] The reader chip may perform functions to control the operation and processing of the reader device 1626. Specifically, the reader chip may perform functions to control payment interfaces (e.g., contactless interfaces, contact interfaces, etc.), wireless communication interfaces, wired interfaces, user interfaces (e.g., signal state devices (FPGA)), etc. Furthermore, the reader chip may perform functions to control a timer, which may provide a timer signal indicating the amount of time elapsed following a particular event (e.g., interaction, power-down event, etc.). Furthermore, the reader chip may perform functions to control a clock, which may provide a clock signal indicating the time. Furthermore, the reader chip may perform functions to control a network interface, which may interact with network 1606 as described below.

[0300] Furthermore, the reader chip may perform functions for controlling the power supply. The power supply unit may include one or more power supply components, such as AC power or a physical connection to a battery. The power supply unit may include a power conversion circuit for converting AC power and creating multiple DC voltages for use by the components of the reader device 1626. If the power supply unit includes a battery, the battery may be charged via a physical power connection, via inductive charging, or by any other suitable method.

[0301] The transaction chip may perform functions related to processing payment transactions, interfacing with payment instruments, encryption, and other payment-specific functions. That is, as described above, the transaction chip may access payment data associated with payment instruments and provide the payment data to the POS terminal. The payment data may include, but is not limited to, the buyer's name, the buyer's address, the type of payment instrument (e.g., credit, debit, etc.), the number associated with the payment instrument, the verification values ​​associated with the payment instrument (e.g., PIN Verification Key Indicator (PVKI), PIN Verification Value (PVV), Card Verification Value (CVV), Card Verification Code (CVC), etc.), the expiration date data associated with the payment instrument, the primary account number (PAN) corresponding to the buyer (which may or may not match the number associated with the payment instrument), and restrictions on what types of charges / debts may be made. Furthermore, upon receiving the payment data, the transaction chip may encrypt the payment data.

[0302] It should be understood that in some examples, the reader chip may have its own central processing unit and computer-readable medium, and / or the transaction chip may have its own central processing unit and computer-readable medium. In other examples, the functions of the reader chip and transaction chip may be performed on a single chip or on multiple chips, each containing any suitable combination of central processing unit and computer-readable medium for collectively performing the functions of the reader chip and transaction chip described herein.

[0303] Although the user device 1602, which may be a POS terminal, and the reader device 1626 are shown as separate devices, in additional or alternative examples, the user device 1602 and the reader device 1626 may be part of a single device, which may be a battery-operated device. In such examples, the components of both the user device 1602 and the reader device 1626 may be associated with a single device. In some examples, the reader device 1626 may have an integrated display, which may be an addition to (or a replacement for) the display 1616 associated with the user device 1602.

[0304] Server 1604 may include one or more servers or other types of computing devices that can be implemented in any number of ways. For example, in the server example, modules, other functional components, and data may be implemented in a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, a cloud-hosted storage service, etc., but other computer architectures may be used in addition or alternatively.

[0305] Furthermore, although the diagram shows the components and data of server 1604 as existing in a single location, these components and data can alternatively be distributed in any way across different computing devices and locations. Thus, the functionality can be implemented by one or more server computing devices, and the various functions described above can be distributed in various ways across different computing devices. Multiple servers 1604 can be located together or separately, and can be organized, for example, as virtual servers, server banks, and / or server farms. The described functionality can be provided by a single merchant or enterprise server, or by multiple different buyer or enterprise servers and / or services.

[0306] In the examples described, server 1604 may include one or more processors 1628, one or more computer-readable media 1630, one or more I / O devices 1632, and one or more communication interfaces 1634. Each processor 1628 may be a single processing unit or several processing units, and may include one or more computing units or multiple processing cores. Processor 1628 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operation instructions. For example, processor 1628 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to perform the algorithms and processes described herein. Processor 1628 may be configured to fetch and execute computer-readable instructions stored in computer-readable media 1630, which can be programmed to perform the functions described herein.

[0307] Computer-readable media 1630 may include volatile and non-volatile memory and / or removable and non-removable media, implemented in any type of technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media 1630 may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, optical storage, solid-state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other media used to store desired information and accessible by computing devices. Depending on the configuration of server 1604, computer-readable media 1630 may be a type of computer-readable storage medium and / or, where referred to, a non-temporary computer-readable medium may be a tangible non-temporary medium to the extent that non-temporary computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves. Alternatively, computer-readable media may be temporary.

[0308] The computer-readable medium 1630 may be used to store any number of functional components that can be executed by the processor 1628. In many implementations, these functional components include instructions or programs that can be executed by the processor 1628 and, when executed, specifically configure one or more processors 1628 to perform the actions described above on the service provider 1612 and / or the payment processing service. The functional components stored in the computer-readable medium 1630 may optionally include the merchant module 1636, the training module 1638, and one or more other modules and data 1640.

[0309] The merchant module 1636 can be configured to receive transaction data from a POS system such as the POS system 1524 described above with reference to FIG. 15. The merchant module 1636 can send requests (e.g., authorization, capture, settlement, etc.) to a payment service server computing device to facilitate POS transactions between the merchant and the buyer. The merchant module 1636 can communicate the success or failure of a POS transaction to the POS system. The payment processing module 116 described above with reference to FIG. 1 can correspond to the merchant module 1636.

[0310] The training module 1638 can be configured to train a model using a machine learning mechanism. For example, the machine learning mechanism can analyze training data to train a data model that creates an output that can be a recommendation, a score, and / or another indication. The machine learning mechanism can include, but is not limited to, supervised learning algorithms (e.g., artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbors, etc.), unsupervised learning algorithms (e.g., artificial neural networks, association rule learning, hierarchical clustering, cluster analysis, etc.), semi-supervised learning algorithms, deep learning algorithms, etc., statistical models, etc. In at least one example, the machine-trained data model can be stored in a data store associated with the user device 1602 and / or the server 1604 for use once after the data model is trained (e.g., at runtime).

[0311] One or more other modules and data 1640 may include an interactive element generator 138 and / or a command generator 140, the functionality of which has been described at least partially above. Furthermore, one or more other modules and data 1640 may include programs, drivers, and data used or created by functional components. In addition, the server 1604 may include many other logical, programmatic, and physical components, of which those described above are merely examples relevant to the description in this document.

[0312] One or more “modules” and / or “components” referenced in this book may be implemented as more or fewer modules, and the functions described for a module may be redistributed depending on the implementation details. The term “module” as used in this book broadly refers to software stored in a temporary or non-temporary storage medium (e.g., volatile or non-volatile memory for computing devices), hardware, or firmware (or any combination thereof) module. A module is typically functional in such a way that it may take a given input and produce useful data or other output. A module may be built-in or not. An application program (also called an “application”) may contain one or more modules, or a module may contain one or more application programs (e.g., executable code that causes a device to perform an action) that may be accessed over a network or downloaded onto a device as software. In additional and / or alternative examples, a module may be implemented as computer-readable instructions, various data structures, etc., via at least one processing unit for executing instructions and configuring the computing device described herein to perform the operations described herein.

[0313] In some examples, a module may include one or more application programming interfaces (APIs) to perform some or all of its functions (e.g., operations). In at least one example, a software developer kit (SDK) may be provided by a service provider to enable third-party developers to include and / or utilize service provider functions related to their third-party applications. Additionally or alternatively, in some examples, a service provider may use an SDK to integrate third-party service provider functions into its application. That is, APIs and / or SDKs may enable third-party developers to customize how their respective third-party applications interact with service providers, or vice versa. API 148 described above may address such an example.

[0314] The computer-readable medium 1630 may further include an operating system 1642 for controlling and managing various functions of the server 1604.

[0315] The communication interface 1634 may include one or more interfaces and hardware components to enable communication with various other devices, such as via or directly through the network 1606. For example, the communication interface 1634 may enable communication via one or more networks 1606 and may include, but are not limited to, any type of network known in the art, such as a local area network or a wide area network such as the Internet, a wireless network such as a cellular network, a local wireless network such as Wi-Fi, a near-field communication network such as Bluetooth®, BLE, NFC, RFID, a wired network, or any other such network, or any combination thereof. Thus, the network 1602 may include both wired and / or wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as wired or optical fiber technologies. The components used for such communication may depend on the type of network, the environment chosen, or at least part of both. Protocols for communicating over such networks are well known and are not described in detail herein.

[0316] Server 1604 may further be equipped with various I / O devices 1632. Such I / O devices 1632 may include displays, various user interface controls (e.g., buttons, joysticks, keyboards, mice, touchscreens, biometric or sensor input devices, etc.), audio speakers, connection ports, and the like.

[0317] In at least one example, system 1600 may include a data store 1644 which can be configured to store accessible, manageable, and updatable data. In some examples, data store 1644 may be integrated with user device 1602 and / or server 1604. In other examples, as shown in Figure 16, data store 1644 may be located remotely from server 1604 and be accessible from server 1604. Data store 1644 may include multiple databases and / or servers connected locally and / or remotely via network 1606. Data store 146 described above with reference to Figure 1A may correspond to data store 1644.

[0318] In at least one example, data store 1644 may store user profiles, which may include merchant profiles, buyer profiles, and so on.

[0319] A merchant profile may store or otherwise associate data associated with a merchant. For example, a merchant profile may include information about the merchant (e.g., merchant name, merchant geographical location, merchant business hours, employee information, etc.), merchant category classifications (MCCs) offered for sale by the merchant, hardware used by the merchant (e.g., device type), transaction data associated with the merchant (e.g., transactions made by the merchant, payment data associated with the transactions, items associated with the transactions, descriptions of items associated with the transactions, expenditures per item and / or total expenditures for each item in the transaction, parties to the transaction, date, time, and / or location associated with the transaction, etc.), and other information related to the merchant. The merchant profile may store or otherwise associate linked loan information (e.g., previous loans made to the merchant, previous defaults on such loans), risk information associated with the merchant (e.g., risk indications, examples of fraud, chargebacks), appointment information (e.g., previous appointments, upcoming (scheduled) appointments, appointment timing, appointment length), payroll information (e.g., employees, pay frequency, pay amount), employee information, booking data (e.g., previous bookings, upcoming (scheduled) bookings, interactions associated with such bookings), inventory data, buyer service data, etc. The merchant profile may securely store bank account information such as that provided by the merchant. Furthermore, the merchant profile may store payment information associated with payment instruments linked to the merchant's storage balance, such as storage balances maintained in a ledger by the service provider 1412.

[0320] A buyer profile may store buyer data including, but is not limited to, buyer information (e.g., name, phone number, address, bank information), buyer preferences (e.g., learned or buyer-specified), purchase history data (e.g., identifying one or more items purchased (and information about each item), payment method used to purchase one or more items, returns associated with one or more orders, status of one or more orders (e.g., in preparation, packing, in transit, delivered, etc.)), appointment data (e.g., previous appointments, upcoming (scheduled) appointments), payroll data (e.g., employees, pay frequency, pay amount, etc.), booking data (e.g., previous bookings, upcoming (scheduled) bookings, booking period, interactions associated with such bookings, etc.), inventory data, and buyer service data.

[0321] In at least one example, the account described above with reference to Figure 1 may include or be associated with the merchant profile and / or buyer profile described above.

[0322] Furthermore, in at least one example, data store 1644 may store an inventory database and / or a catalog database. As described above, inventory may store data associated with the quantity of each item available to a merchant. The records described above may be stored in the inventory data store. Furthermore, the catalog database may store data associated with items available to a merchant for acquisition. Data store 1644 may store additional or alternative types of data as described in this document.

[0323] In summary, the techniques described in this document concern embedded card reader security. For example, Personal Account Number (PAN) data read from a payment instrument may be temporally and / or spatially separated from Personal Identification Number (PIN) data used to complete the payment for the transaction. Temporal separation may include removing the PAN data from the merchant device before requesting the PIN data. Spatial separation may include using a trusted execution environment, a separate embedded card reader application, an intermediate application, and / or trusted routines to enable, for example, different components of the merchant device and / or components of other devices and systems to handle the PAN data and the PIN data. Providing such functionality enhances data security during payment transactions, among other things.

[0324] The phrases "in some cases," "according to various examples," "in the examples shown," "in one example," "in other examples," "various examples," and "some examples" generally mean that the specific characteristics, structures, or features following those phrases are included in at least one example of the present invention, and may be included in two or more examples of the present invention. In addition, such phrases do not necessarily refer to the same or different examples.

[0325] If the specification states that a component or function may be included or characterized by such a component or function, then it is not required that the specific component or function be included or characterized by such a component or function.

[0326] Furthermore, the above description applies to devices and applications related to payment technology. However, it should be understood that this technology can be extended to any device and application. Moreover, the technology described in this document can be configured to work regardless of the type of payment object reader, POS terminal, web application, mobile application, POS topology, payment card, computer network, and environment.

[0327] The various figures included in this book are flowcharts illustrating exemplary methods that include the techniques described herein. The methods described are illustrated with reference to Figures 11-14 for convenience and ease of understanding. However, the methods described are not limited to being performed using the components shown in Figures 1A-10, 15, and 16, and such components are not limited to performing the methods described herein.

[0328] Furthermore, the methods described above are represented as a set of blocks in a logical flow graph, representing a sequence of actions that may be implemented in hardware, software, or a combination thereof. In the context of software, a block represents a computer-executable instruction stored on one or more computer-readable storage media that, when executed by a processor, performs the described action. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular abstract data type. The order in which the actions are described is not intended to be interpreted as limiting, and any number of described blocks may be combined in any order and / or in parallel to carry out the process. In some embodiments, one or more blocks of the process may be omitted entirely. Furthermore, methods may be combined with each other or with other methods, either whole or in part.

[0329] The foregoing are merely illustrative examples of the principles of this disclosure, and various modifications can be made by those skilled in the art without departing from the scope of this disclosure. The examples described above are presented for illustrative purposes only and not for limitation. This disclosure can also take many forms other than those expressly described herein. Accordingly, it is emphasized that this disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to include their variations and modifications within the spirit of the appended claims.

[0330] As further examples, modifications may be made to the requirements of the apparatus or process (e.g., dimensions, configuration, components, process step sequence, etc.) to further optimize the structures, devices, and methods provided, as shown and described herein. In any case, the structures and devices and related methods described herein have many applications. Therefore, the subject matter disclosed should not be limited to any single example described herein, but rather should be interpreted in the breadth and scope that is in accordance with the appended claims.

[0331] The following sections are also disclosed. 1. A method, Configuring a point-of-sale (POS) application installed on a mobile device to utilize the mobile device's built-in card reader (ECR), The POS application is configured to utilize the touchscreen display of the mobile device, The aforementioned POS application, Receiving the individual account number (PAN) from the aforementioned ECR, The system is configured to receive a personal identification number (PIN) from the aforementioned touchscreen display, In the aforementioned POS application, receiving the PAN for a transaction, Before requesting the aforementioned PIN, the POS application removes the PAN from the mobile device, Requesting the PIN using the aforementioned touchscreen display, In the aforementioned POS application, receiving the PIN and A method comprising completing the transaction based on the receipt of the aforementioned PAN and PIN. 2. The method described in Section 1, Sending the aforementioned PAN to the payment processing service, A method wherein removing the PAN from the mobile device corresponds to sending the PAN to the payment processing service. 3. The method described in Section 1, Receiving a request from the payment processing service to obtain the aforementioned PIN, A method for removing the PAN from the mobile device in response to receiving the request for the PIN. 4. A method according to Section 1, wherein requesting the PIN corresponds to removing the PAN from the mobile device. 5. The method described in Section 1, After receiving the PAN, a trust routine is executed in relation to the mobile device, the trust routine is configured to determine whether the mobile device has been tampered with, The process further includes determining that the trust routine indicates that the mobile device has not been tampered with, A method in which requesting the aforementioned PIN is in response to the trust routine indicating that the mobile device has not been tampered with. 6. The method described in Section 1, Receiving the PAN includes receiving the PAN in the trusted execution environment (TEE) of the mobile device. The PIN is received outside the TEE of the mobile device, in a manner that allows for this. 7. The method described in Section 1, The further includes receiving an indication that user input corresponding to the PIN has been received in response to the request for the PIN, Completing the aforementioned transaction is a method based at least in part on the aforementioned indication. 8. The method described in Section 1, wherein receiving the PAN includes receiving encrypted first data representing the PAN from the ECR, and the method is The encrypted first data is transmitted to the payment processing service, Receiving encrypted second data representing the aforementioned PIN, A method further comprising transmitting the encrypted second data to the payment processing service. 9. The method described in Section 1, Receiving encrypted data representing the aforementioned PIN, The encrypted data is transmitted to the payment processing system, The payment processing system further includes receiving an indication from the payment processing system that the PIN is authorized in relation to the PAN when it is decrypted by the payment processing system, Completing the aforementioned transaction is at least in part based on the fact that the PIN is authorized in connection with the PAN. 10. The method described in Section 1, wherein the POS application includes a first application, and the method is In the second application configured to suppress communication between the second application and the first application, the reception of the PIN and Sending the aforementioned PAN from the first application to the payment processing service, A method further comprising transmitting the PIN from the second application to the payment processing service. 11. A device, Touchscreen and One or more processors, A non-temporary computer-readable medium for storing instructions, wherein the instructions, when executed by one or more processors, Configuring the point-of-sale (POS) application to utilize an embedded card reader (ECR), The POS application is configured to receive personal account numbers (PANs) from the ECR, Configuring a Personal Identification Number (PIN) application to receive a PIN from the touchscreen, The PIN application is configured to suppress communication with the POS application, In the aforementioned POS application, receiving the PAN for a transaction, Requesting the PIN using the aforementioned touchscreen, In the aforementioned PIN application, receiving the PIN and A device including a non-temporary computer-readable medium that causes one or more processors to perform an operation including completing the transaction based on the receipt of the PAN and PIN. 12. The device described in Section 11, wherein the operation is Sending the aforementioned PAN to the payment processing service, A device, including removing the PAN from the device in response to sending the PAN to the payment processing service. 13. The device described in Section 11, wherein the operation is Receiving a request from the payment processing service to obtain the aforementioned PIN, A device comprising: removing the PAN from the device in response to receiving the request for the PIN. 14. A device as described in Section 11, wherein the operation further includes removing the PAN from the device, and requesting the PIN corresponds to removing the PAN from the device. 15. The device described in Section 11, wherein the operation is After receiving the PAN, a trust routine is executed in relation to the device, the trust routine is configured to determine whether the device has been tampered with, The further includes determining that the trust routine indicates that the device has not been tampered with, The request for the aforementioned PIN is in response to the trust routine indicating that the device has not been tampered with. 16. The devices described in Section 11, Receiving the PAN includes receiving the PAN in a trusted execution environment (TEE) of the device. The PIN is received outside the TEE of the device. 17. The device described in Section 11, wherein the operation is The further includes receiving an indication that user input corresponding to the PIN has been received in response to the request for the PIN, The completion of the payment is at least partially based on the user input corresponding to the PIN on the device. 18. The devices described in Section 11, Receiving the PAN includes receiving encrypted first data representing the PAN from the ECR. A device whose receiving the PIN includes receiving encrypted second data representing the PIN. 19. A device as described in Section 11, wherein receiving the PIN includes receiving encrypted data representing the PIN, and the operation is: The encrypted data is transmitted to the payment processing system, The payment processing system further includes receiving an indication from the payment processing system that the PIN is authorized in relation to the PAN when it is decrypted by the payment processing system, Completing the transaction is at least partially based on the fact that the PIN is authorized in connection with the PAN. 20. A device as described in Section 11, wherein the operation further includes removing the PAN from the device before the POS application requests the PIN. 21. A method implemented by a point-of-sale (POS) application installed on a mobile device, In the aforementioned POS application, an indication is received that a payment is being received using the near-field communication (NFC) card reader of the mobile device. The POS application transmits a request to the NFC card reader to initiate the payment. In the aforementioned POS application, the NFC card reader receives the personal account number (PAN) associated with the payment device, From the aforementioned POS application to the payment processing service, The aforementioned PAN and, Default Personal Identification Number (PIN), The identifier of the transaction associated with the aforementioned payment, and the transmission of The POS application removes the PAN from the mobile device after (i) sending the PAN to the payment processing service and (ii) requesting the account PIN associated with the payment tool. Requesting the account PIN associated with the payment instrument, Receiving the account PIN using the touchscreen input of the mobile device, Sending the aforementioned account PIN and the aforementioned transaction identifier to the payment processing service, A method including completing a payment based on receiving an indication that the aforementioned account PIN has been accepted. 22. The method described in Section 21, Sending the request to initiate payment from the POS application to the NFC card reader includes sending the request from the POS application to an intermediate application configured to communicate with the POS application and the NFC card reader. A method in which the POS application receives the PAN from the NFC card reader, including receiving the PAN from the intermediate application. 23. The method described in Section 21, wherein the POS application includes Europay, Mastercard, and Visa (EMV) kernels, and the method is In the aforementioned POS application, the EMV data associated with the payment instrument is received from the NFC reader, wherein the EMV data is not encrypted by the NFC reader. A method comprising determining the PAN using the EMV data via the POS application. 24. The method described in Section 21, wherein the POS application includes Europay, Mastercard, and Visa (EMV) kernels, and the method is In the aforementioned POS application, the EMV data associated with the payment instrument is received from the NFC reader, and the EMV data is encrypted by the NFC reader. The POS application decrypts the EMV data so that decrypted EMV data is generated. A method comprising determining the PAN using the decoded EMV data by the POS application. 25. A device, Near Field Communication (NFC) card reader and, One or more processors, A non-temporary computer-readable medium for storing instructions, wherein the instructions, when executed by one or more processors, In a POS application, the NFC card reader receives the Personal Account Number (PAN) associated with the payment device, To the payment processing service, The aforementioned PAN and, Sending the default Personal Identification Number (PIN) and, The POS application removes the PAN from the device before requesting the account PIN associated with the payment instrument, A device comprising a non-temporary computer-readable medium that causes one or more processors to perform an operation including receiving the account PIN using the touchscreen input of the device, and completing the payment, at least in part, based on an indication that the account PIN has been accepted. 26. The devices described in Section 25, When received by the aforementioned POS application, the PAN is encrypted as Europay, Mastercard, or Visa (EMV) data. Sending the PAN to the payment processing service includes sending the EMV data to the payment processing service, Completing the payment is at least in part based on the PAN being decrypted in the payment processing service and the account PIN being accepted by the device. 27. The devices described in Section 25, The PAN is encrypted as Europay, Mastercard, Visa (EMV) data, configured to be encrypted by the original equipment manufacturer (OEM) associated with the device. The transmission of the PAN includes sending the EMV data to the OEM, along with a request to decrypt the EMV data and provide the PAN to the payment processing service. Completing the aforementioned payment is at least in part based on the acceptance of the PAN and the account PIN as decrypted as OEM by the device. 28. A device as described in Section 25, further including a Trusted Execution Environment (TEE), wherein the operation is: The TEE receives Europay, Mastercard, and Visa (EMV) data, including the encrypted version of the PAN. The method further includes decoding the EMV data in the TEE so that the PAN is identified, The device that completes the payment includes completing the payment using the PAN when it has been decrypted in the TEE. 29. The device described in Section 25, wherein the operation is Prior to receiving the PAN, a trust routine is performed in relation to the device, the trust routine is configured to determine whether the device has been tampered with in a manner that indicates the device is not secure for completing the payment, The trust routine determines that the device has not been tampered with, The device further includes, in response to the trust routine indicating that the device has not been tampered with, the POS application requesting the PAN. 30. A device as described in Section 25, wherein the operation includes transmitting a request to initiate payment from the POS application to an intermediate application configured to communicate with the POS application and the NFC card reader, the POS application receiving the PAN from the NFC card reader, the POS application receiving the PAN from the NFC card reader, and the POS application receiving the PAN from the intermediate application. 31. The device described in Section 25, wherein the POS application includes the Europay, Mastercard, and Visa (EMV) kernels, and the operation is as follows: In the aforementioned POS application, the EMV data associated with the payment instrument is received from the NFC reader, wherein the EMV data is not encrypted by the NFC reader. A device comprising: determining the PAN using the EMV data via the POS application. 32. The device described in Section 25, wherein the POS application includes the Europay, Mastercard, and Visa (EMV) kernels, and the operation is as follows: In the aforementioned POS application, the EMV data associated with the payment instrument is received from the NFC reader, and the EMV data is encrypted by the NFC reader. The POS application decrypts the EMV data so that decrypted EMV data is generated. A device comprising: determining the PAN using the decoded EMV data via the POS application. 33. A method implemented by a point-of-sale (POS) application installed on a mobile device, The mobile device receives an indication that a payment has been received using its Near Field Communication (NFC) card reader. The POS application sends a request to initiate the payment to an intermediate application configured to communicate with the POS application and the NFC reader. In the aforementioned POS application, the individual account number (PAN) associated with the payment instrument is received from the aforementioned intermediate application, From the aforementioned POS application to the payment processing service, The aforementioned PAN and, Sending the default Personal Identification Number (PIN) and, Removing the PAN from the mobile device before requesting the account PIN associated with the payment instrument, Receiving the account PIN using the touchscreen input of the mobile device, A method including completing a payment based at least in part on an indication that the aforementioned account PIN has been accepted. 34. The method described in Section 33, When received by the aforementioned POS application, the PAN is encrypted as Europay, Mastercard, or Visa (EMV) data. Sending the PAN to the payment processing service includes sending the EMV data to the payment processing service, Completing the payment is a method that is at least in part based on the decrypted PAN and the acceptance of the account PIN in the payment processing service. 35. The method described in Section 33, The PAN is encrypted as Europay, Mastercard, Visa (EMV) data, configured to be encrypted by the original equipment manufacturer (OEM) associated with the device. The transmission of the PAN includes sending the EMV data to the OEM, along with a request to decrypt the EMV data and provide the PAN to the payment processing service. Completing the aforementioned payment is a method at least in part based on the acceptance of the PAN and the account PIN as decrypted as the OEM. 36. The method described in Section 33, In the trusted execution environment (TEE) of the aforementioned mobile device, Europay, Mastercard, and Visa (EMV) data, including the encrypted version of the PAN, The method further includes decoding the EMV data in the TEE so that the PAN is identified, A method for completing the payment, which includes completing the payment using the PAN as it was decrypted in the TEE. 37. The method described in Section 33, Before receiving the PAN, a trust routine is executed in relation to the mobile device, the trust routine is configured to determine whether the mobile device has been tampered with, The trust routine determines that the mobile device has not been tampered with, A method further comprising: having the POS application request the PAN in response to the trust routine indicating that the mobile device has not been tampered with. 38. The method described in Section 33, Sending the request to initiate payment from the POS application to the intermediate application involves causing the embedded card reader application to query the NFC card reader for the PAN. Receiving the PAN from the intermediate application is a method comprising the intermediate application receiving the PAN from the embedded card reader application and transmitting the PAN to the POS application. 39. The method described in Section 33, wherein the POS application includes Europay, Mastercard, and Visa (EMV) kernels, and the method is In the aforementioned POS application, the EMV data associated with the payment instrument is received from the NFC reader, wherein the EMV data is not encrypted by the NFC reader. A method comprising determining the PAN using the EMV data via the POS application. 40. A method according to Section 33, wherein the POS application is configured to obtain the PAN from the NFC card reader and from a separate physical card reader associated with the mobile device.

Claims

1. It is a device, One or more processors, A non-temporary computer-readable medium for storing instructions, wherein the instructions, when executed by one or more processors, The Personal Account Number (PAN) application installed on the device is configured to utilize the device's built-in card reader (ECR), wherein the PAN application is configured within the device's trusted execution environment (TEE), and the components within the TEE are isolated from components outside the TEE. In the aforementioned PAN application, receiving a PAN for a transaction is at least partially based on the interaction between the ECR and the device, Using the aforementioned PAN application, the PAN is transmitted to the payment processing service, In response to determining that the PAN has been received by the payment processing service, the following actions are taken: a Personal Identification Number (PIN) application residing on the device, configured outside the TEE of the device, renders a PIN user interface, suppresses communication between the PIN application and the PAN application, and the PIN application receives the PIN using the PIN user interface; Using the PIN application, the PIN is transmitted to the payment processing service. Completing the transaction, at least in part, based on an indication from the payment processing service that the PAN and PIN have been accepted. A device including a non-temporary computer-readable medium that causes one or more processors to perform an operation including the above.

2. A device according to claim 1, wherein the operation further includes removing the PAN from the device in response to transmitting the PAN to the payment processing service.

3. The device according to claim 1, wherein the operation is Receiving a request for the PIN from the aforementioned payment processing service, A device further comprising removing the PAN from the device in response to receiving the request for the PIN.

4. A device according to claim 1, wherein the operation further includes removing the PAN from the device, and requesting the PIN is in response to removing the PAN from the device.

5. The device according to claim 1, wherein the operation is After receiving the aforementioned PAN, a trust routine is executed in relation to the device, wherein the trust routine is configured to determine whether the device has been tampered with. The further includes determining that the trust routine indicates that the device has not been tampered with, The request for the aforementioned PIN corresponds to the trust routine indicating that the device has not been tampered with.

6. The device according to claim 1, wherein the operation is The further includes receiving an indication that user input corresponding to the PIN has been received in response to the request for the PIN, Completing the transaction is at least partially based on the user input corresponding to the PIN of the device.

7. The device according to claim 1, Receiving the PAN includes, in the PAN application, receiving encrypted first data representing the PAN from the ECR. Receiving the PIN includes, in the PIN application, receiving encrypted second data representing the PIN.

8. The device according to claim 1, wherein receiving the PIN includes receiving encrypted data representing the PIN in the PIN application, and the operation is The encrypted data is transmitted to the payment processing service, The payment processing service further includes receiving an indication from the payment processing service that the PIN is authorized in relation to the PAN when decrypted by the payment processing service, The completion of the transaction is at least in part based on the fact that the PIN is authorized in relation to the PAN.

9. A device according to claim 1, wherein the operation further includes removing the PAN from the device before the PIN is requested by the PAN application.

10. The device according to claim 1, wherein transmitting the PAN to the payment processing service further comprises transmitting a default PIN associated with the payment processing service.

11. A method performed by a device, The Personal Account Number (PAN) application installed on the device is configured to utilize the device's built-in card reader (ECR), wherein the PAN application is configured within the device's trusted execution environment (TEE), and the components within the TEE are isolated from components outside the TEE. In the aforementioned PAN application, receiving a PAN for a transaction is at least partially based on the interaction between the ECR and the device, Using the aforementioned PAN application, the PAN is transmitted to the payment processing service, In response to determining that the PAN has been received by the payment processing service, the following actions are taken: a Personal Identification Number (PIN) application residing on the device, configured outside the TEE of the device, renders a PIN user interface, suppresses communication between the PIN application and the PAN application, and the PIN application receives the PIN using the PIN user interface; Using the PIN application, the PIN is transmitted to the payment processing service. A method comprising completing the transaction based at least in part on an indication from the payment processing service that the PAN and PIN have been accepted.

12. A method according to claim 11, further comprising removing the PAN from the device in response to transmitting the PAN to the payment processing service.

13. The method according to claim 11, Receiving a request for the PIN from the aforementioned payment processing service, A method further comprising removing the PAN from the device in response to receiving the request for the PIN.

14. A method according to claim 11, further comprising removing the PAN from the device, wherein requesting the PIN corresponds to the removal of the PAN from the device.

15. The method according to claim 11, After receiving the aforementioned PAN, a trust routine is executed in relation to the device, wherein the trust routine is configured to determine whether the device has been tampered with. The further includes determining that the trust routine indicates that the device has not been tampered with, A method in which requesting the aforementioned PIN corresponds to the trust routine indicating that the device has not been tampered with.

16. The method according to claim 11, The further includes receiving an indication that user input corresponding to the PIN has been received in response to the request for the PIN, Completing the transaction is a method that is at least partially based on the user input corresponding to the PIN.

17. The method according to claim 11, Receiving the PAN includes, in the PAN application, receiving encrypted first data representing the PAN from the ECR. A method for receiving the PIN, comprising receiving encrypted second data representing the PIN in the PIN application.

18. The method according to claim 11, wherein receiving the PIN includes receiving encrypted data representing the PIN in the PIN application, the method is The encrypted data is transmitted to the payment processing service, The payment processing service further includes receiving an indication from the payment processing service that the PIN is authorized in relation to the PAN when decrypted by the payment processing service, Completing the aforementioned transaction is at least in part based on the fact that the PIN is authorized in relation to the PAN.

19. A method according to claim 11, further comprising removing the PAN from the device before the PIN is requested by the PAN application.

20. A method according to claim 11, wherein transmitting the PAN to the payment processing service further comprises transmitting the default PIN associated with the payment processing service.

Images