> 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/petroleum-docs/petro-and-c-store/commander-highlights-user-guides-release-notes-and-certifications/commander-56.03/commander-56.03.02-release-notes/whats-new-in-version-56.03.02.md).
# What’s New In Version: 56.03.02
### Release Summary
Verifone Commander Release 56.03.02 delivers new features and resolutions focused on payment processing, Auto Upgrade reliability, and system stability. Highlights include Commander Central memory reporting for upgrade planning, Voyager Track 1 card parsing fixes, Spanish DCR prompt support for Latin America markets, and batch monitoring. Key resolutions address Visa Fleet format errors, duplicate loyalty TCP sessions, incorrect Store and Forward refund message types, age verification issues, and long-standing issues with coin changers, USB displays, and printer-related delays and reboots.
## Enhancements and New Features
### Verifone Commander Central
#### 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 as-set 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)
#### 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)
#### 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)
### Dispenser Card Readers
#### Language Support
Additional language support has been added for secure prompts displayed on DCRs, expanding the languages available for customer-facing secure entry screens at the dispenser. This supports multilingual site deployments requiring localized DCR prompt text. (133827/134151)
### EPS System
#### Track 1 Parsing
1. 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)
2. Support for variable-length name fields in Voyager Track 1 card data has been implemented in the EPS processing layer. The updated delimiter-based parsing logic correctly handles the full range of Voyager Track 1 card formats. (135682)
#### Comdata Payment Channel
The Comdata payment channel now supports establishing either an SSL (TLS) or non-SSL connection to the Comdata host, giving sites flexibility as they transition to secure host connectivity. An SSLConfig component has been wired into the primary IP channel configuration so that outbound connections can establish over TLS when required, while standard non-SSL behavior remains unaffected. (137896)
### POS System
#### Auto Upgrade
Auto Upgrade reliability has been improved by fixing an issue where two internal licensing components could occasionally lock each other out, causing the process to stall. This has been resolved by changing how connection updates are handled internally, preventing the freeze-up across all affected systems. (137320)
Resolutions
### Verifone Commander Configuration Client
At some sites, users could get locked out of Commander Configuration Client with a “Read timed out” login error, and the only correction was rebooting the site. This issue has been resolved, so Commander Configuration Client logins now stay reliable without requiring a reboot. (168674)
### Verifone Commander Central
1. 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)
2. 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)
### Dispensers
1. There was an issue where changing the fuel price-per-unit (PPU) decimal format (e.g., from
$X.XXX to $XX.XX) caused incorrect fuel prices to be sent to the host in Price Change Notifications. For example, a price of $11.29 would be reported as $1.129. Commander now correctly sends fuel prices to the host regardless of the configured PPU format. Additionally, if a PPU decimal format change is pending, Commander will now block a Fuel Prices Init and prompt the user to perform a Full Fuel Init first, preventing pricing inconsistencies. (134199)
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. 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)
2. 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)
### EPS System
1. 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)
2. Configuration changes made to CommFleet (Comdata/WEX OTR) host settings through Commander Central were not being applied to the active processing channel until EPS was manually restarted, causing unnecessary service interruptions. This has been resolved by updating the FEP table update handler to reinitialize the channel when configuration changes are received. (137077)
### Loyalty
1. 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)
2. After a hybrid card loyalty transaction where the customer selected a PCATS02 loyalty program and pressed DONE instead of swiping a separate loyalty card, loyalty discounts and program details were not printing on the receipt because the loyalty authorization element was stored under the card type label but looked up using the FEP name. This has been resolved by adding a key resolution helper that correctly maps hybrid card FEP names to their card type labels, ensuring the authorization is found and the receipt is fully populated. (137742)
### Mobile
When a mobile payment connection was disabled while a second connection sharing the same merchant account was active, the system would become stuck waiting for a financial settlement that could never complete — because the payment host automatically dropped both connections when it detected duplicate accounts. This has been resolved to ensure the connection shuts down cleanly even when a settlement is still pending. (136764)
### POS System
1. A back-office system was sending too many stylesheet-based report requests at once, and when user connections timed out mid-request, the system failed to clean up properly, causing files to pile up and memory usage to spike. This was resolved by processing these reports one at a time, queuing instead of running them all at once, and by improving the cleanup process so resources are released properly, even when something is incorrect. (137529)
2. 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)
3. Auto upgrades on Commander EF sites from version 56.03.00 were completing with errors because the system encountered an unexpected condition when restoring user roles that included functions not available on the current Commander configuration. This has been resolved by updating the restore process to safely skip unavailable functions rather than failing the entire upgrade. (135804)
4. Users experienced checkout lockups and possible data errors because of an outdated method the system used to manage database connections. Under heavy use, too many processes got backed up waiting their turn, which slowed down how quickly connections could be released and picked back up. This was resolved by redesigning how connections are obtained and released so they no longer compete with each other, plus adding extra safeguards to keep the system stable when multiple processes run at the same time. (135650)
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. 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)
7. 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)
8. During a software auto-upgrade at a site, the process took over two hours because the monthly reporting period had never been closed in several years, causing the data backup file to increase over 500,000 records and exceed the upgrade's 30-minute restore timeout — triggering repeated retry attempts that added to the delay. Another issue also caused the system to reject a small number of fuel records with an unrecognized product identifier, and when the restore timed out, it would restart from the beginning rather than picking up where it left off. The resolution includes a software correction to properly handle those invalid fuel records, an increase of the restore timeout from 30 to 60 minutes, and updated upgrade instructions along with a KB Article advising sites to **close their yearly report before initiating an upgrade** if monthly periods have not been closed in a long time. (134040)
9. Auto Upgrades on Commander were sometimes failing to finish correctly because of a rare timing issue in how the system managed its network connection and licensing checks at the same time. On certain sites, this could cause the upgrade to get stuck partway through and prevent the Commander from reconnecting to Commander Central afterward. This has been resolved by changing how that network connection step runs, so it no longer conflicts with the licensing check. Commander updates on affected sites now complete reliably and reconnect to Commander Central as expected. (130800)
10. Transactions were taking 35-40 seconds longer than expected to complete when a receipt printer was set up in the system but not actually plugged in, because the system kept waiting on the printer during that process. This was corrected so the printer setup no longer holds up transaction completion. Additional improvements ensure the “printer unavailable” alert now shows correctly when a printer isn't connected, and that switching a USB-to-serial printer configuration no longer requires restarting the system. (125722)
11. There was an issue where POS devices with a printer configured but not connected would unexpectedly disconnect and reboot after being left running for an extended period. This has been resolved, and affected POS devices should now stay connected and stable. (131293)
12. The USB customer display on C18 hardware would stop working when other USB devices were also connected, due to a conflict introduced by recent Partner USB printer support that affected how devices were recognized on startup. This was corrected so the USB customer display now starts up reliably every time, regardless of what other USB devices are connected. (125568)
13. After upgrading Commander Site Controller to a newer software version, a USB Customer Display connected to the C18 could show a blank screen instead of the expected messages, even though the system still recognized the display as connected. The upgrade process was corrected so it no longer restores an old, conflicting display setting during the upgrade. The USB Customer Display now displays content correctly. (138492)
14. When upgrading Commander Site Controller and C18 devices to the newer software version, it was possible for an error to occur indicating the “Establish Communication” step had failed, even though the overall upgrade completed. This was corrected so that it reliably completes without error, restoring normal system communication and full POS functionality after upgrade. (137387)
### Reports
Users could not close out their end-of-day processing because it kept getting cancelled, caused by an error in the online age verification step combined with a brief network connection loss. This was resolved by handling the errors better during sales processing, and making the network connection more resilient to recover from these brief losses on its own, without needing a system reboot. (136679)
### 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. 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)
## FEP Specific Changes
### Chevron FEP
#### Resolutions
1. During Business Date offline sign-on, an unbounded while loop in the channel reconnect method bypassed the 15-attempt retry limit and could hang the system indefinitely during socket failures, and the EOD flow lacked protection against concurrent sign-on requests after day close. This has been resolved by implementing a bounded 15-attempt retry method shared by both startup and EOD paths, with a thread-safe flag preventing concurrent EOD sign-on requests. (135609)
2. Chevron sites processing refunds that timed out and were stored in the Store and Forward (SAF) queue were having those refunds declined by the payment processor with a response of “12 - Invalid Transaction” because the SAF refund request was being sent with message type 2220 (the Store and Forward message type) instead of the correct 2200 message type with function code 280. This caused the Chevron host to misinterpret the queued refund as a completion request rather than a refund, potentially resulting in the cardholder being charged instead of credited. This has been resolved by updating the SAF refund flow to use the correct predefined message type 2200 with the refund function code 280, consistent with the Chevron host interface specification. (133141)
3. Outside contact transactions on certain DCR models were experiencing format errors because an EMV tag correction script ran before a required configuration file was available, resulting in a corrupted tag value being transmitted in the transaction. This has been resolved by restructuring the installation process so the correction script executes only after all necessary data files have been fully deployed, eliminating the install-order dependency. (137885)
4. When a manual sign-on was used to recover from a loss of communication with the host, the indicator to resume automatic sign on recovery was not being reset properly resulting in manual sign on being required for any future loss of communications with the host to reconnect. This has been corrected and now the system will resume automated sign on retries after a manual sign-on has been completed. (138802)
5. 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)
6. There was an issue where a fuel sale would incorrectly appear as due inside when a customer selected a car wash post-dispense but the car wash device went offline before the code could be generated. The fuel transaction now completes normally at the outdoor DCR without being sent inside. The DCR displays a “CARWASH ERROR. SEE CASHIER” message (in English or Spanish depending on the configuration) and automatically prints a receipt to confirm the customer was not charged for the car wash. (133137)
### NBS FEP
#### Resolution
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)
### Shell FEP
#### Resolution
Users in Shell environments were unable to log in to the secondary Verifone EPS (PMC). This has been fixed by having the system check whether that file exists before using it, restoring normal login for Shell deployments. (136873)
### VAPS FEP
#### Enhancements
**Batch Enhancement**
Enhanced batch close and configuration file management now detects and recreates corrupted or zero-byte batch files that were causing the SAF (Store and Forward) process to enter an infinite loop and block host settlement. This improvement allows affected sites to automatically recover from batch file corruption and resume normal settlement operations without manual intervention. (135320)
**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)
#### Resolutions
1. Transactions were receiving format errors because the NTS encoder's 11-byte Tag 2 output was being incorrectly padded to 12 bytes after a recent encoder buffer change introduced an extra space character that corrupted the field. This has been resolved by adding an override in the NTS base encoder that explicitly enforces 11 bytes for Tag 2, consistent with the NTS specification. (135269)
2. Visa Fleet magnetic stripe sale and postpay transactions were receiving format errors because the legacy Visa Fleet transaction flow was not sending requests as preauth plus completion as required by the NTS v24.1 specification. This has been resolved by updating legacy Visa Fleet sale transactions to use the preauth and completion flow, consistent with the Visa Fleet 2.0 format. (137773)
### Verifone EPS FEP
#### Enhancement
**Bematech Printer**
Cashiers at sites using Bematech Fiscal Printers can now scan a customer's Tax ID (RUC) using a QR code or barcode at the fiscal receipt prompt instead of typing it in manually, reducing data entry time and errors at Latin American sites. This capability accepts valid RUC QR codes and bar codes up to 15 characters (non-UPC symbology) and gives a quick error beep on invalid scans, streamlining fiscal receipt generation. (134329, 134331)
---
# 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/petroleum-docs/petro-and-c-store/commander-highlights-user-guides-release-notes-and-certifications/commander-56.03/commander-56.03.02-release-notes/whats-new-in-version-56.03.02.md?ask=&goal=
```
`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.