1. Timeout failures on payment

Symptom

Payments fail in your POS with client-side timeouts, while the terminal shows the transaction completing — sometimes approved. Cashiers report "it timed out but the customer was charged".

Root cause, almost always

Your HTTP client timeout is shorter than a legitimate payment can take. Card processing includes cardholder interaction plus issuer response time; issuer delays of tens of seconds are normal and are explicitly exercised during certification with a delayed-response scenario.

The rule

Set the HTTP client timeout for payment calls above 90 seconds. This is the single most common integration mistake. A 30- or 60-second timeout will pass happy-path testing and then fail in the field and in certification.

If a timeout still occurs

A timeout means you stopped listening, not that the transaction stopped:

  1. Do not re-send the payment.
  2. Send TransactionStatus with the original ServiceID.
  3. Record the actual outcome (approved → store POITransactionID; declined/aborted → record that).
  4. Only if the terminal has no record of the ServiceID may the payment be treated as never processed.

Distinguish from network failure

If the status call also fails, you have a connectivity problem, not a slow issuer: run Diagnosis, check the LAN, and follow the session recovery in Session and login lifecycle. Keep the unresolved transaction flagged until a status query settles it.