PCI PTS classifies devices at the hardware level. But Visa and Mastercard classify transactions at the message level. No scheme inspects the physical terminal to determine whether it is attended or unattended — that determination is inferred entirely from data elements in the authorisation message. If the message says “attended,” the transaction is treated as attended regardless of the hardware’s PCI PTS listing. If the message says “unattended,” the scheme applies unattended rules — CVM selection, floor limits, interchange category, and compliance edits — accordingly.
This distinction matters because it means the terminal application and host gateway are jointly responsible for setting the correct environment indicators on every transaction. Getting the hardware certified as UPT is necessary but not sufficient; the authorisation messages must consistently declare the unattended context, or the certification is operationally meaningless.
The Three Signaling Points in ISO 8583
Three data elements in a standard ISO 8583 authorisation message convey the attended/unattended classification to the scheme:
| Data Element | Role | Attended Value (Typical) | Unattended Value (Typical) |
|---|---|---|---|
| DE 25 — POS Condition Code | Declares the terminal environment directly. | 00 — Normal presentment | 02 — Unattended terminal, customer operated (CAT) |
| DE 22 — POS Entry Mode | Describes how the PAN was captured (chip, contactless, magstripe, manual) and PIN capability. | Standard chip/contactless values | Same values — DE 22 does not distinguish attended from unattended |
| Terminal Type / POS Environment (scheme-specific subfields) | Visa TADG and Mastercard specifications define subfields for terminal type, CAT level, and environment classification. | POS terminal — cardholder present, attendant present | CAT terminal — cardholder present, no attendant |
The scheme combines these fields to classify the transaction. A correctly coded unattended transaction carries a consistent signal across all three: terminal type set to CAT, POS condition code set to 02 (unattended/customer-operated), and the environment subfield declaring cardholder-present with no attendant. Networks then apply business rules over these fields — interchange routing, risk scoring, CVM validation, and compliance checks — to enforce unattended-specific policies.
Who Sets These Indicators
The terminal application sets the values based on its configured environment. A vending machine, parking terminal, or AFD must be configured to emit unattended indicators on every transaction — this is not dynamic or per-transaction logic in most deployments, it is a fixed configuration reflecting the physical reality of the deployment.
The acquirer or gateway is responsible for passing these indicators through to the scheme correctly and can face compliance edits, interchange penalties, or scheme fines if the coding is wrong. An attended terminal miscoded as unattended — or vice versa — creates downstream problems: incorrect CVM handling, mispriced interchange, distorted issuer risk scoring, and potential L3 certification failures.
One Device, Two Configurations — Never Both at Once
A single physical SmartPOS device can support both attended and unattended use cases across different deployments. The same hardware model might run an attended retail application in one merchant’s checkout lane and an unattended kiosk application in another merchant’s lobby. However, for any given transaction, the device must behave as one or the other — the classification is binary at the message level, and schemes expect it to be consistent with how the cardholder actually interacts with the terminal.
This means the two deployments are effectively two different configurations and two different certification stories, even on identical hardware:
- Different EMV kernel parameters: Terminal Type (Tag
9F35) values21/22for attended vs.23/24for unattended, different CVM lists, different TAC values. - Different ISO 8583 field values: DE 25, terminal type subfields, and environment indicators.
- Different L3 certification cycles: unattended certification is not an extension of attended certification — it requires a separate test plan.
- Different PCI PTS scope: the unattended deployment may require UPT classification, SRED, and C2.4 prompt control that the attended deployment does not.
Configuration Consistency Is a Compliance Requirement
Using an attended configuration in a truly unattended scenario — or an unattended configuration on an attended device — is not a grey area. It produces wrong CVM sets, wrong floor limits, and miscoded POS condition codes. These inconsistencies will surface during L3 testing, scheme compliance monitoring, or acquirer audits. The environment classification must reflect the physical reality of how the cardholder interacts with the terminal, and it must be consistent across hardware certification, EMV kernel parameters, and ISO 8583 message coding.
The “semi-attended” concept — self-checkout lanes with a supervisor nearby, pay-at-table devices in restaurants — is a commercial and acquirer-level classification, not a PCI or scheme-level one. PCI PTS recognises only attended and unattended. Some acquirers and processors layer “semi-attended” as an operational distinction for risk management purposes, but the authorisation message still carries a binary attended-or-unattended signal. When defining certification scope for a semi-attended deployment, clarify with the acquirer whether the environment maps to attended or unattended for scheme messaging and compliance purposes.
References
- Visa — Technical Agent Data Guide (TADG) and related terminal environment guidance.
- Mastercard — Transaction Processing Rules and scheme-specific terminal / environment requirements.