In the existing system, the app is activated by the Lightning Service Provider (LSP) to receive payments automatically, notifying the user only after the transaction has been completed. The proposed method introduces a significant change where the user must actively participate in the transaction process. This involves notifying the user about an incoming payment, requiring them to connect their hardware ledger to accept it, and then confirming the transaction on the device. This process is expected to slow down the payment reception significantly and could potentially degrade the user experience, as it necessitates having the hardware wallet readily available.

The impact of this new approach is twofold: it affects both the technical aspect of payment processing and the overall user experience. Comparatively, when a user's phone is off, the current LSPs have mechanisms to handle such situations, suggesting that similar strategies could possibly be adapted to manage the complexities introduced by hardware device requirements. However, the necessity for users to manually verify transactions could make the experience cumbersome, particularly if they are asked to confirm transactions that appear meaningless due to protocol updates or security measures.

Despite these challenges, there is an acknowledgment of the potential benefits in specific scenarios, such as "synchronous payments," where users are already engaged with their device and merely need to connect to a secure device to validate payment reception. This scenario hints at a reduced impact on user experience for certain types of transactions. Moreover, the conversation touches upon the strategic decision to not develop custom code for the hardware device in the initial project phase, instead leveraging existing capabilities. This cautious approach aims to minimize scope and complexity, recognizing the importance of starting small and learning from practical experience and user feedback.

The dialogue concludes with contemplation on future improvements, including the possibility of designing a specialized LSP to better accommodate the unique requirements of this approach and proposing Blockchain Lightning Improvement Proposals (BLIPs) to enhance its feasibility and user experience. The overarching goal is to explore how this first iteration performs in real-world conditions, identify areas for priority development based on observed challenges and successes, and consider adjustments that could mitigate identified pain points in usability.