artifacts

When a customer sends a problem report by email, the support person gets notified, and the notification includes the WHMCS admin URL, which will typically include a hidden directory name (e.g.: https://www.example.com/whmcs/admin.123-secret-1bc). Now when the support person replies to this by email, and if his mail client includes the original email as quoted text, the customer receives the reply with the WHMCS admin URL still showing in the quoted text. (Observed when using Alpine or Google Gmail.) So a hostile customer is now one step closer to breaching WHMCS security. Being the support person in this case, I will not remember to edit out the admin URL manually. Is there a good way of automatically preventing this disclosure? I'm thinking maybe I should set up a mail alias that feeds into a script, which will edit out the URL and then feed the email to WHMCS. This might be error-prone, though. Looking for something easier. A.

Issue #261 implemented in 3.6.1 would definitely fix one significant shortcoming in WHMCS. However, I notice that WHMCS currently treats an invoice paid from a credit balance as having amount $0.00. So, instead of generating an invoice for a nonzero amount, and then going through a payment transaction, WHMCS generates an invoice with two line items that add up to zero. I hope that issue #261 fixes this problem too. By the way, I have right now in WHMCS 3.6.0 a $0.00 invoice showing as UNPAID. I think it was an invoice paid from a credit balance, which therefore added up to $0.00, which I managed to mark as UNPAID. Probably the only thing more confusing than a PAID invoice for $0.00 is an UNPAID invoice for $0.00. Fortunately I am only testing WHMCS so these are all artificially generated invoices and no real customer is affected. I think there is an underlying design decision in WHMCS that has caused problems in many places. And that was to treat (payment of an invoice) and (receiving money) as one transaction, when in reality these are two different transactions that sometimes occur close together in time. If deep inside WHMCS is still treating the two as one transaction, then the fix you mention will fix one of the symptoms, but the problem may appear in many other places. For example, changing the status of an invoice from PAID to UNPAID will also cause loss of the money that was used to pay the invoice, because this money does not have a separate existence within WHMCS. Rahul

This is not a specific bug report, but it does point out flaws in some billing systems. I have been looking at a number of web hosting billing systems, specifically: WHMCS, AWBS, Accountlab, and Clientexec. Of all of these, WHMCS seems to be the most nicely done. However, all of the above seem to have defects in their business logic in the way they handle money. Some of the above systems cannot handle prepayments at all. Some will accept a prepayment but not automatically apply it to an invoice. Some will take a prepayment but the user cannot see it on the client pages and/or use his credit balance to actually pay an invoice. None of them seem to be able to bill the customer once for everything he owes today, and/or easily apply a single payment to all open invoices oldest first, and let the customer know how much is still owing. And all of them seem to lose track of money if any transactions are undone. On the other hand, there is an open source billing system called Freeside that uses perfect business logic to keep track of money and payments. Transactions can be reversed, voided, undone, and redone, without losing track of a single penny. A single payment can be applied to any number of invoices in any order, as desired. A user can make a payment to build up his credit balance, and this can be used later to pay invoices as they become due. But Freeside does not have any ability to directly create/suspend/delete accounts on a web-hosting system such as DirectAdmin (something WHMCS does nicely). Nor does Freeside handle Paypal Web Payments or Google Checkout (though these could probably be added). It does handle a large number of credit card processing gateways. So we have a problem here: Freeside does the business logic part correctly but doesn't do the web hosting part. The others do the web hosting part correctly and screw up the money-handlng part. Why this gap? I think it's because Freeside was presumably written by somebody with an accounting background, while the others were written by people with web-hosting backgrounds. Everything else in WHMCS is so close to perfect, all it need to do is to handle the money correctly. Rahul

No, marking the invoice as paid while it's pending would be just as incorrect as keeping it unpaid while pending. In both cases we are trying to map three states on the Google side into two states on the WHMCS side. The technically correct solution would be to show the invoice as pending on the WHMCS side so long as it's pending on the Google side. After a suitable period of time, either the invoice goes into a paid state, or if the payment failed, the invoice reverts to an unpaid state and the user gets an email letting him know that his Google Checkout failed. Warning the user about a delay might work, but it won't prevent all duplicate payments, only some of them. People see too many warnings, and they tend to tune out most of them. Rahul

I was bitten by the same problem on a different screen. Suppose the customer has a credit balance, and we want to use that to pay an invoice. On the Credit screen for that invoice, we enter a dollar amount "$12000.75" into the entry box in the Add Credit to Invoice section. (This occurs naturally if we use copy-and-paste to get the amount due on the invoice and enter it here.) When we click on the Add button, WHMCS reports success: Success $$12000.75 credit was successfully added to the invoice But actually nothing was added to the invoice and it remains unpaid. Rahul

In Configuration -> General Settings -> Localization I aeked for dates to be shown as YYYY/MM/DD. But in Transactions -> View Transaction List -> Filter, it offers to let me enter date ranges as "??/??/????". I can't tell whether it wants MM/DD/YYYY or DD/MM/YYYY. (Actually I would rather use YYYY-MM-DD with the hyphens, as recommended by the ISO, because that format is understood the same way by people in every country. But I didn't see this as an option in WHMCS.) Also, requiring three entry boxes for a date makes it impossible to use copy-and-paste. Better make it a single entry box. Rahul

On the manage credits screen: If I use copy-and-paste to enter a dollar amount, WHMCS changes a value like $305.66 into $0.00. And there is no warning, so the money is silently lost. By comparison: When using Paypal in US dollars, I can enter either 305.66 or $305.66, and Paypal will correctly interpret both the same way. Rahul

Suppose an invoice has been paid. We accidentally click on "Mark Unpaid". Now the invoice is marked unpaid, but the money the customer used to pay the invoice is not credited back to the customer. The money originally used to pay the invoice is simply gone, from the customer's point of view. His credit balance hasn't gone up after we accidentally marked the invoice unpaid. To mark the invoice paid again, we have to go to the global display of Transactions -> List Unpaid Invoices. Now we have to remember which invoice we need to fix, and check the box, and then click on Mark Paid. If we misremember the invoice, we may mark the wrong invoice as Paid. When we mark the invoice paid, WHMCS treats this as a new payment, and sends mail to the customer telling him he has paid his invoice. So what we intended as a correction becomes a new transaction. The Transaction list now shows a second payment of the invoice. The Transactions -> View Transactions List will give us the wrong totals, because it's counting the duplicate invoice payments. The incoming money amounts no longer add up. It becomes difficult or impossible to compare the incoming cash flow, as listed by WHMCS, with the amount actually in the bank. Rahul

It's a bit more complex than that. Google Checkout immediately notifies the merchant's software (in this case WHMCS) that a new order is in progress. So WHMCS does know about the new order. But the new order does not become chargeable in Google Checkout until some time later. In effect, Google Checkout progresses from UNPAID to PENDING to PAID. But WHMCS can only show an invoice as UNPAID or PAID. WHMCS has no state for an invoice called PENDING. So when the invoice really is PENDING (from the Google Checkout perspective), the user sees it as still UNPAID in WHMCS and may try to pay it again. WHMCS's state machine doesn't have enough states to reflect Google's state machine. Google seems unlikely to remove any states from its state machine, so WHMCS will likely have to add some. Rahul

I too have noticed in my testing that WHMCS handles prepayments in a counterintuitive manner. When a user adds funds to his accounts, this should build up his credit balance. And the user should then be able to manually or automatically use the credit balance to pay off any invoices. WHMCS doesn't give the user any mechanism of doing this. In fact, so far as I can tell, it doesn't give the admin user any direct mechanism of doing this either. I haven't found any simple way to tell WHMCS "use the user's prepayment to pay his invoices". I think the underlying design decision that might be causing the problems is: treating recurring services as if they were products to be shipped. Recurring services lead themselves to being naturally treated the way phone companies and credit card companies treat them, i.e., you start with a beginning balance, apply debits and credits for services and payments received, then end with a balance due or credit balance. You don't need an invoice number to pay your phone or credit card bill -- all you need is your account number. The payment is simply applied to your total amount due. Products that are shipped more naturally fit the mold if a definite invoice and invoice number for each item, with each payment being applied towards one or more specific invoices. Unfortunately it looks like most of the billing systems out there for web hosting force the product model onto recurring services. This leads to all sorts of confusion, of which the prepayment confusion is one example. Rahul

It appears that after a user completes a Google Checkout, there is about a 20-minute delay before WHMCS sees a transaction from Google Checkout indicating that payment has been made. I think this is because Google Checkout gives the user 15 minutes after doing the checkout to change his mind and void the transaction. After the user has clicked on the Google Checkout button, and completed the checkout, if he then clicks on the "return to example.com" link, he finds himself back at the same invoice that he just paid...and the invoice is marked UNPAID, as WHMCS has not yet recorded any payment. At this point, the user may try to pay the invoice again. Neither WHMCS nor Google Checkout detects this as a duplicate event. The user can successfully pay the same invoice a second time without seeing an error messages. Maybe this explains why people have been reporting (since mid-2007) that invoices got paid twice by Google Checkout users. Rahul