Knowledge Center / The Unobserved Interval
The unadvised transaction: authorization approved, acquirer record unconfirmed
In many acquiring environments, the issuer's authorization decision and the acquirer's financial completion record are structurally separated. Authorization succeeds: the issuer-authorization decision is complete. But the post-authorization completion, capture, or advice step that allows the acquirer to move toward settlement may not follow: connectivity drops, the device restarts, or the session times out. The terminal or application may have reached a customer-visible approved outcome, while the acquirer record remains incomplete or uncertain. Without a signed device-side record of what happened in that interval, resolution is manual — a comparison of two unsigned logs by a person, with a reversal or forced completion as the output.
What is an unadvised transaction?
An unadvised transaction is a payment exception where issuer authorization succeeds, but the post-authorization completion, capture, advice, acknowledgement, or batch-confirmation path remains missing or unconfirmed in the acquirer record. The result is an uncertain state: the customer may see an approved or pending transaction, while the merchant’s settlement position is not yet confirmed.
In short: EMV and issuer authorization prove the transaction decision; EEI proves what the device observed and did during the unsigned post-authorization interval.
This matters to acquirers, payment processors, banks, SoftPOS providers, mPOS operators, and merchant-operations teams that need to explain why a customer-visible approved transaction is missing from settlement, appears as pending, or requires reversal, duplicate checking, manual completion, or scheme-defined adjustment.
1. The authorization-to-completion structure
Many acquiring and processing environments separate the authorization decision from financial completion or capture. The precise message types, timing, and party sequence vary by scheme, acquirer host, terminal integration type, and processing model: some environments use a discrete financial completion or advice message sent from the terminal after the authorization response is processed; others use host-side capture against the authorization record; others use batch clearing against the authorized amount. The EMV acquirer interface specifications [1] and the contactless kernel flow [2] describe the terminal-side behavior in the contact and contactless card-present cases. Where ISO 8583-style messaging is used, the message structure follows the applicable network and acquirer implementation of that framework; transport, settlement, and operational handling remain implementation-specific [3].
The structural property consistent across these models is this: the issuer-authorization decision can complete while the acquirer’s financial completion record remains absent or uncertain. Once the issuer validates the ARQC and returns an authorization response, the issuer-authorization decision is complete, but the acquiring and settlement state may still be incomplete. That gap is the subject of this article.
2. The failure modes that expose the gap
An authorization-without-completion event can arise from three failure modes common in production POS and mPOS estates:
Failure mode A
Connectivity failure
Network connectivity drops after the authorization response is processed but before the post-authorization step is transmitted or acknowledged. On cellular mPOS estates in areas of intermittent coverage, this is a common failure path.
Failure mode B
Device restart or crash
The device or process terminates after the authorization response but before the post-authorization step is durably queued. On Android-based mPOS and SoftPOS this includes OS-level process kills: memory pressure, watchdog timeouts, power failure.
Failure mode C
Timeout without confirmed completion
The post-authorization message is transmitted but no acknowledgement arrives within the protocol timeout. Retry logic may exhaust before either side reaches a confirmed state. Where automated reversal or reconciliation does not resolve it, the case becomes an exception.
In each case, the terminal or application may have reached a customer-visible approved outcome, while the acquirer record remains incomplete or uncertain. The customer’s account may show an authorization hold, debit, or pending transaction depending on issuer and account type. The merchant’s settlement position is uncertain until the case closes.
3. Why manual investigation is difficult
Where automated retry, host-side reversal, and acquirer-side reconciliation cannot deterministically resolve the state, the case becomes an operational exception. Investigation depends on matching the terminal’s local transaction record against the acquirer record, confirming the customer’s charged state, and initiating a reversal or forced completion.
Three conditions limit this in practice:
Condition 1
The terminal record is not signed
On most POS and mPOS implementations, the local log has no cryptographic commitment to its entries. When the terminal and acquirer records disagree, operations is comparing two unsigned sources with no way to establish which is authoritative.
Condition 2
The terminal may not be available
If the device was restarted, replaced, or reset between the failure and the investigation, the local record is gone. The investigation proceeds with one source.
Condition 3
The failure interval is not recorded
Even when the terminal log is accessible, it records transaction status, not the runtime sequence that produced it. Operations knows the advice step failed. They do not know when it failed, whether it was attempted, or whether connectivity was present at the relevant moment. That distinction affects scheme dispute classification, the accountability record, and the operator’s choice of reversal, completion, or adjustment path.
4. Deterministic resolution: local signed ledger
Execution Evidence Infrastructure (EEI), the device-identity infrastructure layer for banking and payments, does not replace EMV, the acquiring host’s processing model, or the scheme reconciliation process. It adds a signed device-side record of what the terminal observed during the authorization and post-authorization interval that those systems do not sign themselves.
The Trusted Runtime Primitive observes and signs each discrete event in the transaction flow at the moment it occurs: the authorization request sent, the authorization response received and processed, the post-authorization step attempted, and the acknowledgement received or the failure recorded. Each event is written as a signed entry to the Local Evidence Ledger, an append-only, hash-linked structure on the device, with a device-bound signature that binds the entry to this device, this session, and this transaction context.
Each evidence entry references the operator’s payment identifiers: trace number, authorization code, terminal identifier, merchant identifier, acquirer reference, amount, currency, and transaction timestamp, sufficient for the operator’s reconciliation system to join against the acquirer record. The entry does not store PAN, track data, PIN block, or sensitive authentication data. Payment references are tokenized or masked according to the operator’s PCI boundary.
When connectivity is restored, the device transmits evidence via the Commander channel. The operator’s verifier replays the signed sequence and produces a deterministic device-side account: was the post-authorization step attempted, did it succeed, was connectivity present, was the acknowledgement received? The verification gives the operations team that account. The resulting action (reversal, manual completion, duplicate check, or scheme-defined adjustment) is then selected under the operator’s existing rules.
EEI proves the device-side execution sequence. It does not assert that the issuer, scheme, or acquirer state has changed unless that state is represented by an observed response or a matched acquirer record.
5. Investigation path: Commander-side gap detection
Where the device is no longer available or has not yet reconnected, the Commander holds the last synchronized evidence state for that device. The operator’s operations system can query for transactions where, within the last synchronized signed sequence for a given terminal and transaction context, an authorization-response event exists but no corresponding post-authorization completion marker follows within the expected window.
The absence of the expected post-authorization completion marker within a bounded signed sequence is a structured indicator of the unresolved state; it does not, by itself, prove the cause. Each such entry carries the signed authorization context: terminal, merchant, amount, currency, timestamp, and the last runtime signals observed before the sequence ends, sufficient to initiate the appropriate operational action under the operator’s rules.
Where the device reconnects after the investigation has begun, any entries post-dating the last sync are transmitted. If the failure was a connectivity drop during which the device continued running, the subsequent entries include the outcome of any retry attempts, allowing the investigation to close with a complete device-side picture.
6. Which signals make it observable
runtime.environment carries connectivity-present and
network-type context at the moment each event is signed. On
Android-based mPOS and SoftPOS, these fields are observable
at the runtime layer and included in the evidence entry when
the post-authorization event is signed. On terminal types
where platform-level connectivity signals are not exposed, the
absence of the expected post-authorization completion marker
within the synchronized sequence is the structured indicator.
The tctx field binds all events in a transaction sequence
to a single context identifier. The seq monotonic counter
makes structural gaps in the sequence detectable at the
verifier without requiring the device to report them actively.
Frequently asked questions
Is an unadvised transaction an EMV failure?
No. EMV and issuer authorization may have completed successfully. The gap appears after authorization, when completion, capture, advice, acknowledgement, or batch confirmation remains unconfirmed.
Does EEI replace acquirer reconciliation?
No. EEI adds signed device-side execution evidence that can be joined with existing acquirer and reconciliation records.
Does the Local Evidence Ledger store cardholder data?
No. The evidence record stores operational references and runtime evidence. It does not store PAN, track data, PIN block, or sensitive authentication data.
What does EEI prove?
EEI proves the device-side execution sequence: what the terminal observed, attempted, acknowledged, or failed to complete during the post-authorization interval.
7. Cross-references
- Sibling articles in this theme:
the-emv-execution-gap: the gap before the authorization cryptogram; this article covers the gap between the authorization response and the acquirer completion record.the-sca-settlement-gap - Architecture:
/architecture/local-evidence-ledger,/architecture/sovereign-verification - Knowledge Center:
dispute-evidence-workflow,pos-tampering - Glossary:
/glossary, entries: Commander, Local Evidence Ledger, Evidence Token,tctx,seq
8. External references
[1] EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems, Book 4 — Cardholder, Attendant, and Acquirer Interface Requirements, v4.4. Cited 2026-06-16.
[2] EMVCo. EMV Contactless Specifications for Payment Systems, Book C-2 — Kernel 2 Specification, v2.10. Cited 2026-06-16.
[3] ISO. ISO 8583:2023 — Financial-transaction-card-originated messages — Interchange message specifications. Cited 2026-06-16.