Setting Up a New Terminal: What the Card Rules Require

What the device itself has to do

Table 5-8 opens with requirements that apply to all acceptance devices in all regions. The device must act upon card preferences for cardholder verification and/or request online authorisation — and the rule adds that where the service code, cardholder verification method list or card transaction qualifiers indicate a preference for a cardholder signature, the merchant may process the transaction without the signature. It must accept all 16-digit payment credentials. It must make available to the cardholder all transaction interfaces supported by the merchant. It must be able to read a magnetic stripe and complete a magnetic stripe-read transaction, except for compliant contactless-only devices and for a mobile acceptance device that is both compliant with the PCI-approved solution for commercial off-the-shelf devices and able to complete a payment transaction by other means at the same location. None of that is a preference. It is the baseline the box is supposed to arrive meeting.

Level 3 testing is the acquirer's job, and it has triggers

Section 5.6.2.1 requires an acquirer to successfully complete Visa Global Level 3 testing using the Visa Global L3 Test Set Files before deploying a new chip-reading device, after a significant change to a chip-reading device, and to address an interoperability issue as required by Visa, submitting results through the Chip Compliance Reporting Tool. In the LAC and US Regions, submission via CCRT is not required for acquirers participating in the Global Chip Acquirer Self Accreditation Program. This matters to a merchant for one practical reason: a terminal that arrives configured is the output of a process someone else owns, and "a significant change" includes the kind of firmware or configuration change that happens between your order and your delivery. Asking when the deployed build was last tested is a reasonable question with a real answer.

The PIN pad, and what "activate" means

Table 5-8 requires that for devices in a face-to-face environment, the merchant activate the PIN pad to enable PIN transactions. For contact chip devices, if using an active PIN pad or PIN pad port capable of supporting a PIN, the device must comply with Visa encryption standards and be active for Visa chip-initiated transactions — and if inactive for chip-initiated transactions, support software to ensure compliance with Visa encryption standards. A contact chip device must also be a chip-reading device, be approved by EMVCo, and process the transaction using data read from the chip on a chip card unless the chip is not EMV-compliant, the chip reader is inoperable, the chip malfunctions or cannot be read, or there is no mutually supported Application Identifier. A dead PIN pad on day one is not a cosmetic issue to raise later.

Contactless and tap-to-phone have specific conformance points

For contactless chip, Table 5-8 requires Level 1 EMVCo certification with a full-range proximity coupling device and Level 2 EMVCo or Visa certification; that the device not limit the transaction amount of a contactless transaction; that it forward the form factor indicator field to Visa in the authorisation request and clearing record when provided; and that it be capable of actively enabling and processing a transaction using the qVSDC transaction path. Devices compliant with the Visa Contactless Payment Specification 2.1 or later, or EMV Contactless Book C-3, must set the Reader CVM Required Limit and the Reader Contactless Floor Limit to the applicable values. For a Tap to Phone Solution, the device must comply with the Visa Ready Tap to Phone Kernel Specification VRTPKS V1.1 or later. Those certification levels have published meanings: EMVCo states that Level 1 testing "assesses the compliance of the acceptance device with the communication protocols defined within the EMV Chip Contact and Contactless Specifications," and that Level 2 testing "assesses the compliance of the acceptance device with the software features defined within" them. Our tap-to-pay guide covers what that framework asks of a phone used as a terminal.

Contactless-only devices carry a condition people miss

Table 5-8 states that a contactless-only device must "not have a disabled contact Chip reader or Magnetic Stripe slot," and that for a Tap to Phone Solution it must comply with the acquirer requirements in Section 5.6.3.1. That is a sharper rule than it sounds: a device is not made contactless-only by switching the other readers off, and a counter that quietly disabled its chip slot to speed up a queue has changed the device's status without meeting the conditions for it. Section 5.6.2.3 sets separate conditions for deploying contactless-only acceptance devices. If you are considering removing an interface from the customer's options, that is a conversation with your acquirer.

An illustrative example of a go-live that found the problems

Illustrative example, made-up round numbers. A shop installs four new terminals and runs 20 test transactions across them before opening: one on each interface the shop supports, plus a decline, a void, a partial refund and a keyed sale. Two findings come out of it, and neither is exotic. One terminal's PIN pad is inactive, which Table 5-8 requires to be activated in a face-to-face environment. One terminal's receipt header carries the previous merchant's trading name, which is a descriptor problem that surfaces later as disputes. Both are twenty-minute fixes on a Tuesday and a bad afternoon on a Saturday. Our billing descriptor guide explains why the second one is worth more attention than it looks.