> For the complete documentation index, see [llms.txt](https://commanderhelp.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://commanderhelp.verifone.com/customer-documentation/petro-and-c-store/commander-highlights-user-guides-release-notes-and-certifications/commander-55.02/commander-55.02.10-release-notes/whats-new-in-release-55.02.10.md).

# What's New In Release: 55.02.10

<h2 align="center">Release Summary</h2>

This release enhances Commander Central with improved cloud connectivity visibility, richer site asset data, and on-demand loyalty configuration, while also adding manual CAPK download support, improved Voyager card acceptance, and new network batch monitoring. The majority of fixes target cash rounding edge cases on prepay transactions, loyalty discount finalization at the pump, and DCR transaction handling including silent cancellations and split tender misreads.

Auto Upgrade reliability sees significant attention, with fixes for back-to-back upgrade failures, period validation, mobile report preservation, and IPv6-related certificate renewal issues.

Additional corrections address fleet card odometer truncation, Visa Fleet 2.0 decimal precision, age verification date checking, and secondary loyalty T-Log capture.

<h2 align="center">New Features and Enhancements</h2>

### Commander Central

#### Commander Site Controller Configuration Client

The Commander Site Controller Configuration Client application now displays the Commander Central connection status, giving site operators immediate visibility into cloud connectivity directly from the configuration interface. This enhancement reduces the need to navigate to separate monitoring tools when diagnosing connectivity issues between the Commander and Commander Central. (135969)

#### Commander Site Controller Memory in Site Asset Data

This initiative extends the Commander Central site asset data model to include the Commander Site Controller installed memory information, providing richer hardware telemetry for fleet management and support operations. The feature enables Commander Central to surface memory details alongside other hardware attributes, supporting proactive monitoring and capacity planning across deployed sites. POS terminals are unaffected by this change. (135924)

#### Commander Site Controller RAM in Site Asset Data

The Commander now reports total installed RAM as part of the site asset data transmitted to the cloud, enabling better infrastructure visibility through Commander Central. The memory value is read from the system, rounded up to the nearest gigabyte, and reported alongside its unit designation; if the value cannot be read for any reason, the field is omitted without impacting the rest of the data payload. (135976)

#### On-Demand Loyalty Configuration Request and Notification

Commander Central can now request loyalty configuration data from Commander on demand, enabling support teams to retrieve current site configuration without waiting for a scheduled sync or requiring a reboot. Additionally, configuration change notifications have been enhanced to indicate the trigger source — such as a Commander reboot, application update, or PSI event — providing better visibility into what initiated a configuration change and simplifying troubleshooting of loyalty-related field issues. (135572)

### EPS System

#### CAPK (Certification Authority Public Key) File Download

Operators can now manually initiate a CAPK (Certification Authority Public Key) file download directly from the point-of-sale terminal, eliminating the need to rely solely on scheduled automatic downloads. This capability provides a manual fallback to ensure payment terminal cryptographic keys remain current when automatic processes are unavailable or need to be expedited. (121167)

#### Track 1 Parsing

The card track 1 data parsing has been updated to use delimiter-based field extraction rather than fixed character positions, accommodating variable-length name fields that differ across card issuers. This enhancement improves Voyager card acceptance reliability by correctly reading all track 1 fields regardless of name field length. (135684)

<h2 align="center">Resolutions</h2>

### Commander Central

1. Following installation of a new Attendant Security Module, the Commander reported the device as onboard-complete with an expired status while the Verifone Commander Central portal continued to display it as pending, creating a confusing status discrepancy for operators. This inconsistency has been resolved to ensure the Commander and Verifone Commander Central portal reflect a consistent and accurate ASM onboarding status. (134207)
2. Beginning in 55.02.09, the fuel rate configuration was no longer syncing to Commander Central. This was caused by a prior change that excluded local backup/restore unsupported commands from processing, which inadvertently prevented the fuel rate configuration dataset from being evaluated for cloud sync. The resolution adds a check to ensure that even when a dataset is marked as local backup/restore unsupported, it is still synced to Commander Central if the dataset is supported there. (137125)
3. When a PCATS loyalty FEP was disabled via Commander Central and an enterprise loyalty program was subsequently assigned, Commander Site Controller failed to close the disabled FEP's TCP connection, leaving two concurrent sessions to the same loyalty host. Velocity Logic permits only one session per site, causing continuous session drops and reconnects that disrupted payment transactions and displayed a PCATS6 error on the POS. The fix corrects the loyalty manager to check whether a FEP is enabled before resetting its channel, explicitly closing the connection when a FEP is disabled and preventing the duplicate TCP session from forming. (135832)

### Dispensers

1. After fueling out on a prepay cash transaction, the system incorrectly displayed the transaction amount as still due, preventing proper completion of the sale. This was corrected to restore correct prepay cash transaction finalization. (136048)
2. Intermittent prepay fuel sales were failing and displaying “Preset Not Allowed” on Partner devices because the RMI client socket factory was serialized into exported stubs using a hard-coded 10-second timeout, ignoring the site's configured timeout value. The resolution updates the RMI server to construct the client socket factory with the configured timeout so all exported stubs correctly apply the intended per-call timeout, eliminating the intermittent prepay failure. (134017)

### Dispenser Card Readers

1. Fleet card transactions were incorrectly appearing as split tender on receipts because the host pre-authorization response, which included both a dollar limit and a volume limit, was not being correctly linked to the primary fuel product at the pump position. The resolution corrects the fuel product resolution logic in the DCR pump authorization state to properly associate the primary fuel product with its secondary products, ensuring the correct price per unit and authorization limits are applied. (134033)
2. At sites with postpay and handle-up calling enabled, customers who inserted a payment card during the brief transition window between loyalty entry and the DCR becoming ready to accept payment would have their transaction silently cancelled — with no message displayed at the dispenser and no alert sent to the cashier. This left the customer unaware of the failure, causing them to lift the handle under the assumption their card was accepted, while the cashier — seeing no indication of an issue — would approve what appeared to be a standard postpay, resulting in potential drive-offs. The resolution adds a “Transaction Cancelled” message at the DCR and a bad card read alert at the cashier workstation whenever a payment failure occurs after loyalty in this scenario, ensuring both the customer and cashier are notified before the pump can be approved. (132916)

### EPS System

Customers using a contactless hybrid card with PIN select were unable to receive cash or debit pricing because the system matched loyalty before debit during payment rematching, causing the transaction to default to credit instead of debit. The resolution persists the debit entry throughout the payment rematch process so that after the loyalty match is resolved, the correct debit pricing is applied as the final payment option. (136274)

### Loyalty

1. At certain pump positions, loyalty awards were not being finalized, causing the pump to dispense fuel at the original price per unit rather than applying the earned loyalty discount. The root cause was a loyalty completion flag that incorrectly defaulted to true when not explicitly set; the flag now defaults to false when a loyalty program ID is present, ensuring proper finalization of pump transactions. (135454)
2. Wayne Anthem dispenser card readers were presenting a “Scan Loyalty Code” option to customers even when the DCR position's scanner was disabled in the Position Attributes configuration. The correction adds a combined check so the “Scan Barcode” softkey is presented only when both the DCR position-level scanner and the loyalty program's barcode scan option are simultaneously enabled. (135353)

### POS System

1. In back-to-back Auto Upgrade scenarios, a preceding AU run could delete current period records for certain period types, causing subsequent upgrade executions to fail because the expected breadcrumb files were never created for those deleted periods. The Auto Upgrade script has been enhanced to create the appropriate period-closed breadcrumb files when neither a closed nor an open-needs-cleanup breadcrumb is present, ensuring back-to-back upgrade sequences complete successfully. (136486)
2. Certain files had no size or age limits, allowing them to grow unbounded over time and consume excessive memory on the Commander. A check has been added to cap the files to the 20 most recent entries, and failure detection dates older than 90 days are now pruned to keep file sizes manageable. (135270)
3. Auto Upgrade log files were not being copied to the Commander Site Controller's hard disk drive because the suffix handling for the file was incorrect, preventing it from being recognized during the log shipping process. The resolution corrects the file reference so that it is properly identified and included when Auto Upgrade logs are shipped to the Commander Site Controller HDD. (135198)
4. Auto Upgrade from version 53 to 55 was timing out when an excessively large accumulation of data existed in an open current period that had never been properly closed, requiring the upgrade process to restore years of period data within a limited window. Period duration validation has been added as part of the Auto Upgrade pre-check stage to detect excess data conditions and either fail gracefully with a clear diagnostic message or automatically clean up records where permitted, preventing multi-hour upgrade timeouts. (134040)
5. Following a same-major-version Auto Upgrade, mobile report data was lost because the active and archive mobile data directories were absent from the backup manifest and were deleted when the mobile application package was reinstalled. The resolution adds both missing mobile data directories to the backup cleanup manifest so they are preserved unconditionally across all Auto Upgrade operations. (133296)
6. Following an Auto Upgrade to 55.02.04 on certain sites, historical reports were no longer accessible after the upgrade completed. The issue occurred because the Commander's certificate renewal process, which runs as part of every upgrade, failed on sites where the network was configured to return an IPv6 address instead of the expected IPv4 address — causing the upgrade to be unable to securely transfer the reports database to the new software. The resolution updates the certificate renewal process to ignore IPv6 addresses and always use the correct IPv4 address, ensuring historical reports are preserved across Auto Upgrades on these sites. (128066)
7. Auto Upgrade (AU) failures occurred in scenarios where a Day Close had been performed but no transactions followed for subsequent days — the period validation logic introduced to ensure periods are closed within their expected duration incorrectly interpreted this as a missing Day Close because the day appeared to contain more than one day's worth of data. The fix updates the validation to confirm there are no open sales after the last Day Close before blocking an AU, preventing false failures in low-activity or idle-day scenarios. (137016)

### Sales

1. When cash rounding was enabled, the coin changer was not triggering on fuel prepay under-runs and lottery paid-outs because the payment line lookup returned the rounding adjustment line rather than the cash line, causing the dispenser amount calculation to be skipped. The resolution updates the payment line scan to explicitly locate the cash line with a negative amount, ensuring the coin dispenser triggers correctly even when a rounding mode-of-payment line is appended last. (136275)
2. During a cash transaction with Charity (Nearest Dollar) penny rounding, the outdoor display briefly showed an incorrect change amount immediately after the charity prompt was processed, before correcting itself. The issue has been resolved by guarding the cash-rounding recalculation in the transaction model with the post-payment mode flag, ensuring only the designated rounding handler updates the displayed change amount during post-payment adjustments. (135940)
3. When a customer canceled a charity donation prompt while cash rounding was active, the outdoor display continued showing a stale non-zero change amount instead of refreshing to zero. The resolution updates the transaction model to notify balance observers whenever the change line is removed or modified after charity cancellation, ensuring the display correctly reflects the rounded change amount. (134444)
4. When cash rounding rounded a prepay transaction down, the small remaining balance was incorrectly treated as unpaid, preventing loyalty and point-of-purchase discount details from being finalized and causing the pump to dispense at the original price per unit. The resolution widens the payment balance check to treat any remaining balance within the configured rounding adjustment as fully settled, ensuring pump discounts are correctly applied on round-down cash prepay transactions. (134320)
5. When a prepay transaction with a gallon limit and cash rounding was completed, the rounding handler re-executed the rounding calculation on the already-rounded cash payment line whenever feature handlers re-fired, inverting the rounding amount and leaving the sale in a coming-due state. The resolution prevents the rounding handler from recomputing when a rounding mode-of-payment is already applied and no recalculation is needed, ensuring gallon-limited prepay transactions with cash rounding finalize correctly. (133419)
6. Customers were able to purchase age-restricted products using a driver's license expiring in the current calendar month because the system validated only the expiration month and year without checking the day. The resolution verifies the expiration date to the day of the month when available, assumes end-of-month expiration for month/year-only formats, and blocks the transaction if the host returns an error following local validation. (94307)
7. In Commander version 55.02.05 and higher, loyalty account numbers and EPS loyalty message events were no longer being captured in T-Log data for secondary loyalty transactions. The root cause was a loyalty authorization data structure that checked for a null array of loyalty authorization objects but did not account for a zero-length array, causing secondary loyalty data to be skipped entirely. The fix adds the additional zero-length array check in Transaction.java, ensuring loyalty account details are correctly captured for secondary loyalty transactions. (134228)

<h2 align="center">FEP Specific Changes</h2>

### NBS FEP

#### Resolutions

Fleet card collect transactions were failing when odometer values entered at the pump exceeded the card network's maximum allowable range, as the generic prompt accepts up to 9-digits while some networks enforce a shorter maximum. The resolution truncates the odometer value to the card network's maximum range before transmission, preventing collect failures caused by out-of-range odometer entries. (133767)

### Phillips 66 FEP

#### Resolution

The Commander Site Controller was applying incorrect decimal precision to three Visa Fleet 2.0 G-segment user data fields — Fuel Quantity, Fuel Unit Price, and Gross/Net Fuel Amount — causing values to be transmitted two decimal places too far to the left (e.g., 1.960 gal reported as 0.0196). The Visa Fleet 2.0 specification requires these fields to use a 9(8)v9999 format (4 implied decimal places); all three fields were corrected accordingly. (136586)

### Rapid Connect FEP

#### Enhancement

**Price Tier Configuration**

The price tier configuration field has been re-enabled for all installations in this release, providing operators with greater flexibility to configure price tiers to meet network-specific requirements. This change benefits sites that require price tier adjustments, removing a prior restriction that had limited field availability. (135298)

#### Resolutions

1. Following repeated unsuccessful day-close settlements, the warning message showing when transactions would stop was compounding the stop date by 15 days on each additional failure, producing an ever-increasing future deadline rather than a fixed one. The resolution calculates the transaction-stop date as a fixed 15-day window from the actual first failure date, so the warning message consistently displays the correct deadline regardless of how many subsequent day-close failures occur. (134409)
2. Mobile wallet transactions (Google Pay, Apple Pay, Samsung Pay) using Discover cards were not receiving the configured host fuel discount. The card number delivered by mobile wallets is in a raw numeric format that lacked the \* stop character expected by the terminal's BIN extraction logic, causing the discount matching engine to return “NO MATCHES FOUND” and skip the discount entirely — physical card transactions were unaffected. The host discounting logic was updated to detect mobile entry mode and reconstruct the PAN into the expected masked format prior to BIN range lookup, allowing Discover mobile wallet transactions to correctly match the host discount table and receive the applicable fuel discount. (134527)

### VAPS FEP

#### Enhancements

**Network Batch Monitoring**

This feature introduces network batch monitoring capabilities, enabling operators to track the status and health of network batch settlements. The enhancement provides greater visibility into batch close operations, helping sites identify and respond to settlement issues before they impact ongoing transactions. (135259)

**Batch Enhancements**

This enhancement introduces batch close and configuration recreation improvements for network integrations, along with additional changes to address Store-and-Forward queue clogging issues. These updates improve network settlement reliability and reduce the risk of SAF queue buildup causing delayed or failed transactions. (135320)

#### Resolution

The Commander Site Controller was applying incorrect decimal precision to three Visa Fleet 2.0 G-segment user data fields — Fuel Quantity, Fuel Unit Price, and Gross/Net Fuel Amount — causing values to be transmitted two decimal places too far to the left (e.g., 1.960 gal reported as 0.0196). The Visa Fleet 2.0 specification requires these fields to use a 9(8)v9999 format (4 implied decimal places); all three fields were corrected accordingly. (136586)


---

# 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://commanderhelp.verifone.com/customer-documentation/petro-and-c-store/commander-highlights-user-guides-release-notes-and-certifications/commander-55.02/commander-55.02.10-release-notes/whats-new-in-release-55.02.10.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.
