Common Payment Applications
  1. What is the difference between CCD and CPA?
  2. How can I get a copy of the specification?
  3. Does an issuer have to implement all the functionality in CPA?
  4. What is an issuer-option?
  5. What is an implementer-option?
  6. Does a card vendor have to implement all the functionality in CPA?
  7. How should the card respond to a Get Data command if the data element requested has more than 255 bytes of data (for example, in a CIACs Entries template with many sets of CIACs)?
  8. When an error occurs what status word should be returned?
  9. Why are the Application Block and Card Block commands not included in CPA?
  10. How many Limit Entries must be supported or can be supported?
  11. A bulletin says something is optional to implement, but the change to the specification says "shall". Is it mandatory or optional?
  1. What is the difference between CCD and CPA?

    CCD (Common Core Definitions) describes a minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction. CCD is not a functional application specification.

    CPA (Common Payment Application) is a functional description of an application that complies with the CCD requirements. CPA implementations must comply with CCD requirements, whereas CCD implementations may not necessarily comply with CPA.

  2. How can I get a copy of the specification?

    The specification is available for download with a royalty-free click license from the EMVCo website in the Specifications section under the heading CPA 1.0.

    In addition to the specification requirements explicit for CPA, CPA implementations must also comply with the CCD requirements included in books 1, 2, and 3 of the EMV Specifications and applicable bulletins to CCD or CPA.

    We recommend that after downloading the specification, you periodically check the EMVCo website for Specification Bulletins that may have been posted to the website.

  3. Does an issuer have to implement all the functionality in CPA?

    The fundamental principle behind CPA was to specify an application that would comply with CCD and would have the functionality commonly needed by most issuers, so that an issuer could use any CPA card and be confident that the card could be personalised to meet their business needs for a chip card program. Many of the features in the card that are mandatory for the Product Provider to support are optional for the issuer to use (see "What is an issuer-option?") subject to brand rules.

  4. What is an issuer-option?

    It refers to functionality that must be supported by the card, but is optional for an issuer to use. The issuer may choose whether or not to activate the option at the time of personalisation. The card must support the behaviour associated with the option being activated (or turned on) and also must support the behaviour associated with the option being deactivated (or turned off).

  5. What is an implementer-option?

    It refers to functionality that is optional for an application vendor and card manufacturer to support in their application or card. An issuer that wants to take advantage of such functionality must ensure that the card they use supports the implementer-option.

    The following table clarifies the implications for each implementer-option specified in CPA:

    Implementer-option

    If the option is not supported, the application must:

    If the option is supported, the application must:

    EMV CPS

    Support a proprietary method for personalisation which is capable of personalising the EMV and CPA data according to CPA sections 21.1 and 21.3.

    Support personalisation of the EMV and CPA data according to CPA sections 21.1, 21.2 and 21.3. The application may also support a proprietary method for personalisation which is capable of personalising the EMV and CPA data according to CPA sections 21.1 and 21.3.

    Dynamic-RSA

    Support:

    (i) offline plain-text PIN, and

    (ii) SDA

    Support:

    (i) offline plaintext PIN,

    (ii) offline enciphered PIN, and

    (iii) SDA, DDA, and CDA

    VLP

    Support:

    (i) the generic Profile Selection functionality and the option to use the default profile, and

    (ii) the CPA profile functionality for non-VLP profiles

    Support:

    (i) the generic Profile Selection functionality and the option to use the default profile,

    (ii) the functionality to determine whether to select the VLP profile,

    (iii) the CPA profile functionality for non-VLP profiles, and

    (iv) the functionality associated with the VLP profile

    Profile Selection Using Card Data

    Support: Profile Selection without appending a PSD to the beginning of the data received in the GPO command from the terminal

    Support personalisation of the GPO parameters template with any value in the range '00' to 'FF' allowed for the Profile Selection Diversifier associated with any tag in the template.

    Specify for issuers the tag within the GPO parameters template that is associated with a specific card data (e.g. AID 1 uses tag 'DF01'; AID 2 uses 'DF02')

    Add the appropriate PSD value to the beginning of the data received in the GPO command from the terminal as described in Annex A2.1

    Application Security Counters

    Meet the security requirements in section 20 and pass the security evaluation process

    Support the security counters as described in Annex F and meet the security requirements in section 20, and pass the security evaluation process.

     

  6. Does a CPA product have to implement all the functionality in CPA??

    Except for functionality that is described in CPA as implementer-optional (and the examples of additional functionality described in section 19), a CPA product must support all the functionality described in CPA in order to be considered a CPA implementation.

  7. How should the card respond to a Get Data command if the data element requested has more than 255 bytes of data (for example, in a CIACs Entries template with many sets of CIACs)?

    CPA does not require support for more than 255 bytes in the response to the GET DATA command. An EMV financial terminal is not expected to accept longer data.

    Such behaviour is theoretically possible if the issuer personalises a template with more than 255 bytes, or reserves more than 255 bytes at personalisation and updates the contents (using PUT DATA) to more than 255 bytes. However, it is highly unlikely for a normal card implementation.

    The card should respond with SW1SW2 = '6A81' or '6A88'; or may support returning the longer data as an additional functionality.

  8. When an error occurs what status word should be returned?

    CPA does not necessarily describe all the error checking that may be included in a specific implementation. The application may do additional checking beyond the minimum defined in CPA, as allowed by the following wording in section 6.4.1:

    Application implementations may respond with other status words to indicate conditions in addition to those specified in CPA. For instance, applications may respond with implementation-specific status words when data required for the execution of a function is not present (that is, has not been personalised) or when data is corrupt. These additional status words are left to the implementation.

  9. Why are the Application Block and Card Block commands not included in CPA?

    The same functionality is available using bits in the Card Status Update data element, so the commands were not needed in CPA. CPA implementations may support these commands as additional functionality. If they are implemented, it is recommended to implement them as described in EMV Book 3.

  10. How many Limit Entries must be supported or can be supported?

    All CPA applications must support up to 6 Limit Entries (and for some data elements, the application should also be able to support not using any of the data element). The application is allowed to support more than 6 Limit Entries up to a maximum of 14 Limit Entries.

    The issuer is not required to use all 6 Limit Entries. With the exception of "Accumulator x", "Counter x", "Cyclic Accumulator x", and "Additional Check Table x", they do not have to be labelled in consecutive order (for example, they could be personalised as Limit Entry 2, Limit Entry 8, Limit Entry 9, Limit Entry 7, Limit Entry 3.

  11. The bulletin says something is optional to implement, but the change to the specification says "shall". Is it mandatory or optional?

    To minimize impact on implementations in progress, update bulletins are typically introduced as optional for an initial period of time.

    However, so that issuers can be assured that all CPA implementations include a core set of features; one basic premise of CPA is to minimize the number of items that are optional for a vendor to implement. Thus, most bulletins will eventually become either mandatory or conditional on support of an implementer-option.

    When determining whether to implement a bulletin, the vendor must consider whether the bulletin will be optional or mandatory at the time the product is to be submitted for EMVCo approval. The bulletin contains the wording that would apply if the bulletin were to be implemented.