Login fails with a BUSY condition

  • Updated

Symptom

Your login request comes back as a failure with a BUSY condition, usually right after the device powers on or the payment application has just started. Retry a moment later and it succeeds.

Cause

BUSY is not a configuration error — it means the payment application is still initializing and isn't ready to open a session yet. It's a transient, expected state during startup, not a sign that your login request is wrong.

Fix

Retry the login after a short delay. Treat BUSY as "not ready yet, try again," not as a hard failure. A simple, robust approach:

  • On a BUSY login response, wait briefly (e.g. a second or two) and send the login again.
  • Repeat with a small backoff until login succeeds or a sensible attempt limit is reached.

Do not change your login request fields in response to BUSY — the request is fine; the payment app just needs a moment.

How to tell BUSY apart from a real login error

A BUSY condition clears on its own with a retry. If login keeps failing with a non-BUSY error after the payment app has had time to start, that's a genuine problem with the request or the environment — inspect the error response detail rather than continuing to retry.

Related

  • Session and login lifecycle — why login must succeed before anything else.
  • How the message model works — handling the login response super-type so the error case (including BUSY) actually reaches your code.

Was this article helpful?

0 out of 0 found this helpful