POS Entry Mode Lookup

Reading a DE 22 like 051

Three digits, two separate fields. 05 is the PAN entry mode and the trailing 1 is the terminal's PIN entry capability, so 051 is a chip read at a terminal with a working PIN pad. 901 is a full stripe swipe at that same terminal, and 812 is e-commerce, where there is no PIN pad to speak of.

Plenty of processors send only the first two digits. That is why DE 22 is quoted as both two and three characters depending on whose specification you are reading, and why a parser that assumes three will misread every message from an endpoint that sends two. The same two digits travel in EMV as tag 9F39, where the field is usually called PAN entry mode instead.

The values you will actually see

Five cover most live traffic. 05 is a contact chip read and 07 is the contactless equivalent, both full EMV transactions with a real cryptogram behind them. 90 is a clean swipe of the full magnetic stripe, 81 is e-commerce, and 01 is keyed by hand.

00 deserves separate treatment, because it is not really a value. It means the terminal did not say. You pay the worst interchange for it, you cannot tell afterwards what actually happened at the point of sale, and a terminal estate sending it in volume has a configuration fault rather than an unusual customer base. Chase it as a defect.

Why this field costs money

Interchange depends heavily on entry mode. A chip read (05) qualifies for the best card-present rates because the cryptogram proves the card was there. A keyed transaction (01) or an unknown mode (00) qualifies for the worst, because nothing proves anything. Sending the wrong value is not a cosmetic bug. It changes what you pay per transaction.

Fallback: 79 and 80

These mean the terminal tried the chip, failed, and fell back to the magnetic stripe. Fallback is legitimate, because chips do fail, but it is also the classic route for a cloned card, because a fraudster can copy a stripe but not a chip. So schemes monitor fallback rates, issuers decline fallback more readily, and liability often sits with whoever allowed it.

A sustained rise in fallback at one terminal almost always means a dirty or failing reader rather than a fraud wave. Check the hardware before the transactions.

Contactless has two modes

07 is contactless EMV: a full chip transaction over the contactless interface, with a real cryptogram. 09, 91 and 82 are contactless mag-stripe mode, which emulates track data and carries a dynamic CVC3 rather than an ARQC. MSD contactless is being withdrawn by the schemes because it is weaker. If you see it in current traffic, something is out of date.

81 and credential-on-file

81 is e-commerce. On its own it says nothing about whether the cardholder was authenticated, so pair it with the 3DS ECI to see whether liability shifted. 10 is credential-on-file, used for merchant-initiated transactions against stored details, and it carries different rules again: MITs generally need a prior cardholder-initiated transaction to reference.

The list is ISO, the values are the scheme's

The table above is the ISO 8583 set, which is the common ground rather than the whole story. Each scheme profiles DE 22 in its own operating regulations, and they do not profile it identically: a value can be reserved on one network, defined on another, and carry a regional exception on a third. Visa and Mastercard both publish their own lists, and it is the scheme's list, not this one, that your acquirer will hold you to.

So read an unfamiliar value as a question for your scheme specification rather than a gap here. This page does not reproduce either list, for the same reason an unlisted merchant category code resolves to its ISO block instead of to the nearest plausible business: a value copied wrongly out of a specification the reader cannot check is worse than no value at all, because it is a value they will go and act on.