2. Polling never returns 200 / stuck on 206

Note

This article applies to the HTTP transport. On the TCP/IP socket there is no polling — responses stream on the open connection; the equivalent symptom is a response that never arrives, and the same resolution order applies (wait → Abort → Diagnosis).

Symptom

Your GET polling loop receives 206 indefinitely, or your POS closed the transaction while the terminal was still processing.

What 206 actually means

206 is "in progress" — the terminal is legitimately working: the cardholder may not have presented a card yet, PIN entry may be ongoing, or the issuer may be slow. It is never a failure state.

Checklist

  1. Are you polling the same endpoint you POSTed to? The GET goes to the operation's own endpoint (e.g. GET /payment after POST /payment).
  2. Is your poll interval sane? Around one second. Faster gains nothing; much slower delays the result.
  3. Is a cardholder actually interacting? A payment with no card presented stays in progress until the terminal's own entry timeout expires, then resolves as Aborted. Ten to sixty seconds of 206 is normal.
  4. Did your client time out and stop polling? See Timeout failures — the fix is a client timeout above 90 seconds, not faster polling.
  5. Genuinely stuck (several minutes)? Send an Abort — it terminates the in-flight operation — keep polling for the Aborted result, then run Diagnosis to check terminal health.

The rule

Never close, retry, or re-send a transaction because you saw 206. If uncertainty remains after a connection loss, resolve it with Checking transaction status — never with a second payment.