Abstract: A payment device such as electronic transaction card or an near field communication device can use a temporary token for payment transactions. When processing a payment transaction, a payment reader can obtain the temporary token from the payment device and provide the temporary token to a server of the issuer of the payment device. The payment reader can receive a new temporary token and an issuer script from the server and provide the new temporary token and the issuer script to the payment device. When the payment device receives the issuer script, the payment device can execute the issuer script, while the payment device is interfaced with the payment reader, to store the new temporary token on the payment device.

Abstract: A payment device such as electronic transaction card or an near field communication device can use a temporary token for payment transactions. When processing a payment transaction, the temporary token is provided to a server of the issuer of the payment device, which can authorize the payment transaction and determine if the temporary token can be used for a subsequent transaction. If the server determines that the temporary token cannot be used for another transaction, the server provides the payment device with a new temporary token and an issuer script. When the payment device receives the issuer script, the payment device can execute the issuer script to store the new temporary token on the payment device.

Abstract: A device may run an application having information with multiple accounts associated with processing of transactions. The application may provide account information that is used to process the transactions. At the same time, a background application may operate on the device. The background application may be compatible with a second device, and when within range of the second device, may communicate background messages relevant to the transaction. The transaction may then be processed based on the account information and the background messages.

Abstract: Systems, devices, and methods for embedded card reader security include configuring a personal account number (PAN) application installed on a device to utilize an embedded card reader (ECR) and receiving, at the PAN application and based at least in part on an interaction between the ECR and the device, a PAN for a transaction. The PAN may be sent to a payment processing service and a personal identification number (PIN) application may render a PIN user interface. The PIN may be received at the PIN application and sent to the payment processing service. The transaction may be completed based at least in part on an indication from the payment processing service that the PAN and the PIN have been accepted.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tampering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: Techniques described herein are directed to embedded card reader security. In an example, personal account number data read from a payment instrument may be temporally and/or spatially separated from personal identification number data utilized to complete a payment for products. Temporal separation may include removing the personal account number data from a merchant device prior to request personal identification number data. Spatial separation may include utilization of trusted execution environments, separated embedded card reader applications, intermediary applications, and/or trust routines, for example to enable different components of a merchant device, and/or components of other devices and systems to handle personal account number data and personal identification number data.

Abstract: Techniques described herein are directed to embedded card reader security. In an example, personal account number data read from a payment instrument may be temporally and/or spatially separated from personal identification number data utilized to complete a payment for products. Temporal separation may include removing the personal account number data from a merchant device prior to request personal identification number data. Spatial separation may include utilization of trusted execution environments, separated embedded card reader applications, intermediary applications, and/or trust routines, for example to enable different components of a merchant device, and/or components of other devices and systems to handle personal account number data and personal identification number data.

Abstract: Techniques described herein are directed to embedded card reader security. In an example, personal account number data read from a payment instrument may be temporally and/or spatially separated from personal identification number data utilized to complete a payment for products. Temporal separation may include removing the personal account number data from a merchant device prior to request personal identification number data. Spatial separation may include utilization of trusted execution environments, separated embedded card reader applications, intermediary applications, and/or trust routines, for example to enable different components of a merchant device, and/or components of other devices and systems to handle personal account number data and personal identification number data.

Abstract: Techniques described herein are directed to embedded card reader security. In an example, personal account number data read from a payment instrument may be temporally and/or spatially separated from personal identification number data utilized to complete a payment for products. Temporal separation may include removing the personal account number data from a merchant device prior to request personal identification number data. Spatial separation may include utilization of trusted execution environments, separated embedded card reader applications, intermediary applications, and/or trust routines, for example to enable different components of a merchant device, and/or components of other devices and systems to handle personal account number data and personal identification number data.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tampering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: Payment readers can variously have kernels of different generations, capable of performing different (or different suites of) payment processing functions. A payment reader may be designed to obtain raw payment data from a payment device, process that data if appropriate, and transmit the data to a mobile device external to the payment reader, the mobile device having similar, more, or different processing resources than the payment reader. A mobile device is capable of determining the type and source of payment data received, for example on whether the data is processed or raw (processed data). The mobile device may then selectively determine whether and how to process the payment data and to transmit it to a payment server for approval of a payment transaction.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader.

Abstract: A device may run an application having information with multiple accounts associated with processing of transactions. The application may provide account information that is used to process the transactions. At the same time, a background application may operate on the device. The background application may be compatible with a second device, and when within range of the second device, may communicate background messages relevant to the transaction. The transaction may then be processed based on the account information and the background messages.

Abstract: A device may run an application having information with multiple accounts associated with processing of transactions. The application may provide account information that is used to process the transactions. At the same time, a background application may operate on the device. The background application may be compatible with a second device, and when within range of the second device, may communicate background messages relevant to the transaction. The transaction may then be processed based on the account information and the background messages.

Abstract: Methods and systems are provided for performing and verifying transactions involving authentication with a secure credential, such as a smart card, in an untrusted or semi-trusted environment. An application module, operating in an untrusted or semi-trusted environment can be denied access to sensitive data. The application module can determine a preliminary command to be sent to the credential and transmit the preliminary command to a broker module. The broker module, operating in a trusted environment, can supply sensitive data and transmit the command to the credential. Subsequently, the broker module can extract sensitive data from a response before it is transmitted to the application module. A verification server can audit the transaction to verify that it was carried out properly.

Abstract: Methods and systems are provided for performing and verifying transactions involving authentication with a secure credential, such as a smart card, in an untrusted or semi-trusted environment. An application module, operating in an untrusted or semi-trusted environment can be denied access to sensitive data. The application module can determine a preliminary command to be sent to the credential and transmit the preliminary command to a broker module. The broker module, operating in a trusted environment, can supply sensitive data and transmit the command to the credential. Subsequently, the broker module can extract sensitive data from a response before it is transmitted to the application module. A verification server can audit the transaction to verify that it was carried out properly.