Max

I think some things are getting mixed up in the comments on that issue.
Tokenization (stripe.js) has nothing to do with 3DS.
 
3DS/SCA is more about redirecting the customer to the website of his bank, to perform 2-factor-authentication there and authenticate the payment.
Customer not only needs a credit card number, but also confirm the payment through the app of his bank or a hardware token nowadays.
See the Payment Intents API for Stripe.

Be aware that using strong customer authentication methods such as Securecode/3Ds becomes mandatory when taking payments from European customers after 14 September 2019.
For subscriptions the first payment should be authenticated, but subsequent payments do not.
So all merchant payment gateways should be updated, or payment processing will simply stop working.
 
See the articles published by the various payment gateways for details. E.g.: https://stripe.com/en-US/guides/strong-customer-authentication

Client should provision his own server using the client area, and specify the password he wants there.
 
Passwords are not stored in the system.
There is absolutely no need for you to have access to the passwords of your customers' servers, if you sell unmanaged dedicated servers.
And there are better solutions like SSH public key authentication if you offer managed ones.

Client should provision his own server using the client area, and specify the password he wants there.
 
Passwords are not stored in the system.
There is absolutely no need for you to have access to the passwords of your customers' servers, if you sell unmanaged dedicated servers.
And there are better solutions like SSH public key authentication if you offer managed ones.

You send an e-mail to your customer that you assigned a server to them, and that they can login to the Blesta client panel to provision it.
They should already have the login for that, if they placed the initial order through Blesta...

 
 

Localize the names of generic payment methods (e.g. credit card, bank transfer, direct debit) somewhere centrally (do not duplicate that in every module), not the gateway names.

The libraries provided by providers often leave to be desired, and are not used by other projects.
E.g. they fail to include unit tests that simulate requests and responses.
 
As far as my module goes, it only implemented a small subset of the gateways as a proof of concept.
For things like merchant gateway support, tokenization (think stripe.js), securecode/3dsecure, and recurring payments changes to Blesta core code would be necessary.

That may work for small code modifications to core modules, but doubt many professional developers would do so for modules they created themselves.
It is more common for developers to retain their rights, and even if the client paid to have something custom developed to only grant them a license.
Why?
Well, it prevents the developer getting sued, if he ever does a similar looking project for another customer.
 
Would personally rather see that Blesta stopped using their own propitiatory modules for things like handling payments, and switched to using something more standard like the Omnipay library.
There is no way Blesta or any other billing system can properly test modules for gateways they are not using themselves. So using something used by more projects makes sense.
And yes, that would mean the competition could use the exact same set of modules. But so what, find something else to compete on...

Do keep in mind that any encryption in this context is the equivalent of putting a lock on your door, but always keeping the key in.
The billing system needs to be able to decrypt it, to display it.
So if the billing system (or server it is running on) is compromised, so will the credentials be.
 
Personally, I would rather see that account passwords are not stored in the billing system at all, and there would only be a "password reset" button instead, allowing a new password to be set.
If the system would be compromised it would indeed still be possible for the intruder to reset the password, but at least that would be noticed pretty soon, as then the legitimate user would be locked out, and complain.
That might be hard to implement for your appliances though.

Do keep in mind that any encryption in this context is the equivalent of putting a lock on your door, but always keeping the key in.
The billing system needs to be able to decrypt it, to display it.
So if the billing system (or server it is running on) is compromised, so will the credentials be.
 
Personally, I would rather see that account passwords are not stored in the billing system at all, and there would only be a "password reset" button instead, allowing a new password to be set.
If the system would be compromised it would indeed still be possible for the intruder to reset the password, but at least that would be noticed pretty soon, as then the legitimate user would be locked out, and complain.
That might be hard to implement for your appliances though.

Module still works as intended with latest Blesta version.
Cannot guarantee any long-term support though. Number of Blesta users is very low.

Yes, in some jurisdictions credit notes can also be used in other situations in which a customer gets a general discount or money back, rather than correcting an indvidual invoice.
I know some use them to administer affiliate earnings.
 
 
And negative lines should be allowed in manually created normal invoices as well. (currently they are prohibited by your validation rules)
E.g. if the user ordered and paid for a $ 10 standard hosting package, but decided the $ 20 super-deluxe package would be a better match for his needs, you could of-course just send him an invoice for another $ 10.
However a more proper way that signifies that the package normally costs $ 20 would be:
 
 

A credit note aka credit invoice is just an invoice with negative amounts.
Could display them in the list of invoices, and let them use the same numbering (although separate range is also allowed)
 
 
 
Do not edit any invoice pdf after it has been issued. For any reason. Ever.
 
 
 
 
 
Separate document.
 
It should be easy to locate and print out all invoices, credit invoices, and other tax relevant documents issued within an accounting period en masse.
They should not be hiding behind an invoice that may be from last year.

A credit note aka credit invoice is just an invoice with negative amounts.
Could display them in the list of invoices, and let them use the same numbering (although separate range is also allowed)
 
 
 
Do not edit any invoice pdf after it has been issued. For any reason. Ever.
 
 
 
 
 
Separate document.
 
It should be easy to locate and print out all invoices, credit invoices, and other tax relevant documents issued within an accounting period en masse.
They should not be hiding behind an invoice that may be from last year.

A credit note aka credit invoice is just an invoice with negative amounts.
Could display them in the list of invoices, and let them use the same numbering (although separate range is also allowed)
 
 
 
Do not edit any invoice pdf after it has been issued. For any reason. Ever.
 
 
 
 
 
Separate document.
 
It should be easy to locate and print out all invoices, credit invoices, and other tax relevant documents issued within an accounting period en masse.
They should not be hiding behind an invoice that may be from last year.

This diff adds support for the automatic generation of a credit note when the "void invoice" button is pressed.
 

 
A credit note is simply an invoice with negative amounts on it, and serves as paper trail that a previously issued invoice was corrected.
Both the original invoice and the credit note end up under the "voided" section in Blesta for now.
 
 

 
I also added support for the accrual accounting method to the "tax liability" report.
If that is selected all invoices are included in the report (as opposed to just the paid ones when using "cash accounting")
The credit notes will have a negative tax amount in the report, as you can deduct the amount from your the next VAT payment to the government.
 
 
http://www2.noc-ps.com/dl/blesta-3-1-credit-notes.diff

This diff adds support for the automatic generation of a credit note when the "void invoice" button is pressed.
 

 
A credit note is simply an invoice with negative amounts on it, and serves as paper trail that a previously issued invoice was corrected.
Both the original invoice and the credit note end up under the "voided" section in Blesta for now.
 
 

 
I also added support for the accrual accounting method to the "tax liability" report.
If that is selected all invoices are included in the report (as opposed to just the paid ones when using "cash accounting")
The credit notes will have a negative tax amount in the report, as you can deduct the amount from your the next VAT payment to the government.
 
 
http://www2.noc-ps.com/dl/blesta-3-1-credit-notes.diff

The west also has pretty good consumer protection laws to compensate though.
E.g. here you are you required to send at least one free written payment reminder by normal postal mail before you are allowed to charge any late fees, or can take any follow-up action.

The west also has pretty good consumer protection laws to compensate though.
E.g. here you are you required to send at least one free written payment reminder by normal postal mail before you are allowed to charge any late fees, or can take any follow-up action.

I am sorry but WHY on earth would you want a system that penalize a customer if he doesn't pay in time?.  This feels like you want to put the customer into a school regime were the admin will yell at him if he misbehaves.
I dont see this working in any meaningful way, it will just harm the customer-service provider relationship and I'm sure it will provoke more users to leave your services for good.
 
You don't penalize a user for late fee, PERIOD.  You can add the "late-fee fee" but that's about it.  I've never seen any system that worked this way, why are you trying to reinvent the wheel. Concentrate on making something that will add value to the customer instead of trying penalize them.

The way Blesta implements things you do need full PCI complaince with all merchant gateways.
 
Whether or not the PSP will actually check you are compliant beforehand is a different question.
However if you are ever compromised and it turns out you were not, things may get expensive.
 
 
Some PSPs also require you to self-certify how you are using them, and may have follow-up questions if you answer that truthfully.
 

 
Note that Blesta does NOT use tokenization clients like stripe.js.

While our commercial server provisioning module does suppport creating Vmware VPSes, I wouldn't recommend it, unless you are targetting the enterprise market (with enterprise pricing  ).
The license terms of the free version of Vmware ESXi do not allow you to sell VPSes, and commercial Vmware VSPP licensing is kinda expensive.

We do not ask for host name until the server is actually provisioned.
Module includes source though so you can change it to your liking.

Our module is indeed LGPL, as indicated in the module:
 
 
  So no, it wouldn't violate the terms if you borrow parts of it and put it in your own module.       Again, I am not very comfortable with the module in this thread submitting end-users' passwords to a third party, and would not recommend our customers to use it. But no, it wouldn't violate our terms, if anybody combined the two.

Our module is indeed LGPL, as indicated in the module:
 
 
  So no, it wouldn't violate the terms if you borrow parts of it and put it in your own module.       Again, I am not very comfortable with the module in this thread submitting end-users' passwords to a third party, and would not recommend our customers to use it. But no, it wouldn't violate our terms, if anybody combined the two.