Every Payment Has a Liability Owner

contact@corebaseit.com (Vincent Bevia) — Thu, 23 Jul 2026 18:30:00 +0200

A card-present payment is often treated as a request/response system: send an authorization, receive Approved or Declined, print a receipt. That model is incomplete. A single tap crosses a terminal, payment application, SDK or kernel, acquirer host, card scheme, and issuer. Each hop can succeed, fail, time out, or succeed without the previous hop ever learning the outcome.

This post is about those disagreements — the edge cases where software behavior turns into financial risk. It covers why UNKNOWN is more expensive than DECLINED, why a retry is a liability decision, how SoftPOS adds failure modes that dedicated terminals do not have, and how store-and-forward and reconciliation force you to decide who absorbs a loss. The happy path of EMV is documented elsewhere; the design work starts when visibility is lost.

A payment is a distributed state machine

The useful mental model is not card → POS → acquirer → scheme → issuer. It is a chain of participants that can each hold a different view of the same payment:

Customer
 → Merchant
 → Terminal / SoftPOS device
 → POS application
 → Payment SDK / EMV kernel
 → Acquirer host
 → Card scheme
 → Issuer

Failure can occur at any layer. When it does, two questions appear immediately, and they are not the same question:

Did the customer pay?
Who loses the money if the answers diverge?

In production systems, an authorization that leaves the device and never returns a usable response is not a clean failure. It is a loss of visibility. The issuer may have approved; the merchant application may still be sitting on a timeout. That gap is where duplicate authorizations, blocked funds, chargebacks, and reconciliation debt come from. The same theme shows up in the double-charging post: an error often means you lost sight of the ledger, not that nothing happened on it.

`UNKNOWN` is the expensive status

Payment UIs are trained on two outcomes. Real platforms need more:

APPROVED
DECLINED
UNKNOWN
REVERSED
EXPIRED
CHARGEBACK

UNKNOWN is the dangerous one. A concrete sequence:

POS sends authorization
 → Issuer approves
 → Response is lost on the network
 → POS times out
 → Customer walks away

At that moment the system cannot answer the operational questions that matter at the counter: Was the cardholder charged or held? Is a retry safe? Should inventory be released? Should a receipt print?

Timeouts themselves are layered. Connection timeouts, request timeouts, and issuer timeouts sit on different clocks; a gateway 504 is yet another visibility cut. None of those signals tells you whether the issuer already posted an approval. Treating the timeout as FAILED and firing a new authorization with a new transaction reference is how one purchase becomes two.

The safer pattern, drawn from the transaction lifecycle model used in production POS and acquirer stacks, is deterministic recovery rather than optimistic retry:

AUTH_REQUESTED → TIMEOUT → status query / reconcile → REVERSAL_SENT → REVERSED

When the outcome remains uncertain, reverse. Do not invent a final state. ISO 8583 reversals (0400 / 0420) exist for exactly this class of uncertainty: unwind a hold when the acquirer or terminal cannot guarantee what the issuer did. The distinctions between reversal, refund, and chargeback — and where each sits relative to settlement — are covered in Reversals, Refunds, and Chargebacks.

Every retry is a financial decision

Outside payments, “retry until success” is a resilience habit. Inside payments it is often a money-moving decision.

Authorization sent
 → Timeout
 → Retry with a new reference
 → Original approval arrives later

Now there are two authorizations for one customer intent. Idempotency is the control that makes retries safe: the host must recognize the second message as the same payment. In ISO 8583 terms that usually means reusing identifiers such as STAN and RRN (and, on many stacks, a composite key with terminal ID and date) so the host can return the cached outcome instead of posting again.

Interpretation, not a universal law: retries before the customer commits — while nothing has left the device — are cheap. After the state machine enters AUTH_REQUESTED, every error is an uncertain outcome. Past that boundary, read-before-write beats blind resend: query status, reconcile, reverse when in doubt, then decide whether another attempt is still justified with the same identifiers.

Exponential backoff alone does not solve this. Backoff without idempotency and recovery only spaces out the duplicate risk.

Every failure has an owner

Payment engineering becomes interesting when the incident review ends with a financial question: who absorbs the loss?

Depending on the stage and the scheme rules, that can be the merchant, the acquirer, the issuer, the scheme, or the payment provider. Architecture choices change that exposure.

Confirmed fact (scheme programme rules, not a statute): card networks did not force EMV migration by legal mandate. They shifted counterfeit-fraud liability toward the party that failed to deploy EMV capability on its side of the transaction. Certification is therefore risk mitigation as much as a conformance exercise.

Interpretation for terminal design: if the merchant supports EMV correctly, counterfeit liability often sits with the issuer after the liability shift. That protection is conditional. Magstripe fallback after a chip read failure is one of the classic ways merchants re-inherit exposure — and the rules are not identical across schemes. Mastercard historically allowed constrained fallback after documented EMV malfunction; Visa has restricted or prohibited fallback in EMV-capable environments in many markets. SoftPOS under PCI MPoC has no magstripe path at all: EMV/NFC only. Treat “fallback” as a scheme- and region-controlled exception, not a default resilience feature.

Other financial edge cases that show up repeatedly in operations:

Lost approval — issuer approved; merchant never learned; customer sees a hold; merchant may retry.
Lost reversal — merchant cancelled or voided locally; issuer never received the unwind; funds stay blocked.
Authorization / settlement mismatch — authorized €100, cleared €95, or currency conversion surprises between merchant EUR and issuer USD.
Chargebacks months later — the only defense is a complete, immutable audit trail of what the terminal, host, and scheme each recorded.

Edge cases that break the happy-path model

Approval lost after issuer authorization

Issuer state: APPROVED. Merchant state: TIMEOUT. Customer state: “my banking app shows the money is gone.” Support cannot resolve this from the POS UI alone. Status inquiry and reconciliation against acquirer records are required before any second attempt.

Application crash or process death after approval

Authorization succeeds. Android kills the SoftPOS process before durable local finalization. The merchant reopens the app and asks whether to “pay again.” If the answer is driven by UI state instead of host state, you recreate the duplicate path. Never acknowledge merchant success before durable storage, and never treat process death as proof that the issuer did not approve.

Early card removal (contact)

During a chip transaction, removing the card before Generate AC completes leaves the EMV dialogue unfinished. The correct recovery is restart of the card dialogue — not a new online authorization invented from partial tags.

Duplicate taps and double button presses

Two NFC events, or three presses of Pay, can produce multiple authorization requests for one physical purchase. Duplicate detection at the application layer and an idempotency key at the host layer are both required. User error still becomes a distributed-systems problem once the first request has left the device.

Battery death between authorization and completion

Exactly between online approval and local completion/finalization, power loss leaves the backend holding an authorization and the merchant holding ambiguity. The durable state should be UNKNOWN / recovery-required, not silently rewritten as declined.

Recovery succeeds after the customer already retried

The original authorization eventually completes. The customer’s second attempt also succeeds. Reconciliation then has to decide which authorization represents the purchase and which must be reversed. This is the nightmare scenario that recovery SLAs and manual investigation queues exist to contain.

SoftPOS adds failure modes dedicated terminals do not have

A traditional payment terminal owns its hardware boundary. SoftPOS runs on a consumer or COTS device, so the operating system becomes part of the payment flow.

Failure modes that matter in practice:

Android lifecycle and process death — the activity resumes; the SDK session, attestation result, and in-memory terminal binding may not. Treating onResume as “ready to tap” is a payment decision made on stale state.
Attestation and Play Integrity — if integrity checks fail or Google services are unavailable (offline, outage), whether payment continues is a policy decision owned jointly by the SoftPOS solution and the acquirer, not a silent default. PCI MPoC treats device integrity as continuously monitored, not as a one-time install gate.
NFC ownership conflicts — two apps competing for reader mode can abort or corrupt a tap mid-dialogue.
Permissions and OEM behavior — NFC, network, location, battery optimization, and Play Services can change while the app is backgrounded. Samsung, Pixel, and industrial OEMs do not fail identically.
Tampered application / rooted device — code signing, integrity verification, and attestation are the controls; continuing after a hard attestation failure is accepting elevated fraud and compliance risk.

These are not theoretical. They are the SoftPOS equivalents of a terminal reboot mid-transaction, except the reboot can be invisible to the cashier.

Store-and-forward is deferred risk, not offline magic

When connectivity is gone, merchants still want to accept payments. Two mechanisms get conflated under the word “offline,” and they have different liability profiles.

True offline EMV — card and terminal approve locally with a Transaction Certificate (TC). Risk is bounded by card and terminal EMV parameters (floor limits, consecutive offline caps, AUC). The issuer may never see a real-time auth.

Store-and-forward (deferred authorization) — the terminal accepts the sale now, stores the ARQC and EMV data, and sends a normal online authorization when connectivity returns. The issuer can still decline hours later. Who pays for goods already handed over depends on the merchant–acquirer agreement and the controls on the queue (amount caps, count caps, encryption at rest, idempotent upload).

Book and field experience converge on the same warning: queued authorizations carry measurable decline exposure after the fact; treat that as merchant (or contractually assigned) risk, not as a free resilience feature. SoftPOS on COTS often supports SAF or nothing — not true offline EMV. The full distinction is in Offline EMV vs Store-and-Forward.

Queue-specific edge cases worth designing explicitly:

Offline queue → phone stolen → pending payments never uploaded
Offline queue → sync timeout → retry → acquirer sees duplicates without idempotency
Offline queue → storage corruption → pending payments disappear

Encrypt the queue, persist it durably, and upload with the same idempotency discipline used for online retries.

Reconciliation is where architecture meets finance

Every mature payment platform eventually discovers that merchant records, acquirer records, and issuer records can disagree:

Merchant: approved Acquirer: declined
Merchant: missing settlement
Settlement without authorization
Authorization without settlement
Duplicate settlement

Automated reconciliation is not a finance afterthought. It is the last control that turns ambiguous distributed state into an explainable euro. Chargebacks months later are won or lost on whether you can prove exactly what happened at each hop — cryptograms, response codes, STAN/RRN correlation, timestamps, and the recovery actions taken after uncertainty.

Three concerns that stay separate

Concern	Goal	Typical mechanisms
Correctness	The payment reaches one final business state exactly once	Idempotency keys, state machines, recovery, reconciliation
Resilience	The system keeps operating under failure	Controlled retries, outbox/durable queues, store-and-forward with caps, circuit breakers
Liability	Financial responsibility is clear when participants disagree	EMV liability rules, PCI controls, immutable audit logs, scheme dispute evidence

Good payment systems do not eliminate failures. They make failures deterministic: a known state, a known recovery path, and a known owner of the residual financial risk.

The question that usually matters in an incident is not whether an API returned HTTP 200. It is whether, months later, you can still explain every euro.

References

EMVCo, EMV Integrated Circuit Card Specifications for Payment Systems (Books 1–4) — card–terminal protocol, cryptograms, and risk management.
ISO, ISO 8583 — financial transaction messaging, including reversal MTIs 0400 / 0420 and correlation fields (STAN, RRN, original data elements).
PCI SSC, PCI Mobile Payments on COTS (MPoC) — SoftPOS security, attestation, and acceptance constraints (including no magstripe path).
Card network programme rules (Visa, Mastercard, and others via your acquirer) — liability shift, fallback policy, authorization validity, and chargeback reason codes are scheme- and region-controlled; confirm current guides before implementation decisions.
Point-of-Sale Systems Architecture: A Practical Guide to Secure, Certifiable POS Systems — Chapter 3 (EMV principles and magstripe fallback constraints), Chapter 8 (transaction lifecycle, timeouts, idempotency, reversal recovery), Chapter 14 (offline EMV vs store-and-forward and queue risk), Chapter 16 (scheme integration, reversal automation, reconciliation), Chapter 17 (liability shift as risk mitigation rather than legal mandate).

Reconciliation on Corebaseit — POS · EMV · Payments · AI · Telecommunications

Every Payment Has a Liability Owner

A payment is a distributed state machine

`UNKNOWN` is the expensive status

Every retry is a financial decision

Every failure has an owner

Edge cases that break the happy-path model

Approval lost after issuer authorization

Application crash or process death after approval

Early card removal (contact)

Duplicate taps and double button presses

Battery death between authorization and completion

Recovery succeeds after the customer already retried

SoftPOS adds failure modes dedicated terminals do not have

Store-and-forward is deferred risk, not offline magic

Reconciliation is where architecture meets finance

Three concerns that stay separate

References

Further reading

Reconciliation on Corebaseit — POS · EMV · Payments · AI · Telecommunications

Every Payment Has a Liability Owner

A payment is a distributed state machine

UNKNOWN is the expensive status

Every retry is a financial decision

Every failure has an owner

Edge cases that break the happy-path model

Approval lost after issuer authorization

Application crash or process death after approval

Early card removal (contact)

Duplicate taps and double button presses

Battery death between authorization and completion

Recovery succeeds after the customer already retried

SoftPOS adds failure modes dedicated terminals do not have

Store-and-forward is deferred risk, not offline magic

Reconciliation is where architecture meets finance

Three concerns that stay separate

References

Further reading

`UNKNOWN` is the expensive status