entering transaction for online payment sometimes does not generate online piece

I have seen this behavior recently when using SunTrust? and the issue seems to be their server - they accept the transaction, but it is never actually scheduled. We are working on the SunTrust? issue, but if you are using a different bank, please let us know which one so that we can figure out where the problem lies. This seems to occur for some payments and not others, and retrying the payment submission several times seems to work sometimes.

Also, please try the latest version (526, or the latest preview - currently 527) since these versions include a change that may solve this.

I had been using 52<something> when I noticed the problem. I'll give 527 a whirl.

I'm connecting with PNC Bank, and am in Pittsburgh, PA (not sure if the location is pertinent or not).

Also, the workaround you mention (retrying the payment a few times until one succeeds) does work for me.

As another data point, I noticed yesterday that the "Send Payment To" option in the online menu exhibited this behavior even in build 520, although the payments seem fine when I pull up the Online Bill Payment dialog itself and go through the more manual process.

I'm having the same problem with PNC Bank, both with 526 and 527. This is a particularly bad failure, since last month most of my payments did not process (although they showed up in the register as usual), so I got hit with a slew of late fees. It was only by very carefully watching the payment process that I noticed what was going on this month. Please please try to fix this problem, it can cause serious financial injury. If you want any further information, I am happy to provide it or work with you to help resolve the issue. I'm a programmer and can follow instructions pretty well :-)

Yep, I'll confirm what was previously posted. I'm seeing the same problem with 527. I'm back on 520 and it seems to be working well in that release.

Again, for me it is intermittent. Perhaps I'm just getting remarkably lucky with 520 and unlucky with the others. But 520 seems much more solid in terms of this problem.

Oops, I neglected to indicate my name on the 4/21/06 09:01:13 post. I'm responding back again after testing 527.

This is happening to me, too (build 526 on Linux w/ Java 1.4.2_11). My bank is Wells Fargo.

An update about the new 2007 beta. I tested with build 555 and it behaves at least as badly as the others that I've reported. I really like the new beta, but the online bill pay is just about unusable with PNC bank.

I believe some of the issue has to do with attempting to pay a bill too soon in the future. I have some limited success when I put a bill payment further out into the future (like a week or more). But it seems that once the program has had a problem with a specific payee (i.e. I hit the bug) it just won't work for that payee afterwards, no matter how much lead time I give for the payment.

So I'm currently hopping into build 555 for most of my work, but when it is time to pay my bills I drop back to 520 which seems a bit more stable in this regard -- it still fails from time to time, but it succeeds much more often than the later builds.

I've just switched to moneydance from quicken, and I'm having this very problem with Citizen's Bank, so it clearly is not specific to any one bank. I'm running 562 on windows XP. Is there some report-back text from the bank which moneydance is not showing? It seemed that in quicken there was a text report of the activity when you updated the account. It gives me a very bad feeling that there is no confirmation of any sort when you send an online transaction.

Just wanted to check in that I am working on this but have not found a solution. The payment request is submitted to the bank (actually to their OFX processor which is usually CheckFree?) and no error message is returned which makes Moneydance assume that the message was successfully processed. I am still trying different techniques to try and solve the problem.

In the meantime, please check the list of payments by selecting the Online->Online Bill Payment button/menu to see if the payment was added to the list. If the payment is in this list then the bank has explicitly acknowledged that it will be processed.

The error seems more likely to occur at certain times of the day, perhaps because the OFX service is busier than normal. Otherwise I haven't been able to detect a pattern and it seems very random. A family member has the same error, but it never seems to occur when I am in the room :(

More information in #582

Just wanted to add that I see this with "Citizens Bank - New England - Business". I'm using Mac OS X with Java Version: 1.5.0_07 and MD build 579. Sometimes it helps to forget stored passwords. So far, every time I have this problem, if I quit MD and get back in, it clears up the problem.

Perhaps one fix would be to have MD send the transaction, then query for pending transactions and see if it is in the list. If not, then MD could retry sending the transaction (for a configurable number of tries).

Any word on this?

I'm using build 583 today and I think it has a decent workaround to this issue. Rather than silently failing to enter the online transaction (and putting a transaction into the register), it told me that there was an error communicating with my online service. I was able to get the transaction to go through by adjusting the payment date forward in time.

I don't know if there is still a problem with this feature or not. The first payment I processed this way went through when I moved the date to 9 days in the future from today. But the next payment I attempted wouldn't go through unless I moved the date to 14 days in the future. So I don't know if a third payment would need a still larger push into the future to be processed or not.

But this release is at least usable in terms of the online pay feature for me. No more going back and forth!

This is fixed by displaying an error message when the other side of the connection doesn't explicitly acknowledge the payment request. The OFX servers are still misbehaving but there's nothing we can do about that. At least now there is no way for moneydance to think that a payment was submitted when it wasn't acknowledged.

Just another follow-up on this. I just had a case where I couldn't schedule an online payment, no matter how far I pushed it into the future (seemingly, anyway). This was with build 583. So I had to drop back to build 520 and process my bills again. *sigh*

But at least 583 did let me know about the problem. Each time it faithfully told me that the payment didn't go through...

Sean,

Just a question regarding this problem. I get that you're now working around the issue by popping up an error box when the OFX server doesn't acknowledge payment. But build 520 somehow does the right thing. Has the code just changed so much that you can't somehow put the algorithm that build 520 was using into the newer builds? Is there no way to make it at least an option for those of us that hit this bug every single time we run Moneydance?

As I've indicated earlier in this bug report, I have been hopping back and forth between build 520 and the latest. 520 lets me pay my bills (at least half of what I do in Moneydance) while the latest is nicer for entering stuff, analysis, etc. But this kind of workflow is really a pain. Just speaking from the user's point of view, it seems like you should be able to fix this by just having an option to let build 583 (or the latest) do whatever build 520 is doing.

I'm going to reopen this ticket just so it gets your attention again so you can reply. This is a serious flaw in the latest builds of Moneydance -- at least for me. The main reason I chose Moneydance was that it supported online bill pay. It really doesn't anymore (practically speaking).