The transaction processing for chip electronic commerce is presented in Annex D of Book 3 in the EMV 2000 specifications . It extends the SET specification by including an EMV ¢ chip card in the configuration of the cardholder access device. The EMV ¢ chip card allows both on-line card authentication, through the generation of an Application Cryptogram by the card, and cardholder verification, through the use of an optional cardholder PIN. The transaction flow of the chip electronic commerce is presented in Figure 8.11.
This transaction flow abstracts the cardholder access device to the interaction between the cardholder system and an EMV ¢ chip card. It does not, however, consider the internal communication between the components of the cardholder system. In Section 8.5.3 we considered the case when the cardholder system consists of two components: a thin client and a remote wallet server.
Following the browsing/ordering phase, the merchant server has all the necessary data to start the payment phase. To this end, it creates the SET Initiation message (see Section 188.8.131.52) and invokes the cardholder system. This initiation message includes data about the transaction details (like the order description, purchase amount, and transaction currency code), the list containing the identifiers (BrandID1, BrandID2, , BrandIDn) of all the acceptable card payment brands for the merchant, and the URL referencing the file that contains the corresponding electronic decals of the acceptable payment brands for the merchant. Once this file is downloaded from the merchant server, the cardholder system can also display the corresponding decals of the acceptable brands. The cardholder system presents to the cardholder all the payment options available at the merchant site.
The cardholder system asks the cardholder to perform the account selection and card selection stage. The cardholder is offered the possibility of selecting the preferred payment brand, and indicating the appropriate payment account and the corresponding card. If this card is an EMV ¢ chip card, the cardholder is prompted to insert the chip card in the ICC interface device. The chip card should not be removed from the ICC interface device until the cardholder system explicitly asks the cardholder to do so.
At present, the EMV ¢ message manager overtakes the processing in the cardholder system. It performs a restricted EMV ¢ transaction, the profile of which is limited to the following stages:
Application selection (see Section 4.4);
Initiate application processing (see Section 6.2);
Read application data (see Section 6.3);
Cardholder verification (see Section 6.6);
Terminal action analysis (see Section 6.8);
Issuer script processing and completion (see Section 6.10).
Considering that the authorization of a transaction in the e-commerce environment is always performed on-line by the issuer, the cardholder system skips the processing corresponding to the off-line data authentication (see Section 6.4), the processing restrictions (see Section 6.5), and the terminal risk management (see Section 6.7) stages.
During the interaction between the cardholder system and the EMV ¢ chip card, the cardholder system can be seen as a terminal that runs an EMV ¢ terminal application. This terminal application is setup with the following parameters:
The Terminal Type (tag 9F35) indicates the cardholder system's environment, its communication capabilities, and its operational control (see Section 6.5.2). In the chip electronic commerce framework, the cardholder system behaves as an unattended terminal, which is connected on-line to the issuer and is under the control of the cardholder. This corresponds to the Terminal Type = 34 (Annex A1 of Book 4 in the EMV 2000 specifications).
The type of financial transaction performed by the cardholder system with a remote merchant server limits to the purchase of goods and services. This means that the value field of the Transaction Type (tag 9C) data object is always 00.
The processing performed by the cardholder system is dynamically reflected in only a few bits of the TVR, the rest being statically set, since the corresponding stages of the EMV ¢ transaction are skipped .
In the first byte of the TVR only bit 6, "IC Card Data missing", is dynamically set, following the evaluation of the mandatory card data objects received from the EMV ¢ card. Since the off-line data authentication is not included in the transaction profile, bit 8, "Off-line data authentication was not performed", is set to 1, while all the other bits in byte 1 of the TVR are statically set to 0.
The bits in the second byte of the TVR, reflecting the results of the processing restrictions, and the bits of the fourth byte of the TVR, corresponding to the terminal risk management, are statically set to 0 since these stages are not performed in the chip e-commerce EMV ¢ transaction. Only bit 8 in byte 4, "Transaction exceeds floor limit", is statically set to 1 to indicate that all the transactions must be forced on-line, regardless of the amount authorized.
The bits in the third byte of the TVR, corresponding to the results of the cardholder verification processing, and the bits in the fifth byte corresponding to the issuer script processing, are dynamically set following the status of the processing performed by the cardholder system.
First, the cardholder system builds the list of applications supported by the merchant (see Section 4.4), taking every BrandID included in the SET initiation message and searching for an equivalent AID in the BrandID-AID table. The content of this equivalence table is regularly updated by the cardholder system, which downloads it from a dedicated server on the Internet.
Second, using the list of applications supported by the merchant, the cardholder system performs the application selection mechanism. The result of this mechanism is the application candidate list.
If the candidate list is empty, the cardholder system either automatically updates the BrandID-AID table or it prompts the cardholder to confirm that the correct EMV ¢ chip card is used.
If this confirmation is provided, the cardholder system updates the BrandID-AID table. If, after the update, a mutually supported application cannot be found, the cardholder system requests that the card be removed from the interface device, and the card selection phase is repeated.
Otherwise, the cardholder system requests that the card be removed from the interface device, and the card selection phase is repeated.
If there is one or several common applications in the candidate list, the cardholder system displays them, allowing the cardholder to participate in the final application selection (see Section 4.4.3).
If an Application Preferred Name (tag 9F12) is provided in the FCI of a common ADF (see Section 184.108.40.206), the cardholder system must display the name of the application according to this string. To this end, the cardholder system uses the Issuer Code Table Index (tag 9F11), which must be present in the FCI, to choose the appropriate alphabet code table. This table allows displaying the characters in the alphanumeric string application preferred name. Therefore, the cardholder system has to keep the ISO 8859 code tables, which allow the correct decoding of alphanumeric strings in various alphabets.
If there is no Application Preferred Name in the FCI of a common ADF, the cardholder system will use the Application Label (tag 50), which is mandatory for inclusion in an FCI to display the common application.
If the FCI of an ADF includes the FCI Issuer Discretionary Data template, the cardholder system will retrieve the Issuer URL (tag 5F50) data object from this template. The value field of this data object references the visual image of the brand logo associated with the ADF on the payment system operator's server. This logo file is then brought into and displayed on the cardholder system, besides either the Application Preferred Name or the Application Label.
After the final application selection is performed, the cardholder system obtains the FCI of the ADF that hosts the selected EMV ¢ card application. The cardholder system stores, for future use, the following data objects: the AID of the selected application (tag 4F or tag 84), the Language Preference (tag 5F2D), and the PDOL (tag 9F38), if the last two data objects were personalized in the FCI.
During the initiate application processing, the selected EMV ¢ card application may require in the PDOL (see Section 6.2.2) a number of data objects from the cardholder system. These data objects describe the transaction details that are relevant for the EMV ¢ card application, as they are known to the cardholder system after receiving the SET initiation message from the merchant server. The cardholder system sends the GET PROCESSING OPTIONS command to the card application, including the values of the required data objects. Taking into account the transaction details received from the cardholder system, the EMV ¢ card application can adapt its strategy to best suit the business environment (see Section 7.6). Consequently, the EMV ¢ card application informs the cardholder system through the AIP (see Section 6.2.3) about the transaction profile it supports, and particularly whether it supports the cardholder verification phase or not. The EMV ¢ card application also informs the cardholder system about the content and organization of its public data, through the AFL (see Section 6.2.3).
During the read application data (see Section 6.3), the cardholder system retrieves the publicly available content of the card application, following the indications it received in the AFL. The cardholder system checks whether the mandatory data objects are present (see Section 6.3.2): Application Expiration Date (tag 5F24), Application PAN (tag 5A), CDOL1 (tag 8C), and CDOL2 (tag 8D). If the cardholder verification stage is supported by the card application (bit 5 = 1 in the first byte of AIP), the cardholder system must verify the presence in the card of the CVM List (tag 8E). The cardholder system stores the mandatory data objects, and eventually the CVM, for future use. It also checks whether the Application PAN Sequence Number (tag 5F34) and the track-2 equivalent data (tag 57) are personalized in the card. The IH could require the track-2 equivalent data for accomplishing an online PIN verification. If these two last data objects are personalized in the card, the cardholder system also stores them for further processing.
After establishing the EMV ¢ transaction context, from the EMV ¢ card application and the order information received in the SET Initiation message, the cardholder system initiates the SET purchase transaction, through the PInitReq and PInitRes messages.
The cardholder system creates the PInitReq as described in Section 220.127.116.11, except that for the BrandID, BIN, and the cardholder's preferred language data items, the cardholder system uses appropriate data objects retrieved from the EMV ¢ card application. The following processing is performed by the cardholder system:
The identifier of the card brand to be used BrandID is obtained from the AID of the selected card application (tag 4F or tag 84). To this end, search the AID in the BrandID-AID table and obtain the equivalent brand identifier BrandID corresponding to this AID.
The bank identification number ( BIN ) is formed from the first 6 digits of the Application PAN (tag 5A) as retrieved from the EMV ¢ card application.
The cardholder's preferred language is obtained from the Language Preference (tag 5F2D) data object retrieved from the FCI of the selected EMV ¢ card application.
The merchant server processes the PInitReq received from the cardholder system and elaborates the appropriate PInitRes towards the cardholder system in the same way as when no EMV ¢ chip card is involved.
After receiving PInitRes, the cardholder system performs the same processing as that described in Section 18.104.22.168. The cardholder system checks the existence of the private SET certificate extension SETExtensions in the entity_data of the key-exchange public key certificate Cert_pKE of the payment gateway (see Section 22.214.171.124). The SETExtensions lists the SET message extensions for payment instructions that the payment gateway supports. Each available SET message extension is indicated with an OID.
For the scope of the chip e-commerce framework there are two meaningful OIDs:
id-set-PIN-Any-Source: This OID means that the payment gateway accepts the extending of the SET messages to allow the verification of an on-line PIN by the issuer. The cardholder's PIN can be entered via any device, including the normal keyboard of a PC .
id-set-commonChip: This OID indicates that the payment gateway is able to transmit the minimum EMV ¢ data elements and the AC to the acquirer, which can forward them via the appropriate payment network to reach the issuing financial institution. The minimum EMV ¢ data elements allow the issuer to verify the cryptogram produced by the EMV ¢ card application during the terminal action analysis stage (first GENERATE AC ). Thus, the issuer can implement the on-line card authentication method .
The cardholder system conditionally performs the cardholder verification stage:
If bit 5 = 1 in the first byte of the AIP, the cardholder system performs the cardholder verification.
Otherwise, the cardholder system directly processes the terminal action analysis stage of the EMV ¢ transaction.
During the cardholder verification stage, the cardholder system obtains enough information from the cardholder to allow identity verification, either directly presenting it to the EMV ¢ chip card or transmitting it on-line to the issuer for verification.
Regardless of the type of cardholder verification method negotiated between the cardholder system and the EMV ¢ card application, the common processing performed by the cardholder system is described in Section 6.6.3, where the cardholder system abstracts the terminal application.
In this stage of the processing, the cardholder system knows the OIDs of the SET message extensions supported by the payment gateway and the CVM List (tag 8E) from the EMV ¢ card application. Based on this information, the cardholder system decides whether the cardholder verification method can be off-line PIN verification by the EMV ¢ card application, online PIN verification by the issuer, or another proprietary method specified by the payment system. The decision process performed by the cardholder system is as follows :
The cardholder system will prompt for off-line PIN entry if the following two conditions are simultaneously fulfilled:
The CVR of the current method in the CVM List indicates that the cardholder verification is the off-line PIN verified by the card.
The id-set-commonChip is among the OIDs of the SET message extensions supported by the payment gateway, as indicated in the key-exchange public key certificate Cert_pKE . If this OID is present, it indicates that the payment gateway can transport the ARQC to the issuer for on-line card authentication. If the card authentication is successful, the issuer also has a physical proof of the legitimate cardholder's participation in the transaction, since only a correct verification of the PIN by the card would have triggered the computation of the ARQC.
In case both conditions are fulfilled the cardholder system continues the processing of the off-line PIN as presented in Section 6.6.4.
If the second condition mentioned above is not fulfilled, the cardholder system will not prompt for off-line PIN entry, but shall attempt processing the next CVR in the CVM List.
The cardholder system will prompt for on-line PIN entry if the following two conditions are simultaneously fulfilled:
The CVR of the current method in the CVM List indicates that the cardholder verification is the on-line PIN verified by the issuer.
The id-set-PIN-Any-Source is among the OIDs of the SET message extensions supported by the payment gateway, as indicated in the key-exchange public key certificate Cert_pKE . If this OID is present, it indicates that the payment gateway can transport the PIN suitably encrypted to the issuer for on-line cardholder verification.
In case both conditions are fulfilled the cardholder system continues the processing of the on-line PIN as outlined in Section 6.6.5.
If the second condition mentioned above is not fulfilled, the cardholder system will not prompt for on-line PIN entry, but shall attempt processing the next CVR in the CVM List.
The cardholder system conditionally performs the terminal action analysis. This stage of the EMV ¢ transaction is performed only when the id-setcommonChip is among the OIDs of the SET message extensions supported by the payment gateway, as indicated in the key-exchange public key certificate Cert_pKE .
The cardholder system abstracts the terminal application in its interaction with the EMV ¢ card application, following the processing described in Section 6.8, with several exceptions mentioned below.
The cardholder system always asks for an ARQC as a reference control parameter of the GENERATE AC command, without comparing the TVR against the Issuer Action Codes, personalized in the card, or against the terminal action codes.
Concerning the data objects required by the EMV ¢ card application in the CDOL1, the cardholder system performs the following processing:
The value field of the Amount, Authorized is obtained by extracting the amount component from the PurchAmt parameter as specified in the SET initiation message. Note that the value field of the Amount, Other is zero since there is no cashback in the e-commerce purchase transaction.
The value field of the Transaction Currency Code is obtained by extracting the currency code component from the PurchAmt parameter as specified in the SET initiation message.
The value field of the transaction date, in the format YYMMDD, is obtained from the PReqDate data item, delivered in the format YYYYMMDD in the PInitRes message, by striping the two leftmost YY digits.
The value field of the Transaction Type is equal to 00, corresponding to the purchase of goods or services, representing a parameter of the cardholder system.
The value field of the TVR is that one set up by the cardholder system, during the processing of the EMV ¢ transaction.
The value field of the Terminal Country Code is obtained from the merchant country code data item included in the merchant_data characterizing the merchant. This data is retrievable from the merchant's signature public key certificate Cert_mKV , which is included in the PInitRes.
The cardholder system does not create the value field of the Unpredictable Number at random, but diversifies it from the XID component of the TransID (which is included in the PInitRes). This allows the payment gateway to regenerate it following the same diversification algorithm.
In response to the GENERATE AC command, the EMV ¢ card application computes either the ARQC, as required by the cardholder system, or an AAC, if the card risk management decided to reject the transaction. This cryptogram is returned to the cardholder system together with the following data objects:
Cryptogram Information Data (mandatory);
Application Transaction Counter (ATC, mandatory);
Issuer Application Data (IAD, optional).
If the terminal action analysis is accomplished with an AAC, as a result of the first GENERATE AC , then the cardholder system terminates the transaction and informs the cardholder that it is now permissible to withdraw the EMV ¢ card from the interface device.
The cardholder system creates the PReq, taking into account whether:
The cardholder has a signature public key certificate Cert_cKV ;
The cardholder verification method is performed and which is its type (on-line/off-line);
The terminal action analysis is performed and which is the type of its result cryptogram (ARQC or AAC).
The decision processing is described below. If the cardholder has a signature public key certificate Cert_cKV , the cardholder system will compute the dual signature DS . Compared to the processing described in Section 126.96.36.199, the following modifications are enacted concerning the content of some data elements in OIData and PIData:
In the PANData template of PIData:
The PAN item consists of the value field of the PAN data object with tag 5A as it is read from the EMV ¢ card application.
The CardExpiry data item, which is in the format YYYYMM, is obtained from the value field of the Application Expiration Date (tag 5F24), which is in the format YYMMDD, making the following format conversion. The cardholder system transforms the YY value from the Application Expiration Date into a four-digit year YYYY as prescribed by the EMV ¢ norms.
In the OIData the items BrandID, BIN , and Language are filled in with the corresponding value fields of the data objects read from the EMV ¢ card, according to the processing and conversion rules already explained in conjunction with the PInitReq message (see Section 8.6.2).
If the cardholder verification method selected by the cardholder system is on-line PIN verified by the issuer, the following supplementary processing is required in conjunction with elaborating PReq:
After the cardholder system captures the PIN, either via a functionally secure encrypting PIN entry device or via a PC keyboard entry with software encryption, the PIN is first transformed into a PIN field of 8 bytes. The PIN filed is submitted to an XOR operation with the account number field, also of 8 bytes, which is obtained from the PAN. The result of the XOR operation is a plaintext PIN block. In this way the PIN is bound to the PAN, preventing the swapping of PAN versus PIN, and assuring that enciphering the same PIN value under a given key shall not produce the same ciphertext for different accounts. Before including it into the digital envelope C (see Section 188.8.131.52), which is currently used for wrapping the PAN and the session key SSK, the plaintext PIN block of 8 bytes is encrypted with SSK (i.e., ePINBlock = DES(SSK)[plaintext PIN block]). Thus, the digital envelope becomes C = RSA( pKE )[ SSK PAN ePINBlock]. This digital envelope is included in the confidential and authentic channel P established by the cardholder system with the payment gateway, which is transmitted in the PReq and is tunneled by the merchant server.
The content of the PANData template is also modified to include besides the PAN, CardExpiry, PANSecret , and EXNonce , an extra data item: the plaintext PIN block.
If the terminal action analysis is accomplished with an ARQC, the cardholder system creates the commonChip extension in the PIHead portion of PIData. The following EMV ¢ data objects, in the TLV format, are included in any order in the emvData field of the commonChip extension:
EMV ¢ data objects processed in relation with the CDOL1:
Transaction details: Amount, Authorized (tag 9F02), Amount, Other (tag 9F03), Transaction Currency Code (tag 5F2A), Transaction Date (tag 9A), and Transaction Type (tag 9C);
Terminal environment: Terminal Verification Results (tag 95), Terminal Country Code (tag 9F1A), and Unpredictable Number (tag 9F37).
The sources from where the aforementioned data objects were obtained by the cardholder system, and the corresponding processing is presented in Section 8.6.4.
Application Interchange Profile (tag 82), as it was obtained by the cardholder system in the response to the GET PROCESSING OPTIONS command (see Section 184.108.40.206);
Application PAN Sequence Number (tag 5F34) as it was read from the EMV ¢ card application;
Track-2 equivalent data (tag 57), as read from the EMV ¢ card application, whose PAN and expiration date fields are overwritten with 0;
Data objects returned by the EMV ¢ card application in the response to the first GENERATE AC : Application Cryptogram (tag 9F26), Application Transaction Counter (tag 9F36), Cryptogram Information Data (tag 9F27), and Issuer Application Data (tag 9F10).
The payment gateway processes the AuthReq as described in Section 220.127.116.11, with the following modifications:
Use the payment gateway's private decryption key pKD to open the digital envelope C originated by the cardholder and tunneled by the merchant. Obtain the symmetric key SSK and the cardholder's account information, and check whether the cryptogram of the PIN block is inside the envelope (i.e., SSK PAN ePINBlock = RSA ( pKD ) [ C ]). If the payment gateway supports on-line PIN processing, the rest of the processing described in this paragraph is performed inside a secure module. The ePINBlock cryptogram is decrypted with SSK to obtain the plaintext PIN block as DES ˆ’ 1 (SSK) [ePINBlock]. The plaintext PIN block is submitted to an XOR operation with the account number field, which is obtained from the PAN, to recover the PIN field. Convert this PIN field to another PIN block format if needed, reencrypt it under symmetric encryption, and then pass the reencrypted PIN in the 1100 authorization request message (see also Section 6.6.6). This message is directed via the acquirer to the appropriate payment network and further to the issuer.
Use SSK to decrypt C' and to obtain the payment message, PIData DS H( OIData ) = DES ˆ’ 1 (SSK) [ C' ]. Check whether the commonChip extension is included in the PIHead part of PIData . If so, recompute the Unpredictable Number using the same data and algorithm like those involved by the cardholder system. Compare the result with the value field of the data object with tag 9F37 as included in the emvData field of the commonChip extension. If the two values are different, proceed directly to elaborate an AuthRes with the error code piAuthMismatch in the AuthCode, with no need to format the 1100 authorization request message.
Format the 1100 Authorization Request message and forward it to the acquirer. The acquirer delivers the message to the appropriate payment network, which forwards it to the card issuer. The issuer evaluates the 1100 Authorization Request and decides on the authorization or the rejection of the transaction, sending the adequate 1110 Authorization Request Response back to the payment gateway.
After receiving the 1110 authorization request response message from the issuer, via the payment network and acquirer, the payment gateway creates the AuthRes as outlined in Section 18.104.22.168, with the following additional processing:
If either the Issuer Authentication Data with tag 91(see Section 22.214.171.124) or the issuer script(s) encoded either with tag 71 or 72 (see Section 6.10), or both, are included in the 1110 authorization request response, the payment gateway must transmit them to the merchant server. To this end, the payment gateway prepares the AuthRes that includes the AcqCardMsg. This data template is extended with acqCardExtensions, which transports whatever EMV ¢ data objects were received by the payment gateway from the issuer to be handed over to the merchant server. The merchant server forwards them to the cardholder system in the PResPayload field of the PRes message, which includes the AcqCardMsg with acqCardExtensions and AuthCode.
If the merchant server supplies the data required to capture approved transactions either to the payment gateway or directly to the acquirer, then the merchant server must additionally provide the dataEMV ¢ field of the commonChip extension. This allows for the verification of the authenticity of the card involved in the transaction through the correctness of the cryptogram produced during the terminal action analysis. To be able to provide this additional data during the payment capturing stage, the merchant server has to obtain it from the payment gateway.
If the merchant server is allowed to capture a previously authorized transaction outside the SET, then the payment gateway must provide it with the emvData in clear, as an extension of the AuthResPayload field of the AuthRes.
If the merchant server captures the transaction as specified by SET, then it is sufficient if the payment gateway transmits to the merchant server the emvData through the TokenOpaque field of the capture token.
Whenever the cardholder system does not receive the PRes message in a timely manner, or if the PRes message is processed in due time but the AuthCode is one of the values listed below (with their corresponding meaning), the cardholder system shall perform a second GENERATE AC with the AAC as reference parameter and with the value field of the Authorization Response Code (tag 8A) set to Z3. The cardholder system informs the cardholder that the card can be removed from the interface device.
orderReceived: PReq received by the merchant server and PRes sent back before the AuthRes is returned by the payment gateway.
noReply: The issuer did not respond to the authorization request.
piAuthMismatch: The data from the payment instruction elaborated by the cardholder does not match the order instruction elaborated by the merchant server or the Unpredictable Number recomputed by the payment gateway does not match the value field of the data object with tag 9F37 as included in the commonChip extension.
systemError: The request could not be processed by an upstream system (acquirer, financial network, issuer, etc.) because data in the request is invalid.
Whenever the cardholder system receives the PRes message in a timely manner and the AuthCode does not indicate orderReceived, noReply, piAuthMismatch or systemError, it will perform the following processing:
Examine the contents of the acqCardExtensions of the PRes to determine whether issuer scripts (tag 71 or 72) are present. If scripts are present, they are processed as outlined in Section 6.10.
The cardholder system requires the completion of the EMV ¢ transaction with a second GENERATE AC . To this end, the cardholder system examines the AuthCode of PRes to determine which type of cryptogram it should request.
If the AuthCode indicates one of the error codes (declined, callIssuer, AmountError, expiredCard, invalidTransaction), the cardholder system shall request an AAC and will assign the value 05 to the Authorization Response Code (tag 8A).
If the AuthCode indicates approved, the cardholder system shall request a TC and will assign the value 00 to the Authorization Response Code (tag 8A).
After receiving the card's response to the second GENERATE AC command and after the execution of all issuer scripts present, inform the cardholder that it is permissible to remove the card. The results of the second GENERATE AC are ignored, in the sense that they are not communicated through the capture request message to the payment gateway.