Bill Payment Migration State Tracking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Users face difficulties in seamlessly migrating bill payment information when switching from one payment processing service to another, often resulting in loss of in-progress transaction data.
Innovation Solution
A method for selectively migrating bill payment transactions between payment modules and processors, where transactions are treated based on their state, allowing pending payments to be completed at the source and updated at the target, ensuring a seamless transition without data loss.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If a one time copy of payees and payment instructions is made from a first payment processing system to the second payment processing system, then the migration process is simple and quick, but transactions in progress are lost and the user experiences data loss
Solution Approach 1:
The migration process is segmented into distinct phases: pre-migration copying of static payment information, during-migration tracking of transaction states, and post-migration synchronization. This segmentation allows the system to handle different transaction states differently, preventing data loss while maintaining migration efficiency.
Solution Approach 2:
The system performs preliminary actions by copying payment information (payees, payment instructions) from the first payment processing system to the second system before actual transaction processing occurs. This ensures that all necessary payment data is available at the target system before transactions begin, preventing information loss during migration.
2Ease of operation
If bill payment software automatically submits payment instructions to the payment processing system, then the bill payment process is seamless to the user, but changing payment processors requires manual deletion and recreation of payment information
Solution Approach 1:
The system introduces an intermediary migration mechanism that automatically transfers payment information and transaction states between different payment processing systems. This intermediary layer handles the complexity of migration transparently, allowing users to switch processors without manual intervention while maintaining the seamless automated payment experience.
Solution Approach 2:
The system implements feedback mechanisms to track transaction states during migration and synchronize data between source and target payment processing systems. This feedback loop ensures that payment information is accurately transferred and updated, maintaining user convenience while managing migration complexity automatically.
3Productivity
If pending bill payments are migrated directly without iterative updates, then the migration process is faster, but transactions in progress cannot be completed at the source and updated at the target
Solution Approach 1:
The migration process is made dynamic by continuously monitoring transaction states and iteratively updating payment information as transactions progress. This dynamic approach allows the system to adapt to changing transaction states, ensuring reliable completion of payments at the source and appropriate updates at the target system.
Solution Approach 2:
The system maintains continuity of useful action by keeping pending transactions active during migration and continuously synchronizing their states between source and target systems. This ensures that transactions in progress are not lost but rather continuously tracked and updated, maintaining reliability while progressing through the migration process.
Data Source
AI summary
A method and system for migrating transactions, such as bill payment transactions, between payment modules and/or payment processors. Each payment object is set up with payment information input to a payment module and results in one or more transactions. During a selective migration, each transaction is treated separately, based on a state of the transaction. A transaction that has either not been yet submitted, or has been completed can be migrated directly, while a transaction that is in some state of processing is iteratively migrated as it completes processing.