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:

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.

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

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.

There is no order number. Your module will receive an array of invoices instead.

You can let your module create its own separate invoices for the overage, but that's not an acceptable solution for small amounts.

Blesta doesn't support overage nor metered billing. http://www.blesta.com/forums/index.php?/topic/551-overage-billing/

Even if he wanted to, it is not a given a developer can continue working on any IT projects in his spare time, after accepting a job at a larger company. Having non-compete clauses forbidding exactly that is more common than not.

1) Unzip the files to your Blesta folder 2) Activate and configure the gateway in the Blesta admin settings like any other gateway.

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.

Should send an e-mail with verification verification code. Testing if a mail box exist is not reliable, e.g. will not work if the mail server has grey listing enabled. Nor does it guarantee the e-mail address belongs to the person that signed up. It is also a requirement when doing domain registrations that you verified the address, at many tlds.