Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Max last won the day on July 7 2019

Max had the most liked content!

1 Follower

About Max

  • Rank
    Advanced Member

Recent Profile Visitors

1,477 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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
  5. Hey Max, 

    I'm using Blesta 4.2.2 and NOCPS - the plugin doesn't seem to be working correctly. Is there any update to the module or troubleshooting I can do?

  6. 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...
  7. 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.
  8. 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.
  9. - 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:
  10. 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.
  11. 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...
  12. 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 sta
  13. 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 intrud
  14. Module still works as intended with latest Blesta version. Cannot guarantee any long-term support though. Number of Blesta users is very low.
  15. 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.
  • Create New...