Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: Methods, devices, and systems are described for sending and receiving messages between a terminal reader and a payment device, such as a credit card. A dynamic signature is calculated on the payment device from an application transaction counter, a terminal unpredictable number, and a transaction amount, and it is sent with an application the locator (AFL) to the reader. The reader then sends a read record command to the payment device to get records associated with the AFL, among other normal processing. While the normal processing is occurring for the transaction, the dynamic signature can be recalculated and compared with that from the payment device in order to assure that nothing has surreptitiously changed the values in the messages.

Abstract: A payment authentication service authenticates the identity of a payer during online transactions. The authentication service of the present invention allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate is the issuing financial institution. One embodiment of the invention for authenticating the identity of a cardholder during an online transaction involves querying an access control server to determine if a cardholder is enrolled in the payment authentication service, requests a password from the cardholder, verifies the password, and notifies a merchant whether the cardholder's authenticity has been verified. In another aspect of the invention, a chip card and the authentication service independently generate cryptograms that must match in order for the service to verify that the correct chip card is being used by the cardholder.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: A payment authentication service authenticates the identity of a payer during online transactions. The authentication service of the present invention allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate is the issuing financial institution. One embodiment of the invention for authenticating the identity of a cardholder during an online transaction involves querying an access control server to determine if a cardholder is enrolled in the payment authentication service, requests a password from the cardholder, verifies the password, and notifies a merchant whether the cardholder's authenticity has been verified. In another aspect of the invention, a chip card and the authentication service independently generate cryptograms that must match in order for the service to verify that the correct chip card is being used by the cardholder.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: Methods, devices, and systems are described for sending and receiving messages between a terminal reader and a payment device, such as a credit card. A dynamic signature is calculated on the payment device from an application transaction counter, a terminal unpredictable number, and a transaction amount, and it is sent with an application the locator (AFL) to the reader. The reader then sends a read record command to the payment device to get records associated with the AFL, among other normal processing. While the, normal processing is occurring for the transaction, the dynamic signature can be recalculated and compared with that from the payment device in order to assure that nothing has surreptitiously changed the values in the messages.

Abstract: Methods, devices, and systems are described for sending and receiving messages between a terminal reader and a payment device, such as a credit card. A dynamic signature is calculated on the payment device from an application transaction counter, a terminal unpredictable number, and a transaction amount, and it is sent with an application file locator (AFL) to the reader. The reader then sends a read record command to the payment device to get records associated with the AFL, among other normal processing. While the normal processing is occurring for the transaction, the dynamic signature can be recalculated and compared with that from the payment device in order to assure that nothing has surreptitiously changed the values in the messages.

Abstract: Methods, devices, and systems are described for sending and receiving messages between a terminal reader and a payment device, such as a credit card. A dynamic signature is calculated on the payment device from an application transaction counter, a terminal unpredictable number, and a transaction amount, and it is sent with an application file locator (AFL) to the reader. The reader then sends a read record command to the payment device to get records associated with the AFL, among other normal processing. While the normal processing is occurring for the transaction, the dynamic signature can be recalculated and compared with that from the payment device in order to assure that nothing has surreptitiously changed the values in the messages.

Abstract: A method comprising, at a reader, performing at least one transaction-based risk management process prior to energizing a contactless interface, initiating communication with a card utilized for a contactless transaction, receiving information associated with the card, terminating communication with the card, and authorizing the contactless transaction.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: A personalization of a batch of smart cards is provided. A user is provided with a plurality of queries regarding smart card features. Responses to the plurality of queries are received from the user. A personalization data file is generated using the responses to the plurality of queries, where the personalization data file comprises values, which may be used to provide features on a batch of smart cards.

Abstract: A method comprising, at a reader, performing at least one transaction-based risk management process prior to energizing a contactless interface, initiating communication with a card utilized for a contactless transaction, receiving information associated with the card, terminating communication with the card, and authorizing the contactless transaction.

Abstract: A method. The method comprises, at a reader, performing at least one transaction-based risk management process prior to energizing a contactless interface, initiating communication with a card utilized for the contactless transaction, receiving information associated with the card, and terminating communication with the card to authorizing the contactless transaction.

Abstract: A personalization of a batch of smart cards is provided. A user is provided with a plurality of queries regarding smart card features. Responses to the plurality of queries are received from the user. A personalization data file is generated using the responses to the plurality of queries, where the personalization data file comprises values, which may be used to provide features on a batch of smart cards.

Abstract: A personalization of a batch of smart cards is provided. A user is provided with a plurality of queries regarding smart card features. Responses to the plurality of queries are received from the user. A personalization data file is generated using the responses to the plurality of queries, where the personalization data file comprises values, which may be used to provide features on a batch of smart cards.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.

Abstract: An interface and device architecture for a payment device. An interface between a payment application installed in a payment device and one or more value-add applications (such as loyalty programs, transit applications, etc.) that are also installed in the payment device. The API or interface design permits communications and data transfer between the payment application and one or more value-add applications. This reduces (and in some cases may prevent) the need for back-end server processing of data that may be relevant to both a payment transaction and to a function of the value-add application. Similarly, the same or another API or interface may enable communications and data transfer between a value-add application and the payment application.