Terminal telemetry: what to log, what to drop
The temptation is to log everything. The practical answer is more like ten fields, plus a mechanism for turning on more when you need them.
Terminal telemetry is one of those things everyone underinvests in until an incident forces the issue. Then they overinvest and drown in noise. The middle path — a small set of always-on fields, with a mechanism to enable more on demand — is what actually works.
Based on a fleet observability review, 2024; written May 2026.
What to always log
The set that reliably answers "what happened in this transaction" is small:
- Correlation ID, propagated end-to-end.
- Attempt ID, incrementing per retry.
- Terminal ID, MID, TID, batch ID — for reconciliation.
- Transaction start and end wallclock timestamps — with timezone.
- Result state — APPROVED / DECLINED / UNKNOWN, per the earlier post on honest state.
- Message class and code — for schemes that expose them.
- Delivery state — sent / unacknowledged / acknowledged / failed.
- A small structured error object on failure — code plus one-line message, not a stack trace.
That's it. Ten or so fields, ~500 bytes per transaction, well within any reasonable retention budget.
What to log on demand
Turn these on when investigating:
- Full request/response bodies (with card data redacted).
- EMV kernel decisions and CVM path.
- Radio/network state during the transaction.
- Device sensor telemetry.
Give operations a switch to enable them per-terminal or per-MID for a short window, and make sure the switch auto-expires.
What to never log
- PAN in cleartext.
- PIN block, in any form.
- Full track data.
- Cryptographic keys.
- Anything that would fail a PCI audit.
The point of telemetry is diagnostics, not evidence. Keep the always-on set small enough that operators actually read it.