srn

A simple notice for the actual cancellation would be sufficient. Anything is better than nothing. Maybe
 
Hi {contact.first_name},

Your service {package.name} - {service.name} has been canceled.

A simple notice for the actual cancellation would be sufficient. Anything is better than nothing. Maybe
 
Hi {contact.first_name},

Your service {package.name} - {service.name} has been canceled.

A simple notice for the actual cancellation would be sufficient. Anything is better than nothing. Maybe
 
Hi {contact.first_name},

Your service {package.name} - {service.name} has been canceled.

Partial refund support is a requirement for us with any payment provider.
 
http://www.blesta.com/forums/index.php?/topic/1596-partial-refund/ suggests a full refund and then another charge for the same amount. But this second charge may require explicit authorization by the customer, and there's no guarantee they'll take the time to do it.
 
Partial refund support from within blesta would greatly streamline the customer support workflow.

Partial refund support is a requirement for us with any payment provider.
 
http://www.blesta.com/forums/index.php?/topic/1596-partial-refund/ suggests a full refund and then another charge for the same amount. But this second charge may require explicit authorization by the customer, and there's no guarantee they'll take the time to do it.
 
Partial refund support from within blesta would greatly streamline the customer support workflow.

It is not uncommon for people to accidentally check in sensitive information such as database logins and API keys (x-ref http://arstechnica.com/security/2015/03/ubers-epic-db-blunder-is-hardly-an-exception-github-is-awash-in-passwords/) and the blesta encryption key is almost as sensitive. I think there should really be a script that uses the old key and a newly generated key and descrypts/re-encrypts the data in the database.