> 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/cug-57.01-en/commander-user-reference-57.01/store-and-forward.md).

# Store and Forward

## Overview

Store and Forward manages fallback transactions when the payment host is unavailable.

Use it with your EPS and FEP configuration.

Host behavior can vary by processor.

{% hint style="info" %}
For VAPS CITGO, from Verifone Commander Release 57.01, in order to ensure timely reconciliation, the following has been implemented:

When there are open network batches older than 72 hours, a message is displayed on the POS "Unclosed Network Batches; Call Help Desk"

When there are open network batches that are older than 120 hours, a message is displayed on the POS "Unclosed Network Batches; Transaction Processing Halted; Call Help Desk" and transaction processing is blocked on the Commander. Transaction processing resumes after old batches are processed.
{% endhint %}

## Configuring Store and Forward

Configure Store and Forward in [Payment Controller](/cug-57.01-en/commander-user-reference-57.01/configuration-client-forms/payment-controller.md).

Go to **EPS Configuration** → **EPS Global Configuration** → **EPS** → **Misc**.

Review these fields:

* **Store and Forward Limit** — sets the number of fallback transactions allowed.
* **Online Velocity Check Required** — applies velocity checks to online and offline transactions.
* **Data Storage Time (In Days)** and related security fields — display retention settings.

EMV transactions can allow stand-in approvals when the host is offline.

Stand-in parameters are FEP-specific.

Refer to your FEP documentation before changing EMV stand-in values.

## Monitoring Store and Forward

Use [Tools](/cug-57.01-en/commander-user-reference-57.01/configuration-client-forms/tools.md) to review payment status.

Go to **Helpdesk Diagnostics** → **Payment Status**.

This view includes:

* Store and Forward count
* Current batch details
* Last transaction timing

### Network Batch Monitoring

<table data-header-hidden><thead><tr><th width="132" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Released</td><td valign="top">Base057.01.00  ·  Base056.03.02  ·  Base055.02.10</td></tr><tr><td valign="top">Customer</td><td valign="top">CITGO (brand-specific)</td></tr><tr><td valign="top">Platform</td><td valign="top">Viper / EPS (Commander-side, NTS network)</td></tr></tbody></table>

CITGO sites were experiencing "stuck" batches caused by corrupted or zero-byte settlement files. When either BatchClose.xml or BatchConfig.xml was damaged, the Store-and-Forward (SAF) thread entered a silent infinite loop, blocking all transaction settlement. Sites would not discover the problem for hours.

{% hint style="info" %}
Note: The original feature request described a 72-hour and 120-hour batch aging monitor with POS warnings and transaction blocking. The implemented solution takes a different approach — it prevents and self-heals the root cause (corrupted files) rather than monitoring aging. The aging monitor concept was redirected to the C-Site Health & Alerts project.
{% endhint %}

#### What This Feature Does

Three layers of protection were added to the NTS network batch settlement process:

<table><thead><tr><th width="103" valign="top">Layer</th><th width="174" valign="top">Name</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">1</td><td valign="top">Prevention</td><td valign="top">Settlement files are written atomically. The system prepares the file in a temporary location first, then swaps it in all at once, so a crash can never leave a half-written or empty file behind.</td></tr><tr><td valign="top">2</td><td valign="top">Self-Healing</td><td valign="top">If a corrupted file is detected on startup or during settlement, the system automatically reconstructs it from individual transaction records stored on disk.</td></tr><tr><td valign="top">3</td><td valign="top">Alarm Escalation</td><td valign="top">If automatic reconstruction fails entirely, a new alarm fires immediately so staff are notified instead of the system looping silently.</td></tr></tbody></table>

#### Behavior Details

**Atomic File Writes**

Both BatchClose.xml and BatchConfig.xml are written using a safe three-step process:&#x20;

* write to a temporary file,&#x20;
* flush to disk,&#x20;
* rename to the final filename.&#x20;

This operation is retried up to three times on failure. Any leftover temporary files from a previous crash are automatically removed when the Verifone Commander starts up.

A new configuration flag (ATOMICBATCHCFGWRITE) controls whether atomic writing is enabled for BatchConfig.xml.

**Zero-Byte File Detection**

Before reading either file, the system checks whether the file is empty. An empty file is treated as unreadable and triggers the reconstruction process rather than causing an unmarshal error.

**Automatic Reconstruction**

<table><thead><tr><th valign="top">File</th><th valign="top">Rebuilt From</th><th valign="top">When Triggered</th></tr></thead><tbody><tr><td valign="top">BatchClose.xml</td><td valign="top">BatchConfig.xml, with fallback from the batch directory name</td><td valign="top">File exists but is unreadable</td></tr><tr><td valign="top">BatchConfig.xml</td><td valign="top">Individual transaction files scanned from disk</td><td valign="top">File is absent or corrupt</td></tr></tbody></table>

*If key fields such as batch number or sequence number cannot be read from the config, the system recovers them individually from the batch directory name, avoiding off-by-one errors in settlement totals.*

#### BATCH CLOSE ERROR — CALL HELPDESK Alarm

If reconstruction fails entirely, the system raises the alarm: “BATCH CLOSE ERROR — CALL HELPDESK”. This alarm appears on the Commander alarm screen and is also available in Spanish. Settlement does not continue silently; the site is expected to call the Help Desk for manual recovery.

This extreme scenario requires multiple files to be damaged simultaneously and is very rare under normal operating conditions.

#### Scope and Applicability

<table><thead><tr><th width="186" valign="top">Attribute</th><th valign="top">Value</th></tr></thead><tbody><tr><td valign="top">Network</td><td valign="top">NTS (CITGO brand only)</td></tr><tr><td valign="top">Platform</td><td valign="top">Viper / EPS — Commander side</td></tr><tr><td valign="top">Transaction Types</td><td valign="top">All transaction types using NTS batch settlement</td></tr><tr><td valign="top">New FID</td><td valign="top">ATOMICBATCHCFGWRITE (in FIDTable.xml)</td></tr><tr><td valign="top">New Alarm</td><td valign="top">BATCH CLOSE ERROR — CALL HELPDESK (English and Spanish)</td></tr></tbody></table>

This feature is not active for non-CITGO brands. It applies only when the NTS network is installed.

#### **Settlement Stuck / SAF Looping Silently**

1. Check Commander logs for WARN entries mentioning zero-byte BatchClose.xml or BatchConfig.xml.
2. Check whether the batch directory name matches the expected date-and-sequence format.
3. Look for the BATCH CLOSE ERROR — CALL HELPDESK alarm on the Commander alarm screen.
4. If no alarm is present but SAF appears to be looping, check the NTS batch directory for temporary files that may indicate an interrupted write.

#### **Alarm Fires but Settlement Does Not Recover**

This means BatchClose.xml, BatchConfig.xml, *and* the individual transaction files are all unreadable — an extreme multi-failure scenario. Manual intervention is required. The site must contact the Help Desk to recover the batch data.

#### **Feature Not Active on a CITGO Site After Upgrade**

* Confirm the installed network is NTS (CITGO brand).
* Verify the build is Base057.01.00, Base056.03.02, or Base055.02.10 or later.
* Check FIDTable.xml on the Commander for the presence of the ATOMICBATCHCFGWRITE entry.

## Related functions

Use [Methods of Payment](/cug-57.01-en/commander-user-reference-57.01/methods-of-payment.md) when you need manual recovery options.

**26 - Force Post** is used for transactions processed while the host was offline.

Use [Network Functions](/cug-57.01-en/commander-user-reference-57.01/network-functions.md) for related host and payment network workflows.

## Troubleshooting

**If Store and Forward counts increase unexpectedly, verify host connectivity first.**

**Then review EPS settings and FEP stand-in parameters.**

**If behavior differs by card type, confirm processor-specific rules with your FEP provider.**


---

# 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/cug-57.01-en/commander-user-reference-57.01/store-and-forward.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.
