> 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-57.01/commander-57.01.00-release-notes/whats-new-in-version-57.01.00.md). # What’s New In Version: 57.01.00

Release Summary

The 57.01.00 Commander release delivers enhancements and resolutions across the platform. New features include cloud-based hardware telemetry and report visibility through Commander Central, expanded language support on dispensers, Mudflap commercial fleet payment support, Smart Suggestions up-selling at self-checkout, charity donation configuration improvements, PCI-compliant password controls, Latin America payment processing, and initial market expansion into Argentina, Brazil, Uruguay, and the Cayman Islands. For the resolutions, the release addresses issues across the EPS, POS, mobile, loyalty, and auto upgrade systems, including corrections for transaction format errors, upgrade failures, connectivity issues, display issues, and database performance problems.

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 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) #### **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 Generated Reports** Commander-generated reports are now accessible through Commander Central, providing operators with cloud-based visibility into site reporting data. This implementation enables viewing of closed Commander reports directly from the Commander Central portal. (132995) ### 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 #### **Mudflap Fleet** Commander now supports Mudflap as a commercial fleet payment option. Sites can configure Mudflap fleet FEP settings through the standard commercial fleet configuration interface. (133889) #### **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) #### **Improved EMV Key Management** This update improves how the Verifone Commander manages the 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) ### Loyalty #### **Third-Party Loyalty API and Rewards** Commander has been integrated with the third-party loyalty API to support loyalty rewards redemption at the POS. This allows sites using the third-party loyalty platform to process loyalty rewards points and redemptions through the Commander payment flow. (114571) ### Mobile #### **Fleet Codes** Wright Express (WEX) and Comdata fleet codes can now be entered through mobile app transactions, expanding fleet card acceptance to mobile-initiated payment flows. This allows drivers using the mobile app to complete WEX and Comdata fleet transactions with the same prompt and validation experience as traditional DCR transactions. (131476) ### POS System #### **Decimal Positions** Commander now supports additional decimal positions for tax rate configuration, accommodating jurisdictions that require higher precision tax rates. Sites can now configure tax rates with the extra decimal precision needed to calculate taxes accurately without rounding errors. (133062) #### **Maintenance Menu** Several POS Maintenance Menu item labels have been updated with corrected or improved translations to better reflect their function. These are display only text changes with no impact on system behavior. (133970) #### **Passwords** Commander now enforces a one day waiting period between password changes, helping prevent password cycling. Users who forget their password within the 24-hour window may use the forgot password feature once, while Helpdesk and secure users retain unrestricted ability to reset passwords for other users. (135300/135362) #### **Reports and Back Office** Operators can now close a cashier shift from the back-office without requiring an active POS session. This is useful in scenarios where the POS is unavailable or a shift needs to be closed remotely from the Commander Site Controller. (124057) #### **RAM Requirements** Both the auto upgrade package and PSI installer now include a hardware prerequisite check that validates available system memory before proceeding. Systems with less than 8GB of RAM will be blocked from installation or upgrade, and an informative error is displayed so technicians know the hardware must be upgraded before continuing. (125624, 134705) #### **Spanish POS Menu Translation Improvements** Several Spanish language labels in the POS Maintenance Menu (including Helpdesk login/logout, upgrade summary and status, POS pairing, and cash recycler admin) used awkward or imprecise translations. These have been reviewed and corrected to more accurate, natural Spanish phrasing. This is a display-only text change with no impact on system behavior. (134214) #### **Xpient POS Integration** Support for the Xpient POS integration has been removed from Commander as part of an end-of-life cleanup. Sites using Xpient should contact support to discuss migration options before upgrading to this release. (133397/135221) ### Sales #### **Charity Donations** The Charity Donations feature has been enhanced to support independent configuration of the indoor charity prompt for both cash and card payment sections. Operators can now configure whether the charity prompt appears indoors, outdoors, or both through the back-office configuration interface. (135168/134704) #### **Smart Suggestions** Smart Suggestions, a new upselling feature that allows merchants to configure promotional prompts that appear to cashiers and customers at checkout time. Suggestions can be based on individual items (PLU), menu items, or NAXML combo and mix-and-match deals, with priority ordering available when multiple suggestions are configured. Each transaction displays one suggestion at a time on the POS, PIN pad, and/or self-checkout screen, giving store operators a simple, flexible way to remind customers about current promotions and increase basket size without requiring cashier training. (118225, 137080)

Resolutions

### Verifone Commander Central 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) ### Car Wash 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 and Spanish) and automatically prints a receipt to confirm the customer was not charged for the car wash. (133137) ### 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) 3. 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) ### 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. There was an issue where a DCR getting stuck during initialization could cause a completed inside prepay fuel transaction to incorrectly appear as due. The DCR could become stuck when a card was inserted during the initialization process, triggering error recovery. Commander now ensures the DCR properly completes its initialization and returns to a ready state after error recovery, preventing the transaction from being flagged as unpaid. (131013) 3. 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 canceled — 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 Can celled” 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 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. 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) 3. 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) 4. After an automatic update, a timing issue could cause the payment processing system to start up before all necessary configuration data had finished loading, resulting in missing information that caused a background process to crash repeatedly and block all payment transactions until the system was manually restarted. This has been resolved by ensuring the system waits for configuration data to be fully available before attempting to use it, preventing the crash from occurring. (136814) ### 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. 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) 4. 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) 5. 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) 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 auto upgrades, the Kiosk service failed to register with the upgrade remote service because critical initialization calls were inside a try-catch block where a prior exception silently prevented them from executing. This has been resolved by restructuring the startup sequence so initialization steps execute correctly and failures are properly logged and handled. (137373) 9. 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) 10. During an Auto Upgrade, a false E2001 POS Software Incompatibility overlay was displayed on the POS after Commander restarted with the new version but before the POS software had been upgraded, creating unnecessary alarm to operators even though the upgrade was proceeding normally. This has been resolved by introducing a centralized Auto Upgrade status tracker that suppresses the E2001 overlay while an upgrade is in progress. (137359) 11. The system was incorrectly reporting the suite name as Marathon instead of Buypass for sites using the Marathon customer profile in harmonized application deployments. This has been resolved by always reporting the correct suite name regardless of which customer profile is active. (137087) 12. On systems with less than 4GB of RAM, a fresh installation that included a data restore could get stuck because the system's low-memory protection was preventing essential services from starting, causing the restore process to time out and fail. This has been resolved by temporarily allowing all necessary services to start during the restore process on low memory systems, with the system automatically rebooting once the restore is complete. (136241) 13. 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) 14. Auto upgrades on Commander EF sites were failing because the system's configuration was missing required components, causing essential software modules to be left out of the upgrade package. A secondary issue was also incorrectly associating certain modules with hardware that wasn't present on the system. Both issues have been resolved by correcting the Commander EF configuration to include all required modules and ensuring software is only associated with hardware that is actually present. (135707) 15. After completing initial setup, Commander Site Controllers were not appearing as active in Commander Central and transaction logs were not being recorded. This was caused by the system publishing its site profile to the wrong endpoint during setup. This has been resolved by publishing the correct endpoint, ensuring sites become active and visible in Commander Central as expected. (135699) 16. During a previous software update, several important configuration and tracking files — including CAPK tracking files — were associated with the wrong component in the backup and restore process. This did not affect full Auto Upgrades, but caused these files to not be restored correctly during partial upgrades. This has been resolved by moving the files to the correct location and ensuring they are properly backed up and restored during all upgrade types. (134970) 17. 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) 18. 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) 19. 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) 20. 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) 21. There was an issue where sites using Cash Rounding (Penny Elimination) could see errors during Auto Upgrade, caused by rounding-related sales totals not carrying over correctly. Totals now restore properly during upgrade, so sites can update from Release 56.03 to 57 without interruption. (133067) 22. There was an issue where penny rounding amounts were not displaying for refund transactions on the cashier and shift reports. Rounding values now display correctly for refunds, giving cashiers and managers accurate, complete reporting. (133086) 23. There was an issue where, right after an upgrade, the POS could briefly show a misleading “software incompatibility” error while it was still connecting to Commander. The system now displays a clearer, more accurate message in this situation, reducing confusion during and after upgrades. (133388) ### Reports Users could not close out their end-of-day processing because it kept getting canceled, 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. 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 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) 4. 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) 5. 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) 6. There was an issue where prepay fuel sales with a gallon limit and cash rounding enabled could show a false “Sale Coming Due” message and an incorrect $0.00 cash line on the receipt after fueling completed. Sales now complete cleanly and receipts display correctly when the gallon limit is reached with rounding active. (133419)

FEP Specific Changes

### Chevron FEP #### Enhancement **WEX Fleet** Chevron sites now support additional and modified DF30 fleet prompts for WEX fleet card transactions, including updated prompt configurations required by WEX for compliance and enhanced fleet data capture. This ensures Chevron WEX transactions collect the correct fleet information at the dispenser. (131377) #### 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. During Chevron DRP Visa Fleet 2.0 certification testing, the Generic ID fleet prompt (Tag #23) was being incorrectly mapped to Tag #31 (User ID) in the Chevron host request. This was caused by a prior change that replaced Tag 23 with Tag 31 without accounting for the card-type-specific routing requirement, where Tag 23 is correct for Visa Fleet 2.0 cards and Tag 31 is correct for WEX Fleet 4.0 cards. This has been resolved by refactoring the prompt tag mapping logic to dynamically identify the card type and route the User ID prompt data to the correct tag for each fleet card program. (134404) 5. Sites were experiencing an issue where the End-of-Day Sequence Number (EODSN) was incorrectly incrementing when a site reconnected to the host after performing two or more store closes while offline. This occurred because the offline sign-on process triggered during a store close did not properly validate the request type, allowing a generic host success response to incorrectly update the business date and EODSN. This has been resolved by routing the offline sign-on process through the Reconcile Agent, ensuring that only properly validated requests carrying the required flag can update the business date or EODSN. (131511) 6. During a network outage affecting the host, many 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) 7. 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) ### 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) ### 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 **Datawire** Fiserv Datawire EMV CAPK session transaction certification has been completed, validating Commander's compliance with Buypass/Datawire requirements. The integration has been updated to support CAPK key downloads using a session-based transaction flow, where Commander initiates a session with the Datawire host, downloads the CAPK table, and terminates the session cleanly, ensuring EMV key management compliance for Buypass/ Datawire sites. (134607, 135408) #### Resolutions 1. When the Buypass FEP merchant ID was cleared off from Commander Central configuration, the Update Manager entered an infinite loop waiting for host acknowledgment that could never arrive with a blank Manager ID (MID), freezing the system and blocking all further configuration updates until a manual reboot. This has been resolved by adding a null check to skip the loop when the MID is blank and introducing a 60-second timeout to prevent similar loops when a non-blank incorrect MID is configured. (137512) 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) 3. 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) 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 was resolved by updating the reversal logic to send the card number as required by the host specification. (133105) 5. Some sites found that after installing an update, the payment host showed as offline and they could not run key end-of-day tasks like price/discount downloads or till reconciliation. This was resolved by correcting file permissions during installation, so the payment host connects properly and these tasks run as expected. (134182) 6. After a Verifone Commander Site Controller finished onboarding, some network time settings sent from the cloud were not syncing correctly with Commander Central going forward. Store staff could update the time server settings, but the changes would not reliably show up on both sides. This was corrected so these settings stay in sync between Commander Central and the site as expected. (133736) ### Shell FEP #### Enhancement Commander has been updated to support Shell Loyalty Stacking, allowing Shell sites to stack a secondary loyalty program on top of the primary Shell loyalty session. The system now logs in as multiple-loyalty-capable and applies discount precedence rules in the correct order per the Shell loyalty specification. (109807) #### Resolution 1. Shell sites using older INFX EPS versions were experiencing login failures because the IFSF Login message was incorrectly sending the Multiple Loyalty Capable value regardless of actual site configuration, and a configuration refresh loop was creating an infinite cycle that flooded Commander logs. This has been resolved by tying the Multiple Loyalty Capable login value strictly to the Multiple Loyalty Enabled configuration flag (now defaulting to false for Shell sites) and removing the active POS Configuration re-pull that was triggering the infinite refresh loop. (137886) 2. Sites were finding that loyalty account numbers and related transaction details weren't showing up in the T-Log reports or the Commander Central reporting view for loyalty purchases, which stopped them from being reimbursed under their loyalty rebate programs. This has been fixed so that loyalty account information is now captured and recorded correctly for all transactions. (134228) ### VAPS FEP #### Enhancements **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) **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. There was an installation issue affecting sites on the NTS network that could cause required software components to be skipped during setup, leaving the system incompletely configured. NTS installations now complete correctly with all necessary components included. (134243) ### Verifone EPS FEP #### Enhancements **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) **Higher Fuel Preset Limits for PAM Protocol Sites** 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) **Latin America and Caribbean Support** 1. Initial market support has been added to the Commander platform for four new Latin America and Caribbean markets: Argentina, Brazil, Uruguay, and the Cayman Islands. This expansion lays the groundwork for full Commander operation in these regions. (135460, 135463, 135465, 137528) 2. Additional processing support for the Evertec payment processor has been added for Latin America and Caribbean deployments. This expands Commander's payment network compatibility for LAC sites that use Evertec as their payment host. (133298/131092) **Loyalty** 1. Cashiers can now press the loyalty button and scan a loyalty QR code to initiate loyalty processing with a third-party EPS. When the barcode is scanned, Commander routes the loyalty data directly to the loyalty FEP, removing the dependency on the third-party EPS for loyalty data submission. (135466) 2. Loyalty processing support with a secondary EPS has been implemented for the VerifoneEPS to Third-Party EPS configuration in LAC deployments. This enables sites to handle loyalty transactions correctly when using VerifoneEPS as the primary payment processor alongside a third-party EPS. (135220) #### Resolutions 1. 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) 2. 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) 3. Scotiabank Caribbean credit card transactions were failing when customers paid by chip or swipe. The card was declined with a generic failure message instead of completing the sale. This was corrected and it only affects newer payment terminals used with Scotiabank cards in the Caribbean region. (133502) 4. 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) --- # 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-57.01/commander-57.01.00-release-notes/whats-new-in-version-57.01.00.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.