Release V9.2.6.9
Security Improvements
This release introduces enhancements to our security infrastructure:
FEATURE
[UP-780]Futurex Tokenization Service Integration
Context: The existing StrongAuth tokenization service needed to be replaced with a more robust and modern solution for secure payment card tokenization.
Solution: Implemented integration with Futurex tokenization service, allowing secure tokenization of card data without migration of existing tokens.
Impact: Payment processing now uses Futurex for secure card tokenization with improved reliability and performance, while maintaining the same API interface for clients. Note that certain batch operations may have different behavior compared to previous implementation.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: Added new tables
TOKEN_REGISTER_FUTUREX_PROFILEandFUTUREX_TOKEN_TRANSACTION, added new provider entry (ID: 228) for 'tokenization/futurex', increased API Key field size to 100 characters - Configuration Changes: Added new tokenization provider type 'futurex', parameters for API authentication and profile specifications, configuration toggle for integrated/standalone modes
- Code Changes: Added new service classes for Futurex integration, implemented REST API integration using "/kmes/v7/token-profiles/" endpoints, updated tokenization helpers
- Filesystem Changes: No direct filesystem changes required
- Data Migration: No data migration required for existing tokens; new cards will be tokenized with Futurex; existing StrongAuth tokens will be invalidated
Implementation Actions
- Configure Futurex tokenization profile in administration panel
- Update configuration to use Futurex as tokenization provider
- Set appropriate integrated mode parameter based on environment
- Test tokenization and detokenization with new service
Configuration and Access Steps
- Configure Futurex tokenization profile with API Key and Profile ID (e.g., "01000000-5225-0000-0000-000000000001")
- Set configuration parameter
unibroker.tokenization.provider=futurex - Configure integrated mode setting (
unibroker.tokenization.integrated=true/false) - Navigation: System → Token Register → Futurex
Test Scenarios
-
Single Card Tokenization/Detokenization
- Steps: Submit a new card (e.g., "4111111111111111") for processing, retrieve and store the token, submit token for detokenization
- Expected result: Original card number is successfully returned
-
Multiple Card Processing
- Steps: Process transactions with multiple different cards, verify unique token assignment, attempt re-processing of same card
- Expected result: Each card receives a unique token, same card consistently receives same token
-
Error Handling
- Steps: Submit invalid card data, test with expired credentials, simulate connection failures
- Expected result: System returns appropriate error codes and messages for each failure scenario
Common Issues
- Token format errors due to incorrect Futurex profile configuration
- Connection timeouts when network connectivity to Futurex servers is unstable
- "Invalid data length" errors when profile configuration restricts allowed data length
- Configuration parameter spelling errors causing startup issues
Potential Impact Areas
- Real-time Processing: Tokenization/detokenization operations in payment processing flow
- Settlement Operations: Card data handling during settlement processes
- Reporting: Card-related data in reports now uses new token format
Schema Updates
- Added new table
TOKEN_REGISTER_FUTUREX_PROFILEwith columns for API Key, Profile ID, and related configuration - Added new table
FUTUREX_TOKEN_TRANSACTIONfor tracking tokenization transactions - Added new provider entry in provider table with ID 228 for 'tokenization/futurex'
Example SQL
CREATE TABLE `TOKEN_REGISTER_FUTUREX_PROFILE` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`API_KEY` varchar(100) NOT NULL,
`PROFILE` varchar(45) NOT NULL,
PRIMARY KEY (`ID`)
);
-- Provider entry
INSERT INTO `PROVIDER`
(`PROVIDER_ID`, `PROVIDER_TYPE_ID`, `CODE`, `NAME`, `GROUP_CODE`, `ACCESSIBILITY_POLICY_ID`)
VALUES (228, 9, 'tokenization/futurex', 'Futurex Token Register', '04.01', 2);
Rollback Information
Database changes are fully rollbackable as all modifications are additive. However, business continuity would be affected since tokens created with Futurex would become invalid after rollback.
- Stop all services using tokenization
- Revert configuration to use StrongAuth tokenization service
- Execute rollback script to remove Futurex-specific tables
- Plan for a transaction blackout period during rollback to minimize impact