Store and Forward

Store and forward Configure and monitor offline fallback transactions.

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.

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.

Configuring Store and Forward

Configure Store and Forward in Payment Controller.

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 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

Released	Base057.01.00 · Base056.03.02 · Base055.02.10
Customer	CITGO (brand-specific)
Platform	Viper / EPS (Commander-side, NTS network)

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.

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.

What This Feature Does

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

Layer	Name	Description
1	Prevention	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.
2	Self-Healing	If a corrupted file is detected on startup or during settlement, the system automatically reconstructs it from individual transaction records stored on disk.
3	Alarm Escalation	If automatic reconstruction fails entirely, a new alarm fires immediately so staff are notified instead of the system looping silently.

Behavior Details

Atomic File Writes

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

• write to a temporary file,
• flush to disk,
• rename to the final filename.

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

File	Rebuilt From	When Triggered
BatchClose.xml	BatchConfig.xml, with fallback from the batch directory name	File exists but is unreadable
BatchConfig.xml	Individual transaction files scanned from disk	File is absent or corrupt

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

Attribute	Value
Network	NTS (CITGO brand only)
Platform	Viper / EPS — Commander side
Transaction Types	All transaction types using NTS batch settlement
New FID	ATOMICBATCHCFGWRITE (in FIDTable.xml)
New Alarm	BATCH CLOSE ERROR — CALL HELPDESK (English and Spanish)

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 when you need manual recovery options.

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

Use Network Functions 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.