PCI Watch

Tracking changes across the Payment Card Industry

SB n° 300: PICC Presence Check

v1.0 Specification Bulletins
Contactless Acceptance Device

EMV® Specification Bulletin No. 300 First Edition June 2024 PICC Presence Check Procedure This Specification Bulletin introduces the presence check procedure.

Applicability

This Specification Bulletin applies to:

  • EMV Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification, Version 3.2 – July 2022.

Related Documents

  • None

Description

This Specification Bulletin introduces the presence check procedure. This procedure checks for the continued presence of the PICC inside the operating volume of the PCD after the PICC transaction processing is completed. It provides an alternative way to the removal procedure to ensure that the PICC has been removed from the PCD operating volume. Proposed Specification Changes Update section 2.5 as follows: … Besides the various protocol layers, this document also deals with the specification of the state machine of the PICC and the specification of the PCD processing (polling, collision detection, activation, removaltransaction completion, and exception processing). … Chapters 5 and 6 specify the commands that are available to the PCD for the polling, collision detection, activation, and removaltransaction completion procedures. Chapter 5 lists the requirements related to Type A commands and responses. Chapter 6 does the same for the Type B commands and responses. … Chapter 9 specifies the PCD processing during polling, collision detection, PICC activation, and PICC removal detection during transaction completion. This chapter includes a detailed description of the specific requirement that the PCD does not initiate the transaction if more than one PICC is detected in the Operating Field. … Update section 5 as follows:

countries.

… This chapter specifies the Type A commands that are available to the PCD for the polling, collision detection, activation and removaltransaction completion procedures. Commands and responses are transmitted within frames as specified in section 4.7. … Update section 6 as follows: … This chapter specifies the Type B commands that are available to the PCD for the polling, collision detection, activation and removaltransaction completion procedures. Commands and responses are transmitted within the frames as specified in section 4.7. … Update section 9 as follows: … This chapter specifies the functionality implemented in the PCD. This includes the polling, collision detection, activation and removaltransaction completion procedures. The transmission protocol used to process the transaction is specified in Chapter 10. The actual transaction processing is at the application layer and outside the scope of this specification. … Update section 9.1.1 as follows: … 5. In some environments it is necessary to ensure that the PICC has left the field by employing either a removal procedure or a presence check procedure. The removal procedure is specified in section 9.5.1, and the presence check procedure is specified in section 9.5.2. When the PICC is removed from the Operating Field, the PCD resets the Operating Field (as defined in section 3.2.6), waits during a time tPAUSE with unmodulated carrier (optional) and resumes with the polling and collision detection (optional). The value of tPAUSE is implementation specific. In other environments where the physical configuration and the way the transaction completes may be sufficient to ensure no overlapping transactions, the removal procedure and presence check procedure may be skipped. … Update Requirements 9.1 as follows: Requirements 9.1: PCD Requirements Related to the Main Loop PCD …

countries.

PCD 9.1.2.7 The PCD shall perform the removala transaction completion procedure as specified in section 9.5, when requested to do so by the terminal. … Change Section 9.5 as follows:

9.5 Transaction Completion This section specifies how the PCD proceeds when transaction completion is requested by the terminal. Transaction completion is performed by either a removal procedure or a presence check procedure. Requirements 9.8a: Transaction Completion PCD 9.5.0.1 The PCD shall support either the removal procedure or the presence check procedure.

9.5.1 Removal This section specifies how the PCD proceeds when the removal procedure is executed requested by the terminal. Figure 9.5 shows that the PCD continues polling until the PICC is removed. The implementation of the removal procedure is mandatory for the PCD, but the removal procedure is only executed upon request from the terminal. …

countries.

Include new section 9.5.2 as follows:

9.5.2 Presence Check This section specifies how the PCD proceeds when the presence check procedure is executed. Figure 9.6 shows that the PCD continues checking for the presence of the PICC until the PICC is removed. Requirements 9.9a: Presence Check Procedure PCD 9.5.2.1 The PCD shall wait for a time tP with unmodulated carrier.

9.5.2.2 The PCD shall check for the presence of the PICC by sending an R(NAK) block. If the PCD receives any response (correct or not) to the R(NAK) block, then the PCD shall continue with 9.5.2.3. If the PCD receives no response to the R(NAK) block, then the PCD shall continue with 9.5.2.4.

9.5.2.3 The PCD shall wait for a time tP with unmodulated carrier before continuing with 9.5.2.2.

9.5.2.4 The PCD shall send another R(NAK) block within FWT + ∆FWT + ΔTPCD + tRETRANSMISSION after the previous R(NAK) block. If no response is received, then the PCD shall send a further R(NAK) block within FWT + ∆FWT + ΔTPCD + tRETRANSMISSION after the last R(NAK) block. If the PCD receives any response (correct or not) to these R(NAK) blocks, then the PCD shall continue with 9.5.2.3. If no response is received to the final R(NAK) block, then the PCD shall report a time out error to the terminal and terminate the presence check procedure.

countries.

Figure 9.6: Presence Check Procedure WAIT tP R(NAK) RESPONSE? YES NO R(NAK) RESPONSE? YES NO R(NAK) RESPONSE? YES NO WAIT tP

countries.

Update Requirements 9.10 as follows: Requirements 9.10: Exception Processing PCD … 9.6.1.2 On detection of a protocol error (except during the polling and removaltransaction completion procedures):

  • The PCD shall report the protocol error to the terminal, reset the Operating Field (as defined in section 3.2.6), and return to the polling procedure.
  • The PCD shall start the reset of the PICC no later than tRESETDELAY measured from the start of the response frame containing the protocol error (i.e. the start of SoF for Type A response and the start of SoS for a Type B response as defined in section 4.8).

9.6.1.3 On detection of a time-out error (except during the polling and removaltransaction completion procedures):

  • The PCD shall retransmit the command a maximum of two times.
  • For the SELECT and ANTICOLLISION commands, the PCD shall retransmit the command after FDTPICC,MAX + tMIN,RETRANSMISSION and before FDTPICC,MAX + tRETRANSMISSION.
  • For the RATS and ATTRIB commands, the PCD shall retransmit the command after FDTPICC,MAX + tMIN,RETRANSMISSION and before FDTPICC,MAX + ΔTPCD + tRETRANSMISSION. Refer to Annex A.5 for the value of tMIN,RETRANSMISSION.
  • If on the second retransmission (third transmission), no valid response has been received:
  • The PCD shall report a time-out error to the terminal, reset the Operating Field (as defined in section 3.2.6) and return to the polling procedure.
  • The PCD shall start the reset of the PICC no later than tRESETDELAY after the maximum allowed response time applicable for the command. countries. Update Requirements 10.12 as follows: Requirements 10.12: Block Handling Rules for the PCD PCD 10.3.4.3 When an R(ACK) block is received with a block number not equal to the PCD’s current block number, then the PCD shall re-transmit the last I-block if this R(ACK) block is received in response to an R(NAK) block sent by the PCD to notify a time-out. In all other cases, when an R(ACK) block with a block number not equal to the PCD’s current block number is received, then the PCD may directly report a protocol error to the terminal or the PCD may re-transmit the last I-block, unless this R(ACK) block is received in response to an R(NAK) block sent by the PCD to perform the presence check procedure.

10.3.4.4 When the PCD has re-transmitted an I-block two times (i.e. same I-block sent 3 times), if an R(ACK) block with a block number not equal to the PCD's current block number is received, it shall be considered as a protocol error.

10.3.4.5 When an R(ACK) block is received, if its block number is equal to the PCD’s current block number and the last I-block sent by the PCD indicated chaining, then chaining shall be continued. If the last I-block sent by the PCD did not indicate chaining, then the PCD shall consider the R(ACK) block as a protocol error.

10.3.4.6 When an R(NAK) block is received by the PCD, it shall be considered as a protocol error.

countries.

Update Requirements 10.15 as follows: Requirements 10.15: Exception Processing – PCD PCD … 10.3.5.9 If no error recovery is possible, then the PCD shall reset the Operating Field (as defined in section 3.2.6). At this stage it is up to the implementation to define how terminal and PCD continue processing. Options include (but are not limited to):

  • Wait with unmodulated carrier for a time tPAUSE and resume with the polling procedure as specified in section 9.2.
  • Continue with the removal procedure as specified in section 9.5.1. Note that in this case the reset of the Operating Field in requirement 9.5.1.1 should be skipped.
  • Power-off of the Operating Field as specified in section 3.2.9 countries.

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications

countries.