Release V9.2.6.4
Bug Fixes
This release addresses a critical issue with token handling:
Fixed tokenCode population in PaymentOption for NOC transactions
Context: When processing NOC (Notification of Change) for ACH transactions, the ibilling.billing-create-claims task was encountering failures due to inconsistent token values in the PaymentOption database entity.
Solution: Modified the token handling mechanism to ensure that both token and tokenCode fields in the PaymentOption database entity contain identical values.
Impact: The billing task now executes successfully for merchants with NOC transactions, ensuring reliable processing of billing operations and preventing system failures.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: No structural changes to database schema
- Configuration Changes: None required
- Code Changes: Modified token handling in TransactionProcessingServiceBean to ensure consistent token values
- Filesystem Changes: None
- Data Migration: None required
Update Actions Analysis
No Update Actions are required for this implementation.
- The change is implemented entirely through code modifications
- No configuration adjustments are needed
- No database structure changes are involved
- Standard deployment procedures are sufficient
Implementation Actions
- Deploy the updated code to production environment
- Verify successful execution of billing tasks after deployment
- Monitor billing operations involving NOC transactions
- No additional configuration or setup is required
Configuration and Access Steps
- No special configuration needed for testing
- Create test ACH payment option in test environment
- Process a test NOC transaction
- Navigate to: Billing → Tasks → ibilling.billing-create-claims
Test Scenarios
-
Token Consistency Verification
- Steps: Create a PaymentOption, process an NOC change, and examine the database values
- Expected result: token and tokenCode fields contain identical values
-
Billing Task Execution
- Steps: Execute the ibilling.billing-create-claims task for accounts with NOC processed ACH payment options
- Expected result: Task completes successfully without errors
-
Transaction Processing after NOC
- Steps: Process transactions with payment options that have undergone NOC changes
- Expected result: Transactions process correctly with the updated payment information
-
Database Query Verification
- Steps: Run SQL query to verify PaymentOption records after NOC processing
- Expected result: All NOC-affected records show matching token and tokenCode values
Common Issues
- Billing task logs may show previous errors with tokenCode mismatch
- Historical records processed before the fix may still have inconsistent token values
- Verify both new and existing payment options after NOC processing
- Check that all code paths for NOC processing are covered by the fix
Potential Impact Areas
- UI Components: No impact on user interface components
- Reports & Analytics: No impact on reporting functionality
- APIs & Integrations: No changes to API contracts or integration points
- Database Queries: Queries using tokenCode will now receive the same value as those using token
- Business Logic: Billing operations involving tokenCode field will process correctly
- Performance: No performance impact expected, as change simplifies token handling
Schema Updates
- No schema changes are made to the database structure
- Only data values in the PaymentOption entity are affected
- The fix ensures that token and tokenCode fields contain identical values
Rollback Possibility Assessment
Database changes can be rolled back if necessary.
- The change only affects how new data is written, not existing database structure
- No data transformation or loss occurs during the update
- Existing records are not modified by the deployment itself
- In case of rollback, new records would revert to previous behavior with potentially different token and tokenCode values
The deployment should be scheduled during non-business hours in the client's time zone, as any database-affecting change carries potential risk of extended offline periods due to unforeseen circumstances.