This table summarizes the applicable specifications versions.
| Specifications |
|---|
| ICC Products |
| PURE Specifications for Issuers and Acquirers Dual-Interface cards v1.5.3.e/.g/.h |
| PURE Specifications for Issuers and Acquirers Contact cards v1.5.3.e/.g/.h |
| Kernel Products |
| PURE contactless reader Specifications for PURE Dual-Interface cards and Mobile PURE v2.1.8 |
| Cloub-Based Mobile Payment Solutions |
| PURE Cloud-Based Payment Solution Specifications version v1.3 |
| PURE Cloud-Based Payment Solution Specifications version v1.4.9 |
Versioning notes
The specification providers clarifies the following information about the different specifications versions:
PURE Specifications for Issuers and Acquirers
The version number is formed of 3 numerical fields and one lowercase alphabetical field: <X>.<Y>.<Z>.<a>
- <X> represents the technology family of the specifications. The active family is ‘1’ for generic EMV payment cards, while ‘2’ designates tailored or purposed applications.
- <Y> represents a major functional evolution that does not guarantee to maintain backward compatibility with earlier releases.
- <Z> represents a functional evolution where backwards compatibility has been maintained. This allows newer product to remain interoperable with existing environments as well as configuring newer environments to accept older products.
- <a> indicates an incremental editorial release for a constant functional and behavioral perimeter. Such releases are typically motivated by clarifications of typological corrections.
Considering the above information, a user of the PURE Specifications for Issuers and Acquirers who is interested in ensuring the interoperability of elements across a payment system will need to primarily focus on the <X>.<Y> part of the version and optionally <Z> to evaluate the specific dispositions to take in order to remain in the backwards compatibility tolerance of elements from different specifications versions. <a> does not need to be taken into consideration.
A user of the PURE Specifications for Issuers and Acquirers who is interested in implementing and testing a product is encouraged to use the most recent version accepted by the authority on the targeted market. In particular, the most recent <a> of a given <X>.<Y>.<Z> is encouraged to benefit from all clarifications, and doesn’t prevent to apply for a certification on a lower <a> value.
PURE contactless reader Specifications for PURE Dual-Interface cards and Mobile PURE
The version number is only formed of 3 numerical fields: <A>.<B>.<C>
- <A> represents a major functional evolution that does not guarantee to maintain backward compatibility with earlier releases.
- <B> represents a functional evolution where backwards compatibility has been maintained. This allows newer product to remain interoperable with existing environments as well as configuring newer environments to accept older products.
- <C> indicates an incremental editorial release for a constant functional and behavioral perimeter. Such releases are typically motivated by clarifications of typological corrections.
To this date, two versions of these specifications have been published (2.1.7 and 2.1.8). Following the above information, they are functionally equivalent: Besides some editorial adaptions and clarifications, the main update of v2.1.8 is the following Acquirer options having been moved to being Implementation options:
- Support of long tap for Issuer Response communication
- Support of additional tap for Issuer Response communication
- Support of torn transaction recovery using ECHO command
Consequently, only a payment system that relies on these features will need to make sure that they are been implemented in a 2.1.8 product. In other cases, the payment system can indifferently use product implemented after 2.1.7 or 2.1.8 versions.
An implementer is rather encouraged to consider the more recent version to benefit from all clarifications, as well as align better with up-to-date certification tools.