> For the complete documentation index, see [llms.txt](https://docs.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verifone.com/kld/kld-user-guide/network-communication-and-power-failure-error-handling.md).

# Network Communication and Power Failure Error Handling

## Upload keys failure management

When the user clicks the Upload option to send/upload keys to the terminal, a few failures are possible.

The network connection can be a problem especially if Wi-Fi used is not stable.

Power to KLD or the Terminal may be lost accidentally. In these cases, there is a chance the KLD sent a key to the terminal, the terminal successfully installed it, but the KLD did not receive the response. In these cases, KLD will have to assume that the terminal received the key(s) and delete them from the local repository to avoid sending the same key to a different terminal. In case of BDK, the DID must be increased. This assumption may delete a Master or IK keys even if the Terminal did not receive the key, but this is the trade-off vs sending the same to multiple terminals in case of these edge cases.

## Key State Change Conditions During Upload

### DID Increment and IK/Master Key Deletion

Scope: From the moment the user starts an upload until the upload (and any crash recovery) is fully complete.

&#x20;Two types of key state changes occur after an upload:

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">DID incremented by 1; key deleted when DID exceeds DID_END</td></tr><tr><td valign="top">IK</td><td valign="top">Top key entry deleted from the key list file</td></tr><tr><td valign="top">Master (MS)</td><td valign="top">Top key entry deleted from the key list file</td></tr></tbody></table>

### Conditions by Send (or Upload) outcome

#### 1. Successful Send (status = 0)

The KRD acknowledged receipt (HTTP 200, confirmed success).

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Text</th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">DID incremented by 1 in repo (or key deleted if DID > DID_END)</td></tr><tr><td valign="top">IK</td><td valign="top">Top key entry deleted from the IK key list</td></tr><tr><td valign="top">Master</td><td valign="top">Top key entry deleted from the MS key list</td></tr></tbody></table>

***KeyInfoLog.log**: Entry written. **Comm Status = SUCCESS***.

#### 2. KRD Explicitly Rejected the Key (ERROR\_KEYS\_DOWNLOAD\_FAILED)

The terminal responded with an explicit rejection (HTTP non-200 or status=failed). The key was not loaded by the KRD.

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">No change. DID is not incremented.</td></tr><tr><td valign="top">IK</td><td valign="top">No change. Key entry is not deleted.</td></tr><tr><td valign="top">Master</td><td valign="top">No change. Key entry is not deleted.</td></tr></tbody></table>

***KeyInfoLog.log**: No entry written.*

#### 3. Pre-Network Error (ERROR\_KLD\_INTERNAL)

The send failed before any data left the device (e.g., URL construction failed). The key was never transmitted.

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">No change. DID is not incremented.</td></tr><tr><td valign="top">IK</td><td valign="top">No change. Key entry is not deleted.</td></tr><tr><td valign="top">Master</td><td valign="top">No change. Key entry is not deleted.</td></tr></tbody></table>

***KeyInfoLog.log**: No entry written.*

#### 4. Communication Failure — Data May Have Been Sent

Two error codes fall in this category:

<table data-header-hidden><thead><tr><th valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">ERROR_KLD_SERVER_RESPONSE_EMPTY</td><td valign="top">KLD completed the PUT; response was NULL. Data was transmitted; KRD state is unknown.</td></tr><tr><td valign="top">ERROR_KLD_HTTP_PUT_FAILED</td><td valign="top">Transport failed. Data may or may not have reached the KRD.</td></tr></tbody></table>

Policy: once the payload has been put on the wire and the outcome is uncertain, KLD treats the key as possibly loaded.

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">DID incremented by 1 in repo (or key deleted if DID > DID_END)</td></tr><tr><td valign="top">IK</td><td valign="top">Top key entry deleted from the IK key list</td></tr><tr><td valign="top">Master</td><td valign="top">Top key entry deleted from the MS key list</td></tr></tbody></table>

***KeyInfoLog.log**: Entry written. **Comm Status = FAILURE**.*

#### 5. Power Failure or Hang During Send (WAL Replay on Next Boot)

The device lost power (or hung) while upload was executing. No return code was recorded.

On the next KLD startup, KLD reads the WAL (Write Ahead Log) file and runs recovery.

<table><thead><tr><th valign="top">Key Type</th><th valign="top">Description</th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">BDK</td><td valign="top">DID incremented by 1 in repo (or key deleted if DID > DID_END)</td><td valign="top">WAL stores the pre-send DID. Replay only increments if the current repo DID still equals the pre-send DID — prevents double-increment if power failed after cleanup but before WAL was deleted.</td></tr><tr><td valign="top">IK</td><td valign="top">Top key entry deleted from the IK key list</td><td valign="top">Naturally idempotent — if the file was already deleted, the next key shares the same key_file_name_ and is consumed instead. See Notes.</td></tr><tr><td valign="top">Master</td><td valign="top">Top key entry deleted from the MS key list</td><td valign="top">Same as IK.</td></tr></tbody></table>

***KeyInfoLog.log**: Entry written. **Comm Status = FAILURE**. The timestamp used is the original send timestamp stored in the WAL — it reflects when the interrupted send occurred, not when the device rebooted.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.verifone.com/kld/kld-user-guide/network-communication-and-power-failure-error-handling.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
