will

There is a previous amount due available on the invoice that might be useful, e.g.
{% for invoice in invoices %} Previous Amount Due: {invoice.previous_due | currency_format invoice.currency} {% endfor %}

Don't forget to configure your SSL for stronger security! See https://mozilla.github.io/server-side-tls/ssl-config-generator/ to help you decide on what level of security you want to employ. The trade-off that comes with the strongest of security is dropping support for older browsers. For most of Blesta's markets, I suspect you won't be breaking things for very many customers if you go with "modern" security, and chances of breaking things for *any* customers are slim if you go with "intermediate" security. "Old" security includes support for SSLv3 which is known to be broken. Do not use the "old" option unless you absolutely have to.
 
(Warning: if you haven't configued OCSP stapling or HSTS before, I strongly recommend you test them on a non-production server first, as screwing the config up make your site inaccessible... potentially for the duration of max-age. Use a very small max-age while testing.)
 
The config generator mentions a "dhparam.pem." You can generate a DH parameter file with 
openssl dhparam -out dhparam.pem 2048 You want at least 2048 bits in light of the Logjam attack. 
 
We force SSL for all connections to Blesta. (Also, if you want to support ipv6, you'll need to specify that you want to listen on ipv6 interfaces.)
server { listen 80; listen [::]:80 ipv6only=on; # This last flag can fix some issues nginx can have with binding to ports. server_name mydomain.com; return 301 https://$server_name$request_uri; #Force SSL } server { listen 443; #SSL Only listen [::]:443 ipv6only=on; #For ipv6 server_name mydomain.com; # The rest of the config goes down here } EDIT: If you want to be paranoid (e.g. security bonus points) your config directory should be readable by PHP, but not nginx. Similarly, your SSL certs should be readable by nginx, but not PHP. On top of that, your DB should be protected by your firewall - there's no reason for it to be listening to any requests except local ones.
 
One more thing: you can tell nginx to ignore requests for sensitive files or folders.
location ~ ^/(cache|config|errors|helpers|internal|language|lib|index.php/api|api) { deny all; return 404; } # If you're using your API with some kind of external service, you can remove those last two. # If that service has a static IP, you can add "allow x.x.x.x;" on the previous line, where x.x.x.x is the service's IP.

One thing to note is that if your backup server is compromised, currently the encrypted data would be useless to an attacker. They would be unable to decrypt credit card data, or encrypted service fields, etc. But, if the config file was present, then they'd have the key necessary to decrypt the data.
 
I'm not opposed to a more complete backup, but such a solution should probably be optional and also be able to back up all files, including the uploads directory.
 
For example:
 
[x] Backup database
[x] Backup files
 
Which files?
(x) /config/blesta.php config file only () All files, including uploads directory

It would really make updates a lot easier if you guys made the current release available via either Bitbucket or Github.   This way users will simply need to to do a git update to upgrade to the latest version, and I could easily see the change history in my local code.... and roll back if I need too.
 
Right now I 
 
-  make sure everything is pushed to my private report.
-  copy over the update files.
-  test the application
-  update my private source.
 
that's easy enough I guess, but it would be even easier if I can fork off an repository....  Then i simply pull down changes to the production server instead of having to copy files over...
 
The other benefit is the community could make pull requests.... :-)

I assume you mean this....
 
http://www.blesta.com/forums/index.php?/topic/1078-vqmod-for-blesta-now-available/
 
Not crazy about adding what appears to be a third party module to do the updates; especially when git is so widely used.
 
I've also notice this has never worked....
 

That's weird. Those pages do seem at odds with their API page; it looks like it's supported by their API. From https://bitpay.com/api 
 
/invoices/:invoiceId/refunds
Creates a refund request for the given invoice.
    Response Name Type idRefund request resource idstring requestDateTime of API calldate statusCan be `pending`, `success`, or `failure`string tokenAPI token for invoice refund request resource  
 
EDIT: It looks like it's a relatively recent addition to their API.
http://blog.bitpay.com/2014/09/18/announcing-the-new-bitpay-api.html

The way I read the documentation I don't think it's incorrect. getRules() is not meant to be called automatically as it is a private method. The getRules() method can be named whatever you want and you need to call it in your code like:
$this->Input->setRules($this->getRules($vars));