Darin

The strange thing is the card is still being successfully charged. It's not just that Blesta keeps charging the card, Stripe is also approving the charge and I'm getting paid. The Stripe portal lists the payments, clearly showing the expired date of the card that was charged. Now, I'm happy to continue getting paid, so I'm not going to complain. But I find it odd behavior.

Thanks for clarifying how it works. The reminders definitely did not go out. I've set Blesta to cc me on these reminders, and I've never received one. My clients also said they didn't receive the reminders. The next one isn't for another month, so I'll watch for it then. Perhaps the upgrade to 3.6.2 will have fixed my issue. Any thoughts on the second part of my post?

Blesta has never sent any credit card expiration reminders, and the Automation settings indicate that the Card Expiration Reminders task has never run. All of the other Automation tasks run regularly. I use the Stripe gateway, and have set it to store card information offsite with Stripe. However, Blesta still stores the card expiration date and the last 4 digits of the card number, so I don’t know why reminders wouldn’t be sent. What is most strange is that I have a customer with an expired card stored as a payment account for auto debit, yet auto debit continues to successfully charge his card through Stripe whenever payments are due. How can this be happening? Observed mostly on Blesta 3.4.3 with Stripe gateway 1.2.0. But I recently upgraded to Blesta 3.6.2 with Stripe gateway 1.3.1. So far, no difference in behaviour. Any insight is appreciated.

Another option would be a link that pops up a window with the original/suggested template contents, so that you can review it and then copy some or all of it as needed. This way, you don't have to completely wipe out your current template in order to cherry pick a few lines from the original template.

+1 Or replace the existing date created column with a rate column. For my purposes, seeing the rate, term and renewal date at a glance is far more important than the date created. I can always drill down if I need to find the date created (which is almost never).

For now, I've added the phone number as an additional line on my address in the company settings. Works great for my purposes.

+1

What I would like to see added beside or below that attachments checkbox is a listing of attachments, if any, that would be included if the box was ticked.

The previous billing system I used showed PayPal Subscription as an option to clients when they were setting up their equivalent of a payment account. If they selected it, they were advised that a subscription would be initiated when they paid their next recurring invoice. That way, the client was informed of all their options and felt like they were in control. Currently, in Blesta's client portal, the client isn't even made aware that PayPal Subscription is an option for future automatic payments. As far as I can tell, the only times the client sees the option for PayPal subscriptions is on the order page or when they actually go to pay an invoice. It would be better to show this an an option on their payment accounts page (if you choose to allow it).

I agree! It may make sense to separate these on the backend, but on the client side a payment method is a payment method. Clients should see a simple list of payment options and select the one they want. For them, there should be no apparent distinction between choosing credit card, PayPal, etc.

That's what I thought. Too bad. Thanks for clarifying.

In the Invoice Delivery email templates, how can I test if a client has a payment account on file, but has not selected anything for auto debit? I'd like to be able to automatically present a custom message in the invoice emails sent to these clients, because I think they are assuming that adding a payment account to their profile is enough, when in fact they also need to designate it as auto debit (as has been discussed in other threads). The default Invoice Delivery templates already test if auto debit is enabled for the client's profile and, if so, if the client has a payment account designated for auto debit. However, unless I'm misunderstanding the logic, the templates aren't currently testing if a payment account is available but not selected for auto debit.

@Paul I would love to see the ability to restore defaults, as long as we're given the option of doing it on a per template basis. I wouldn't want to wipe out all of my customizations for the sake of restoring a single template. Until then, I will backup the templates before editing them, as you guys suggested.

Does Blesta store all of the original email templates somewhere? Before I make any dramatic changes to the email templates, I'd like to know if I need to manually save each original text, or is it all safely tucked away somewhere I can later retrieve it if necessary.

+1

Rather than setting the renewal date based on an invoice or payment date, I would think it should be based on the activation date. That way, it's not dependent on a particular seller's billing/accounting policies. Edit: Oh, I see that CORE-912 says basically the same thing.

This is not always the case. There are many jurisdictions where a client can provide a tax ID number AND should still be charged tax. It must not automatically be assumed that providing a tax ID numbers makes the client tax exempt.

Ah, now I understand your request. I agree.

I know of at least one province in Canada that has a provincial sales tax rate of 9.975%, so it definitely needs the decimal places. However, I don't need them, so I used round( ) on the tax rate in my invoice template to get rid of those zeros in the pdf invoice. In line 315 of components/invoice_templates/default_invoice/default_invoice_pdf.php change $tax->amount to round($tax->amount) so that it looks like $data[] = array('notes'=>null,'label'=>Language::_("DefaultInvoice.tax_heading", true, $tax->name, round($tax->amount)),'price'=>$this->CurrencyFormat->format($tax->tax_total, $this->invoice->currency, self::$standard_num_options)); If you still want some of the decimal places, you can specify how many like this round($tax->amount,2) It doesn't bother me if the zeros still appear in the admin panel, so this change was all it took to make me happy.

Ha, I guess I was updating my previous post at the same time you were posting.

Except that it isn't currently called "Cancellation Options", it's called "Cancel Options". I do see your point about "Cancel", though. My original request was to change the button to "Cancellation Options", because I think that "Cancel Options" implies "cancel the options". Edit: By way of illustration: Cancel Package = cancel the package Cancel Service = cancel the service logically, then Cancel Options = cancel the options This is why I'm advocating to change the button text to "Cancellation Options"

Well, I guess I have no common sense because the first time I saw it, I thought "Cancel Options" meant "Cancel my options". Thankfully, I have the luxury to test what happens when I click the button, but my customers do not. Perhaps it's a grammar thing. I believe that if the word "options" is to remain on the button, then "Cancelation Options..." (with or without the ellipsis) conveys a more accurate meaning. However, I actually like your first comment about how the button on most systems would simply state "Cancel..." I would support this change.

That is what I have done, for now. But I posted this as a feature request because I believe the change is better for Blesta. This proposal is not for Admins and users who are already very familiar with Blesta, it is for customers who are seeing that page for the first time. I always try to look at things from the perspective of the end user, which in this case is the customer. It is my opinion that the current button is potentially confusing, causing some customers to think that clicking the button will cancel their package options rather than showing them the available cancelation options.

I was just expanding on the current text of the button, which includes the word "Options". But even "Cancel..." would be an improvement, in my opinion, for the same reasons I previously stated.

I recommend changing the text of the Cancel Options button found on the client's Manage Service page to: Cancelation Options... Reason: I think the current text on the button is unclear. The first time I saw this big red button, I thought it was meant to cancel all configurable options associated with the service package. Also, in it's current form, it implies that clicking the button is the final, irrevocable action. Adding an ellipsis informs the user that they will be presented with options after clicking the button.