Vortex Release Version (March 15, 2026)

Fixed an issue where SaleCompletion transactions could intermittently fail validation because the system attempted to verify the original authorization before it was persisted in the database. The payment broker now checks Redis cache when the transaction is not yet available in the database, ensuring the correct authorization data is retrieved and preventing false authCode mismatch errors during secondary transaction processing.
Fixed a settlement issue where the Cardholder Activated Terminal indicator for Mastercard ecommerce transactions was not correctly populated, resulting in blank values and network rejects. The updated logic now sets the indicator based on device.catLevel when available, assigns 2 for off-premise unattended devices, assigns 6 for ecommerce or wallet transactions, and leaves the field blank when the transaction is not a CAT transaction.
Added new APIs to the eos-payment-api-cutoff service to allow on-demand triggering of bot-funding, bot-ach, and bot-dispute jobs. This improves testing efficiency by eliminating the need to wait for scheduled execution cycles and aligns with the existing job control pattern used for other Vortex services.
Resolved multiple issues in the Point of Sale Addenda Record for Vortex Omaha settlement files to ensure alignment with TapTrans specifications and authorization data. The final authorization code field now uses a static default value of 1 for all card brands, and several Discover-specific fields are now correctly mapped from authorization data elements while unsupported Discover fields are populated according to settlement specifications.
Corrected serialization of several fields in Discover Chip Addenda Records for Vortex Omaha settlement files. The fix ensures proper population of values including the Card Sequence Number, Terminal Country Code, Terminal Capability, CVM Results, Application Version Number, Application Identifier, and Interface Device Serial Number, aligning settlement output with legacy behavior.
Fixed mapping issues in the Discover Auth Addenda Record so settlement file values match the original authorization data. Identification method, MOTO indicator, and service development code fields are now populated correctly according to settlement specifications.
Corrected an issue where Discover transactions populated spaces in the CPS/IC1 Addenda Record instead of required values. The system now sends the electronic commerce indicator value for ecommerce transactions using a payment token and defaults to 00 for Discover transactions without a token, ensuring consistency with legacy settlement output.
Resolved an issue where the Terminal Verification Results value from Tag 95 was missing from the settlement file Chip 1 Addenda Record for certain EMV transactions. The Chip 3 Addenda Record indicator was also corrected to properly signal when additional addenda records follow, aligning settlement file behavior with the legacy system.
Added support for enriching Canadian Visa and Mastercard transactions processed through Stripe with Level 2 and Level 3 data fields such as tax amount, quantity, product code, and product description. This enables evaluation of potential interchange savings for merchants while transactions without enrichment continue to qualify at Level 1. Interac and Amex processing flows remain unchanged.

Impact

These updates improve settlement file accuracy across multiple card networks, strengthen validation logic for secondary transactions, and enhance compatibility with network specifications. They also expand testing capabilities through on-demand job execution and introduce support for Level 2 and Level 3 transaction enrichment to help evaluate potential interchange savings for Canadian merchants.