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 Ser. No. 17 / 183,149, entitled "EMBEDDED CARD READER SECURITY," filed February 23, 2021, and U.S. patent application Ser. No. 17 / 183,129, entitled "EMBEDDED CARD READER SECURITY," filed February 23, 2021, the entire contents of which are incorporated herein by reference.

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

[0003] A payment instrument is utilized to purchase an item. In some examples, the reader is embedded in a point-of-sale device associated with a payment processing service. In other examples, the reader is separate from such point-of-sale device. In still other examples, the embedded card reader may be configured to operate on a personal device such as a mobile phone, tablet, etc. In these and other examples, security of information obtained by the reader and / or other information associated with the transaction is desirable. In particular, problems to be solved include how to effectively inhibit malicious actors from obtaining data associated with the payment transaction to ensure that the payment transaction and the payment instrument, such as a payment card, remain secure. [Brief description of the drawings]

[0004] The features of the present disclosure, its nature and various advantages will become more apparent upon consideration of the following detailed description in conjunction with the accompanying drawings. The detailed description is set forth below with reference to the accompanying drawings. In the figures, the left-most digit of a reference number identifies the figure in which the reference number first appears. The use of the same reference number in different figures indicates similar or identical items. The systems depicted in the accompanying drawings are not to scale, and components within the drawings may not be drawn to scale relative to each other.

[0005] [Figure 1A] An exemplary environment for Embedded Card Reader (ECR) security is described.

[0006] [Figure 1B] 1 illustrates a conceptual diagram of components utilized to implement a software personal identification number (PIN) on a consumer off-the-shelf device technology and an ECR technology.

[0007] [Diagram 2] An exemplary process associated with protecting payments utilizing ECR without generating a default PIN is described.

[0008] [Diagram 3] An exemplary process associated with securing payments utilizing an ECR is described, where a point of sale (POS) application communicates directly with the ECR.

[0009] [Figure 4] An example process associated with securing a payment utilizing an intermediary application configured to communicate with a POS application and an ECR is described.

[0010] [Diagram 5] An exemplary process associated with securing a payment using an ECR is described, where the ECR application performs security operations associated with the payment.

[0011] [Figure 6] A conceptual diagram of exemplary components utilized to secure payments is described, and the process is associated with obtaining a personal account number (PAN) and a PIN, where the PIN is separated.

[0012] [Figure 7] A conceptual diagram of exemplary components utilized to secure payments is illustrated, where PAN data is handled by a segregated service and a POS application handles PIN data.

[0013] [Figure 8] 1 illustrates a conceptual diagram of exemplary components utilized to secure payment, Europay, MasterCard, Visa (EMV) data processing handled by a payment processing service on behalf of a merchant device.

[0014] [Figure 9] 1 illustrates a conceptual diagram of exemplary components utilized to secure payments, and the processing of EMV data is handled by a vendor data center.

[0015] [Figure 10] illustrates a conceptual diagram of example components utilized to secure payments using a trusted execution environment (TEE).

[0016] [Figure 11] An exemplary process for ECR security will be described.

[0017] [Figure 12] Another exemplary process for ECR security will now be described.

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

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

[0020] [Figure 15] An exemplary merchant ecosystem for facilitating, among other things, the techniques described herein is illustrated.

[0021] [Figure 16] 15 provides additional details associated with the individual components of the merchant ecosystem. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] The technology described herein is directed, among other things, to embedded card reader (ECR) security configured to improve data security during a payment transaction. A payment transaction typically involves the 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 a particular payment instrument, such as a payment card, to be used. For example, entry of a PIN code may enable a PAN to be obtained from the payment instrument, which may then be transmitted along with other transaction information to a payment processing service or bank to facilitate the transaction.

[0023] Increasingly, merchants are choosing not to utilize specific POS devices to handle such payment transactions, but instead to utilize consumer off-the-shelf (COTS) devices to perform the transactions. Exemplary COTS devices include typical mobile (computing) devices such as mobile phones (typically, smart phones), tablets, etc. The 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 sent / received by the COTS device. Thus, these COTS devices may be utilized to install one or more applications that enable the COTS device to be utilized to obtain PAN data, PIN data, and / or other information to satisfy a payment. To do so, in one example, a Near Field Communication (NFC) component of the COTS device may be utilized by one or more applications on the device to read PAN data from a payment instrument such as a payment card, which may then utilize the PAN data to complete the transaction. Such technology, where a card reader is housed or embedded within the COTS device, may be described as Embedded Card Reader (ECR) technology.

[0024] In some examples, COTS devices and other devices may be configured to obtain PIN data to authorize a transaction in addition to or instead of obtaining PAN data. Techniques for obtaining PIN data include "PIN-on-glass" techniques, where a PIN pad or other user interface is displayed on the 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 utilized for comparison with reference PIN data associated with a given payment instrument to complete a payment. Additionally, techniques for obtaining PIN data may include Software-Based PIN Entry on COTS (SPoC), where a secure reader PIN, PIN application, merchant device, and back-end monitoring and attestation system are utilized to obtain PIN data using the COTS device. It should be understood that when "card reader" and / or "reader" are described herein, these terms encompass components configured to obtain data from a payment instrument, which may be a physical card, and / or may be another device and / or an object other than a card, such as an electronic device that stores payment account information. Thus, wherever a "card" is described as being used as an example, it will be understood that this is merely an example and that in general any payment instrument may be used.

[0025] The use of an embedded card reader in a COTS device to conduct a transaction has many significant advantages. Payment transactions can be more versatile since all that is needed is a COTS device such as a mobile phone. No other dedicated payment hardware such as a traditional payment card reader is needed. This means that payments can be made almost anywhere at any time. No complicated setup or pairing process is needed between the merchant device and the card reader, reducing complexity, increasing reliability, and increasing the potential throughput of transactions. The use of an embedded card reader is also more environmentally friendly since no dedicated card reader device needs to be manufactured. Instead, all that is needed is a COTS device. That being said, the use of such COTS devices to conduct transactions is not without challenges. In particular, the use of COTS devices, or other devices that are not specifically configured as POS devices with typical security mechanisms in place, represents an increased risk of unauthorized exposure of PAN and / or PIN data by malicious actors. For example, the inventors have recognized the problem that, once a malicious actor has gained access to a given COTS device, the presence of both PAN and PIN data on the COTS device simultaneously and / or for the same application increases the risk that the malicious actor can obtain both pieces of information that can then be used in a fraudulent transaction. This technical shortcoming could potentially limit the viability of using COTS devices in payment transactions.

[0026] This technical shortcoming in the security of transaction flows using COTS or other non-native 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, enabling a more versatile payment infrastructure that does not rely on purpose-built, dedicated POS devices or payment readers, and therefore provides the advantages discussed above. This advancement is achieved while maintaining the security of the transaction flows and payment data.

[0027] In further detail, the techniques described herein enable PAN and PIN data to be separated through various mechanisms described below, such as two-phase server messaging and other spatial or temporal separation techniques. Alternatively, other techniques described herein also enable PIN data entry and PAN collection by a device to occur in a secure manner without such spatial or temporal separation, as described in more detail below. In other words, this disclosure describes techniques for, among other things, ensuring temporal and / or spatial separation of PAN and PIN data as utilized by a COTS device to complete a payment associated with a transaction, in addition to techniques for collecting unsegregated PAN and PIN data in a secure manner.

[0028] In one example, the COTS device may include one or more components to ensure temporal and / or spatial separation of PAN data and PIN data on the COTS device. In some examples, the ECR may be incorporated into the card reader library of the POS application, and in these examples, the ECR may communicate directly with the POS application and the NFC components of the COTS device. In this example, the ECR may be utilized to obtain PAN data from the payment instrument and provide the PAN data to the POS application. The POS application may then be configured to associate a default PIN with the PAN data and transmit a reimbursement request with the PAN data and the default PIN to the payment processing service. Once the PAN data and default PIN are transmitted 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 account PIN from the buyer. By doing so, the PAN data and PIN data for the account PIN are not simultaneously present on the COTS device. This temporal separation of the PAN data and the PIN data may prevent a malicious actor from obtaining both pieces of information required to utilize the payment instrument to make a payment. This significantly improves the security of the COTS device for performing transactions. In some examples, 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 transmitted to a payment processing service, which may then transmit an authorization request for the payment to the payment instrument issuer. By utilizing the above process, the security of the payment instrument is increased through technological means implemented in the computing device associated with the transaction. This increase in transaction security is achieved on the fly, in a time-sensitive manner, in other words, in a manner that does not adversely affect the speed of the transaction. Thus, increased 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 the PIN entry request, the POS application may return a default PIN without presenting a PIN entry dialog to the buyer so that the payment kernel can proceed to create the PIN result. The PIN result may be stored in association with the payment processing service without the actual PIN, which may then be collected by the POS application and sent to the service. At the payment processing service, the reimbursement request or transaction request may be stored and upon receiving the actual account PIN, may replace the default PIN. The payment processing service may then send an authorization request to the issuer of the payment instrument utilized 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 introduced 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 allow PAN data processing to occur at a payment processing service and / or a vendor data center separate from the payment processing service.

[0031] In other examples, the ECR may be separated from the POS application and / or the card reader library, and the ECR may be utilized as an isolated service. In these examples, there may be an intermediate application 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 separation of the ECR and the POS application may provide a smaller attack surface for the payment kernel, ensuring that the ECR operates outside of the POS application, which may be the most likely point of attack by a malicious actor. This further improves data security for the COTS device in which the card reader is embedded.

[0032] In some examples, multiple trust applications may be utilized to determine if the COTS device is still a trusted device at the time of payment. In yet other examples, the ECR may be deployed on the COTS device as a separate application utilizing the card reader library as a separate application. In these examples, the ECR may be responsible for performing the default PIN addition process. In still other examples, data encryption may be utilized 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 the POS application may send the encrypted data to a payment processing service. The payment processing service may manage keys and / or other decryption mechanisms and may decrypt the encrypted data to identify the PAN data and / or PIN data. In other examples, instead of the encrypted data being sent to the POS application, the encrypted data is sent to a vendor data center that may be operated by the original equipment manufacturer (OEM) of the device. 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 yet another example, a TEE may be utilized to enhance ECR security on a COTS device.

[0033] By implementing one or more of the techniques described herein, the spatial and / or temporal separation of PAN data from other data utilized for the transaction, such as PIN data, promotes security of the transaction and makes it difficult to obtain unauthorized access to all the information required to fraudulently utilize the payment instrument. These techniques are specific to the computer-centric technical problem of how best to handle digital payment transactions in a secure manner on COTS devices, which are premised on the fact that such devices are more commonly or easily hacked and unauthorized access can occur than on traditional dedicated POS devices that typically include built-in security features. For completeness, it is noted that the disclosed 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 the order of seconds) between the time the transaction is initiated and the time the transaction is completed, minimizing delays in the payment process, thus providing security without adversely affecting the speed or efficiency of the payment transaction.

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

[0035] The present disclosure provides a general understanding of the principles of the structure, function, manufacture and use of the systems and methods disclosed herein. One or more examples of the present disclosure are illustrated in the accompanying drawings. Those skilled in the art will appreciate that the systems and methods specifically described herein and illustrated in the accompanying drawings are non-limiting embodiments. Features described or illustrated in connection with one embodiment may be combined with features of other embodiments, including between the systems and methods. Such modifications and variations are intended to be included within the scope of the appended claims.

[0036] Additional details are described below with reference to certain exemplary embodiments.

[0037] An exemplary environment for embedded card reader security is described. In FIG. 1A, a server 106 can be associated with a payment processing service, which can communicate with user computing devices, such as a merchant device 102 (also described herein as a merchant device and / or a merchant system) and a buyer device 104, via a network 108. That is, the merchant device 102 and the buyer device 104 are networked devices that allow end users to access services provided by the payment processing service (e.g., via the server 106). Additional details associated with the server 106, the user computing devices (e.g., 102, 104), and the network 108 are described below with reference to FIGS. 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 process, among other things, 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 authorization of the payment data, and process the transaction based on a response from the payment processing service. In other examples, the payment processing component 152 may access an account maintained by the payment processing service and use funds associated with the account to process the transaction.

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

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

[0041] In at least one example, the server 106 may include or otherwise have access to a data store 146. The 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, accounts maintained by the payment processing service on behalf of the buyer may be mapped to or otherwise associated with the buyer's user profile. Such accounts may store funds received from peer-to-peer payment transactions, deposits from an employer, transfers from the buyer's other accounts, and the like. Additionally or alternatively, a merchant's user profile may be mapped to or otherwise associated with the merchant's accounts (which may be maintained by the payment processing service, a bank, or another payment service). Additional details are provided below.

[0042] 1A, the merchant device 102 may be associated with a user interface that allows 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 dedicated product provided by a payment processing provider, provided by a third party, etc.), or the like, to allow the buyer to access the functionality 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 dedicated product provided by a payment processing service, provided by a third party, etc.), to allow the buyer to interact with the buyer device 104 and access the functionality and / or services as described herein.

[0043] As described above, the environment 100 may include a merchant device 102, a server 106, and / or a buyer device 104. The 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, in addition to the components described above. The microphone 116 may be configured to receive audio from the environment 100 and generate corresponding audio data, which may be utilized as discussed herein. The speaker 118 may be configured to output audio. The display 120 may be configured to present an image (which may be described as a video). The NFC component 122 may be utilized to wirelessly obtain data from an NFC-enabled payment instrument. The memory 114 may include one or more components, such as a POS application 124, an ECR application 126, an intermediary application 128, an EMV kernel 130, one or more trust applications 132, a PIN application 134, and / or a TEE 136. These components are described in detail below. It should be noted that the merchant device 102, as well as other devices and systems described herein, may take the form of one or more of a computing device, a laptop computer, a telephone, and / or components thereof.

[0044] In 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 described below with reference to FIGS. 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 examples, there may be multiple POS devices connected to multiple other devices, such as "secondary" terminals, e.g., back-of-the-house systems, printers, line buster devices, POS readers, etc., to allow information from the secondary terminals to be shared between the primary POS terminal and the secondary terminals, e.g., via short-range communications techniques.

[0045] Server 106, also referred to herein as payment processing service 106, may include one or more components including, for example, one or more processors 138, one or more network interfaces 140, and / or memory 142. Memory 142 may include one or more components such as, for example, an EMV kernel 144, one or more data stores 146 (described above), one or more machine learning models 148, one or more APIs 150 (described above), and / or a payment processing component 152 (described above). These components are described below as examples.

[0046] For example, the COTS device 102 may include one or more of the above-mentioned components to ensure temporal and / or spatial separation of the PAN and PIN data on the COTS device 102. In some examples, the ECR 126 may be incorporated into a card reader library, and in these examples, the ECR 126 may communicate directly with the POS application 124 and the NFC component 122 of the COTS device 102. In this example, the ECR 126 may be utilized to obtain the 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 a default PIN with the PAN data and send a reimbursement request to the payment processing service 106 along with the PAN data and the default PIN. By sending the PAN data and the default PIN to the payment processing service 106, the payment processing service 106 may have the necessary information to initiate 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 pre-defined PIN that the payment processing service 106 is configured to recognize to enable the processes described herein to increase 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 account PIN from the buyer. By doing so, the PAN data and the PIN data for the account PIN are not simultaneously present on the COTS device 102. This temporal separation of the PAN data and the PIN data may prevent a malicious actor from obtaining both pieces of information needed to utilize the payment instrument to make a payment. Once the PAN data is removed, a PIN entry dialog may be displayed to the buyer, and the buyer may provide user input representing the account PIN. In examples, the PIN application 134 may be configured to receive the user input and generate the 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 that handles the PAN data and the application that handles the PIN data. The PIN data may be transmitted to the payment processing service 106, which may then transmit an authorization request for payment to the payment instrument issuer. The issuer may compare the entered account PIN to a reference PIN associated with the PAN to determine if the entered account PIN is authorized for the PAN. If authorized, the issuer may return an authorization response to the payment processing service 106. The payment processing service 106 may provide an authorization indication to the COTS device 102, which may complete the transaction. Utilizing the above process enhances payment instrument security in a computer-centric manner that is performed on-the-fly and in a time-sensitive manner.

[0048] In other examples, the ECR 126 and the card reader library may be separated, and the ECR 126 may be utilized as an isolated service. In these examples, the card reader library may act as an intermediate application 128 between the ECR 126 and the POS application 124. This spatial separation of the ECR 126 and the POS application 124 may provide 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 point of attack by a malicious actor. In these examples, multiple trust applications 132 may be utilized to determine whether the COTS device 102 is still a trusted device at the time of payment. Additional details regarding the use of the trust applications 132 are provided herein, but generally, the trust applications 132 may be utilized to determine whether one or more conditions of the COTS device 102 indicate that the COTS device 102 has been compromised or is otherwise not a trusted device for obtaining PAN and / or PIN data. In examples where an intermediate application 128 is utilized, a trusted application 132 may be utilized to determine if the POS application 124 has been tampered with, or another trusted application 132 may be utilized to determine if the intermediate application 128 has been tampered with. 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 the PIN and PAN data may not be performed, and instead, an encryption scheme may be utilized to facilitate security of the PIN and PAN data. This encryption-based scheme is described in more detail below with reference to FIG. 2. In these examples, 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 and PAN data may be performed using the same encryption technique.

[0050] The trust application 132 may be configured with enhanced tamper and fraud detection methods (e.g., trust routines) as described in more detail in U.S. Patent Application Nos. 15 / 199917 and 15 / 199933, which are incorporated by reference in their entireties. In some examples, one or more trust commands may be initiated on one or more target devices (e.g., user device and / or merchant device). The trust commands include various levels of specificity and granularity, such as hashing portions of the software code, scanning the payment entity's memory, checking for jailbreaks in the software code, collecting metadata of mounted file systems, etc. The trust commands may be based on reliably measured data, or test criteria collected across a population of payment platforms, or pre-set values ​​determined by security experts. After incorporation of the trust routines, the service may assign the user device and / or merchant device as a trusted device for a pre-defined period of time. In various examples, the service may assign attestation tickets to the trusted devices for future interactions. In such instances, upon expiration of the period of time, the attestation routine may be reinitialized and re-run to attest the trusted device. Thus, the trusted device may be used to securely transfer transaction data, payment instrument data, and / or verification data between a transaction server and user devices and / or merchant devices to perform secure transactions and reduce instances of fraud.

[0051] In yet another embodiment, the ECR 126 may be deployed on the COTS device 102 as a separate application utilizing the card reader library as a separate application. In these examples, the ECR 126 may be responsible for performing the default PIN addition process. Again, this embodiment allows for a smaller attack surface for the payment kernel and improves spatial separation of the processes performed between the POS application 124 and the ECR application 126. Another advantage of this embodiment is that the NFC communication is isolated from the POS application 124, since the ECR application 126 handles many of the operations that would have been performed on the POS application 124. Because an intermediate application 128 is utilized in this embodiment, two trusted applications 132 may be utilized, as described above.

[0052] In yet another example, data encryption may be utilized on the COTS device 102 such that decryption of at least the PAN data, and in some examples the PIN data, is performed on the COTS device 102, and the payment processing service 106 is utilized to identify the PAN data and / or PIN data from the encrypted data transmitted to the payment processing service 106. For example, an encryption API may be utilized to encrypt the PAN data read from the NFC component 122. The COTS device 102 may not 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 transmit the encrypted data to the payment processing service 106. The payment processing service 106 may manage the keys and / or other decryption mechanisms and may decrypt the encrypted data to identify the PAN data and / or PIN data. The encrypted data may be described as encrypted EMV data when an EMV protocol is utilized to obtain the 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 of the EMV parser utilized during processing. EMV kernel 144 may parse the EMV data to identify the PAN data, as described herein.

[0053] In yet another example, data encryption may be utilized on the COTS device 102 such that decryption of at least the PAN data, and in some examples the PIN data, is performed on the COTS device 102, and the payment processing service 106 is utilized to identify the PAN data and / or PIN data from the encrypted data transmitted to the payment processing service 106. For example, an encryption API may be utilized to encrypt the PAN data read from the NFC component 102. The COTS device 102 may not include the keys or other decryption mechanisms necessary to decrypt the encrypted data. In this example, instead of the encrypted data being transmitted to the POS application 102, the encrypted data is transmitted to a vendor data center 154, which may be operated by the OEM of the COTS device 102. The OEM may have the 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 for the PAN data and / or for an encrypted version of the PAN data that may be decrypted by the payment processing service 106 to complete the transaction. In this example, the POS application 124 simply receives indications of the status of the payment from other components of the COTS device 102 and / or from the payment processing service 106, but the PAN data is spatially separated from the POS application 124 at all times during a transaction.

[0054] In yet another example, the TEE 136 may be utilized 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 the TEE 136, which may be isolated from other components of the COTS device 102. The TEE 136 may provide more security than the POS application 124 in that it limits access to the TEE 136 without proper authorization. In this example, the 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 a payment transaction indication may be sent from the payment processing service 106 to the POS application 124 to indicate whether the payment is authorized. In this manner, the POS application 124 may not have access to the PAN data and may instead 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 herein, spatial and / or temporal separation of PAN data from other data utilized for a transaction, such as PIN data, promotes security of the transaction and makes it difficult to obtain unauthorized access to all the information necessary to illicitly utilize the payment instrument. These techniques are inherent to the computer-centric problem of dealing with digital transactions on COTS devices 102, where such devices may be compromised and unauthorized access may occur. These techniques are also inherent to computer-centric solutions utilizing 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 a matter of seconds) between when a transaction is initiated and when it is completed, minimizing delays in the payment process.

[0056] In at least one example, the operations performed by the payment processing service may leverage a multi-party merchant ecosystem. That is, in some examples, the payment processing service (e.g., a server associated therewith) may communicate with end users (e.g., customers and / or merchants) via individual user computing devices and over one or more networks. Such a remote, networked, multi-party merchant ecosystem may enable the payment processing service to access data associated with multiple different merchants and / or customers and to use such data to enhance ECR security in real-time or near real-time in some examples. Having a payment processing service, which may have access to multiple disparate merchants and multiple disparate platforms, perform processes associated with the processes described herein may enable 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 in the context where a user has provided consent for such exchange of information. For example, upon device setup and / or application initiation, a user may be provided with an opportunity to opt-in and / or opt-out of data exchange between devices and / or performance of functions described herein. Additionally, in the case where one of the devices is associated with a first user account and another one of the devices is associated with a second user account, user consent may be obtained prior to performing some, any, or all of the operations and / or processes described herein. Additionally, operations performed by components of the system described herein may only be performed in the context where a user has provided consent for the operations to be performed.

[0058] In addition, the model 148 may be trained based on the transaction information and / or other information associated with the payment transaction. For example, transaction information of transactions performed between multiple merchants and multiple buyers may be received at the payment processing service 106. The information may be received from a merchant computing device associated with the merchant. In these examples, the merchant computing devices may have separate instances of a merchant application installed to configure each merchant computing device as a point of sale (POS) terminal. The separate instances of the merchant application may configure the POS terminal to communicate the transaction information to the payment processing service 106 over one or more networks. In some examples, the POS terminal may be an online terminal. Using the transaction information, the payment processing service 106 may generate a profile using a model trained using at least one of the merchant information, the buyer information, and / or the 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 the multimedia interface. The methods and systems may be integrated with "wake words" to invoke those respective voice services, e-commerce, and fulfillment channels. For example, speaker recognition technology may be utilized to determine a user profile associated with a user providing a user utterance to a user device to perform one or more of the operations described herein. The determined user profile may be utilized to customize the security protocols described herein. Additionally, the voice interface may be associated with an online platform, which may be utilized to fulfill merchant commands as described herein.

[0060] FIG. 1B illustrates a conceptual diagram of components utilized to implement the SPoC and ECR techniques. FIG. 1B is utilized herein to provide an exemplary process flow of a PIN transaction in a software-based PIN entry solution. As illustrated in FIG. 1B, there may be a COTS device, such as a merchant device 102, which may include an installed PIN Cardholder Verification Method (CVM) application, such as a POS application 124 and / or a PIN application 134. The COTS device may be associated with a PIN pad entry screen, an attestation component, and a secure session component. In addition, there may be a Secure Card Reader-PIN (SCRP). The SCRP may include a physical card reader, such as a reader device 175, and may include PCRs that have been evaluated to be compliant. In examples, the SCRP may be coupled to the merchant device via a wired or wireless connection, such as via Bluetooth, BLE, or the like. Additional details are provided below with reference to FIG. 15 and FIG. 16. In some examples, the SCRP may read information from a payment instrument. In some examples, the SCRP 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 examples, there may be multiple POS devices connected to multiple other devices, such as "secondary" terminals, e.g., back-of-the-house systems, printers, line buster devices, POS readers, etc., to allow information from the secondary terminals to be shared between the primary POS terminal and the secondary terminals, e.g., via short-range communication techniques. In examples, the card reader library and / or intermediate application described herein may be configured to assist in establishing and / or facilitating the secure exchange of data between the SCRP and the POS application 124 and / or ECR 126.

[0061] The SCRP may include components utilized for PIN conversion and for obtaining PAN data and tracking equivalent data encryption. A buyer device and / or payment instrument may also be present to perform the SPoC techniques described herein. In addition to or instead of the SCRP, an ECR, such as ECR 126, may be present. The ECR may not be a separate physical card reader, such as the SCRP, but may instead include components that are embedded in the COTS device. The ECR may be configured to encrypt PAN data and oversee data encryption associated with the payment. In an 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, such as POS application 124, and / or other components of the COTS device.

[0062] One or more devices and / or systems may be capable of communicating with the COTS device and may include a supervisory attestation component, an instance of a PIN CVM application, a COTS component, an SCRP component, an attestation component, and / or other components that may be used for PIN CVM application key management and / or attestation. 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, key management processes may be performed similar to PIN transaction security hardware security module (HSM) security requirements. In addition to this, payment processing processes may also be performed as described herein. In cases where an ECR is used as opposed to an SCRP, a 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, a key may be used for PIN and / or PAN encryption.

[0063] Utilizing some or all of the components described herein, the following SPoC technique may be implemented to utilize a software PIN to secure and / or authorize a transaction. First, the PIN CVM application on the COTS device and the SCRP may be initialized with a key. This process may be asynchronous to the pending transaction. A secure communication channel between the PIN CVM application and the backend monitoring system may then be established. To do this, the secure session component of the COTS device and the secure session component of the other device may communicate to establish a secure session.

[0064] The backend monitoring system may then utilize the attestation 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 applications may communicate to determine the security status of the devices and components and attestation may be performed. Attestation may include operations between a verifier, which may be server-based, and a prover, which may be client-based, to determine the current security state / behavior of the prover based on predefined measurements and thresholds provided by the prover.

[0065] A payment card and / or other device capable of transmitting card data, such as a buyer device, may then 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 by the PIN CVM application to the SCRP. The SCRP may encrypt the PAN data using a preloaded data encryption key using an online PIN verification or offline PIN verification process. The payment transaction may then be processed using the payment processing components described herein.

[0066] Alternatively, a payment card and / or other device capable of transmitting card data, such as a buyer device, may be presented to the ECR to collect SCRP data. For example, the 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 a process that causes the reader to obtain data from the payment instrument. For example, the ECR may generate and / or utilize a stored APDU command and send it to the POS application so that the POS application and the NFC component may communicate directly to obtain 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 include 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 to enter a PIN is made to collect the account PIN needed to associate with the PAN data. However, in this example, to facilitate temporal separation of the PAN and PIN data on the merchant device, the response to the PIN entry request may not cause the display of a PIN entry user interface or otherwise cause the device to obtain 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 needed to request authorization from the payment processing service for a payment using the payment instrument. Once the PAN data is 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 his or her PIN using the rendered PIN pad from the PIN CVM application.

[0067] In other examples, spatial and / or temporal separation of the PIN and PAN data may not be performed, and instead, an encryption scheme may be utilized to facilitate security of the PIN and PAN data. This encryption-based scheme is described in more detail below with reference to FIG. 2. The PAN data may be obtained using the ECR as described herein. The PIN CVM application PIN entry component may render a PIN entry screen on the COTS platform, and the cardholder may enter his / her PIN using the rendered PIN pad from the PIN CVM application. In these examples, 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 and PAN data may be performed using the same encryption technique.

[0068] In yet another example, the POS application receiving an indication that the payment process is to be initiated may generate a payment initiation request and send it to the intermediate application. This spatial separation of the ECR and the POS application may provide a smaller attack surface for the payment kernel, ensuring that the ECR operates outside of the POS application, which may be the most likely point of attack by a malicious actor. In these examples, multiple trusted applications may be utilized to determine whether the merchant device is still a trusted device at the time of payment. Additional details regarding the use of trusted applications are provided herein, but generally, a trusted application may be utilized to determine whether one or more conditions of the merchant device indicate that the merchant device has been compromised or is otherwise not a trusted device for obtaining PAN and / or PIN data. In examples where an intermediate application is utilized, a trusted application may be utilized to determine whether the POS application has been compromised, and another trusted application may be utilized 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. If an actual PIN is required, the PIN CVM application PIN entry component may render a PIN entry screen on the COTS platform and the cardholder may enter his or her PIN using the rendered PIN pad from the PIN CVM application.

[0069] In yet other examples, the ECR application may perform security operations associated with the payment. In these examples, in addition to using the intermediate application, the intermediate application may send an instance of a payment initiation request to the ECR application. For example, if the trust routine indicates that the intermediate application has not been tampered with, the intermediate application may send an instance of a payment initiation request to the ECR application. The ECR application may 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 an example, the PIN is entered on a touch screen of the COTS device, but in some examples, a buyer device is utilized to enter the PIN, and attestation, monitoring, and other operations associated with the SPoC technology are performed in conjunction with the buyer device.

[0071] Figure 2 illustrates an example process associated with securing payments utilizing an ECR without generating a default personal identification information (PIN). Figure 2 provides a sequence diagram illustrating an example sequence of the process. It should be understood that the sequence provided in Figure 2 is provided by way of example and not by way of limitation, and that some or all of the operations 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 to be purchased by a buyer, and when all of the products the buyer wants to purchase have been added, the merchant may initiate a payment process to satisfy the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate and send a payment initiation request to the ECR 126.

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

[0074] At 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 transmit the read PAN data to one or more components of the merchant device.

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

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

[0077] In block 212, the ECR 126 may send a PIN entry request to the POS application 124. Generally, for PIN-on-glass and SPoC transactions, the request for a PIN is made to capture the account PIN needed to associate with the PAN data.

[0078] In block 214, the POS application 124 may cause a PIN entry dialog to be presented to the buyer. In other embodiments in which 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 herein. For example, a user interface of the merchant device may display a PIN entry dialog, such as a PIN pad configured to accept user input corresponding to the account PIN. In SPoC embodiments, the merchant device may query one or more devices to receive a software PIN, as described more fully herein.

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

[0080] At block 218, the POS application 124 may perform encryption of the PIN data and the PAN data. In an example, the encryption of the PIN data may be performed using one encryption technique and / or a first encryption credential (e.g., a key) and the encryption of the PAN data may be performed using a different encryption technique and / or a second encryption credential. In another example, the 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 reimbursement request to the payment processing service 106. The reimbursement request may include an identifier of the pending payment, the PAN data, which may be encrypted in certain instances, and the account PIN.

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

[0083] In block 224, the issuer may return an authorization response that may indicate whether the payment instrument was accepted or rejected to satisfy the payment. In examples, the authorization response may not include the 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 reimbursement response to the POS application 124. The reimbursement response may indicate to the POS application 124 that the reimbursement request was received but that the account PIN is still required.

[0085] In block 228, the POS application 124 may send a charge completion request to the payment processing service 106. For example, if the issuer authorizes the use of the payment instrument to satisfy the payment, the POS application 124 may generate a charge completion request indicating that the requirements to complete the payment have been met and that any outstanding charges associated with the payment are completed. The payment processing service 106 may utilize the charge completion request to update the system to indicate that the status of the payment is complete.

[0086]

[0023] Figure 3 illustrates an example process 300 associated with securing payments using an ECR, where a POS application communicates directly with the ECR. Figure 3 provides a sequence diagram illustrating an example sequence of the process. It should be understood that the sequence provided in Figure 3 is provided by way of example and not by way of limitation, and that some or all of the operations 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 to be purchased by a buyer, and when all of the products the buyer wants to purchase have been added, the merchant may initiate a payment process to satisfy the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate and send a payment initiation request to the ECR 126.

[0088] At block 304, the ECR 126 may send an Application Protocol Data Unit (APDU) command to the POS application 124. The APDU command may initiate a process that causes the reader to obtain data from the payment instrument. For example, the ECR 126 may generate and / or utilize a stored APDU command and send the command to the POS application 124 such that the POS application 124 and the NFC component 122 may communicate directly to obtain the PAN associated with the buyer's payment instrument.

[0089] At 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 transmit the read PAN data to one or more components of the merchant device.

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

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

[0092] In block 312, the ECR 126 may send a PIN entry request to the POS application 124. Typically, for PIN-on-glass and SPoC transactions, the request for a PIN is made to collect the account PIN needed to associate with the PAN data. However, here, to facilitate temporal separation of the PAN and PIN data on the merchant device, the response to the PIN entry request may not cause the display of a PIN entry user interface or otherwise cause the device to obtain 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 numeric, alphabetic, and / or alphanumeric code that is predefined to be a default code to satisfy the requirement that the PAN data include a PIN when sent to the payment processing service 106. However, because the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be utilized to complete the transaction.

[0094] At block 316, the ECR 126 may send an authorization request to the POS application 124. At this point, the POS application 124 may have all the data needed to request authorization from the payment processing service 106 for a payment using the payment instrument. In addition, the data needed to satisfy the requirements of the ECR 126 to proceed with the payment process may also be satisfied.

[0095] At block 318, the POS application 124 may send a reimbursement request to the payment processing service 106. The reimbursement request may include an identifier of the outstanding payment, the PAN data, which may be encrypted in certain examples, and the default PIN. The payment processing service 106 may receive the reimbursement request and identify the included PIN as the default PIN. Based at least in part on the reimbursement request including the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. Although one default PIN is described, it should be understood that the default PIN may be dynamic, e.g., changing over time and / or based on characteristics of the merchant, the buyer, the transaction, and / or any other factors associated with the payment. At this point, the POS application 124 may remove the PAN data from the merchant device such that the PAN data is not present 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 reimbursement response to the POS application 124. The reimbursement response may indicate to the POS application 124 that the reimbursement request was received but that the account PIN is still required.

[0097] In block 322, the POS application 124 may cause a PIN entry dialog to be presented to the buyer. In other embodiments in which 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 herein. For example, a user interface of the merchant device may display a PIN entry dialog, such as a PIN pad configured to accept user input corresponding to the account PIN. In SPoC embodiments, the merchant device may query one or more devices to receive a software PIN, as described more fully herein.

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

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

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

[0101] In block 330, the issuer may return an authorization response that may indicate whether the payment instrument to satisfy the payment was accepted or rejected. In examples, the authorization response may not include the 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 an add PIN response to the POS application 124. The add PIN response may be in response to the add PIN request described above and may indicate that the payment instrument has been approved or rejected to satisfy the payment.

[0103] In block 334, the POS application 124 may send a charge completion request to the payment processing service 106. For example, if the issuer authorizes the use of the payment instrument to satisfy the payment, the POS application 124 may generate a charge completion request indicating that the requirements to complete the payment have been met and that any outstanding charges associated with the payment are completed. The payment processing service 106 may utilize the charge completion request to update the system to indicate that the status of the payment is complete.

[0104] Figure 4 illustrates an example process 400 associated with securing a payment utilizing an intermediary application configured to communicate with the POS application 124 and the ECR 126. Figure 4 provides a sequence diagram illustrating an example sequence of the process. It should be understood that the sequence provided in Figure 4 is provided by way of example and not by way of limitation, and that some or all of the operations 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 intermediary application 128, sometimes described herein as a card reader library application. For example, the merchant may add products to a transaction to be purchased by the buyer, and when all of the products the buyer wants to purchase have been added, the merchant may initiate a payment process to satisfy the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate and send a payment initiation request to the intermediary application 128. This spatial separation of the ECR 126 and the POS application 124 may provide 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 point of attack by a malicious actor. In these examples, multiple trusted applications may be utilized to determine whether the merchant device is still a trusted device at the time of payment. Additional details regarding the use of the trust application are provided herein, but in general, the trust application may be utilized to determine whether one or more conditions of the merchant device indicate that the merchant device has been compromised or is otherwise not a trusted device for obtaining PAN and / or PIN data. In instances where an intermediate application 128 is utilized, a trust application may be utilized to determine whether the POS application 124 has been compromised, or another trust application may be utilized to determine whether the intermediate application 128 has been compromised. In these instances, the POS application 124 may still perform the default PIN addition process described above.

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

[0107] At block 406, the ECR 126 may send an APDU command to the intermediary application 128. The APDU command may initiate a process that causes the reader to obtain data from the payment instrument. For example, the ECR 126 may generate and / or utilize a stored APDU command and send the command to the intermediary application 128 to be sent to the POS application 124.

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

[0109] At block 410, the POS application 124 may send an 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 transmit the read PAN data to one or more components of the merchant device.

[0110] At block 412, the NFC component 122 may send an APDU response to the POS application 124. The APDU response may include the PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining the 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 the instance of the APDU response to the intermediate application 128 rather than directly to the ECR 126 in order to maintain spatial separation for 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, the intermediate application 128 may send an instance of the APDU response to the ECR 126 if the trust routine indicates that the intermediate application 128 has not been tampered with.

[0113] In block 418, the ECR 126 may send a PIN entry request to the intermediary application 128. Typically, for PIN-on-glass and SPoC transactions, the request for a PIN is made to gather the account PIN needed to associate with the PAN data. However, here, to facilitate temporal separation of the PAN and PIN data on the merchant device, the response to the PIN entry request may not cause the display of a PIN entry user interface or otherwise cause the device to obtain the PIN data.

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

[0115] In block 422, the POS application may generate a default PIN and send the default PIN to the intermediary application 128. The default PIN may be any numeric, alphabetic, and / or alphanumeric code that is predetermined to be a default code to satisfy the requirement that the PAN data include a PIN when sent to the payment processing service 106. However, because the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be utilized to complete the transaction.

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

[0117] At block 426, the ECR 126 may generate and send an authorization request to the intermediary application 128. The authorization request may indicate that the data required to satisfy the requirements of the ECR 126 to proceed with the payment process has been met.

[0118] At block 428, the intermediary 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 tampered with, the intermediary 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 needed to request authorization from the payment processing service 106 for a payment using the payment instrument.

[0119] At block 430, the POS application 124 may send a reimbursement request to the payment processing service 106. The reimbursement request may include an identifier of the outstanding payment, the PAN data, which may be encrypted in certain examples, and the default PIN. The payment processing service 106 may receive the reimbursement request and identify the included PIN as the default PIN. Based at least in part on the reimbursement request including the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. Although one default PIN is described, it should be understood that the default PIN may be dynamic, e.g., changing over time and / or based on characteristics of the merchant, the buyer, the transaction, and / or any other factors associated with the payment. At this point, the POS application 124 may remove the PAN data from the merchant device such that the PAN data is not present 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 reimbursement response to the POS application 124. The reimbursement response may indicate to the POS application 124 that the reimbursement request was received but that the account PIN is still required.

[0121] In block 434, the POS application 124 may cause a PIN entry dialog to be presented to the buyer. In other embodiments in which 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 herein. For example, a user interface of the merchant device may display a PIN entry dialog, such as a PIN pad configured to accept user input corresponding to the account PIN. In SPoC embodiments, the merchant device may query one or more devices to receive a software PIN, as described more fully herein.

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

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

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

[0125] In block 442, the issuer may return an authorization response that may indicate whether the payment instrument was accepted or rejected to satisfy the payment. In examples, the authorization response may not include the 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 an add PIN response to the POS application 124. The add PIN response may be in response to the add PIN request described above and may indicate that the payment instrument has been approved or rejected to satisfy the payment.

[0127] In block 446, the POS application 124 may send a charge completion request to the payment processing service 106. For example, if the issuer authorizes the use of the payment instrument to satisfy the payment, the POS application 124 may generate a charge completion request indicating that the requirements to complete the payment have been met and that any outstanding charges associated with the payment are completed. The payment processing service 106 may utilize the charge completion request to update the system to indicate that the status of the payment is completed.

[0128] Figure 5 illustrates an example process 500 associated with securing a payment using an ECR, where an ECR application performs security operations associated with the payment. Figure 5 provides a sequence diagram illustrating an example sequence of the process. It should be understood that the sequence provided in Figure 5 is provided by way of example and not by way of limitation, and that some or all of the operations 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 intermediary application 128, sometimes described herein as a card reader library. For example, the merchant may add products to a transaction to be purchased by the buyer, and when all of the products the buyer wants to purchase have been added, the merchant may initiate a payment process to satisfy the payment for the products. Upon receiving an indication that the payment process is to be initiated, the POS application 124 may generate and send a payment initiation request to the intermediary application 128. This spatial separation of the ECR application 126 and the POS application 124 may provide 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 by a malicious actor. In these examples, multiple trusted applications may be utilized to determine whether the merchant device is still a trusted device at the time of payment. Additional details regarding the use of the trust application are provided herein, but in general, the trust application may be utilized to determine whether one or more conditions of the merchant device indicate that the merchant device has been compromised or is otherwise not a trusted device for obtaining PAN and / or PIN data. In instances where an intermediate application 128 is utilized, a trust application may be utilized to determine whether the POS application 124 has been compromised, or another trust application may be utilized to determine whether the intermediate application 128 has been compromised. In these instances, the POS application 124 may still perform the default PIN addition process described above.

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

[0131] In block 506, the ECR application 126 may send an APDU command to the NFC component 122. The APDU command may initiate a process that causes the reader to obtain data from the payment instrument. 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] At block 508, the NFC component 122 may send an APDU response to the ECR application 126. The APDU response may include the PAN data read from the payment instrument. The APDU response may also include other information associated with obtaining the 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 initiation of such process by the POS application 124. For example, instead of querying the POS application 124 to initiate the PIN entry process in the example of FIG.

[0134] In block 512, the ECR application 126 may generate a default PIN. The default PIN may be any numeric, alphabetic, and / or alphanumeric code that is predefined to be a default code to satisfy the requirement that the PAN data contain a PIN when transmitted to the payment processing service 106. However, because the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be utilized to complete a transaction.

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

[0136] At block 516, the intermediary 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 tampered with, the intermediary 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 needed to request authorization from the payment processing service 106 for a payment using the payment instrument.

[0137] At block 518, the POS application 124 may send a reimbursement request to the payment processing service 106. The reimbursement request may include an identifier of the outstanding payment, the PAN data, which may be encrypted in certain examples, and the default PIN. The payment processing service 106 may receive the reimbursement request and identify the included PIN as the default PIN. Based at least in part on the reimbursement request including the default PIN, the payment processing service 106 may determine whether the received default PIN corresponds to a predefined default PIN. Although one default PIN is described, it should be understood that the default PIN may be dynamic, e.g., changing over time and / or based on characteristics of the merchant, the buyer, the transaction, and / or any other factors associated with the payment. At this point, the POS application 124 may remove the PAN data from the merchant device such that the PAN data is not present on the merchant device before the account PIN is provided to the merchant device.

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

[0139] In block 522, the POS application 124 may cause a PIN entry dialog to be presented to the buyer. In other embodiments in which 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 herein. For example, a user interface of the merchant device may display a PIN entry dialog, such as a PIN pad configured to accept user input corresponding to the account PIN. In SPoC embodiments, the merchant device may query one or more devices to receive a software PIN, as described more fully herein.

[0140] At block 524, user input data representing an account PIN and / or software PIN may be received at the POS application 124. At this point, the POS application 124 may associate and store the account PIN and / or software PIN, but the PAN data has not been stored, assuming the PAN data was previously removed from the merchant device as described above.

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

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

[0143] At block 530, the issuer may return an authorization response that may indicate whether the payment instrument to satisfy the payment was accepted or rejected. In examples, the authorization response may not include the PAN data and / or account PIN, but instead may include an indication of payment acceptance or rejection.

[0144] At block 532, the payment processing service 106 may send an add PIN response to the POS application 124. The add PIN response may be in response to the add PIN request described above and may indicate that the payment instrument has been approved or rejected to satisfy the payment.

[0145] In block 534, the POS application 124 may send a charge completion request to the payment processing service 106. For example, if the issuer authorizes the use of the payment instrument to satisfy the payment, the POS application 124 may generate a charge completion request indicating that the requirements to complete the payment have been met and that any outstanding charges associated with the payment are completed. The payment processing service 106 may utilize the charge completion request to update the system to indicate that the status of the payment is completed.

[0146] FIG. 6 illustrates a conceptual diagram of example components utilized to secure payments, where the processes associated with obtaining the PAN and PIN are separated. For example, the merchant device 102 shown in FIG. 6 may be a COTS device for performing a transaction. These devices may be utilized to install one or more applications that allow the COTS device to be utilized to obtain PAN data and / or other information to satisfy a payment. To do so, the NFC components of the COTS device may be utilized by one or more applications on the device to read PAN data from the payment instrument, which may utilize the PAN data to complete the transaction. In some examples, COTS devices and other devices may be configured to obtain PIN data to authorize a transaction, in addition to obtaining PAN data. The requirement for PIN data may add a layer of security to a transaction, since 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" technology, where a PIN pad or other user interface is displayed on the merchant device configured to receive user input representing the PIN. Corresponding PIN data is generated on the merchant device and utilized for comparison to reference PIN data associated with a given payment instrument to complete the payment. Additionally, techniques for obtaining PIN data include SPoC, in which a secure reader PIN, a PIN application, the merchant device, and a back-end monitoring and attestation system are utilized to obtain the PIN data.

[0147] As shown in FIG. 6, the merchant device 102 may communicate with a payment instrument and / or customer device 104 that may store PAN data that may be read by an NFC component of the merchant device 102. In the example of FIG. 6, obtaining the PAN data involves different components than the components involved in obtaining the PIN data. For example, an NFC driver 602 may be stored in a kernel component of the merchant device 102 and may communicate with an NFC daemon 604 stored in association with a system user space. The NFC daemon 604 may communicate between the NFC driver 602 and the POS application 124 to obtain the PAN data as described herein. A 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] Additionally, a screen driver 606 stored in association with the kernel may be configured to cause a screen of the merchant device 102 to display an input means for obtaining PIN data, 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 a 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 the PAN data and the PIN data, but the PAN data may be received at a different component of the POS application 124 than the PIN data. Additionally, the PAN data and the PIN data may not be handled by the same components at the kernel and system levels of the merchant device 102. This may facilitate spatial separation between the PAN and PIN data at the merchant device 102 .

[0149] FIG. 7 illustrates a conceptual diagram of example components utilized to secure payments, where PAN data is handled by an isolated service and a POS application handles PIN data. FIG. 7 may include some of the same components as described in FIG. 6. For example, the merchant device 102 of FIG. 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 FIG. 7, the POS application 124 may include 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 that may store PAN data that may be read by an NFC component of the merchant device 102. In the example of FIG. 7, obtaining the PAN data involves different components than those involved in obtaining the PIN data. For example, the NFC driver 602 may be stored in a kernel component of the merchant device 102 and may communicate with an NFC daemon 604 stored in association with the system user space. The NFC daemon 604 may communicate between 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 the 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] Additionally, a screen driver 606 stored in association with the kernel may be configured to cause a screen of the merchant device 102 to display an input means for obtaining PIN data, 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 entry dialog, as described herein. User input data representing the PIN may be sent from the touch input component 608 to a 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, additional separation of PAN data and PIN data may be achieved at the application level of the merchant device 102.

[0152] Figure 8 illustrates a conceptual diagram of example components utilized to secure payments where processing of EMV data is handled by a payment processing service instead of a merchant device. Figure 8 may include some of the same components as described in Figure 6. For example, the merchant device 102 of 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 the PAN data, the 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 a customer device 104 that may store PAN data that may be read by an NFC component of the merchant device 102. In the example of FIG. 8, an NFC driver 602 may be stored in a kernel component of the merchant device 102 and may communicate with an NFC daemon 604 stored in association with a user space portion of the system. In the example of FIG. 8, an encryption API 802 may be utilized at the kernel level to encrypt the PAN data received from the NFC driver 602. In another example, instead of an encryption API 802 being utilized 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 the keys and / or other decryption means to decrypt the EMV data. Alternatively, the NFC daemon 604 may send the encrypted EMV data to the POS application 124, which may send the encrypted EMV data to the payment processing service 106. When encryption occurs as described in these examples, encryption keys may be utilized, which may be symmetric AES keys that may be generated and sent by the POS application 124. The POS application 124 may derive the encryption keys from one or more public keys sent from the payment processing service 106 to the POS application 124.

[0154] The payment processing service 106 may store associated security keys and / or other decryption means to decrypt EMV data received from the merchant device 102. 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 the PIN data to a reference PIN associated with the payment instrument, and the payment processing service 106 may determine whether use of the payment instrument is authorized to satisfy the outstanding payment. If authorized, the payment processing service 106 may send an indication of authorization to the POS application 124, which may complete the transaction based at least in part on receiving the indication.

[0155] Figure 9 illustrates a conceptual diagram of example components utilized to secure payments, where processing of EMV data is handled by a vendor data center. Figure 9 may include some of the same components as described in Figure 6. For example, the merchant device 102 of 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 the PAN data, the 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 that may store PAN data that may be read by an NFC component of the merchant device 102. In the example of FIG. 9, the NFC driver 602 may be stored in a kernel component of the merchant device 102 and may communicate with an NFC EMV daemon 902 stored in association with a user space portion of the system. In the example of FIG. 9, an encryption API 802 may be utilized 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 utilized at the kernel level, the 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 the keys and / or other decryption means to decrypt the EMV data. Alternatively, the NFC EMV daemon 902 may transmit the encrypted EMV data to a 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 associate and store security keys and / or other decryption means to decrypt EMV data received from the merchant device 102. 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 an indication of the payment status (e.g., the obtained 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 such 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 the appropriate authorization indication to proceed with the transaction.

[0158] FIG. 10 illustrates a conceptual diagram of example components utilized to secure payments using a TEE. The environment of FIG. 10 may include some of the same components described with respect to FIG. 1, including, for example, a customer device 104 and / or a customer payment instrument, a POS application 124, a TEE 136, and / or a payment processing service 106. FIG. 10 illustrates the use of a TEE 136 to facilitate ECR security as described herein. For example, the TEE 136 may be utilized to enhance ECR security on a COTS device. For example, when PAN data is read by an NFC component of a COTS device, the PAN data may be sent to the TEE 136, which may be isolated from other components of the COTS device. The TEE 136 may provide more security than the POS application 124 in that it limits access to the TEE 136 without proper authorization. In this example, the 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 utilize this data to determine whether the payment is authorized, and a payment transaction indication may be sent from the payment processing service 106 to the POS application 124 to indicate whether the payment is authorized. In this manner, the POS application 124 may not 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] The spatial and / or temporal separation of PAN data from other data utilized for a transaction, such as PIN data, by implementing one or more of the techniques described herein, promotes security of the transaction and makes it difficult to obtain unauthorized access to all the information necessary to illicitly utilize the payment instrument. These techniques are inherent to the computer-centric problem of dealing with digital transactions on COTS devices, where such devices may be compromised and unauthorized access may occur. These techniques are also inherent 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 a matter of seconds) between the time a transaction is initiated and the time the transaction is completed, minimizing delays in the payment process.

[0160] 11-14 illustrate a process for embedded card reader security. The processes described herein are illustrated as a collection of blocks in a logical flow diagram, which represent a sequence of operations, some or all of which may be implemented in hardware, software, or a combination thereof. In the context of software, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, programs the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the blocks are described should not be construed as a limitation unless otherwise noted. Any number of the described blocks may be combined in any order and / or in parallel to implement a process, or alternative processes, and not all of the blocks need be executed. For purposes of explanation, the processes are described with reference to the environments, architectures and systems described in the examples herein, such as those described with respect to Figures 1A-10, 15 and 16, although the processes may be implemented in a wide variety of other environments, architectures and systems.

[0161] 11 illustrates an example process 1100 for ECR security. The order in which 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 implement the process 1100.

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

[0163] At block 1104, process 1100 may include sending a request to initiate a payment from the POS application to the NFC reader. 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 obtain 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 may communicate directly to obtain 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] At block 1106, the process 1100 may include receiving, at the POS application, from the NFC reader, a PAN associated with the payment instrument. 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 the data from the payment instrument, such as encryption related data when encryption is utilized. The POS application may send the 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 the payment process may proceed.

[0165] At block 1108, the process 1100 may include transmitting the PAN, the default PIN, and an identifier of the transaction associated with the payment from the POS application to the payment processing service. For example, the POS application may transmit the default PIN to the ECR. The default PIN may be any numeric, alphabetic, and / or alphanumeric code that is predefined to be a default code to satisfy the requirement that the PAN data include a PIN when transmitted to the payment processing service. However, because the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be utilized to complete the transaction. The ECR may transmit an authorization request to the POS application. At this point, the POS application may have all the data required to request authorization from the payment processing service for the payment using the payment instrument. In addition, the data required to satisfy the requirements of the ECR to proceed with the payment process may also be satisfied. The POS application may transmit a reimbursement request to the payment processing service. The reimbursement request may include an identifier of the outstanding payment, the PAN data, which may be encrypted in certain instances, and the default PIN. The payment processing service may receive the reimbursement request and identify the included PIN as the default PIN. Based at least in part on the reimbursement request that includes the default PIN, the payment processing service may determine whether the received default PIN corresponds to a predefined default PIN. Although one default PIN is described, it should be understood that the default PIN may be dynamic, e.g., changing over time and / or based on characteristics of the merchant, the buyer, the transaction, and / or any other factors associated with the payment.

[0166] At block 1110, process 1100 may include removing the PAN from the mobile device, by the POS application, (i) after transmitting the PAN to the payment processing service and (ii) before requesting the account PIN associated with the payment instrument. For example, to facilitate temporal separation of the PAN and PIN on the merchant device, the PAN may be removed from the POS application and / or from the merchant device altogether.

[0167] At block 1112, the 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 in which SPoC is utilized, the POS application may query one or more devices, such as the buyer device, for a software PIN, as described more fully herein. For example, a user interface of the merchant device may display a PIN entry dialog, such as a PIN pad configured to accept user input corresponding to the account PIN. In SPoC embodiments, the merchant device may query one or more devices to receive a software PIN, as described more fully herein.

[0168] At block 1114, process 1100 may include receiving an account PIN using a touch screen input of the mobile device. For example, user input data representing the account PIN and / or software PIN may be received at the POS application. At this point, the POS application may associate and store the account PIN and / or software PIN, but the PAN data has not been stored, assuming the PAN data was previously removed from the merchant device as described above.

[0169] At block 1116, process 1100 may include transmitting the account PIN and the identifier of the transaction to a payment processing service. For example, the POS application may transmit the account PIN, whether in an encrypted format or not, to the payment processing service in response to the payment processing service requesting the account PIN.

[0170] At block 1118, process 1100 may include completing the payment based on receiving an indication that the account PIN was accepted. For example, the payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with the payment instrument, and that the payment instrument is otherwise authorized to satisfy the payment.

[0171] Additionally or alternatively, process 1100 may include sending a request 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, at the POS application, the PAN from the intermediate application.

[0172] Additionally or alternatively, process 1100 may include receiving, at the POS application, from an NFC reader, EMV data associated with the payment instrument, where the EMV data is unencrypted by the NFC reader. Process 1100 may also include determining, by the POS application, the PAN utilizing the EMV data.

[0173] Additionally or alternatively, process 1100 may include receiving, at the POS application, from an NFC reader, EMV data associated with the payment instrument, where the EMV data has been encrypted by the NFC reader. Process 1100 may also include decrypting, by the POS application, the EMV data, such that decrypted EMV data is generated. Process 1100 may also include determining, by the POS application, the PAN utilizing the decrypted EMV data.

[0174] Additionally or alternatively, process 1100 may include encrypting the PAN as EMV data when received at the POS application and transmitting the EMV data to a payment processing service. Process 1100 may also include completing the payment based at least in part on the PAN and the account PIN being accepted when decrypted at the payment processing service.

[0175] Additionally or alternatively, process 1100 may include encrypting the PAN as EMV data configured to be decrypted by an 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 a payment processing service. Process 1100 may also include completing the payment based at least in part on the OEM accepting the decrypted PAN and account PIN.

[0176] Additionally or alternatively, process 1100 may include receiving, at the TEE, EMV data including an encrypted version of the PAN. Process 1100 may also include decrypting, at the TEE, the EMV data such that the PAN is identified. In these examples, completing the payment may include completing the payment using the decrypted PAN at the TEE.

[0177] Additionally or alternatively, process 1100 may include a trust routine being executed in association with the device prior to receiving the PAN, the trust routine being configured to determine whether the device has been tampered with in a manner that indicates 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 by the POS application in response to the trust routine indicating that the device has not been tampered with.

[0178] 12 illustrates another example process 1200 for ECR security. The order in which 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 implement the process 1200.

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

[0180] At block 1204, process 1200 may include sending a request to initiate a 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 tampered with, 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 obtain data from the payment instrument. For example, the ECR may generate and / or utilize a stored APDU command and send the command to the intermediate application to 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 tampered with, 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 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 transmit the read PAN data to one or more components of the merchant device.

[0181] At block 1206, process 1200 may include receiving, at the POS application, from the intermediary application, a PAN associated with the payment instrument. For example, 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 the data from the payment instrument, such as encryption related data when encryption is utilized.

[0182] At block 1208, process 1200 may include transmitting the PAN and the default PIN from the POS application to the payment processing service. For example, the POS application may transmit the default PIN to the ECR. The default PIN may be any numeric, alphabetic, and / or alphanumeric code that is predefined to be a default code to satisfy the requirement that the PAN data include a PIN when transmitted to the payment processing service. However, because the PIN is not the actual account PIN associated with the payment instrument, the default PIN cannot be utilized to complete the transaction. The ECR may transmit an authorization request to the POS application. At this point, the POS application may have all the data required to request authorization from the payment processing service for a payment utilizing the payment instrument. In addition, the data required to satisfy the requirements of the ECR to proceed with the payment process may also be satisfied. The POS application may transmit a reimbursement request to the payment processing service. The reimbursement request may include an identifier of the outstanding payment, the PAN data, which may be encrypted in certain instances, and the default PIN. The payment processing service may receive the reimbursement request and identify the included PIN as the default PIN. Based at least in part on the reimbursement request that includes the default PIN, the payment processing service may determine whether the received default PIN corresponds to a predefined default PIN. Although one default PIN is described, it should be understood that the default PIN may be dynamic, e.g., changing over time and / or based on characteristics of the merchant, the buyer, the transaction, and / or any other factors associated with the payment.

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

[0184] At block 1212, process 1200 may include receiving an account PIN using a touch screen input of the mobile device. For example, user input data representing the account PIN and / or software PIN may be received at the POS application. At this point, the POS application may associate and store the account PIN and / or software PIN, but the PAN data has not been stored, assuming the PAN data was previously removed from the merchant device as described above.

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

[0186] Additionally or alternatively, process 1200 may include encrypting the PAN as EMV data when received at the POS application. Process 1200 may also include transmitting the EMV data to a payment processing service. Process 1200 may also include completing the payment based at least in part on the PAN and the account PIN being accepted when decrypted at the payment processing service.

[0187] Additionally or alternatively, process 1200 may include the PAN being encrypted as EMV data configured to be decrypted by an 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 a payment processing service. Process 1200 may also include completing the payment based at least in part on the PAN as decrypted by the OEM and the account PIN being accepted.

[0188] Additionally or alternatively, process 1200 may include receiving, at a TEE of the mobile device, EMV data including an encrypted version of the PAN. Process 1200 may also include decrypting, at the TEE, the EMV data such that the PAN is identified. In these examples, completing the payment may be performed at the TEE using the decrypted PAN.

[0189] Additionally or alternatively, process 1200 may include a trust routine being executed in association with the mobile device prior to 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] Additionally or alternatively, process 1200 may include sending a request to initiate a payment from the POS application to an intermediate application that causes the embedded card reader application to query the NFC reader for the PAN. Process 1200 may also include receiving the PAN from the intermediate application, including the intermediate application receiving the PAN from the embedded card reader application and sending the PAN to the POS application.

[0191] Additionally or alternatively, process 1200 may include receiving, at the POS application, from an NFC reader, EMV data associated with the payment instrument, where the EMV data is unencrypted by the NFC reader. Process 1200 may also include determining, by the POS application, the PAN utilizing the EMV data.

[0192] Additionally or alternatively, process 1200 may include receiving, at the POS application, from an NFC reader, EMV data associated with the payment instrument, where the EMV data has been encrypted by the NFC reader. Process 1200 may also include decrypting, by the POS application, the EMV data, such that decrypted EMV data is generated. Process 1200 may also include determining, by the POS application, the PAN utilizing the decrypted EMV data.

[0193] 13 illustrates an example process 1300 for temporally separating PAN 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 the described operations may be combined in any order and / or in parallel to implement process 1300.

[0194] At block 1302, the process 1300 may include configuring a point of sale (POS) application installed on the mobile device to utilize the mobile device's built-in card reader (ECR). For example, some merchants may not utilize a particular POS device to handle a transaction, but instead, choose to utilize a COTS device to perform the transaction. Exemplary COTS devices include typical mobile devices such as mobile phones (typically smartphones), tablets, and the like. These devices may be utilized to install one or more applications that allow the COTS device to be utilized to obtain PAN data and / or other information to satisfy a payment. To do so, an NFC component of the COTS device may be utilized by one or more applications on the device to read PAN data from the payment instrument, which may utilize the PAN data to complete the transaction. In some examples, COTS devices and other devices may be configured to obtain PIN data to authorize the transaction in addition to obtaining PAN data. The requirement for PIN data may add a layer of security to the transaction, since 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 a PIN. Corresponding PIN data is generated on the merchant device and utilized for comparison to reference PIN data associated with a given payment instrument to complete a payment. Additionally, techniques for obtaining PIN data include SPoC, in which a secure reader PIN, PIN application, merchant device, and back-end monitoring and attestation systems are utilized to obtain the PIN data.

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

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

[0197] At block 1308, process 1300 may include receiving a PAN for the transaction at the POS application. For example, an APDU command may initiate a process that causes the reader to obtain data from the 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 the PAN data from the payment instrument and / or transmit the read PAN data to one or more components of the merchant device.

[0198] At block 1310, process 1300 may include removing the PAN from the mobile device by the POS application prior to requesting the PIN. For example, the PAN may be removed from the POS application and / or from the merchant device altogether to facilitate temporal separation of the PAN and PIN on the merchant device.

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

[0200] At block 1314, process 1300 may include receiving the PIN at the POS application. For example, a touch screen display may be utilized to receive user input representing the PIN, and the PIN data may be received at the POS application.

[0201] At block 1316, process 1300 may include completing the payment based on receiving an indication that the account PIN was accepted. For example, the payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with the payment instrument, and that the payment instrument is otherwise authorized to satisfy the payment.

[0202] Additionally or alternatively, process 1300 may include transmitting the PAN to a payment processing service. In these examples, removing the PAN from the mobile device may be in response to transmitting the PAN to the payment processing service.

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

[0204] Additionally or alternatively, process 1300 may include requesting the account PIN in response to removing the PAN from the mobile device.

[0205] Additionally or alternatively, process 1300 may include executing a trust routine in association with the mobile device after receiving the PAN, the trust routine 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 the account PIN may be in response to the trust routine indicating that the mobile device has not been tampered with.

[0206] Additionally or alternatively, process 1300 may include receiving the PAN in a TEE of the mobile device. Process 1300 may also include receiving the account PIN outside the TEE of the mobile device.

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

[0208] Additionally or alternatively, process 1300 may include transmitting the first encrypted data to a payment processing service. Process 1300 may also include receiving second encrypted data representing the account PIN. Process 1300 may also include transmitting the second encrypted data to a payment processing service.

[0209] Additionally or alternatively, process 1300 may include receiving encrypted data representing the account PIN. Process 1300 may also include transmitting the encrypted data to a payment processing system. Process 1300 may also include receiving an indication from the payment processing system that the account PIN decrypted by the payment processing system is authorized in association with the PAN. In these examples, completing the payment may be based at least in part on the account PIN being authorized in association with the PAN.

[0210] Additionally or alternatively, the processes 1300 may include receiving an account PIN at a second application configured to inhibit communication between the second application and the first application. The processes 1300 may also include transmitting the PAN from the first application to a payment processing service. These processes 1300 may also include transmitting the account PIN from the second application to a payment processing service.

[0211] 14 illustrates an example process 1400 for spatially separating PAN 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 the described operations may be combined in any order and / or in parallel to implement process 1400.

[0212] At block 1402, process 1400 may include configuring a POS application to utilize the ECR. For example, some merchants may not utilize a particular POS device to handle a transaction, but instead, choose to utilize a COTS device to perform the transaction. Exemplary COTS devices include typical mobile devices such as cell phones (typically smartphones), tablets, and the like. These devices may be utilized to install one or more applications that allow the COTS device to be utilized to obtain PAN data and / or other information to satisfy a payment. To do so, the NFC component of the COTS device may be utilized by one or more applications on the device to read PAN data from the payment instrument, which may utilize the PAN data to complete the transaction. In some examples, COTS devices and other devices may be configured to obtain PIN data to authorize the transaction in addition to obtaining PAN data. The requirement for PIN data may add a layer of security to the transaction, since 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 a PIN. Corresponding PIN data is generated on the merchant device and utilized for comparison to reference PIN data associated with a given payment instrument to complete a payment. Additionally, techniques for obtaining PIN data include SPoC, in which a secure reader PIN, PIN application, merchant device, and back-end monitoring and attestation systems are utilized to obtain the PIN data.

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

[0214] At block 1406, process 1400 may include configuring a PIN application to receive the PIN utilizing a touch screen, where the PIN application is configured to inhibit communication with the POS application. For example, 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 the software PIN.

[0215] At block 1408, process 1400 may include receiving a PAN for the transaction at the POS application. For example, an APDU command may initiate a process that causes the reader to obtain data from the 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 the PAN data from the payment instrument and / or transmit the read PAN data to one or more components of the merchant device.

[0216] At block 1410, process 1400 may include requesting a PIN utilizing a touch screen. For example, a PIN may be obtained and attestation and / or validation operations may be performed by a server-side device and / or system. The process for obtaining a PIN may include, for example, monitoring and / or managing platform security status, ensuring PIN security requirements, attestation procedures, and / or key management procedures.

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

[0218] At block 1414, process 1400 may include completing the transaction based on receiving an indication that the account PIN has been accepted in association with the PAN. For example, the payment processing service may provide an indication that the provided account PIN corresponds to an account PIN associated with the payment instrument, and that the payment instrument is otherwise authorized to satisfy the payment.

[0219] Additionally or alternatively, process 1400 may include transmitting the PAN to a payment processing service. Process 1400 may also include removing the PAN from the device in response to transmitting the PAN to the payment processing service.

[0220] Additionally or alternatively, process 1400 may include receiving a request from a payment processing service for the account PIN. Process 1400 may also include removing the PAN from the device in response to receiving the request for the PIN.

[0221] Additionally or alternatively, 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] Additionally or alternatively, process 1400 may include executing a trust routine in association with the device after receiving the PAN, the trust routine 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 the account PIN may be in response to the trust routine indicating that the device has not been tampered with.

[0223] Additionally or alternatively, process 1400 may include receiving the PAN in the TEE of the device. Process 1400 may also include receiving the account PIN outside the TEE of the device.

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

[0225] Additionally or alternatively, process 1400 may include receiving the PAN, including receiving first encrypted data from the ECR that represents the PAN. Process 1400 may also include receiving second encrypted data that represents the account PIN.

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

[0227] Additionally or alternatively, process 1400 may include removing the PAN from the device by the POS application prior to requesting the account PIN.

[0228] FIG. 15 illustrates an exemplary merchant ecosystem for, among other things, supporting the techniques described herein. The environment 1500 includes a server computing device 1502 that may communicate with user devices 1506 (which in some examples may be merchant devices 1508 (individually, 1508(A)-1508(N)) and / or a server computing device 1510 associated with a third-party service provider) via a network 1504. The server computing device 1502 may be associated with a service provider 1512 that may provide one or more services for the benefit of a user 1514, as described below. Actions attributed to the service provider 1512 may be executed by the server computing device 1502.

[0229] In at least one example, the service provider 1512 may correspond to the payment processing service provider described above. In at least one example, the server computing device 1502 may correspond to the server 104 and the network 1504 may correspond to the 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 the server computing device 1510, which is associated with a third-party service provider.

[0230] The environment 1500 may facilitate enhanced security measures associated with embedded card readers as described herein. As noted above, techniques for spatially and / or temporally separating PAN and PIN data on an on-the-shelf device utilized to make a payment may be employed utilizing the system 1500 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 at the device. Other methods include utilizing different applications to handle PAN and PIN data, utilizing an intermediate application in addition to a trusted routine to determine if the merchant device has been compromised, utilizing various encryption methods, processing EMV data at a remote system, etc.

[0231] As discussed above, users of platforms (e.g., websites, applications, and other network-based communication tools offered by service providers) leverage tools for online commerce ("e-commerce"). However, current technology has limitations as discussed above. In some instances, a malicious actor that gains access to a merchant device, particularly a COTS device, may be able to gain access to both PAN and PIN data. The environment 1500 described herein enables a more secure transaction environment while operating within typical transactions and without introducing undue delays to payment processing. Thus, the technology described herein provides an improvement over existing technology.

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

[0233] 1 and other merchant devices 106 may include user devices 1506 as described herein. Similarly, merchants and buyers, as used herein, may include users 1514.

[0234] In at least one example, the users 1514 may include merchants 1516 (individually, 1516(A)-1516(N)). In one example, the merchants 1516 may operate respective merchant devices 1508, which may be user devices 1506 configured for use by the merchants 1516. For purposes of this discussion, a "merchant" may be any entity that offers items (e.g., goods or services) for purchase or other acquisition (e.g., renting, borrowing, negotiating, etc.). The merchants 1516 may offer items for purchase or other acquisition via a real-world store, a mobile store (e.g., a pop-up store, a food truck, etc.), an online store, a combination of the foregoing, etc. In some examples, at least some of the merchants 1516 may be associated with the same entity but may have different merchant locations and / or may have franchise / franchisee relationships. In additional or alternative examples, the merchants 1516 may be different merchants. That is, in at least one example, merchant 1516(A) is a different merchant than merchant 1516(B) and / or merchant 1516(C).

[0235] For purposes of this discussion, "different merchants" may refer to two or more unrelated merchants. Thus, "different merchants" may refer to two or more merchants that are different legal entities (e.g., natural persons and / or corporations) that do not share accounting, employees, branding, etc. As used herein, "different merchants" have different names, employer identification numbers (EINs), (in some instances) lines of business, inventory (or at least a portion thereof), and / or the like. Thus, use of the term "different merchants" does not refer to merchants with different merchant locations or franchise / franchisee relationships. Such merchants with different merchant locations or franchise / franchisee 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 a POS application 1518 stored thereon. The POS application 1518 may configure the merchant device 1508 as a POS terminal, which allows a merchant 1516(A) to interact with one or more buyers 1520. As described above, the users 1514 may include buyers, such as the buyer 1520 shown interacting with the merchant 1516(A). For purposes of this discussion, a "buyer" may be any entity that obtains items from a merchant. Although only two buyers 1520 are shown in FIG. 15, any number of buyers 1520 may interact with the merchant 1516. Additionally, although FIG. 15 shows the buyers 1520 interacting with the merchant 1516(A), the buyers 1520 may interact with any of the merchants 1516.

[0237] In at least one example, an interaction between the buyer 1520 and the merchant 1516 involving an exchange of funds (from the buyer 1520) for an item (from the merchant 1516) may be referred to as a “POS transaction” and / or a “transaction.” In at least one example, the POS application 1518 may determine transaction data associated with the POS transaction. The transaction data may include payment information, user authentication data, purchase amount information, point-of-purchase information (e.g., item purchased, purchase date, purchase time, etc.), which may be obtained from a reader device 1522 associated with the merchant device 1508(A). The POS application 1518 may transmit the transaction data to the server computing device 1502. Additionally, the POS application 1518 may present a UI to enable the merchant 1516(A) to interact with the POS application 1518 and / or the service provider 1512 via the 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 execution of the POS application 1518). In at least one example, the POS terminal may be connected to a reader device 1522 capable of accepting various payment instruments, such as credit cards, debit cards, gift cards, near-field communication-based payment instruments, and the like, 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, a headphone port, an audio jack, a 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, and the like. Additional details are described below with reference to FIG. 16. In some examples, the reader device 1522 may read information from alternative payment instruments, including, but not limited to, wristbands, and the like.

[0239] In some examples, the reader device 1522 may physically interact with a payment instrument such as a magnetic stripe payment card, an EMV payment card, and / or a near field 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). The POS terminal may provide a rich user interface and communicate with the reader device 1522 and with a server computing device 1502, which may provide, among other services, payment processing services. The server computing device 1502, associated with a service provider 1512, may communicate with the server computing device 1510, as described below. In this manner, the POS terminal and the reader device 1522 may collectively process a transaction between the merchant 1516 and the buyer 1520. In some examples, the POS terminal and the reader device may be configured in a one-to-one pairing. In other examples, the POS terminals and reader devices may be configured in a many-to-one pairing (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 "secondary" terminals, e.g., back-of-the-house systems, printers, line buster devices, POS readers, etc., to allow information from the secondary terminals to be shared between the primary POS terminal and the secondary terminals, e.g., via near-field communication technology. This type of configuration may also allow one device (e.g., secondary terminal) to continue to receive user input in an offline-online scenario and function to synchronize data with another device (e.g., primary terminal) if 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 examples, the POS application described herein may be configured to communicate with the reader device 1522 and / or the ECR to receive PAN data from the reader device 1522 and / or the ECR. The card reader library and / or intermediary application described herein may be configured to assist in establishing and / or facilitating secure communications 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 the 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 a display integrated therein for presenting information to the buyer 1520. In additional or alternative examples, the POS terminal may have a display integrated therein for presenting information to the buyer 1520. A POS system, such as the POS system 1524, may be mobile such that the POS terminal and reader device may process transactions at different locations around the world. The POS system may be used to process card present and card not present (CNP) transactions, as described below.

[0242] A card-present transaction is one in which both the buyer 1520 and his or her payment instrument are physically present at the time of the transaction. A card-present transaction may be processed by a swipe, dip, tap, or any other interaction between a physical payment instrument (e.g., a card) or otherwise present payment instrument and the reader device 1522, whereby the reader device 1522 can obtain payment data from the payment instrument. A swipe is a card-present transaction in which the buyer 1520 slides a card or other payment instrument having a magnetic strip through the reader device 1522, which captures the payment data contained on the magnetic strip. A dip is a card-present transaction in which the buyer 1520 first inserts a payment instrument having an embedded microchip (i.e., chip) into the reader device 1522. The dipped payment instrument remains in the payment reader until the reader device 1522 prompts the buyer 1520 to remove the card or other payment instrument. While the payment instrument is in the reader device 1522, the microchip may create a one-time code to be sent from the POS system 1524 to the computing device server 1510 (which may be associated with an acquiring bank, an issuer, and / or a third party service provider offering payment services, including but not limited to a card payment network, such as, for example, Mastercard®, VISA®, etc.) to be matched with an identical one-time code. A tap is a card presence transaction in which a 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) over the reader device 1522 to complete the transaction via short-range communication (e.g., NFC, RFID, Bluetooth®, BLE, etc.). The short-range communication allows the payment instrument to exchange information with the reader device 1522. A tap may be referred to as a contactless payment.

[0243] A CNP transaction is one in which a card or other payment instrument is not physically present at the POS, and as a result, payment data must be manually keyed in (e.g., by the merchant, buyer, etc.) or payment data must be recalled from a card-on-file data store 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 if the transaction is authorized. For example, the POS system 1524 may provide encrypted payment data, user authentication data, purchase amount information, point of purchase information, etc. (collectively, transaction data) to the server computing device 1502 over the network 1504. The server computing device 1502 may transmit the transaction data to the server computing device 1510. As mentioned above, in at least one example, the server computing device 1510 may be associated with a third party service provider that provides payment services, including, but not limited to, an acquiring bank, an issuer, and / or a card payment network (e.g., Mastercard®, VISA®, etc.).

[0245] For purposes of this discussion, a "payment service provider" may 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 a 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. The acquirer (e.g., a server computing device 1510 associated therewith) may send a funds transfer request to a server computing device of the card payment network (e.g., Mastercard®, VISA®, etc.) to determine whether the transaction is authorized or delinquent. In at least one example, the service provider 1512 may act as an acquirer and connect directly to the card payment network.

[0246] The card payment network (e.g., a server computing device 1510 associated therewith) may forward the funds transfer request to an issuing bank (e.g., an “issuer”). An issuer is a bank or financial institution that provides a financial account (e.g., a credit or debit card account) to a user. The issuer may issue a payment card to a user and may pay an acquirer for purchases made by a cardholder to whom the issuing bank issued a payment card. The issuer (e.g., a server computing device 1510 associated therewith) may make a determination as to whether a buyer has the ability to incur associated fees associated with a payment transaction. In at least one example, the service provider 1512 may act as an issuer and / or may be affiliated with an issuer. The transaction is approved or rejected by the issuer and / or the card payment network (e.g., a server computing device 1510 associated therewith), and a payment authorization message is communicated from the issuer to the POS device via the reverse path described above or via an alternative path.

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

[0248] Based on the authorization notification received by the POS system 1524 from the server computing device 1502, the merchant 1516(A) may indicate to the buyer 1520 whether the transaction was approved. In some examples, the authorization may be indicated at the POS system 1524, for example, on a display of the POS system 1524. In other examples, information regarding the approved transaction may be provided to a near-field communication payment instrument, such as a smartphone or watch operating as a near-field communication payment instrument, for presentation via a display of the smartphone or watch. In some examples, additional or alternative information may be further presented along with the approved transaction notification, including, but not limited to, a receipt, special offers, coupons, or loyalty program information.

[0249] As discussed above, the service provider 1512 may provide 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, appointment services, loyalty tracking services, restaurant management services, order management services, fulfillment services, peer-to-peer payment services, onboarding services, identity verification (IDV) services, and the like, among other services. In some examples, the user 1514 may have access to all of the services of the service provider 1512. In other examples, the user 1514 may have tiered access to services, which may be based on risk tolerance, IDV output, subscription, and the like. In at least one example, access to such services may be made available to the merchant 1516 via the POS application 1518. In additional or alternative examples, each service may be associated with its own access point (e.g., an application, a web browser, and the like).

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

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

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

[0253] In at least one example, the service provider 1512 may provide inventory management services. That is, the service provider 1512 may provide inventory tracking and reporting. The inventory management services may enable the merchant 1516(A) to access and manage a database that stores data associated with the quantity of each item available to the merchant 1516(A) (i.e., inventory). Additionally, in at least one example, the service provider 1512 may provide a catalog management service to enable the merchant 1516(A) to maintain a catalog, which may be a database that stores data related to items that are available for acquisition to the merchant 1516(A) (i.e., catalog management services). In at least one example, the catalog may include a plurality of data items, where a data item of the plurality of data items may represent an item that is available for acquisition to the merchant 1561(A). The service provider 1512 may provide recommendations related to pricing of items, placement of items on the catalog, and multi-party fulfillment of inventory.

[0254] In at least one example, the service provider 1512 may provide business banking services that enable a merchant 1516(A) to track deposits (from payment processing and / or other funding sources) to the merchant's 1516(A) account, payroll payments from the account (e.g., payments to employees of the merchant 1516(A)), payments from the account to other merchants either directly or from a linked debit card (e.g., business to business), withdrawals made via scheduled and / or immediate deposits, etc. Additionally, the business banking services enable merchant 1516(A) to obtain customized payment instruments (e.g., credit cards), check how much money they are earning (e.g., via presentation of available earned balance), understand where their money is going (e.g., via deposit reports (which may include fee breakdowns), expense reports, etc.), access / use earned money (e.g., via scheduled deposits, instant deposits, linked payment instruments, etc.), and feel in control of their money (e.g., via managing deposit schedules, deposit speeds, linked instruments, etc.). Additionally, the business banking services enable merchant 1516 to visualize their cash flow to track their financial health, set aside money for upcoming obligations (e.g., savings), organize money according to goals, etc.

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

[0256] In at least one example, the service provider 1512 may provide financial services to provide and / or lend loans to borrowers that, in some examples, may be used to fund the borrower's short-term operational needs (e.g., capital loans). For example, a potential borrower that is a merchant may obtain a capital loan via a capital loan product to finance various operational costs (e.g., rent, payroll, inventory, etc.). In at least one example, the service provider 1512 may offer different types of capital loan products. For example, in at least one example, the service provider 1512 may offer a daily repayment loan product, where the capital loan is repaid daily, e.g., from a portion of transactions processed by the payment processing service on behalf of the borrower. Additionally and / or alternatively, the service provider 1512 may offer a monthly repayment loan product, where the capital loan is repaid monthly, e.g., via debit from a bank account linked to the payment processing service. A merchant's credit risk may be assessed using a risk model that considers factors such as payment amount, the credit risk of similarly situated merchants, past transaction history, seasonality, and credit history.

[0257] Additionally and / or alternatively, the service provider 1512 may, in some examples, provide financing services to provide and / or lend loans to borrowers that are used to fund the borrower's customer purchases (e.g., consumer loans). In at least one example, a borrower may submit a request for a loan to enable the borrower to purchase an item from a merchant, which may be one of the merchants 1516. The service provider 1512 may create the loan based at least in part on determining that the borrower has purchased or is about to purchase an item from the merchant. The loan may be associated with a balance that is 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 through installments, which may be paid through funds managed and / or held by the service provider 1512 (e.g., from payments processed on behalf of the merchant, payments paid to the merchant from funds transferred to the merchant, etc.). The service provider 1512 may offer specific financial products, such as payment instruments, that are specifically 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 terms of the loan. In some instances, a merchant may only use a debit card to make certain purchases. In other instances, "installments" associated with a loan product are credited directly via the payment instrument. Thus, the payment instrument is customized to the loan and / or the parties associated with the loan.

[0258] The service provider 1512 may provide 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, aesthetically pleasing websites. Some of these web page editing applications allow users to build and / or modify web pages (e.g., change, add, or remove content associated with the web page). Additionally, the web development services may create and maintain other online omni-channel presences, such as social media posts, in addition to websites. In some examples, the resulting web pages and / or other content items may be used to offer items for sale via an online / e-commerce platform. 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, the service provider 1512 may recommend and / or create content items to supplement the merchant's 1516 omni-channel presence. That is, if a merchant of merchant 1516 has a web page, service provider 1512 may recommend and / or create additional content items through web development or other services to be presented via other channels such as social media, email, etc.

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

[0260] Additionally, in at least one example, the service provider 1512 may provide workforce management services for managing workforce schedules, and / or may provide appointment services for enabling users 1514 to schedule appointments.

[0261] In some examples, the service provider 1512 may provide restaurant management services to enable the user 1514 to make and / or manage reservations, monitor front-of-house and / or back-of-house operations, etc. In such examples, the merchant device 1508 and / or the server computing device 1502 may be configured to communicate with one or more other computing devices, which may be located in the front-of-house (e.g., a POS device) and / or in the back-of-house (e.g., a kitchen display system (KDS)). In at least one example, the 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, the service provider 1512 can provide a fulfillment service that may use a courier for delivery, and the courier may travel between multiple locations to provide delivery services, photo services, etc. A courier may be a user 1514 that may travel between locations to perform a service (e.g., deliver an item, capture an image, etc.) for a requesting user 1514. In some examples, the courier may receive compensation from the service provider 1512. A courier may use one or more vehicles, such as a car, bicycle, scooter, motorcycle, bus, airplane, helicopter, boat, skateboard, etc. However, in other examples, a courier may travel on foot, or otherwise, without a vehicle. Some examples discussed herein enable people to participate as couriers in a type of crowd-sourced service economy, where essentially any person with a mobile device can quickly become or not be a courier in a courier network that provides the services described herein. In at least one example, a courier may be an unmanned aerial vehicle (e.g., a drone), an autonomous vehicle, or any other type of vehicle capable of receiving instructions to travel between locations. In some examples, the service provider 1512 may receive a request for courier services via a user interface (e.g., an application, web browser, or other access point) presented via each device 1506, automatically assign the request to an active courier, and communicate delivery instructions to the courier.

[0263] In some examples, the 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, the service provider 1512 may leverage other merchants and / or sales channels that are part of the service provider's 1512 platform to fulfill the buyer's order. That is, another merchant may provide one or more items to fulfill the buyer's order. Additionally, in some examples, another sales channel (e.g., online, a brick-and-mortar store, etc.) may be used to fulfill the buyer's order.

[0264] In some examples, the service provider 1512 can enable conversational commerce via a conversational commerce service, which may use one or more machine learning mechanisms to analyze messages exchanged between two or more users 1514, voice inputs to a virtual assistant, etc., to determine the intent of the users 1514. In some examples, the service provider 1512 can use the determined intent to automate buyer services, offer promotions, provide recommendations, or otherwise interact with the buyer in real time. In at least one example, the service provider 1512 can integrate goods and services and payment mechanisms into a communications platform (e.g., messaging, etc.) to enable a buyer to make a purchase or otherwise transact without having to call, email, visit a merchant's web page, or other channel. That is, conversational commerce alleviates the need for a buyer to switch back and forth between a conversation and a web page to gather information and make a purchase.

[0265] In at least one example, the 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, the 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 a user 1514. In one example, an instance of a payment application running on a first device operated by a payer may send a request to the service provider 1512 to transfer an amount of funds (e.g., fiat currency or non-fiat currency such as cryptocurrencies, securities, and related assets) from a payer account to a payee account (e.g., a peer-to-peer payment). The service provider 1512 may facilitate the transfer and may send a notification to an instance of a payment application running on a second mobile device operated by the payee that the transfer is in process (or has been completed). In some examples, the service provider 1512 may send additional or alternative information to an instance of a payment application (e.g., low balance to the payer, current balance to the payer or payee, etc.). In some embodiments, the payer and / or payee may be automatically identified based on, for example, context, proximity, prior transaction history, etc. In other examples, the payee may send a request for funds to the payer before the payer initiates the transfer of funds. The funds to be transferred may be associated with any digital currency type, including, but not limited to, cash, cryptocurrency, etc. In some embodiments, the service provider 1512 funds the request to the payee on behalf of the payer to speed up the transfer process and compensate for any delays that may be due to the payer's financial network.

[0266] In some embodiments, the service provider 1512 may trigger a peer-to-peer payment process via an identification of a “payment proxy” having a particular syntax. For example, the syntax includes a currency indicator prefixed with one or more alphanumeric characters (e.g., $Cash). The currency indicator operates as a tagging mechanism that indicates to the computer system to treat the input as a request from the sender to transfer cash, and detection of the syntax (including one or more alphanumeric characters tagged with the currency indicator) triggers the transfer of cash. The currency indicator may correspond to various currencies, including, but not limited to, dollars ($), euros (Euro symbol), pounds (Pound symbol), rupees (Rupee symbol), yuan (￥), etc. Although 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 particular application running on the user device 1506.

[0267] In some embodiments, the peer-to-peer process may be implemented within a forum context. The term "forum," as used herein, refers to a media channel of a content provider (e.g., a social networking platform, a microblog, a blog, a video sharing platform, a music sharing platform, etc.) that enables user interaction and engagement via comments, posts, messages on an electronic bulletin board, messages on a social networking platform, 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 one another (e.g., through creating messages, posting comments, etc.). In some embodiments, a "forum" may also refer to an application or web page of an e-commerce or retail organization offering goods and / or services. Such a website may provide an online "form" to be completed before or after a product or service is added to a virtual cart. The online form may include one or more fields for receiving user interaction and engagement. 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 a payment proxy instead of other types of payment mechanisms such as credit cards, debit cards, prepaid cards, gift cards, virtual wallets, etc.

[0268] In some embodiments, the peer-to-peer process may be implemented within a communication application context, such as a messaging application context. The term “messaging application,” as used herein, refers to any messaging application that enables communication between users (e.g., senders and recipients of messages) over a wired or wireless communication network through the use of communication messages. The messaging application may be utilized by a service provider 1512. For example, the service provider 1512 may provide a messaging service that provides communication services to users via the messaging application (e.g., chat or messaging capabilities). The messaging application may include, for example, a text messaging application for communication between phones (e.g., traditional cell phones or smartphones), or a cross-platform instant messaging application for smartphones and phones that use the Internet for communication. The messaging application may be executed on a user device 1506 (e.g., a mobile device or a traditional personal computer (PC)) based on instructions sent to or from a server computing device 1502 (which may be referred to as a “messaging server” in such examples). In some examples, the messaging application may include a payment application with messaging capabilities that allows users of the payment application to communicate with one another. In such examples, the payment application may execute on the user device 1506 based on instructions sent to or from the server computing device 1502 (e.g., a payment service discussed herein or another payment service that supports payment transactions).

[0269] In at least some embodiments, the 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 a recipient associated with the personalized location address. The personalized location address that identifies the landing page may include a payment proxy as described above. The 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 that identifies the landing page is a uniform resource locator (URL) that incorporates a payment proxy. In such an embodiment, the landing page is a web page, such as www.cash.me / $cash.

[0270] In at least one example, the user 1514 may be new to the service provider 1512, such that the user 1514 has not registered with the service provider 1512 (e.g., has not subscribed to receive access to one or more services offered by the service provider). The service provider 1512 may provide onboarding services to register the potential user 1514 with the service provider 1512. In some examples, onboarding may involve presenting the potential user 1514 with various questions, prompts, etc. to obtain information that may be used to create a profile about the potential user 1514. In at least one example, the service provider 1512 may provide limited or short-term access to its services prior to or during onboarding (e.g., a user of a peer-to-peer payment service may transfer and / or receive funds before being fully onboarded, a merchant may 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 services of the service provider 1512 may be transitioned to more permissive (e.g., less limited) or longer-term access to such services.

[0271] The service provider 1512 may be associated with an IDV service that may be used by the 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 the server computing device 1510). That is, the service provider 1512 may provide an IDV service to verify the identity of a user 1514 who uses or attempts to use their services. Identity verification requires a buyer (or potential buyer) to provide information that is used by a compliance department to prove that the information is associated with the identity of a real person or entity. In at least one example, the service provider 1512 may perform a service to determine whether identifying information provided by the user 1514 accurately identifies the buyer (or potential buyer) (i.e., is the buyer who they say they are?).

[0272] The service provider 1512 may provide additional or alternative services, and the services described above are provided as a sampling of services. In at least one example, the 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 the service provider 1512 to provide services such as those described above. In additional or alternative examples, such a third party service provider may access the services of the service provider 1512. That is, in some examples, the third party service provider may be a subscriber or otherwise access the services of the service provider 1512.

[0273] The techniques described herein may be configured to operate in both real-time / online and offline modes. An "online" mode refers to a mode where the device is able to communicate with a service provider 1512 (e.g., server computing device 1502) and / or server computing device 1510 over a network 1504. In some examples, the merchant device 1508 is unable to connect with the service provider 1512 (e.g., server computing device 1502) and / or server computing device 1510, e.g., due to network connectivity issues. In additional or alternative examples, the server computing device 1502 is unable to communicate with the server computing device 1510, e.g., due to network connectivity issues. In such examples, the device may operate in an “offline” mode in which at least some payment data is stored on the merchant device 1508 (e.g., the merchant device 1508) and / or the server computing device 1502 until connectivity is restored and the payment data can be transmitted to the server computing device 1502 and / or the 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, an inventory hub, a fulfillment hub, etc., which may enable integration with one or more additional service providers (e.g., associated with additional server computing device 1510). In some examples, such additional service providers may offer additional or alternative services, and service provider 1512 may provide an interface or other computer-readable instructions for integrating the functionality of service provider 1512 with the one or more additional service providers.

[0275] The technology described herein is directed to services provided via a distributed system of user devices 1506 in communication with one or more server computing devices of a service provider 1512. That is, the technology described herein is directed to particular implementations, or practical applications, that utilize a distributed system of user devices 1506 in communication with one or more server computing devices 1502 of a service provider 1512 to perform various services, as described above. The non-conventional configuration of the distributed system described herein enables a server computing device 1502 located remotely from an end user (e.g., a user 1514) to intelligently provide services, in near real-time, in some examples, based on aggregate data associated with an end user, such as a user 1514 (e.g., data associated with multiple, different merchants and / or multiple different purchasers). Thus, the technology described herein is directed to particular configurations of elements that provide technical improvements over conventional techniques for performing payment processing services, and the like. Particularly for small business owners, the business environment is typically fragmented and dependent on unrelated tools and programs, making it difficult for owners to manually consolidate and view such data. The technology described herein constantly or periodically monitors disparate and separate merchant accounts, e.g., accounts within the control of the service provider 1512 and accounts outside the control of the service provider 1512, to track the merchant's business status (e.g., payables, receivables, payroll, invoices, promises, capital, etc.). The technology herein provides a consolidated view of the merchant's cash flow, predicts needs, preemptively provides recommendations or services such as capital, coupons, etc., and / or enables the movement of money between disparate accounts (merchant, another merchant, or payment services) in a frictionless and transparent manner.

[0276] As described herein, artificial intelligence, machine learning, and the like can be used to dynamically make decisions, recommendations, and the like, thereby adding intelligence and context awareness to an otherwise one-size-fits-all approach to provide the payment processing services described herein and / or additional or alternative services. In some implementations, the techniques described herein improve upon existing technology processes by enabling a distributed system to apply intelligence derived from an existing user base to new users, thereby making the onboarding experience for new users more personalized and less frictionless as compared to traditional onboarding methods.

[0277] As mentioned above, various graphical user interfaces (GUIs) may be presented to assist the techniques described herein. Some of the techniques described herein are directed to user interface features presented via the GUI to improve interaction between the user 1514 and the user device 1506. Furthermore, such features are dynamically changed based on the profile of the user engaged in interacting with the GUI. As such, the techniques described herein are directed to improvements in computing systems.

[0278] As will become apparent throughout the discussion below, any of the methods discussed herein may be implemented by a computer. In other words, a data processing apparatus, device or system may include means for performing any of the steps of the methods disclosed herein. A computer program may include instructions that, when executed by a computer, cause the computer to perform any of the steps 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 of the steps of the methods disclosed herein.

[0279] FIG. 16 illustrates additional details associated with the individual components of the merchant ecosystem illustrated in FIG. 15. The system 1600 includes a user device 1602 that communicates with a server computing device (e.g., a 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 near-field communications such as Bluetooth®, Bluetooth® Low Energy (BLE), and the like). Although a single user device 1602 is shown, in additional or alternative examples, the system 1600 may have multiple user devices, as described above with reference to FIG. 15.

[0280] The environment 1600 may facilitate enhanced security measures associated with embedded card readers as described herein. As noted above, techniques for spatially and / or temporally separating PAN and PIN data on an on-the-shelf device utilized to make a payment may be employed utilizing the system 1600 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 at the device. Other methods include utilizing different applications to handle PAN and PIN data, utilizing an intermediate application in addition to a trusted routine to determine if the merchant device has been compromised, utilizing various encryption methods, processing EMV data at a remote system, etc.

[0281] As discussed above, users of platforms (e.g., websites, applications, and other network-based communication tools provided by service providers) leverage tools for online commerce ("e-commerce"). However, current technology has limitations as discussed above. In some instances, a user interested in selling a product may initiate the sale of the product in a given unit of measurement. Such systems do not provide insight into the best unit of measurement in which to purchase, store, and / or sell the product. Furthermore, current infrastructure does not enable automated filtering of transaction data associated with units of measurement, placing the onus on merchants to collect and interpret this information. Thus, current technology is inefficient and not user-friendly. The environment 1600 described herein enables frictionless (or near-frictionless) unit conversion recommendations via interactions between merchants and merchant devices. Thus, the technology described herein provides an improvement over existing technology.

[0282] In at least one example, the user device 1602 may be any suitable type of computing device, e.g., portable, semi-portable, semi-stationary, or stationary. Some examples of the user device 1602 may include, but are not limited to, a tablet computing device, a smartphone or mobile communication device, a laptop, netbook or other portable or semi-portable computer, a desktop computing device, a terminal computing device or other semi-stationary or stationary computing device, a dedicated device, a wearable computing device or other body-worn computing device, an augmented reality device, a virtual reality device, an Internet of Things (IoT) device, and the like. That is, the user device 1602 may be any computing device capable of transmitting communications and performing functions in accordance with the techniques described herein. The user device 1602 may include devices such as a payment card reader or components capable of accepting payments, as described below.

[0283] In the depicted example, 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 sensors 1618.

[0284] In at least one example, each processor 1608 may itself comprise one or more processors or processing cores. For example, the 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, the processor 1608 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to execute the algorithms and processes described herein. The processor 1608 may be configured to fetch and execute computer-readable processor-executable instructions stored on the 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-transitory computer storage medium and may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storage of 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 media technologies. Additionally, in some examples, the user device 1602 may access external storage such as a RAID storage system, storage array, network attached storage, storage area network, cloud storage, or any other medium that may be used to store information and that may be accessed by the processor 1608 directly or through 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 may be executed by the processor 1608. Additionally, when referred to, non-transitory computer readable media excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves. Alternatively, computer readable media may be transitory.

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

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

[0288] In at least one example, the computer-readable medium 1610 may include additional functional components, such as an operating system 1624 for controlling and managing various functions of the user device 1602 and enabling basic user interaction.

[0289] The communication interface 1612 may include one or more interfaces and hardware components for enabling communication with various other devices, such as through the network 1606 or directly. For example, the communication interface 1612 may enable communication over one or more networks 1606, which may include any type of network known in the art, such as, but not limited to, a local area network or a wide area network such as the Internet, a wireless network such as a cellular network, a cloud network, a local wireless network such as Wi-Fi, and / or a near field communication such as Bluetooth, BLE, NFC, RFID, a wired network, or any other such network, 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 fiber optic technologies. The components used for such communication may depend at least in part on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0290] Embodiments of the present 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 provisioned and released with minimal administrative effort or service provider interaction. Thus, cloud computing allows users to access virtual computing resources (e.g., storage, data, applications, and complete virtualized computing systems) in the "cloud" 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.), tactile output devices, etc. The I / O devices 1614 may also include attachments that utilize accessories (audio jacks, USB-C, Bluetooth, etc.) to connect with 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 may 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 may be presented and / or projected. In some examples, the display 1616 may have a touch sensor associated with the display 1616 to provide a touch screen display configured to receive touch input to enable interaction with a graphical interface presented on the display 1616. Thus, implementations herein are 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 audibly, tactilely, etc.

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

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

[0295] In addition, the user device 1602 may include various other components not shown, examples of which include removable storage, a power source such as a battery and a power control unit, a barcode scanner, a printer, a cash drawer, etc.

[0296] Additionally, in some examples, the user device 1602 may include, be connectable to, or otherwise coupled to a reader device 1626 to read a payment instrument and / or identifier associated with a payment object. In some examples, as described above, the reader device 1626 may plug into a port of the user device 1602, such as a microphone port, a headphone port, an audio jack, a 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, or the like. The reader device 1626 may include a read head for reading a magnetic strip of a payment card and may further include encryption technology for encrypting information read from the magnetic strip. Additionally or alternatively, the reader device 1626 may be an EMV payment reader, which in some examples may be embedded in the user device 1602. Additionally, numerous other types of readers may be used in conjunction with the user device 1602 herein depending on the type and configuration of the user device 1602.

[0297] The reader device 1626 may be a portable magnetic stripe card reader, an optical scanner, a smart card (a card with an embedded IC chip) reader (e.g., an EMV compliant card reader or a near field communication enabled reader), an RFID reader, etc. configured to detect and acquire data from any payment instrument. Thus, the reader device 1626 may include hardware implementations such as slots, magnetic tracks, and rails with one or more sensors or electrical contacts to aid in the detection and acceptance of a payment instrument. That is, the reader device 1626 may include a hardware implementation that enables the reader device 1626 to interact with a payment instrument via a swipe (i.e., a card presence transaction in which the buyer slides a card having a magnetic strip through a payment reader that captures the payment data contained on the magnetic strip), a dip (i.e., a card presence transaction in which the buyer first inserts a card having an embedded microchip (i.e., chip) into the payment reader until the payment reader prompts the buyer to remove the card), or a tap (i.e., a card presence transaction in which the buyer taps or hovers his or her electronic device, such as a smartphone running a payment application, to complete the transaction via short-range communication) to obtain payment data associated with the buyer. Additionally or optionally, the reader device 1626 may include a biometric sensor to receive and process the biometric characteristics and process them as a payment instrument, provided that the biometric characteristics are registered with the payment processing service provider and connected to a financial account using a bank server. It will be understood that the reader device may 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 execute one or more modules and / or processes to cause the reader device 1626 to perform various functions, as described above and in further detail in the following disclosure. In some examples, the processing unit may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU, or other processing units or components known in the art. Additionally, each of the processing units may possess 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 some combination thereof. In at least one example, the computer-readable media of the reader device 1626 may include at least one module for performing various functions described herein.

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

[0300] Additionally, the reader chip may perform functions to control a power source. The power supply may include one or more power supplies, such as a physical connection to AC power or a battery. The power supply may include power conversion circuitry to convert the AC power and create multiple DC voltages for use by the components of the reader device 1626. If the power supply includes a battery, the battery may be charged via a physical power connection, via inductive charging, or via 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, the transaction chip may access payment data associated with the payment instrument and provide the payment data to the POS terminal, as described above. 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 value 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.), expiration 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), restrictions on what types of charges / debts may be made, etc. Additionally, the transaction chip may encrypt the payment data upon receiving it.

[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, while in other examples, the functionality of the reader chip and the transaction chip may be embodied in a single chip or in multiple chips, each including any suitable combination of a central processing unit and computer readable medium for collectively performing the functions of the reader chip and the transaction chip as 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, both components of 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 a display integrated therewith, which may be in addition to (or in place of) 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 may be implemented in any number of ways. For example, in the server example, the modules, other functional components, and data may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, a cloud-hosted storage service, etc., although other computer architectures may additionally or alternatively be used.

[0305] Additionally, while the diagram depicts server 1604 components and data as residing in a single location, these components and data may alternatively be distributed in any manner across different computing devices and different locations. Thus, functionality may be implemented by one or more server computing devices, and the various functions described above may be distributed in various manners across the various computing devices. Multiple servers 1604 may be located together or separately, and may be organized, for example, as virtual servers, server banks, and / or server farms. The described functionality may be provided by a single merchant or business server, or may be provided by multiple different buyers or business servers and / or services.

[0306] In the illustrated example, the 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 single or multiple computing units or multiple processing cores. The 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 operational instructions. For example, the processor 1628 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to execute the algorithms and processes described herein. The processor 1628 may be configured to fetch and execute computer-readable instructions stored on the computer-readable media 1630, which may program the processor 1628 to perform the functions described herein.

[0307] The 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 is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, 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 medium that can be used to store the desired information and accessed by a computing device. Depending on the configuration of the server 1604, the computer readable media 1630 may be any type of computer readable storage medium and / or may be a tangible non-transitory medium to the extent that, when referred to, non-transitory computer readable media excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves. Alternatively, the computer readable media may be transitory.

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

[0309] The merchant module 1636 may 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 may send requests (e.g., authorization, capture, settlement, etc.) to a payment services server computing device to facilitate a POS transaction between a merchant and a buyer. The merchant module 1636 may communicate success or failure of the POS transaction to the POS system. The payment processing module 116 described above with reference to FIG. 1 may correspond to the merchant module 1636.

[0310] The training module 1638 may be configured to train the model using a machine learning mechanism. For example, the machine learning mechanism may analyze the training data to train a data model that creates an output that may be a recommendation, a score, and / or another indication. The machine learning mechanism may 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 may be stored in a data store associated with the user device 1602 and / or the server 1604 for use at a time (e.g., at run-time) after the data model has been trained.

[0311] The 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 in part above. Additionally, the one or more other modules and data 1640 may include programs, drivers, and the like, as well as data used or created by the functional components. Additionally, the server 1604 may include many other logical, programmatic, and physical components, of which the above-described are merely examples relevant to the discussion herein.

[0312] One or more of the "modules" and / or "components" referenced herein may be implemented as more or fewer modules, and the functionality described for a module may be redistributed depending on the implementation details. The term "module" as used herein broadly refers to software stored in a temporary or non-transitory storage medium (e.g., volatile or non-volatile memory for a computing device), hardware, or firmware (or any combination thereof) module. A module is typically functional such that it may use specified inputs to create useful data or other output. A module may or may not be self-contained. An application program (also called an "application") may include one or more modules, or a module may include 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. An application program (also called an "application") may include one or more modules, and a module may include one or more application programs. Additionally and / or alternatively, the modules may be implemented as computer readable instructions, various data structures, etc. via at least one processing unit to execute the instructions and configure a 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 service provider functionality and / or utilize service provider services in connection with their own third party applications. Additionally or alternatively, in some examples, a service provider may utilize an SDK to integrate third party service provider functionality into its applications. That is, the APIs and / or SDKs may enable third party developers to customize how their respective third party applications interact with the service provider and vice versa. The API 148 described above may correspond to such.

[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 for enabling communication with various other devices, such as through the network 1606 or directly. For example, the communication interface 1634 may enable communication over one or more networks 1606, which may include any type of network known in the art, such as, but not limited to, 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 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 fiber optic technologies. The components used for such communication may depend at least in part on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0316] The server 1604 may further include various I / O devices 1632. Such I / O devices 1632 may include a display, various user interface controls (e.g., buttons, joysticks, keyboards, mice, touch screens, biometric or sensor input devices, etc.), audio speakers, connection ports, etc.

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

[0318] In at least one example, the data store 1644 can store user profiles, which can include merchant profiles, buyer profiles, and the like.

[0319] A merchant profile may store or otherwise be associated with data associated with a merchant. For example, a merchant profile may store information about the merchant (e.g., the merchant's name, the merchant's geographic location, the merchant's business hours, employee information, etc.), the Merchant Category Classification (MCC) 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 the items associated with the transactions, spending per each item and / or total for the transactions, parties to the transactions, dates, times, and / or locations associated with the transactions, etc.), and other information about the merchant. The merchant profile may store or be otherwise associated with associated loan information (e.g., previous loans made to the merchant, previous defaults on such loans, etc.), risk information associated with the merchant (e.g., indications of risk, instances of fraud, chargebacks, etc.), appointment information (e.g., previous appointments, upcoming (scheduled) appointments, timing of appointments, length of appointments, etc.), payroll information (e.g., employee, pay frequency, pay amount, etc.), employee information, reservation data (e.g., previous reservations, upcoming (scheduled) reservations, interactions associated with such reservations, etc.), inventory data, buyer service data, etc. The merchant profile may securely store bank account information as provided by the merchant. Additionally, the merchant profile may store payment information associated with a payment instrument linked to the merchant's stored balance, such as a stored balance maintained in a ledger by the service provider 1412.

[0320] The buyer profile may store buyer data including, but not limited to, buyer information (e.g., name, phone number, address, banking information, etc.), buyer preferences (e.g., learned or buyer specified), purchase history data (e.g., identifying one or more items purchased (and respective item information), payment instrument used to purchase one or more items, returns associated with one or more orders, status of one or more orders (e.g., in preparation, in packing, in transit, delivered, etc.), appointment data (e.g., previous appointments, upcoming (scheduled) appointments), payroll data (e.g., employee, pay frequency, pay amount, etc.), reservation data (e.g., previous appointments, upcoming (scheduled) appointments, reservation duration, interactions associated with such appointments, etc.), inventory data, buyer service data, etc.

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

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

[0323] In summary, the technology described herein is directed to embedded card reader security. In an example, personal account number (PAN) data read from a payment instrument may be separated in time and / or space from personal identification number (PIN) data utilized to complete the payment for a transaction. Temporal separation may include removing the personal account number data from the merchant device prior to requesting the PIN data. Spatial separation may include utilizing a trusted execution environment, separate embedded card reader applications, intermediate applications, and / or trusted routines, for example, to allow different components of the merchant device and / or components of other devices and systems to handle the personal account number data and the PIN data. Providing such functionality, among other things, improves data security during a payment transaction.

[0324] The phrases "in some examples," "according to various examples," "in the illustrated example," "in one example," "in another example," "various examples," "several examples," and the like generally mean that the particular feature, structure, or characteristic that follows the phrase is included in at least one example of the invention, and may be included in more than one example of the invention. Additionally, such phrases do not necessarily refer to the same or different examples.

[0325] If the specification states that a component or feature "may," "may," "could" or "may" be included or have a feature, it does not require that the particular component or feature be included or that the feature be included.

[0326] Additionally, the above description is directed to devices and applications related to payment technology. However, it will be understood that the technology may be extended to any device and application. Moreover, the technology described herein may be configured to operate regardless of the type of payment object reader, POS terminal, web application, mobile application, POS topology, payment card, computer network, and environment.

[0327] Various figures included herein are flow charts illustrating exemplary methods incorporating the techniques described herein. The methods described are described 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 depicted in Figures 1A-10, 15, and 16, and such components are not limited to performing the methods described herein.

[0328] Additionally, the methods described above are illustrated as a collection of blocks in a logic flow graph, which represent sequences of operations that may be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by a processor, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as limiting, and any number of the described blocks may be combined in any order and / or in parallel to perform a process. In some embodiments, one or more blocks of a process may be omitted entirely. Additionally, the methods may be combined in whole or in part with each other or with other methods.

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

[0330] As a further example, variations in the apparatus or process requirements (e.g., dimensions, configuration, components, process step order, etc.) may be made to further optimize the provided structures, devices, and methods as shown and described herein. In any event, the structures and devices and related methods described herein have many applications. Thus, the disclosed subject matter should not be limited to any single example described herein, but rather should be construed in breadth and scope in accordance with the appended claims.

[0331] The following clauses are also disclosed: 1. A method comprising: Configuring a point of sale (POS) application installed on a mobile device to utilize an embedded card reader (ECR) of said mobile device; Configuring the POS application to utilize a touch screen display of the mobile device; The POS application receiving a personal account number (PAN) from the ECR; receiving a personal identification number (PIN) from the touch screen display; and receiving the PAN for a transaction at the POS application; removing, by the POS application, the PAN from the mobile device prior to requesting the PIN; requesting the PIN utilizing the touchscreen display; and receiving the PIN in the POS application; and completing the transaction based on receiving the PAN and PIN. 2. The method according to clause 1, transmitting the PAN to a payment processing service; The method of claim 1, wherein removing the PAN from the mobile device is in response to transmitting the PAN to the payment processing service. 3. The method according to clause 1, receiving a request for the PIN from a payment processing service; The method of claim 1, wherein removing the PAN from the mobile device is in response to receiving the request for the PIN. 4. The method of claim 1, wherein the requesting the PIN is in response to removing the PAN from the mobile device. 5. The method according to clause 1, causing a trust routine to be executed in association with the mobile device after receiving the PAN, the trust routine being configured to determine whether the mobile device has been tampered with; determining that the trust routine indicates that the mobile device has not been tampered with; The method, wherein the requesting the PIN is in response to the trust routine indicating that the mobile device has not been tampered with. 6. The method according to clause 1, receiving the PAN includes receiving the PAN in a Trusted Execution Environment (TEE) of the mobile device; The PIN is received outside the TEE of the mobile device. 7. The method according to claim 1, and receiving, in response to requesting the PIN, an indication that user input corresponding to the PIN has been received; The method, wherein completing the transaction is based at least in part on the indication. 8. The method of claim 1, wherein receiving the PAN includes receiving encrypted first data representative of the PAN from the ECR, the method comprising: transmitting the encrypted first data to a payment processing service; receiving encrypted second data representative of the PIN; sending the encrypted second data to the payment processing service. 9. The method according to clause 1, receiving encrypted data representative of the PIN; transmitting the encrypted data to a payment processing system; receiving an indication from the payment processing system that the PIN, when decrypted by the payment processing system, is authorized in association with the PAN; 13. A method of claim 12, wherein completing the transaction is based at least in part on the PIN being authorized in association with the PAN. 10. The method of claim 1, wherein the POS application includes a first application, the method comprising: receiving the PIN at a second application configured to inhibit communication between a second application and the first application; transmitting the PAN from the first application to a payment processing service; transmitting the PIN from the second application to the payment processing service. 11. A device comprising: Touch screen and one or more processors; A non-transitory computer-readable medium storing instructions that, when executed by the one or more processors, Configuring a point of sale (POS) application to utilize an embedded card reader (ECR); configuring the POS application to receive a personal account number (PAN) from the ECR; configuring a personal identification number (PIN) application to receive a PIN from the touchscreen; the PIN application is configured to inhibit communication with the POS application; and receiving the PAN for a transaction at the POS application; requesting the PIN utilizing the touchscreen; and receiving the PIN in the PIN application; and completing the transaction based on receiving the PAN and PIN. 12. A device according to clause 11, wherein the operation comprises: transmitting the PAN to a payment processing service; and removing the PAN from the device in response to transmitting the PAN to the payment processing service. 13. A device according to clause 11, wherein the operation comprises: receiving a request for the PIN from a payment processing service; and removing the PAN from the device in response to receiving the request for the PIN. 14. The device of clause 11, wherein the actions further include removing the PAN from the device, and wherein the requesting the PIN is in response to removing the PAN from the device. 15. A device according to clause 11, wherein the operation comprises: causing a trust routine to be executed in association with the device after receiving the PAN, the trust routine being configured to determine whether the device has been tampered with; determining that the trusted routine indicates that the device has not been tampered with; The device, wherein the requesting of the PIN is in response to the trust routine indicating that the device has not been tampered with. 16. A device according to clause 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. A device according to clause 11, wherein the operation comprises: and receiving, in response to requesting the PIN, an indication that user input corresponding to the PIN has been received; The device, wherein completing the payment is based at least in part on the user input corresponding to the PIN. 18. A device according to clause 11, receiving the PAN includes receiving encrypted first data representative of the PAN from the ECR; The device, wherein receiving the PIN includes receiving encrypted second data representative of the PIN. 19. The device of claim 11, wherein receiving the PIN includes receiving encrypted data representative of the PIN, and the operations include: transmitting the encrypted data to a payment processing system; receiving an indication from the payment processing system that the PIN, when decrypted by the payment processing system, is authorized in association with the PAN; The device, wherein completing the transaction is based at least in part on the PIN being authorized in association with the PAN. 20. The device of clause 11, wherein the actions further include removing, by the POS application, the PAN from the device before requesting the PIN. 21. A method implemented by a point of sale (POS) application installed on a mobile device, comprising: receiving an indication in the POS application that a payment is received using a near field communication (NFC) card reader of the mobile device; sending a request from the POS application to the NFC card reader to initiate the payment; receiving, at the POS application, from the NFC card reader, a personal account number (PAN) associated with a payment instrument; from the POS application to a payment processing service; The PAN; A default personal identification number (PIN), a transaction identifier associated with the payment; and removing, by the POS application, the PAN from the mobile device after (i) transmitting the PAN to the payment processing service and (ii) prior to requesting an account PIN associated with the payment instrument; requesting the account PIN associated with the payment instrument; receiving the account PIN using a touch screen input of the mobile device; transmitting the account PIN and the identifier of the transaction to the payment processing service; and completing the payment based on receiving an indication that the account PIN was accepted. 22. The method according to clause 21, comprising: sending the request to initiate the payment from the POS application to the NFC card reader includes sending the request from the POS application to an intermediary application configured to communicate with the POS application and the NFC card reader; The method, wherein receiving the PAN from the NFC card reader at the POS application includes receiving the PAN at the POS application from the intermediary application. 23. The method of claim 21, wherein the POS application includes a Europay, MasterCard, Visa (EMV) kernel, the method comprising: receiving, at the POS application, from the NFC reader, EMV data associated with the payment instrument, the EMV data being unencrypted by the NFC reader; and determining, by the POS application, the PAN utilizing the EMV data. 24. The method of claim 21, wherein the POS application includes a Europay, MasterCard, Visa (EMV) kernel, the method comprising: receiving, at the POS application, from the NFC reader, EMV data associated with the payment instrument, the EMV data being encrypted by the NFC reader; decrypting, by the POS application, the EMV data such that decrypted EMV data is generated; and and determining, by the POS application, the PAN utilizing the decrypted EMV data. 25. A device comprising: Near Field Communication (NFC) card reader and one or more processors; A non-transitory computer-readable medium storing instructions that, when executed by the one or more processors, receiving, in a POS application, from the NFC card reader, a personal account number (PAN) associated with a payment instrument; To payment processing services, The PAN; transmitting a default personal identification number (PIN); removing, by the POS application, the PAN from the device prior to requesting an account PIN associated with the payment instrument; and a non-transitory computer-readable medium that causes the one or more processors to perform operations including: receiving the account PIN using a touch screen input of the device; and completing the payment based at least in part on an indication that the account PIN has been accepted. 26. A device according to clause 25, the PAN, when received at the POS application, is encrypted as Europay, MasterCard, Visa (EMV) data; transmitting the PAN to the payment processing service includes transmitting the EMV data to the payment processing service; The device, wherein completing the payment is based at least in part on the PAN being decrypted at the payment processing service and the account PIN being accepted. 27. A device according to clause 25, the PAN is encrypted as Europay, MasterCard, Visa (EMV) data configured to be encrypted by an original equipment manufacturer (OEM) associated with the device; transmitting the PAN includes transmitting the EMV data to the OEM along with a request to decrypt the EMV data and provide the PAN to the payment processing service; The device, wherein completing the payment is based at least in part on the PAN and the account PIN being accepted when decrypted as the OEM. 28. The device of clause 25, further comprising a trusted execution environment (TEE), the operation comprising: receiving, at the TEE, Europay, MasterCard, Visa (EMV) data including an encrypted version of the PAN; decrypting the EMV data at the TEE such that the PAN is identified; The device, wherein completing the payment includes utilizing the PAN when decrypted in the TEE to complete the payment. 29. A device according to clause 25, wherein the operation comprises: a trust routine is executed in association with the device prior to 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; determining that the trusted routine indicates that the device has not been tampered with; and requesting, by the POS application, the PAN in response to the trust routine indicating that the device has not been tampered with. 30. The device of clause 25, wherein the operations include sending a request to initiate the payment from the POS application to an intermediate application configured to communicate with the POS application and the NFC card reader, and receiving the PAN from the NFC card reader in the POS application includes receiving the PAN from the NFC card reader in the POS application from the intermediate application. 31. The device of claim 25, wherein the POS application includes a Europay, MasterCard, Visa (EMV) kernel, and the operation comprises: receiving, at the POS application, from the NFC reader, EMV data associated with the payment instrument, the EMV data being unencrypted by the NFC reader; and determining, by the POS application, the PAN utilizing the EMV data. 32. The device of clause 25, wherein the POS application includes a Europay, MasterCard, Visa (EMV) kernel, and the operation comprises: receiving, at the POS application, from the NFC reader, EMV data associated with the payment instrument, the EMV data being encrypted by the NFC reader; decrypting, by the POS application, the EMV data such that decrypted EMV data is generated; and and determining, by the POS application, the PAN utilizing the decrypted EMV data. 33. A method implemented by a point of sale (POS) application installed on a mobile device, comprising: receiving an indication that a payment has been received using a near field communication (NFC) card reader of the mobile device; sending a request to initiate the payment from the POS application to an intermediary application configured to communicate with the POS application and the NFC reader; receiving, at the POS application, from the intermediary application, a personal account number (PAN) associated with a payment instrument; from the POS application to a payment processing service; The PAN; transmitting a default personal identification number (PIN); removing the PAN from the mobile device prior to requesting an account PIN associated with the payment instrument; receiving the account PIN using a touch screen input of the mobile device; and completing the payment based at least in part on the indication that the account PIN was accepted. 34. The method according to claim 33, comprising: the PAN, when received at the POS application, is encrypted as Europay, MasterCard, Visa (EMV) data; transmitting the PAN to the payment processing service includes transmitting the EMV data to the payment processing service; 11. The method of claim 10, wherein completing the payment is based at least in part on the PAN being decrypted at the payment processing service and the account PIN being accepted. 35. The method according to claim 33, comprising: the PAN is encrypted as Europay, MasterCard, Visa (EMV) data configured to be encrypted by an original equipment manufacturer (OEM) associated with the device; transmitting the PAN includes transmitting the EMV data to the OEM along with a request to decrypt the EMV data and provide the PAN to the payment processing service; The method of claim 1, wherein completing the payment is based at least in part on the PAN when decrypted as the OEM and the account PIN being accepted. 36. The method according to claim 33, comprising: receiving, in a trusted execution environment (TEE) of the mobile device, Europay, MasterCard, Visa (EMV) data, including an encrypted version of the PAN; decrypting the EMV data at the TEE such that the PAN is identified; The method, wherein completing the payment includes utilizing the PAN when decrypted in the TEE to complete the payment. 37. The method according to claim 33, comprising: causing a trust routine to be executed in association with the mobile device prior to receiving the PAN, the trust routine being configured to determine whether the mobile device has been tampered with; determining that the trust routine indicates that the mobile device has not been tampered with; The method further includes requesting, by the POS application, the PAN in response to the trust routine indicating that the mobile device has not been tampered with. 38. The method according to claim 33, comprising: sending the request to initiate the payment from the POS application to the intermediary application causes an embedded card reader application to query the NFC card reader for the PAN; The method, wherein receiving the PAN from the intermediate application includes the intermediate application receiving the PAN from the embedded card reader application and transmitting the PAN to the POS application. 39. The method of claim 33, wherein the POS application includes a Europay, MasterCard, Visa (EMV) kernel, the method comprising: receiving, at the POS application, from the NFC reader, EMV data associated with the payment instrument, the EMV data being unencrypted by the NFC reader; and determining, by the POS application, the PAN utilizing the EMV data. 40. The method of claim 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. 1. A method comprising: Configuring a point of sale (POS) application installed on a mobile device to utilize an embedded card reader (ECR) of said mobile device; Configuring the POS application to utilize a touchscreen display of the mobile device; The POS application, receiving a personal account number (PAN) from the ECR; receiving a personal identification number (PIN) from the touchscreen display; receiving the PAN for a transaction at the POS application; removing, by the POS application, the PAN from the mobile device prior to requesting the PIN; requesting the PIN utilizing the touchscreen display; receiving the PIN at the POS application; and completing the transaction based on receiving the PAN and PIN.

2. 2. The method of claim 1 , transmitting the PAN to a payment processing service; The method, wherein removing the PAN from the mobile device is at least partially in response to transmitting the PAN to the payment processing service.

3. 3. The method according to claim 1 or 2, receiving a request for the PIN from a payment processing service; The method, wherein removing the PAN from the mobile device is at least partially in response to receiving the request for the PIN.

4. 4. The method of claim 1, wherein the requesting a PIN is at least partially in response to removing the PAN from the mobile device.

5. 5. The method according to claim 1 , further comprising the steps of: causing a trust routine to be executed in association with the mobile device after receiving the PAN, the trust routine being configured to determine whether the mobile device has been tampered with; determining that the trust routine indicates that the mobile device has not been tampered with; The method, wherein the requesting of the PIN is at least partially in response to the trust routine indicating that the mobile device has not been tampered with.

6. 6. The method according to any one of claims 1 to 5, comprising: Receiving the PAN includes receiving the PAN in a Trusted Execution Environment (TEE) of the mobile device; The method of claim 1, wherein the PIN is received outside the TEE of the mobile device.

7. 7. The method according to any one of claims 1 to 6, comprising: and receiving, in response to requesting the PIN, an indication that user input corresponding to the PIN has been received; The method, wherein completing the transaction is based at least in part on the indication.

8. 8. The method of claim 1, wherein receiving the PAN includes receiving encrypted first data representative of the PAN from the ECR, the method comprising: transmitting the encrypted first data to a payment processing service; receiving encrypted second data representative of the PIN; transmitting the encrypted second data to the payment processing service.

9. 9. The method according to any one of claims 1 to 8, comprising: receiving encrypted data representative of the PIN; transmitting the encrypted data to a payment processing system; receiving an indication from the payment processing system that the PIN, when decoded by the payment processing system, is authorized in association with the PAN; A method, wherein completing the transaction is based at least in part on the PIN being authorized in association with the PAN.

10. 10. The method of claim 1, wherein the POS application includes a first application, the method comprising: receiving the PIN at a second application configured to inhibit communication between a second application and the first application; transmitting the PAN from the first application to a payment processing service; transmitting the PIN from the second application to the payment processing service.

11. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to any one of claims 1 to 10.

12. A computer readable medium containing instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 10.

13. 1. A mobile device, comprising: Touch screen and one or more processors; and a computer readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method according to any one of claims 1 to 10.

14. A device, comprising: Touch screen and one or more processors; A computer-readable medium storing instructions that, when executed by the one or more processors, Configuring a point of sale (POS) application to utilize an embedded card reader (ECR); configuring the POS application to receive a personal account number (PAN) from the ECR; configuring a personal identification number (PIN) application to receive a PIN from the touchscreen, the PIN application configured to inhibit communication with the POS application; receiving the PAN for a transaction at the POS application; requesting the PIN utilizing the touch screen; receiving the PIN in the PIN application; and completing the transaction based on receiving the PAN and PIN.

15. 15. The device of claim 14, wherein the action comprises: transmitting the PAN to a payment processing service; and removing the PAN from the device in response at least in part to transmitting the PAN to the payment processing service.

16. 16. A device according to claim 14 or 15, wherein the operation comprises: receiving a request for the PIN from a payment processing service; and removing the PAN from the device in response at least in part to receiving the request for the PIN.

17. 17. The device of claim 14, wherein the action further comprises removing the PAN from the device, and wherein the requesting the PIN is at least partially in response to removing the PAN from the device.

18. 18. A device according to any one of claims 14 to 17, wherein the operation comprises: causing a trust routine to be executed in association with the device after receiving the PAN, the trust routine being configured to determine whether the device has been tampered with; determining that the trust routine indicates that the device has not been tampered with; The device, wherein the requesting of the PIN is at least partially in response to the trust routine indicating that the device has not been tampered with.

19. A device according to any one of claims 14 to 18, comprising: 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.

20. 20. A device according to any one of claims 14 to 19, wherein the operation comprises: and receiving, in response to requesting the PIN, an indication that user input corresponding to the PIN has been received; The device, wherein completing the payment is based at least in part on the user input corresponding to the PIN.

21. A device according to any one of claims 14 to 20, comprising: receiving the PAN includes receiving encrypted first data representative of the PAN from the ECR; The device, wherein receiving the PIN includes receiving encrypted second data representative of the PIN.

22. 22. A device according to any one of claims 14 to 21, wherein receiving the PIN comprises receiving encrypted data representative of the PIN, and the operations include: transmitting the encrypted data to a payment processing system; receiving an indication from the payment processing system that the PIN, when decoded by the payment processing system, is authorized in association with the PAN; The device, wherein completing the transaction is based at least in part on the PIN being authorized in association with the PAN.

23. 23. The device of claim 14, wherein the action further comprises removing the PAN from the device before requesting the PIN, by the POS application.

24. 1. A method comprising: Configuring a point of sale (POS) application to utilize an embedded card reader (ECR); configuring the POS application to receive a personal account number (PAN) from the ECR; configuring a personal identification number (PIN) application to receive a PIN from the touchscreen; the PIN application is configured to inhibit communication with the POS application; and receiving the PAN for a transaction at the POS application; requesting the PIN utilizing the touch screen; receiving the PIN in the PIN application; and completing the transaction based on receiving the PAN and PIN.

Images