Max
-
Posts
283 -
Joined
-
Last visited
-
Days Won
6
Posts posted by Max
-
-
Just now, Paul said:
What is getting mixed up exactly? CORE-3068 is for implementing Stripe 3DS, and the core changes required to support it.
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.
-
On 7/27/2019 at 1:39 PM, Blesta.Store said:
Part of CORE-3068
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.
- activa and Serverhosh
-
2
-
On 11/4/2016 at 11:35 PM, Paul said:
If we have to localize the names of gateways, then that sort of pushes us toward language files. I'm not convinced that gateway names like "PayPal" or "2Checkout" translate well into other languages. Are they not known by their names in other languages?
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.
-
23 hours ago, Paul said:
Merchant payment gateways do not show the name. For example, the customer will never see "Authorize.net", but rather "Credit Card". So, I see this exclusively for non-merchant gateways, and the example of showing simply "PayPal" instead of "PayPal Payments Standard" and "Bitcoin" instead of "Bitpay" are excellent examples.
- 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.
-
14 minutes ago, Licensecart said:
True they use the api library provided by the providers but they do everything Blesta needs and callbacks themselves so they know it works fully and it would also be harder to use a third-party library like omnipay, and try and get every payment gateway to tell Blesta what's it's doing. But if people do want omnipay you did a module for it
But I'm bias as a few know and try and keep third party modules to ones I need and know they maintain it and donate if needed or pay a monthly or one-time price.
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.
-
3 hours ago, Licensecart said:
Agreed about the developer but not with the Omnipay library as that means you have to relay on them and not Blesta who make the software they develop.
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...
-
On 6/21/2016 at 0:15 AM, evolvewh said:
Is there any sort of disclaimer / agreement that could be made saying that if they contribute, they lose the rights to it and it's Blesta?
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...
-
18 hours ago, INUMIO-Rob said:
- Will the credentials be encrypted? How?
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.
- Michael and INUMIO-Rob
-
2
-
-
It should be possible to raise a Credit Note as required without it being linked to any particular invoice.
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:
1 super-deluxe package 20
-1 standard package 10
-
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)
So, the credit note will be a deduction on the invoice, correct? As in, the invoice should show the correct amount after adjustments from credit notes?Do not edit any invoice pdf after it has been issued. For any reason. Ever.
I think it would be preferable to add credit notes as additional pages onto the invoice PDF.
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.
- Blesta Addons, Michael and Ekim
-
3
-
Not really, because I spot the people who get banned. You've never heard of it? You get a mobile phone contract in the west, if you don't pay you get punished You get a nice credit rating which prevents you getting credit.
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.
- Blesta Addons and Michael
-
2
-
Not all gateways require you to be compliant but it is a good idea to be. The non merchant gateways do not require it and some of the merchant gateways don't, including Stripe, Paypal Payflow Pro and possibly others.
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.
-
-
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/
-
That way developers and even yourself can continue working on the developed plugins and modules.
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.
-
the NOC-PS module is released in open source and under GPL as i think . i don't see any conflict here, and violation of term .
the client pay for service and not for how an when he should use the API .
Our module is indeed LGPL, as indicated in the module:
* May be distributed under the terms of the LGPL license.* In plain English: feel free to use and modify this file to fit your needs,* however do NOT ioncube encode it.* The source code must be available to anyone you distribute this module to.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.- Michael, Blesta Addons and Nelsa
-
3
-
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.
Blesta unable to accept payments from European credit cards after September
in Bugs
Posted
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.