Max

Just saying that it is a "little" bit more work than just the points stated in the issue. If you were already aware of that, and that were just the first things you wanted to get started with, rather than the whole plan of action, ignore I mentioned it. :-) No sorry. I am not using Blesta in production, but still have my own (ancient) home made billing system for now. May switch some day, and would like to see your software working perfectly if/when we do, but cannot test it with real customers right now.

As far as I can see Johnathan only listed the changes needed for card tokenization. As in let Stripe.js collect the digits of a credit card number, let the browser Javascript phone it back to Stripe, get a token in return. That is only to prevent the credit card number touching your own server, and yes, that is best practice, and you should have that too. However that alone does not give you SCA support yet. Be aware that there is a reasonable change that the customer may be leaving your website page totally during the process, and does not stay on your page (like do is the case with just card tokenization methods like stripe.js) And if all goes great, he may be redirected back to it some time later. So make sure that all payment session information is stored somewhere. Preferably in the database. Also be prepared for the case that some banks do not redirect the customer back to you automatically, and require the customer to click some link to return to shop. Some customers over see that and close their browser instead. If you do want to receive payment in the case the customer did confirm the payment, but is not redirected to you, and does not click the link, you should implement webhooks to listen for the event that payment was confirmed and finalize the charge then. Otherwise it is not processed You probably also don't want to put your customer through the confirmation process every month for every recurring payment... If you want Stripe/the bank to remember that you already completed the process for the first payment the customer did, and want to indicate you should be exempt for recurring transactions, it requires that you create Stripe Customer objects, and save the payment details to that after the initial charge. You should store the "id" of that customer object in your database (instead of the actual card details). And similar changes like that.

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

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...

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.

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.

- It should be possible to have multiple payment methods per non-merchant gateway. E.g. if I want to use Paypal for processing credit cards as well, there shouldn't be just "Paypal" but "Credit card" as well. And for European gateways it is pretty common to have 4 different payment methods handled by a single gateway. - Ideally it should also be possible for individual payment modules to add additional arbitrary fields to the form under the payment method. Like Woocommerce allows for iDeal payments, where the user has to select his own bank from a list: This prevents having the user to go through an extra screen later, and promotes the concept of a single page order screen.

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.

Well, Blesta did not write the third-party libraries they are currently using to communicate with say Stripe, Braintree, PagSeguro and Converge either... And the implementations they did do are kinda minimal. E.g. the HTML form "buy" buttons for non-merchant gateways like Paypal that Blesta currently spits out, and that the customer has to click on, may technically work. But properly using the payment provider's API to create a transaction and redirecting the customer automatically would be a lot nicer...

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.

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: