I advised my client, who was using recurring sales receipts for in-house payment plans, to move to a different merchant processor that had this functionality built natively into the platform. However, based on your experience and the number of similar reports spanning years, it does not appear this issue was ever properly resolved. Witness @cody_a responded to my post almost exactly one year ago with almost identical wording. I invested hours of my time with the Office of the President staff who attempted to troubleshoot the issue with a tone as if my case was unique and yet, here we are.
The biggest issues here, in my opinion, are:
1. Repeated requests to review and resolve serious issues do not appear to gain meaningful traction. I can cite several other ongoing issues, some now four years old. The support model often feels less like “resolution” and more like “visibility containment.” Once users are moved into private chats or support tickets, the public thread goes quiet, the issue appears isolated, and the cycle starts over again with the next customer.
2. The issue I personally raised last year involving recurring sales receipts simply not processing, with no error message, warning, or failed-payment notification while still being marked “paid,” is not a cosmetic glitch. It is a critical accounting and operational failure. My client lost over $2K when the final payments in several series failed to actually process, the customer received their goods, and the discrepancy was not discovered until monthly reconciliation. By then, the customer had vanished into the mist like a dinosaur trying to avoid extinction.
3. Anyone not performing proper bank reconciliations may never even notice this discrepancy. Worse, if you open the individual sales receipt from the Customer Center, it is visually presented as paid by default. You have to already suspect something is wrong and know exactly what detail to look for... i.e. the absence of the card last 4 and the account funds deposited to with a date.
4. There is no standard exception report that surfaces this clearly. The closest workaround I found is reviewing customer detail by payment method reports and looking for anomalies such as transactions quietly showing as “cash” instead of the expected card payment. Which is… not exactly the level of internal control one expects from accounting software handling automated recurring payments.
If goods or services are delivered based on the assumption that “paid” in green actually means paid, there is a very real possibility businesses are shipping products for free and only discovering it weeks later during reconciliation. If at all. At that point, proving a negative to a customer becomes difficult when the system itself confidently announced the payment succeeded.
“Trust but verify” is a sensible philosophy for international diplomacy or buying a used car from a man named Rick in a gravel parking lot. It should not be the default operating procedure for recurring transactions inside accounting software.
At some point, “we understand your concern” stops sounding reassuring and starts sounding like the hold music version of accountability.
