Session and login lifecycle

A Local API session is the period between a Login and a Logout. Transactions can only run inside an open session. This applies to the HTTP and TCP/IP transports; the Cloud API has no session.

Login

POST /login opens the session. Send your SaleSoftware details (application name, provider, version). In the Login the POS advertises the highest protocol version it supports; the terminal answers with the version it will use for the session.

A Response.Result of Success confirms the session is open. If the incoming message cannot be parsed, the terminal returns an EventNotification with EventToNotify: Reject instead.

Working inside the session

  • Only one service dialogue runs at a time. Starting a second payment before the first finishes returns a Busy or NotAllowed condition (HTTP 403 on the payment endpoint while one is in progress).
  • Persist the POITransactionID of each completed payment for later reversals, refunds, and status queries.

Detecting a hardware swap

Persist the terminal's serial number on first login (available via a Diagnosis call) and verify it on subsequent logins. A changed serial means the physical terminal behind the same address was swapped — a fraud and reconciliation risk your POS should flag.

Logout

POST /logout closes the session. Re-login after any terminal restart or firmware update. Operations sent after a logout, or after the session expires, return the LoggedOut condition.

Note

See the Local API reference on MuleSoft for the Login and Logout schemas.

Was this article helpful?

0 out of 0 found this helpful