3. No result within waitTime

Symptom

The process-transaction call returns without a final outcome; or the cashier saw "timeout" while the customer's payment went through on the terminal.

What actually happened

The transaction outlasted the synchronous window (waitTime, default 20 seconds — short against real cardholder behaviour). The terminal completed it regardless; your ECR just stopped listening. This is the Cloud API's variant of the universal rule: a timeout means you lost the result, not that the transaction stopped.

Resolve the pending transaction

  1. Do not re-send the payment — there is no deduplication; a re-send can charge twice.
  2. If you use a notificationUrl, check the webhook receipt first — the result was pushed there.
  3. Otherwise query last-transaction and match by your ecrTransactionId.
  4. Record the true outcome; only a result that is not yours (or none) means the payment never processed.

Prevent the recurrence — pick one pattern

  • Synchronous ECR: raise waitTime to cover real payments (up to 300s) and set your HTTP client timeout just above it. A 20s default with a 15s client timeout fails every slow issuer.
  • Webhook ECR: keep waitTime short deliberately, and treat the webhook as the source of truth — the synchronous response is then only an acknowledgement.

The failure mode to eliminate is the hybrid: short waitTime, no webhook, and sale logic that trusts the synchronous response.