This section is intended to provide background information to facilitate a better understanding of various technologies described herein. As the section's title implies, this is a discussion of related art. That such art is related in no way implies that it is prior art. The related art may or may not be prior art. It should therefore be understood that the statements in this section are to be read in this light, and not as admissions of prior art.
Global pandemics require a reevaluation of the manner in which people interact and engage in commercial activities. Touchless experiences will be the new normal in a post-COVID world. Current solutions are not completely end-to-end and use separate tools for identity, payment and access.
Described herein are various implementations of a method for providing identity, payment and/or access. In one implementation, a primary account number (PAN) is read from a card or token. A hashed PAN is generated. A transaction result is determined based on the hashed PAN.
In one implementation, the transaction result can be determined locally.
The transaction result can be determined locally by performing an offline match of the hashed PAN against a locally stored whitelist.
In one implementation, the transaction result can be determined based on a decision made by a backend server.
The hashed PAN can be sent to the backend server and the backend server can match the received hashed PAN against a whitelist.
In one implementation, the PAN can be read from a contactless card.
In one implementation, the PAN can be read via a token provided by a digital wallet present on a mobile device.
In one implementation, the PAN can be read via a token provided by a digital wallet accessible via a wearable device
In one implementation, the PAN can be read using a select proximity payment system environment (PPSE) command to ensure that PANs from a particular payment processor are read.
Described herein are various implementations of a method for providing identity, payment and/or access. In one implementation, a zero dollar transaction is initiated with a card or token. A primary account number (PAN) is determined from information received via the zero dollar transaction. The card or token is authenticated. A hashed PAN is generated. A transaction result is determined based on the hashed PAN.
In one implementation, the card or token can be authenticated using CDA.
In one implementation, the transaction result can be determined locally.
The transaction result can be determined locally by performing an offline match of the hashed PAN against a locally stored whitelist.
In one implementation, the transaction result can be determined based on a decision made by a backend server.
The hashed PAN can be sent to the backend server and the backend server can matches the received hashed PAN against a whitelist.
In one implementation, the transaction data can be provided to a server in real-time.
In one implementation, the transaction data includes application transaction counter (ATC) data.
In one implementation, the zero dollar transaction can be initiated with a contactless card.
In one implementation, the zero dollar transaction can be initiated with a digital wallet present on a mobile device.
In one implementation, the zero dollar transaction can be initiated with a token provided by a digital wallet accessible via a wearable device.
Described herein are various implementations of a method for providing identity, payment and/or access. In one implementation, an access identifier (ID) or primary account reference (PAR) is read from a card or token. A transaction result is determined locally or via a server based on the access ID or PAR.
In one implementation, the transaction result is determined by matching the access ID or PAR against a whitelist.
The above referenced summary section is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description section. Additional concepts and various other implementations are also described in the detailed description. The summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter, nor is it intended to limit the number of inventions described herein. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Implementations of various techniques will hereafter be described with reference to the accompanying drawings. It should be understood, however, that the accompanying drawings illustrate only the various implementations described herein and are not meant to limit the scope of various techniques described herein.
System 100 includes implementations that are designed to enable cardholders to use any EMV contactless card or token to easily access value-added services, such as identification, loyalty and access in various use cases such as retail, smart cities, travel & hospitality.
The present system provides end-to-end implementations for identity 110, loyalty programs 115 and access 120 using the EMV standard 105 via, for example, contactless cards, tokens, mobile device digital wallet, wearable devices coupled to mobile devices. Examples related to identity 110 include passports 135, student identification 130 and user identification 125. Examples related to loyalty 115 include earning points 140 and redeeming points 145. Examples related to access include office building and/or wework systems 150, hotels and other types of rental properties 155, and attractions 160, e.g., tourism, sports or other activities. The present system brings an end-to-end, seamless touchless experience by unlocking hidden potential in existing contactless cards/tokens.
In one implementation, when a consumer uses an EMV card, token, or digital wallet having an associated payment card number or primary account number (PAN), the access server 220 matches the loyalty program identifier of the consumer with the PAN of the consumer. In other words, the access server maps/binds the loyalty program identifier to the PAN of the consumer.
In one implementation, a hashed PAN or digital account number (DAN) is generated using the following method. Salt is provisioned to the terminal 320 by the access server 330. The PAN/DAN is read from the EMV card or token. A salt is random data that is used as an additional input to a one-way function that hashes data, a password or passphrase. Salts are used to safeguard PANs/DANs. A new salt is randomly generated for each PAN/DAN. In one implementation, the salt and the PAN/DAN (or a version of the PAN/DAN) are concatenated and fed to a cryptographic hash function. The hashed PAN/DAN, e.g., output hash value, (but not the original PAN/DAN) can be stored in a local memory or sent to access server 330. Hashing allows for later authentication without keeping and therefore risking exposure of the PAN/DAN if the authentication data store is compromised. In one implementation, the PAN/DAN read by terminal 320 can be 13 to 19 digits. In one implementation, the hashed PAN (PAN|SALT) or hashed DAN (DAN|SALT) can be generated by a SHA256 hash function. For the sake of simplicity, wherever the present disclosure describes implementations related to a PAN, the same methods described herein can be applied to DANs and/or tokens presented by mobile and/or wearable devices.
A Category 1 terminal is provided for simple access. The credential type for this type of system is a hashed PAN. In this implementation combined dynamic data authentication-application cryptogram generation (CDA) is not necessary. In this implementation, the terminal, e.g., terminal 320, reads the PAN and/or user identifier (UID) from the EMV card, mobile device or wearable device and provides access. Access can be provided by matching the hashed PAN locally or upon verification by a remote access server, e.g., access server 330. The terminal can be provided using a software data kit (SDK), no application transaction counter (ATC) update is required, and the certification requirements for the terminal are low. An ATC is a counter maintained by the EMV card or digital wallet application that provides a sequential reference to each transaction. The ATC is a sequential counter managed by the contactless card or token that is used to ensure that all cryptograms produced are unique. A duplicate ATC, a decrease in ATC or a large jump in ATC values may indicate data copying or other fraud to an issuer.
A Category 2 terminal is provided for access and/or transit systems. The credential for this type of system is a hashed PAN and CDA. CDA, which is also referred to as combined data authentication, involves including the card decision among the data being signed by the card's RSA key (public key or asymmetric key algorithm). In this implementation, the terminal, e.g., terminal 320, performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal is an EMV terminal implementing full EMV access kernel according to access terminal specifications. In this implementation, ATC updates can be deferred and certification requirements are medium.
A Category 3 terminal is provided for secure access systems. Secure access systems can be directed to access and/or identification systems The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal, e.g., terminal 320, performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal SDK can be one of two types. The first terminal type for this implementation is an EMV terminal implementing a full EMV access kernel according to access terminal specifications. The second terminal type is an SDK communicating with an EMV access kernel implemented in a cloud point of sale (POS) server. In this implementation, ATC updates can be deferred or provided in real-time and certification requirements are medium.
A Category 4 terminal is provided for loyalty systems. Loyalty systems can be directed to merchant retail stores and/or payments. The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal, e.g., terminal 320, performs full EMV transactions from the terminal and/or cloud POS SDK. The vendor's terminal can include a terminal SDK or be hosted by a cloud POS server. In this implementation, ATC updates are provided in real-time and full certification is required.
In one implementation, the terminal reads PAN numbers by using SELECT PPSE and READ RECORD command, e.g., for Category 1 transactions. In this implementation, a get processing options (GPO) command is not issued. This implementation, while simpler to implement, is less secure and subject to card cloning or emulation.
In one implementation, the terminal performs CDA with a GPO command, which will increase the ATC. In this implementation, the access server sends ATC updates to the issuer. This implementation is more secure and ensures that the card/token is genuine.
In one implementation a Cloud POS server can be leveraged to implement an EMV/EA Kernel for some use cases to reduce the terminal upgrade efforts.
In one implementation NFC data exchange performed by a terminal can be modified to perform a READ RECORD followed by a GPO. This implementation enables a single-tap hashed PAN reading mode for loyalty systems.
The card PAN can be read, for example, using select proximity payment system environment (PPSE) command to ensure that PANs/tokens from a particular payment processor are read. Once verification that a PAN/token from the particular payment processor is presented, a read record command is given read the PAN/token. The following are example select PPSE and Read Record commands:
Certification for a terminal providing method 500 includes testing that the terminal can interact with the EMV card or device (mobile or wearable). Certification further includes testing to verify whether the terminal can determine that the EMV card is powered and that the flow of information can be shared. In addition, certification includes determining whether the terminal and access server can implement the transaction and data handling described in method 500.
The service provider uploads, e.g., via a backend server, the transaction data from the terminal (including UID, hashed PAN and/or other pertinent data) to the access server in real-time or as soon as possible. The access server sends ATC update messages to issuers based on transaction data received from all service providers. Sending ATC updates to issuers notifies the issuer that the ATC has been incremented more than may be usual. Keeping the issuer apprised via ATC update messages avoids situations that may create unexpected declines for payment transactions.
Certification for a terminal providing method 600 includes testing that the terminal can interact with the EMV card or device (mobile or wearable). Certification further includes testing to verify whether the terminal can determine that the EMV card is powered and that the flow of information can be shared. In addition, certification includes determining whether the terminal and access server can implement the transaction and data handling described in method 600. In one implementation, an access kernel is provided. In this implementation certification includes testing to determine whether the access kernel and the card/token can communicate the correct information to allow data sharing and to allow decision-making on processing at the terminal.
Item 810 describes supported configuration fields in AppConfig.json. The fields in item 810 describe options available to use the SDK for access control. In one implementation, a hashedPanSalt is a random string having a suitably long length. The salt value is appended to the PAN and hashed to generate unique EMV card values across different terminals. A terminalMode field can be one of three values: a hashedPan, an auth, or a fullTransaction. When the hashedPan is used, the SDK returns the hashed PAN from reading an EMV card. When auth is used, the SDK returns the hashedPAN and transaction data from a $0 authorization. When fullTransaction is used, the SDK requests for a transaction amount, performs a full EMV transaction, and returns the outcome of the transaction. An nfcMode field can have an internal value or an external value. When the internal value is set, the SDK uses the internal NFC module of the host Android device. When the external value is set, the SDK uses an external universal serial bus (USB) NFC driver.
At item 1, issuer 1045 onboards key cards onto access server 1035 as hashed PANs. At item 2, vendor, e.g., terminal backend 1015, downloads, from access server 1035, a list of eligible hashed PANs, e.g., a whitelist. Terminal backend 1015 also uploads transaction records to access server 1035. At item 3, when a passenger presents a transportation key card at transportation terminals, e.g., gantry 1010 or fleet terminals 1055, entry details are stored in a memory of the gantry/terminal 1010, 1055. Gantry/terminal 1010, 1055 supports internal and external expandable storage capability, e.g., SD cards. A hashed PAN is generated for the transportation key card and CDA authentication is performed to ensure that the card is genuine. In this implementation, the ATC counter is incremented. At item 4, hashed PANs are synchronized to the fleet and historical transaction data is uploaded. At item 5, access server 1035 sends ATC updates to the issuer 1045 via the payment network 1040.
The implementation of
In one implementation, certain hashed PANs are allowed for free transit. These hashed PANs are stored in a whitelist. The whitelist is transferred from Access Server 1035 and stored in gantry terminals 1050. During tap in at the gantry, the card transaction data is stored in the gantry terminal, but at end of day reconciliation, the card transaction data is synchronized to the backend 1015, and forwarded to Access Server 1034.
At item 1, a user onboards a corporate ID badge and EMV card to access server 1425 as described in
The present system provides a variety of advantages. QR codes, bar codes and vendor cards can easily be duplicated. The present disclosure provides a system that can read PAN and serial number from physical and digital EMV cards. The hardware of the present disclosure is low-cost and uses existing gantries and/or USB NFC devices. Implementations of the present disclosure are built on top of existing highly secure and proven EMV payment standards, provides a unified digital-first experience for consumers across different domains, and provides more data points for merchants.
The memory 1620 can store information within the hardware configuration 1600. In one implementation, the memory 1620 can be a computer-readable medium. In one implementation, the memory 1620 can be a volatile memory unit. In another implementation, the memory 1620 can be a non-volatile memory unit.
In some implementations, the storage device 1630 can be capable of providing mass storage for the hardware configuration 1600. In one implementation, the storage device 1630 can be a computer-readable medium. In various different implementations, the storage device 1630 can, for example, include a hard disk device/drive, an optical disk device, flash memory or some other large capacity storage device. In other implementations, the storage device 1630 can be a device external to the hardware configuration 1600. The input/output device 1640 provides input/output operations for the hardware configuration 1600.
As mentioned above, Category 5 terminal is provided for simple access. The credential type for this type of system is an access ID or a payment account reference (PAR). In this implementation, combined dynamic data authentication-application cryptogram generation (CDA) is not necessary. Further, the terminal, e.g., terminal 320, reads the access ID or PAR from the EMV card, mobile device or wearable device and provides access. In one implementation, the access ID can be read using a third party data and the PAR can be read via an EMV card or token. In another implementation, third party data can be provided via tag 9F6E and the PAR can be provided via tag 9F24. Access can be provided by matching the access ID or PAR locally or upon verification by a remote access server, e.g., access server 330. The terminal can be provided using a software data kit (SDK), no application transaction counter (ATC) update is required, and the certification requirements for the terminal are low. The terminal SDK can be implemented on a computer operating system or implemented on a mobile device operating system, e.g., for a phone, tablet or similar mobile device.
As mentioned above, Category 6 terminal is provided for secure access systems. Secure access systems can be directed to access and/or identification systems. The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal, e.g., terminal 320, performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal SDK is an EMV terminal implementing a full EMV access kernel according to access terminal specifications. The full terminal SDK can be based on a contactless reader SDK or implemented in a mobile device operating system, e.g., for a phone, tablet or similar mobile device. In this implementation, ATC updates can be deferred or provided in real-time and certification requirements are medium.
As mentioned above, Category 7 terminal is provided for access and/or transit systems. In particular, the Category 7 terminal is provided for an open transit system. The credential for this type of system is a hashed PAN and CDA. CDA, which is also referred to as combined data authentication, involves including the card decision among the data being signed by the card's RSA key (public key or asymmetric key algorithm). In this implementation, the terminal, e.g., terminal 320, performs a zero dollar ($0) authorization CDA transaction. The vendor's terminal is an EMV terminal implementing full EMV access kernel according to access terminal specifications. In this implementation, ATC updates can be deferred and full certification is required.
As mentioned above, Category 8 terminal is provided for access and/or payment systems. In particular, the Category 8 terminal is provided for retail innovation systems. Retail innovation can be directed to merchant retail stores and/or payments. The credential for this type of system is a hashed PAN and CDA. In this implementation, the terminal, e.g., terminal 320, performs full EMV transactions from the terminal and/or cloud POS SDK. The vendor's terminal can include a terminal SDK implemented on a mobile device running a mobile device operating system or be hosted by a cloud POS server. In this implementation, ATC updates are provided in real-time and full certification is required.
In one implementation, the terminal reads an access ID from third party data (tag 9F6E) by using a SELECT command. In this implementation, a get processing options (GPO) command is not issued. This implementation, while simpler to implement, is less secure and subject to card cloning or emulation.
In one implementation, the terminal performs CDA with a GPO command, which will increase the ATC. In this implementation, the access server sends ATC updates to the issuer. This implementation is more secure and ensures that the card/token is genuine.
In one implementation, the SDK can be implemented via contactless reader or via a Cloud POS server.
The subject matter of this disclosure, and components thereof, can be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above. Such instructions can, for example, comprise interpreted instructions, such as script instructions, e.g., JavaScript or ECMAScript instructions, or executable code, or other instructions stored in a computer readable medium.
Implementations of the subject matter and the functional operations described in this specification can be provided in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification are performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output thereby tying the process to a particular machine (e.g., a machine programmed to perform the processes described herein). The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto optical disks; and CD ROM and DVD ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
The discussion above is directed to certain specific implementations. It is to be understood that the discussion above is only for the purpose of enabling a person with ordinary skill in the art to make and use any subject matter defined now or later by the patent “claims” found in any issued patent herein.
It is specifically intended that the claimed invention not be limited to the implementations and illustrations contained herein, but include modified forms of those implementations including portions of the implementations and combinations of elements of different implementations as come within the scope of the following claims. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions may be made to achieve the developers' specific goals, such as compliance with system-related and business related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. Nothing in this application is considered critical or essential to the claimed invention unless explicitly indicated as being “critical” or “essential.”
In the above detailed description, numerous specific details were set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the invention. The first object or step, and the second object or step, are both objects or steps, respectively, but they are not to be considered the same object or step.
The terminology used in the description of the present disclosure herein is for the purpose of describing particular implementations only and is not intended to be limiting of the present disclosure. As used in the description of the present disclosure and the appended claims, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context. As used herein, the terms “up” and “down”; “upper” and “lower”; “upwardly” and downwardly”; “below” and “above”; and other similar terms indicating relative positions above or below a given point or element may be used in connection with some implementations of various technologies described herein.
While the foregoing is directed to implementations of various techniques described herein, other and further implementations may be devised without departing from the basic scope thereof, which may be determined by the claims that follow. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
This application claims the benefit of U.S. provisional patent application Ser. No. 63/189,890, filed May 18, 2021 and titled IDENTITY, PAYMENT AND ACCESS CONTROL SYSTEM, the entire disclosure of which is herein incorporated by reference.
Number | Date | Country | |
---|---|---|---|
63189890 | May 2021 | US |