Overview
The Terminal Gateway implements four key concepts that apply to both HTTP and WebSocket protocols:- Terminal ID Resolution - How the system identifies terminals using deviceId or connectionId
- Single Device Enforcement - One active connection per API key
- Terminal Reconnection Resilience - 60-second grace period for terminal reconnections during payments
- Desktop POS Recovery - Automatic and manual recovery mechanisms for missed payment results
Terminal ID Resolution
When sending commands to terminals (payments, status checks, etc.), theterminalId parameter is resolved in the following order:
-
Device ID (Recommended) - The system first attempts to resolve
terminalIdas adeviceIdfrom the terminal registry. This is the preferred approach asdeviceIdremains constant even when a terminal reconnects and receives a newconnectionId. -
Connection ID (Legacy Fallback) - If no matching
deviceIdis found, the system treatsterminalIdas a rawconnectionIdfor backward compatibility with older integrations.
Single Device Enforcement
The Terminal Gateway enforces single device connection per API key. Only one active connection is allowed at any time.How It Works
First connection established
Your POS client connects with an API key and becomes the active connection.
Second connection attempts
If another device connects with the same API key, the existing connection is forcibly disconnected.
Displacement notification
The displaced connection receives a
forceDisconnect message (WebSocket) or loses session state (HTTP).Why Single Device Enforcement?
Security
Prevents unauthorized access from multiple locations simultaneously.
Consistency
Ensures terminal state and payment flows are managed by a single source.
Auditability
Clear connection tracking for compliance and debugging.
Resource Management
Prevents resource exhaustion from duplicate connections.
forceDisconnect Message (WebSocket)
When your WebSocket connection is displaced, you receive:Disconnect Reasons
| Reason | Description |
|---|---|
api_key_used_elsewhere | Another device connected with the same API key |
stale_connection_timeout | Connection was inactive for too long |
admin_action | Connection terminated by administrator |
other | Other system-initiated disconnect |
Handling forceDisconnect
Best Practices
- Use separate API keys for each POS terminal or workstation
- Do not run multiple instances of your application with the same API key
- Implement graceful handling of
forceDisconnectwith user notification - Log displacement events for debugging connection issues
Terminal Reconnection Resilience
Terminals with a stable device identifier (deviceId) benefit from reconnection resilience during payment processing. If a terminal disconnects mid-payment, there’s a 60-second grace period for it to reconnect.
How It Works
Terminal connects with deviceId
Terminal connects with the
X-Device-Id header and is registered in the terminal registry.Terminal disconnects
If the terminal loses connection during payment processing, the transaction status changes to
AWAITING_RECONNECT.Terminal reconnects (within grace period)
Cached payment results are processed and delivered to your POS.
Status Flow Diagram
Terminal Status Values
Your POS receivesterminalStatusUpdate notifications (WebSocket) or can poll the terminals endpoint (HTTP):
| Status | Description |
|---|---|
connected / online | Terminal is online and ready |
reconnecting | Terminal disconnected, may reconnect within 60 seconds |
disconnected / offline | Terminal is fully offline |
Voided Payments
If a terminal reconnects after the 60-second grace period with a successful payment result:- The payment is automatically voided to prevent charging the customer without your knowledge
- Your POS receives a
paymentVoidednotification (WebSocket) - Transaction status is set to
VOIDED
paymentVoided Notification
Handling Voided Payments
Best Practices
Use deviceId
Always configure terminals with a stable
deviceId via the X-Device-Id header to benefit from reconnection resilience.Handle All Statuses
Implement handlers for
AWAITING_RECONNECT and VOIDED statuses in your payment flow.Monitor Connectivity
Display terminal connection status in your POS UI to help staff identify issues.
Audit Voided Payments
Log all voided payments for reconciliation and customer service purposes.
Desktop POS Recovery
When a desktop POS disconnects after initiating a payment and misses the successful result, the Terminal Gateway provides two complementary recovery mechanisms to ensure payment results are never lost.Recovery Mechanisms
Undelivered Message Queue
Automatic recovery for brief network interruptions. Payment results are stored and pushed automatically upon reconnection.
Transaction Status Query API
Manual fallback for longer disconnections. Query transaction status at any time after reconnection.
Undelivered Message Queue
When a payment completes but the desktop POS cannot receive the result (due to disconnection or network issues), the Terminal Gateway automatically queues the message for later delivery.The message queue handles automatic recovery for common network blips without requiring any action from the desktop POS. Your application receives the
paymentComplete notification as if the connection had never been interrupted.Transaction Status Query API
For longer disconnections or edge cases where the message queue may not apply, use the Transaction Status Query API to manually check payment status. HTTP API:When to Use Each Mechanism
| Scenario | Recommended Approach |
|---|---|
| Brief network interruption (seconds) | Automatic - Message queue handles delivery |
| Desktop restart during payment | Query API on startup with pending transaction IDs |
| Extended offline period (minutes/hours) | Query API for all transactions initiated during downtime |
| Uncertain if result was received | Query API to verify transaction status |
Best Practices
Track Pending Transactions
Maintain a local list of initiated transaction IDs until you receive confirmation. Check these on reconnection.
Implement Idempotent Handlers
Your payment handlers should safely handle receiving the same result twice (from queue and query).
Use Transaction IDs
Always use unique, meaningful transaction IDs that you can query later if needed.
Log Recovery Events
Log when payments are recovered via queue or query for debugging and audit purposes.