I am reaching out to the community and the moderation team regarding a significant service-side regression triggered by the recent R68.28 update.
Following the installation of this update, my Bill Manager/Check Pay functionality—which has been fully verified and active for a long period—was unilaterally reset by the software. The application is now requiring me to re-verify my account via micro-deposits and has imposed a default $1,500 payment limit that I did not authorize.
I have already attempted to resolve this through standard channels:
- Backups: I have restored backups to points prior to the update, but the server-side "handshake" remains broken. It is clear that this is not a local data file issue, but a service-level failure where the update has invalidated my previously established credentials.
- Support Engagement: I have already engaged with two separate Quicken support engineers regarding this issue. Unfortunately, both agents relied on standard, scripted troubleshooting steps that failed to address the fact that this is a server-side account reset. They were unable to identify the cause or offer a path to restore my previous account standing, which is why I am now seeking assistance here to escalate this to the appropriate technical department.
I am requesting assistance from a moderator or the Bill Manager team on the following:
- Confirmation: Can it be confirmed if R68.28 has a known bug regarding the invalidation of Bill Manager authentication tokens?
- Resolution: How can this be escalated to the technical team to manually restore my account to its prior verified status and original payment limits above $1,500?
Waiting for redundant micro-deposit verification is a burden for an account that was already fully verified and functional. I am looking for a permanent fix that recognizes my prior verification rather than being forced to cycle through ineffective, low-level support scripts.
