# POS Disconnection and Timeout Ref Guide
During temporary blips such as network failures or unexpected POS restarts, the connection between the POS and SCA gets disrupted. In such situations it is recommended for the POS to follow certain steps to ensure integrity of the transaction that was triggered prior to losing connection. This section lists best practices and recommendations for handling loss of connectivity between the POS and SCA. The sequence of steps to be performed by POS, help the POS to recover from a blip once the connection is reestablished.
## General Recommendations
**Session Rules**
* SCA payment transactions are always triggered within sessions. The typical sequence of commands is Start Session → Payment Command → Finish Session.
* When the integration does not require usage of Line Items or Idle Card Entry functionality, it is recommended for the POS to send the Session Start command immediately before the Payment command. This will ensure minimal disruptions within the payment session.
**POS Reconciliation**
* POS\_RECON is a field passed in POS Request and is echoed in the POS Response allowing the POS to match the transactions with the LAST\_TRAN command.
## Network Specific Recommendations
**TCP/IP**
* Includes any form of POS Communication using an IP address and Port including Ethernet, WiFi , IP over Bluetooth.
* SCA behaviour during a connection loss :
* Terminates the transaction if transaction is not posted to the processor.
* If connection loss happens during transaction posting to the processor, SCA would not cancel the transaction and attempts to send the response to POS when the connection is reestablished.
* The POS will need to implement logic to receive data from the socket after reconnection.
* General recommendations for the POS to make the communication robust include:
* Using non-blocking sockets to prevent indefinite blocking on receive operations.
* Making the port reusable to allow immediate reuse if the socket is closed abruptly.
* When the receive operation times out, reads 0 bytes from the socket, or gets terminated with errors like connection reset or pipe errors, it indicates an unexpected disconnection. In order to recover, POS should:
* Attempt to reconnect to the terminal using the same port.
* If connection fails, retry after 5 seconds.
**Serial**
* Includes POS communication with the terminal over a serial connection such as Bluetooth.
* SCA behaviour during a connection loss :
* Transaction will not be terminated in any case.
* SCA will attempt to reconnect automatically when it detects a connection loss.
* General recommendations for the POS to make the communication robust include:
* The POS should use listeners and callbacks provided by the SDK to monitor device state.
* Once a reconnection is detected, the device serial number in the connection metadata can be used to uniquely identify the device.
## Recommendations Post Reconnection
Once the connection is reestablished, the POS will need to send a secondary port status to know the current state of SCA on the device. Depending on the values of SECONDARY\_DATA and DETAILED\_STATUS fields in the secondary port status response, the POS will need to perform a sequence of steps to resync with SCA and continue payment processing on the device.
Recommended POS Behaviour
* If the secondary port status command indicates that a payment transaction is completed (TRANSACTION COMPLETED) :
* POS should send a LAST\_TRAN command.
* If the INVOICE, TRANS\_AMOUNT and COMMAND fields in the LAST\_TRAN response match with the current transaction, POS should print receipt and finish session.
* Optionally, POS can send a POS\_RECON field with every payment request which will be echoed back in the LAST\_TRAN response. This can be used to uniquely match the current transaction with the LAST\_TRAN response.
* If the secondary port status command indicates that a payment transaction is being posted to the processor (POSTING TRANSACTION) or card entry is in progress (CAPTURING CARD), the POS should wait until the transaction is completed and a response is received.
* If the secondary port status command indicates that card details are awaited (AWAITING CARD ENTRY), the POS should send a secondary port cancel and finish the session. A new session can be started to process the next payment command.
SCA States Definition
* The various SCA States such as - Transaction Completed, Posting Transaction , Capturing Card, Awaiting Card Entry are defined further in the table below.
* For a detailed list of SCA states, please refer to Secondary Data values section in the guide.
* Below are the major states which SCA may indicate through SECONDARY\_DATA and DETAILED\_STATUS fields in the Secondary Port Status Response when the device is processing any payment transaction.
* These have also been used to indicate various scenarios in Swimlane diagrams below:
| SCA States | SECONDARY\_DATA Values | DETAILED\_STATUS Values |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TRANSACTION COMPLETED | 41 - Response has been received from host 34 - Card has been read for early card capture | N/A |
| POSTING TRANSACTION | 14 - Posting payment transaction to host (Sale, Pre Auth, Post Auth) 17 - Posting void transaction to host 19 - Posting refund transaction to host 21 - Posting gift transaction to host | N/A |
| NO SESSION | 10 - Idle with no active session | |
| IN SESSION | 11 - In session with line items disabled 12 - In session with line items enabled | |
| CAPTURING CARD | 13 - Processing payment transaction 16 - Processing void transaction 18 - Processing refund transaction 20 - Processing gift transaction | 2- Capturing Card Details 3 - Capturing PIN 8 - Capturing Expiry 9 - Capturing CVV 10 - Capturing Zip Code 16 - Capturing PAN, CVV, Expiry 40 - Capturing DCC 42 - Capturing Gift PIN 44 - Capturing EBT Type (Refer to guide for more exhaustive detailed status values) |
| AWAITING CARD ENTRY | 13 - Processing payment transaction 16 - Processing void transaction 18 - Processing refund transaction 20 - Processing gift transaction | Any non-card entry detailed status values |
## Illustrations on Disconnection Scenario
 [Disconnection Outside Session](https://confluence.verifone.com/download/attachments/873002847/OutsideSession_v2.txt?version=1\&modificationDate=1731988340283\&api=v2)
[Disconnection Inside Session - Before Payment Transaction](https://confluence.verifone.com/download/attachments/873002847/BeforeTransaction_v2.txt?version=1\&modificationDate=1731988375792\&api=v2)
[Disconnection/Timeout Inside Session - During Payment Transaction](https://confluence.verifone.com/download/attachments/873002847/DuringTransaction_v2.txt?version=1\&modificationDate=1731988409511\&api=v2)
[Disconnection/Timeout Inside Session - After Payment Transaction](https://confluence.verifone.com/download/attachments/873002847/AfterTransaction_v2.txt?version=1\&modificationDate=1731988433730\&api=v2)
|  | Thank you! We are the payments architects who
truly understand commerce. As payment architects we shape ecosystems for online and in-person commerce experiences, including all the tools you need… from gateways and acquiring to fraud management, tokenization and reporting. As commerce experts, we are here for you and your business. With our payment devices, our systems & solutions and our support. Everywhere. Anytime. So that your customers feel enabled, recognized and well taken care of, even beyond their expectations. Verifone. Creating omni-commerce solutions that simply shape powerful customer experiences.
|
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.verifone.com/sca/tbd-documentation/pos-disconnection-and-timeout-ref-guide.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.