Release V9.2.6.7
Security Enhancements
Security fixes implemented in this release:
Data Security: PAN Data Exposure in Admin Console API Response Logs Display
Context: When viewing transaction logs in the Admin Console, some API responses related to detokenization requests were displaying unmasked PAN data in cleartext, creating a potential security risk and PCI DSS compliance issue.
Solution: Implemented comprehensive response data sanitization that automatically masks sensitive information in API response logs before storing them in the database, while preserving the original data flow for legitimate processing.
Impact: Enhanced security for cardholder data with no change to system functionality. When viewing logs in the System Console, sensitive card data now appears properly masked, preventing unauthorized access to this information.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: No schema changes; data sanitization is now performed before storing in the charge_transaction_log table
- Configuration Changes: None required
- Code Changes: Enhanced GatesLogger and HTTPFormGates classes to implement sensitive data masking
- Filesystem Changes: None
- Data Migration: None required for new transactions; existing sensitive data will be addressed separately
Update Actions Analysis
Update actions are not required for this change
- The security enhancement is implemented entirely through code modifications
- No configuration parameters need to be updated
- The fix is applied automatically to all new API response logs
- Existing data cleanup will be handled as a separate process
Implementation Actions
- Modified the GatesLogger class to identify and mask sensitive data in response logs
- Added detection for detokenization request types to prevent logging them
- Implemented special handling for account numbers using FormatHelper.formatAccount
- Applied data truncation for excessively long values to improve performance
Configuration and Access Steps
- No special configuration is required for this feature
- Testing requires admin access to the System Console
- API detokenization requests must be processed through the system
- Navigation: Perspective > System > Logs > View Logs
Test Scenarios
-
Verify PAN Masking in API Response Logs
- Steps: Process a transaction that requires detokenization, locate the transaction in System Logs, and view the response
- Expected result: Card data should appear masked in the response details
-
Verify Detokenization Request Filtering
- Steps: Check transaction logs for any detokenization requests
- Expected result: New detokenization requests should not appear in the logs
-
Verify Account Number Masking Format
- Steps: Process a transaction with account number, view response log
- Expected result: Account numbers should be masked according to PCI requirements (showing only first 6 and last 4 digits)
-
Verify Other Sensitive Data Masking
- Steps: Process transactions containing other sensitive data (CVV, expiration date)
- Expected result: All sensitive data should be completely masked with asterisks
Common Issues
- Legacy data may still contain unmasked information until cleanup is completed
- Custom transaction types may require verification for proper masking
- Complex nested responses should be checked for complete masking
- Response logs from before the update will not be automatically masked
Potential Impact Areas
- UI Components: No direct impact on UI components
- Reports & Analytics: No impact on reporting functionality
- APIs & Integrations: No change to API behavior; only affects how responses are logged
- Database Queries: No impact on database queries
- Business Logic: No change to transaction processing logic
- Performance: Minimal performance impact from the additional masking operations
Schema Updates
- No database schema changes are required
- No new tables, fields, or indices are added
- Data sanitization occurs in the application layer before storage
Rollback Possibility Assessment
Database rollback is not applicable for this change
- This change affects only how new data is processed before being stored
- No database structure modifications are made
- Any rollback would require code reversion rather than database schema rollback
- Existing data will require a separate cleanup process regardless of code rollback
Note: It is strongly recommended to schedule deployment during non-business hours in the client's time zone. This timing is critical because potential offline periods may extend beyond estimates due to unforeseen circumstances.
Fixes
The following fixes have been implemented in this release:
- Fixed AMEX Transaction Processing in Merchant Warrior Integration (UP-728)
- Enhanced Field Capacity for Merchant Statement Statistics(UP-741)
Fixed AMEX Transaction Processing in Merchant Warrior Integration
Context: AMEX transactions processed through the Merchant Warrior integration were failing with "Data truncation" errors because the authorization code field was too small to accommodate the 15-digit Transaction Identifier used by AMEX.
Solution: Implemented database schema modifications to increase the AUTH_CODE field size and improved parsing logic to properly handle AMEX-specific response formats.
Impact: Merchants can now process AMEX cards through the Merchant Warrior integration without system errors, and all transactions are properly recorded regardless of approval status.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: Modified AUTH_CODE field in MWE_AUTH_RETAIL_TRANSACTION table from VARCHAR(12) to VARCHAR(15)
- Configuration Changes: Updated Hibernate mappings for the MweAuthRetailTransaction entity
- Code Changes: Enhanced parsing logic to properly truncate values and handle AMEX-specific data formats
- Filesystem Changes: None
- Data Migration Needs: None beyond automatic schema update
Update Actions Analysis
Update actions are not required for this fix.
- The database schema changes are handled automatically during deployment
- The code changes are self-contained within the core application
- No configuration files need to be manually modified
- No data migration scripts need to be run separately
Implementation Actions
- Deploy the application with the updated database schema
- Restart the application to apply the changes
- No manual intervention is required
- No additional configuration is needed
Configuration and Access Steps
- Ensure that a merchant account is configured with Merchant Warrior as the payment processor
- Enable AMEX cards in the merchant account configuration
- Verify that the processing profile has all required credentials
- Navigation: Merchant Management → Merchant Account → Payment Cards → Realtime → Merchant Warrior
Test Scenarios
-
AMEX Card Successful Transaction
- Steps: Process a payment using a valid AMEX test card through the Merchant Warrior integration
- Expected result: Transaction completes successfully and is properly recorded in the system
-
AMEX Card Declined Transaction
- Steps: Process a payment using an AMEX test card configured to be declined
- Expected result: Transaction is declined but still properly recorded in the system with the correct status
-
AMEX Card with Long Authorization Code
- Steps: Process a transaction that returns a 15-digit authorization code
- Expected result: The code is correctly stored without truncation or errors
-
Verify Transaction Details
- Steps: View the transaction details page for a completed AMEX transaction
- Expected result: All fields including the authorization code are displayed correctly
Common Issues
- Validate that no "Data truncation" errors appear in the application logs
- Ensure that both approved and declined transactions are visible in the transaction list
- Verify that the authorization code displayed in the UI matches what was returned by Merchant Warrior
- Check that transactions with various authorization code lengths are handled correctly
Potential Impact Areas
- UI Components: Transaction details display should properly show the longer authorization codes
- Reports & Analytics: Transaction reports including authorization codes should display the full code
- APIs & Integrations: API responses with transaction details should include the correct authorization code
- Database Queries: Queries filtering or sorting by authorization code need to handle the longer values
- Business Logic: Authorization verification flows should properly use the full authorization code
- Performance: No significant performance impact is expected from this change
Schema Updates
- Altered MWE_AUTH_RETAIL_TRANSACTION table to increase AUTH_CODE column size from VARCHAR(12) to VARCHAR(15)
- Updated Hibernate mapping files to reflect the new column size
- No other table structures were modified
Rollback Possibility Assessment
Database changes can be safely rolled back if necessary.
- The change is a simple column width increase with no data loss risk
- No data transformations or complex migrations were performed
- Reverting the column size would not affect existing data as long as no authorization codes longer than 12 characters were stored
- Standard schema rollback procedures are applicable
Enhanced Field Capacity for Merchant Statement Statistics
Context: Merchant statement statistics processing failed for high-volume accounts due to numeric field size limitations in the database, causing critical task failures in the Remittance module.
Solution: Increased the capacity of all balance and amount fields in the merchant statement statistics tables by changing their data types from INTEGER to BIGINT, providing significantly higher value limits.
Impact: The system can now correctly process and store statistics for merchants with high transaction volumes without encountering numerical overflow errors, ensuring stable operation of the merchant statistics services.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: Modified field types in IAPP_MERCHANT_STATEMENT_STATISTICS and IAPP_MERCHANT_STATEMENT_STATISTICS_DETAIL tables, changing multiple numeric fields from INTEGER to BIGINT
- Configuration Changes: None
- Code Changes: Updated report templates and field mappings for Monthly Processing Statement reports
- Filesystem Changes: Updated jasper report files in the reporting module
- Data Migration: No data migration required as BIGINT is compatible with existing INTEGER values
Update Actions Analysis
No update actions are required because:
- All necessary changes are implemented through standard database deltas
- Field type modifications are forward-compatible with existing data
- Application code and report templates are updated within the standard deployment process
- No manual data migration or configuration changes are needed
Implementation Actions
- Deploy database deltas to increase field sizes in production database tables
- Update application code with modified report templates
- Monitor statistics processing jobs after deployment to verify successful processing
- Verify report generation for affected merchants
Configuration and Access Steps
- No special configuration is required after deployment
- Verify successful database schema updates by examining table structures
- Test statement statistics processing with large transaction volumes
- Navigation: Reports → Statements → Monthly Processing Statement
Test Scenarios
-
Standard Merchant Statement Generation
- Steps: Generate monthly processing statement for a standard merchant account
- Expected result: Report generates correctly with all financial data properly displayed
-
High-Volume Merchant Statement Generation
- Steps: Generate monthly processing statement for a merchant with transaction totals exceeding 2 billion units
- Expected result: Report generates correctly with accurate balance calculations
-
Statistics Job Execution
- Steps: Run the statistics service job "imerchant.statistics-create-merchant-statement-statistics"
- Expected result: Job completes successfully without out-of-range errors
-
Report Data Verification
- Steps: Compare statement balances in generated reports with transaction data
- Expected result: All amounts match expected values based on transaction history
Common Issues
- If report generation fails, verify jasper report template deployment
- If statistics jobs fail, check application logs for specific error messages
- Verify that the database schema changes were applied correctly
- For any large balance discrepancies, investigate transaction record integrity
Potential Impact Areas
- UI Components: Monthly Processing Statement report display
- Reports & Analytics: Merchant statement statistics and balance reporting
- APIs & Integrations: Merchant statistics API responses should now handle larger values
- Database Queries: Queries for merchant statistics tables should function with increased field sizes
- Business Logic: Remittance processing and statistical calculations now support larger transaction volumes
- Performance: No significant performance impact expected from field size increase
Schema Updates
- Changed NET_BALANCE field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed RETURNS_BALANCE field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed DEDUCTIONS_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed WITHDRAWALS_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed REMITTANCES_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed RETURNS_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed MERCHANT_FEE_REIMBURSEMENT_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed MERCHANT_FEE_WRITEOFF_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed MERCHANT_BALANCE_WRITEOFF_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed ADVANCES_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed PREV_BALANCE field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS table
- Changed AUTHORIZATION_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS_DETAIL table
- Changed SETTLEMENT_AMOUNT field from INTEGER to BIGINT in IAPP_MERCHANT_STATEMENT_STATISTICS_DETAIL table
Rollback Possibility Assessment
Rollback is possible with the following considerations:
- The changes are non-destructive since they only expand field capacity without data transformation
- No data will be lost during rollback as long as no values exceeding INTEGER limits have been stored
- If large values (exceeding 2^31-1) have been stored after deployment, rollback would cause data truncation
- Rollback would require restoring the previous INTEGER field types and could potentially trigger the original overflow errors
Important Note: This deployment should be scheduled during non-business hours in the client's time zone since database schema modifications may cause temporary service disruption. Plan for potential offline periods that may extend beyond initial estimates due to unforeseen circumstances.