> 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.01.md).
# What’s New In Version: 56.03.01
Release Summary
Verifone Commander Release 56.03.01 delivers targeted quality improvements across the platform, resolving 26 defects alongside three new features.
Enhancement
### EPS System
This update improves how the Verifone Commander manages the security keys required for chip card (EMV) transactions, giving operators clearer feedback and more reliable automatic key updates. When a manual key download is performed and no update is available, the POS now displays a confirmation message so cashiers know the request was received and processed; the system also begins tracking when and which payment devices last received updated keys, making it easier to diagnose issues if chip card problems arise. Additionally, the Verifone Commander now monitors chip card read failures across devices and will automatically request fresh security keys from the host when failures exceed a configurable threshold, helping sites stay current with required key updates without manual intervention. (121167)
### Resolutions
#### Verifone Configuration Client
1. Users were experiencing an issue where the DNS domain name entered in the Verifone Commander Configuration Client was being erased immediately after saving or after a configuration refresh, requiring the value to be re-entered repeatedly. The root cause was a prior code change that caused the LAN configuration page to read the domain name from an incorrect data source, affecting multiple software versions. This has been resolved by correcting the domain name retrieval logic to read from the proper configuration field. (128030)
2. Users were experiencing two syslog-related issues: security log server addresses removed through the Verifone Configuration Client were reappearing after a page refresh, and the first security event sent from the POS after a Verifone Commander restart was consistently being lost. The first issue was caused by PSI-configured log server entries not being properly tracked, making their removal appear as a redundant operation that was silently ignored; the second was caused by a timing gap that left the POS-to-Commander rsyslog TCP connection in a closed state after a restart. Both issues have been resolved by ensuring device host entries are synchronized correctly at startup and by adding initialization messages to re-establish the connection after a Verifone Commander syslog restart. (127807)
### Dispensers
Users performing prepay or credit card transactions at pumps using the Bennett RS485 fuel driver were finding that pressing the “Watch Pump” button caused the register screen to become stuck on the fueling message indefinitely after the fuel handle was hung up, with the Verifone Commander incorrectly showing the pump as still fueling. The root cause was that the high frequency of Watch Pump commands continuously filled the command queue, preventing the poll command needed to detect the end-of-transaction signal from being sent. This has been resolved by sending a poll command simultaneously with each pump data request, ensuring end-of-transaction detection is not missed. (129459)
### EPS System
1. Users conducting Visa Fleet 1.0 transactions at Flexpay6 dispensers were finding that the system was not prompting for fleet data fields such as Driver ID and Odometer reading, even though the required information was present in the card's track 2 discretionary data. The root cause was that the system incorrectly identified legacy Visa Fleet 1.0 cards as Visa Fleet 2.0 capable when DF tags were returned in the device response, causing it to look for prompts in DF30 rather than the track data. This has been resolved by adding validation of the 9F0A tag to correctly distinguish between Visa Fleet 1.0 and 2.0 cards before selecting the prompting method. (126705)
2. During Mastercard EMV certification testing, refund transactions were generating an incorrect first generate AC request, causing certification test cases to fail because the card was being asked for a Transaction Certificate instead of the required Authorization Request Cryptogram. The root cause was that during a specific PIN-select card flow, an uninitialized card type object caused an exception that silently defaulted the system to the wrong AC request type. This has been resolved by adding bounds and null checks to the card type lookup, preventing the exception and ensuring the correct cryptogram type is requested for all card flows. (121993)
3. Sites were experiencing an unwanted loyalty prompt appearing on inside PIN pads after payment, where cashiers and customers were asked about additional loyalty tokens even when no additional enrollment was expected, causing customers to abandon transactions. This behavior occurred because all payment cards are hybrid cards, so the system always initiated a loyalty token inquiry by design, with no way to suppress the post-payment prompt. This has been resolved by providing an alternative configuration option that moves the loyalty prompt to before the payment step, allowing sites to reduce disruptive post-payment prompting for cashiers and customers. (114963)
### Loyalty
Sites with dual-enrolled loyalty customers were experiencing an issue where full 16-digit credit card numbers were being transmitted to a loyalty host instead of the customer's phone number as intended. This occurred when a hybrid payment card was used alongside a loyalty card configured to route to multiple loyalty hosts, causing the wrong card data to be sent to the selected host. This has been resolved by adding a validation step to confirm that a loyalty card is authorized to route to the customer-selected host before transmitting any card data. (131663)
### Mobile Payment
Users initiating mobile outdoor fuel transactions at sites were having their transactions approved even when the required offline sign-on process had not yet completed, bypassing a critical authorization prerequisite. The root cause was that the mobile transaction flow was not checking the offline sign-on status before proceeding to approve the transaction at the pump. This has been resolved by adding an offline sign-on status check during the pump reservation state so that any transaction attempted before sign-on is complete is declined with an appropriate error message. (128861)
#### POS System
1. Users reviewing Digital Video Recorder transaction records were finding that actual customer dates of birth were being printed during age verification events, raising privacy concerns. The root cause was that the system logged the literal date of birth value rather than an anonymized indicator. This has been resolved so that the DVR now displays "Age verified" in place of the customer's date of birth. (131609)
2. Sites were frequently encountering socket timeout errors when logging into the Verifone Commander Configuration Client, and configuration commands such as saving, initializing, and refreshing were intermittently failing. The root cause was that the configuration management system was attempting to back up PLU configuration data without properly initializing the required database query object, leading to unhandled exceptions and database connection leaks that degraded system responsiveness over time. This has been resolved by updating the configuration visitor to properly close database connections in all code paths and by excluding unsupported commands from the backup audit process. (130870)
3. Users were experiencing incorrect transaction totals when an item with a combo discount was temporarily set to an invalid quantity and then corrected back to a valid quantity within the same transaction. The root cause was that the system retained the invalid quantity value during rollback, which broke the combo discount calculation and produced incorrect line item amounts. This has been resolved by performing a deep copy of the line item when a quantity veto occurs, ensuring the original quantity and pricing are correctly restored. (130869)
4. Users were experiencing configuration issues where kiosk and country option properties were being concatenated into a single line in the system properties file, preventing the system from reading individual configuration values correctly. The root cause was that a property entry was appended to the file without a trailing newline character, causing subsequent entries to be joined to the same line. This has been resolved by updating the country options initialization script to detect when the properties file does not end with a newline and to insert one before appending new properties. (130649)
5. Users scanning medical marijuana identification cards at the POS for age-restricted item purchases were finding that cards containing no date of birth or age indicator were being accepted, with the system displaying an incorrect default birth date rather than rejecting the scan. The root cause was that when no date of birth could be detected on the card, the system defaulted to a date that resulted in a passing age calculation. This has been resolved so that any ID card without a detectable date of birth is now marked as invalid and rejected at the point of sale. (127996)
6. Users were experiencing situations where PLU item price updates were only partially applied to the Verifone Commander database and were not being synchronized to the POS database when the update process encountered an error mid-stream. The root cause was that when a PLU record with an invalid zero key was encountered, an exception was thrown before the commit stage, leaving partial updates in Verifone Commander without notifying the POS synchronization layer. This has been resolved so that the POS now receives and applies any PLU updates that were successfully committed to the Verifone Commander database, even when the overall update request fails partway through. (121968)
7. Sites with cash rounding enabled were experiencing an incorrect change amount displayed on the Outdoor Display System Peripheral (ODSP) after a Charity donation prompt was canceled mid-transaction. The root cause was that when the charity prompt was dismissed and the change line was removed or modified, the Transaction Model did not notify balance observers of the update, leaving the ODSP showing a stale change amount (e.g., $0.02 instead of $0.00). This has been resolved by updating Transaction Model to notify balance observers whenever the change line is removed or modified after charity cancellation, ensuring the ODSP correctly reflects the zero change amount when rounding absorbs the remainder. (134444)
8. Sites processing fuel prepay transactions with cash rounding set to 'Round Down' and a loyalty per-per-gallon (PPG) discount were finding that the loyalty discount was not being applied at the pump, even though the receipt correctly showed the 'You Saved $X' message. The root cause was that when a round-down cash tender left a small positive remainder (within the rounding adjustment), the balance gate in Network Feature Handler incorrectly treated the transaction as unpaid, preventing the PPG discount finalization from running and causing the pump to dispense at the original price. This has been resolved by widening the balance gate to treat a remainder within the configured rounding adjustment as effectively zero when cash rounding is enabled, ensuring loyalty and POP PPG discounts are finalized and transmitted to the pump on round-down cash prepay transactions. (134320)
9. Users initiating prepay fuel transactions with a gallon limit enforced and cash rounding enabled were experiencing a spurious 'Sale Coming Due' message after fueling completed at the gallon limit, with a $0.00 cash line incorrectly added to the completion receipt. The root cause was that the Rounding Feature Handler re-ran the cash rounding calculation on an already-rounded payment line whenever feature handlers re-fired during prepay or gallon-limit completion events, sign-flipping the rounding MOP and leaving the cash payment out of balance with the rounded total. This has been resolved by short-circuiting the rounding recalculation when a rounding MOP is already applied and a recalculation is not required, ensuring the sale completes cleanly when the gallon limit is reached with rounding active. (133419)
10. Users were experiencing a failure to restore historical reports and totals data following an auto-upgrade, resulting in all pre-upgrade reports appearing empty. The root cause was that sites running on a network with IPv6 DNS configuration returned an IPv6 address for the Commander hostname, which broke the SSH certificate renewal scripts' principal derivation logic and caused certificate renewal to fail silently across the upgrade, preventing the totals database from being restored. This has been resolved by updating the certificate renewal and CA initialization scripts to explicitly select the IPv4 address when the hostname resolves to both IPv4 and IPv6 addresses, ensuring reliable certificate renewal and data restore across auto-upgrades in dual-stack network environments. (128066)
#### Sales
Users processing refunds on transactions that included mix-and-match discounts were receiving a refund amount of zero instead of the correct discounted refund amount. The root cause was that a prior code change failed to account for the sign of the amount in refund transactions, causing the system to incorrectly apply the original undiscounted item price instead of the discounted price when calculating the refund. This has been resolved by adding a sign check for refund transactions when determining which item amount to apply during refund processing. (128730)
## FEP Specific Changes
### Chevron FEP
#### Enhancement
This update adds support for additional and modified DF30 Fleet prompt codes used in WEX Fleet card transactions, aligning the system with the latest WEX Interface Requirements Guide. The updated prompt code mapping ensures that WEX Direct and WEX Third Party transaction flows can be executed correctly without generating incorrect or unmapped prompt IDs. This change enables sites to complete WEX Fleet compliance certification and process these transaction types without interruption. (132908)
#### Resolutions
1. Sites were observing that the End-of-Day Sequence Number and Batch Descriptor incremented unexpectedly after every manual Batch Close, and the POS incorrectly displayed an “Offline SSL Sign-On Successful” message following the close. The root cause was that the system was initiating the offline sign-on process during manual batch closes in addition to Day Close events, which was not the intended behavior. This has been resolved by restricting the offline sign-on trigger to Day Close events only. (131170)
2. During a network outage affecting the host, many Verifone sites failed to process offline-eligible transactions, resulting in declined transactions for customers who should have been approved offline. The root cause was that the offline authorization logic was applied correctly to magnetic stripe card transactions but incorrectly declined EMV chip card transactions rather than authorizing them offline. This has been resolved by updating the transaction processing logic so that EMV transactions also attempt offline authorization when a host unavailability response is received, consistent with the behavior for magnetic stripe transactions. (130888)
3. Sites were experiencing auto-upgrade and Point-of-Purchase upgrade processes that took approximately 40 minutes longer than expected to complete, and PSI local backup and restore operations were also impacted by the same delay. The root cause was that the Chevron secondary sign-on process was being initiated before the Channel Manager had finished initializing, causing an exception that introduced significant delays across all components that referenced the affected module. This has been resolved by relocating the secondary sign-on initiation to occur after the Channel Manager is fully initialized. (130444)
4. During Visa Fleet certification testing, fleet prompt data on printed receipts was only being partially masked rather than fully redacted as required when the card configuration specifies that data should not be printed in clear text. The root cause was that the receipt printing logic applied partial masking to fleet prompt values regardless of the card tag instructions. This has been resolved by implementing full masking of fleet prompt fields on receipts when the card tag indicates that data should not be displayed in clear text. (131183)
5. During Chevron DRP host Visa Fleet 2.0 certification, fleet prompt Tag #23 'Generic ID' was being incorrectly mapped to Tag #31 'User ID' in the Bit49 field of the Chevron host request, causing certification test cases to fail. The root cause was that a prior change intended to add User ID data to Tag #23 for Visa Fleet 2.0 transactions inadvertently replaced Tag #23 with Tag #31 rather than routing User ID data to the appropriate tag based on card type. This has been resolved by correcting the tag mapping logic so that Visa Fleet 2.0 transactions send Generic ID data in Tag #23 and WEX 4.0 transactions send User ID data in Tag #31, consistent with the Chevron host interface specification. (134404)
### HPS FEP
#### Enhancement
This update implements changes to the Visa Fleet 2.0 integration based on a later specification version, including an update to the Product Data Format element in data element 63 from value 3 to the required value of 4. Additional adjustments were made to merchandise data fields, including sending a space for service level and properly transmitting the amount and quantity. These changes ensure compatibility with Heartland processing requirements and alignment with the current Visa Fleet 2.0 specification. (121950)
### Rapid Connect FEP
#### Resolutions
1. Sites were experiencing a complete card processing failure after rebooting the Verifone Commander, with the system unable to accept any card payments. The root cause was that a network socket variable was null after the reboot, causing the payment processing component to fail when attempting to establish a host connection. This has been resolved by adding a null check on the socket client so that the system exits with a network error and can recover gracefully rather than entering an unresponsive state. (125994)
2. Sites were experiencing end-of-day processing failures where site asset data was not being transmitted to the host, leading to incomplete daily reconciliation records. The root cause was a capitalization error in the CRC field of the EMV key exchange packet, which caused a schema validation failure that blocked the subsequent site asset data transmission. This has been resolved by correcting the CRC field capitalization so that the packet passes schema validation and site asset data is sent as expected during end-of-day processing. (125570)
3. Sites were seeing the terminal batch number become stuck and fail to increment after end-of-day processing, and over time this caused the Verifone Commander database to fill to capacity and require a full system reload. The root cause was an incorrect date format in the EPS configuration file, which caused the host to reject the day close totals submission. This has been resolved by correcting the date format in the configuration file so that end-of-day transactions are accepted by the host and the terminal batch increments normally. (124078)
4. Users processing EBT transactions were experiencing failed reversal attempts, with the host returning a format error indicating a tag error in the reversal message. The root cause was that EBT void processing attempted to use track data that had already been cleared, causing the card number to be omitted from the reversal message entirely. This has been resolved by updating the reversal logic to send the card number as required by the host specification. (133105)
### Shell FEP
#### Resolution
Sites were finding that loyalty account numbers and associated transaction details were not appearing in T-Log data or the C-Site reporting view for loyalty transactions, preventing reimbursement for loyalty rebate programs. The root cause was a side effect of BP loyalty enhancements introduced in Base 55 that changed the loyalty authorization data structure from a single object to an array; the updated code checked for a null array but not for a zero-length array, causing secondary loyalty authorization data to be silently skipped during transaction serialization. This has been resolved by adding an additional check for a zero-length array alongside the existing null check, ensuring that loyalty account information is correctly captured and logged for all transaction types. (134228)
### Verifone EPS (LAC) FEP
#### Enhancement
The Forecourt Controller now supports 6-digit mode for the PAM fuel protocol, increasing the maximum preset transaction amount from $999.99 to $9,999.99. This enhancement benefits sites in Latin America and other regions where higher fuel preset amounts are required to accommodate local pricing and market conditions. Operators can now configure larger fuel presets without being limited by the previous 5-digit constraint. (125995)
#### Resolutions
1. Users in Latin America and Caribbean regions were experiencing missing time zone options during installation and in the Verifone Configuration Client, preventing them from selecting the correct local time zone for their country. This occurred because the timezone data package was inadvertently excluded from the system image starting in Base 55, removing several LAC time zones from the available list. This has been resolved by including the latest timezone data package in the system image, restoring all LAC time zones to the time zone selection. (133248)
2. Users installing Verifone Commander with certain Latin American time zones such as Brazil/ Acre or Chile/Continental were unable to access the Configuration Client after installation, receiving an “AAA service unavailable” error, and auto-upgrades were stalling mid-process. The root cause was a time zone format mismatch that prevented the core services from parsing the installation date and completing startup successfully. This has been resolved by correcting the time zone format to ensure proper date parsing during system initialization. (133246)
---
# 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.01.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.