velaware

I don't know if they do or not, but the fact that Google will strip out needed/highly favored tech to push their own products kind of pushes me away from them.

One of the reasons I've moved away from Google and only use it for forum accounts and junk stuff now. I use Outlook.com and as I say to others, its not a Windows vs. Linux thing, its a usability vs. breakability thing.

Does MariaDB use less resources compared to MySQL that you can find out?

Notice any performance improvements?

Does the public and private key change at all or are they created once and that's it?

It is Blesta's responsibility to the degree of what it can do. Blesta isn't responsible for having proper accounts/software installed and configured, but it is responsible for how it stores and handle CC data.

I know PCI level 1 is more towards those who do 4 mil. + transactions, not sure on the others as I'm not a banker or someone heavily involved in it. I've never been aware of a transaction class for them, though, just more so what you intend to do with the data. What Stripe.js does is send the card data directly from the browser to Stripe's servers, without the server Blesta is installed on ever seeing that. It then returns a token/hash of the data that Blesta can store in the database without ever knowing what the card data is. This is why Stripe created the JS library, so that it's client->server instead of client->server->server. From my previous experience, once any bit of card data (last 4, cvv, etc...) touches the server that Blesta is on, it has to conform to PCI regulations, because its still sensitive information. Blesta still stores some data. IF the data is encrypted, then it helps tremendously, but that requires that the last 4, cvv, address, etc...(whatever it stores) is encrypted. But, with how Blesta works now, that data in its completeness is still passed to Blesta, which means now the user has to at least conform to level 4 or 3. Yes, network scans and such are still required even at level 4, though they are not as intrusive so to speak (takes a lot less to do than say a level 1 scan). The whole argument here, and what has I believe been presented before, is that Blesta sees the card data (full PAN, CVV, etc...). Even if Blesta doesn't store it all, it still stores some and thus needs to comply with PCI. Using something like Stripe.js changes that so Blesta doesn't have to concern itself with meeting PCI and it can just store a token that it can then pass to Stripe and Stripe can map it to card data. Basically any servers that see card data need to comply to PCI. A token isn't card data. You can still retrieve the last 4 and all that via the token. It just takes an API call.

The whole purpose of Stripe.js and such is to allow users to store card data without having to meet PCI level 1 & 2 compliance, not to do PCI avoidance. It lets you offload the storage security requirements and worry about managing your systems. https://www.pcisecuritystandards.org/documents/SAQ_D_v3_ServiceProvider.pdf document page 17 (real page 23) starts the questionaire portion of data retention and storage. This document provides the bare minimum required to be PCI compliant (level 4). The JavaScript libraries aren't really exempt from PCI, its just that they allow the provider to meet PCI requirements without having to follow level 1 & 2 guidelines themselves, and it also makes meeting level 3 & 4 a lot easier as well. Which, poses another risk, but its one people take regardless.

It is and isn't. Blesta's Stripe module tokenizes data, but it doesn't do it in a fashion that it should so people are compliant w/t PCI level 3 & 4 (which requires that no card data whatsoever is to touch the server). This is why the JavaScript libraries are made by such providers, so that people can write code with JavaScript (which runs in the browser thus never having to touch the server) to tokenize data, and then the JavaScript just sends the tokenized data to the server. Blesta's Stripe sends the card data to the Stripe's server which then tokenizes it on their end. So, the whole "don't let Blesta store card data and instead let Stripe store it" feature works and is accurate, because you don't store the card data in Blesta's database, but it doesn't solve the PCI compliance issue because you're still directly sending card data to the server Blesta is on. That's the point I was trying to make to Cody but I was also cooking dinner so I may have not got that across properly.

Just to clarify, you're saying having card data be passed through Blesta (which is stored on a seller's server) doesn't violate PCI even if the data isn't stored? Not trying to be a dick, just wanting to verify/clarify this.

The problem with this though is that it violates PCI, since card data still has to enter the server to be tokenized and sent to Stripe. That's the whole issue. That's the whole point behind the JS library being provided, so that it only passes from the client to Stripe's servers, not client->my server->Stripe's server.

Didn't know the Checkout thing required the JS library still. I do know some merchants have offered a non-merchant style payment method too. Why not have the module gain access to the JavaScript helper like widgets and such have?

No problem, feel free to contact me any time on this. Can't it be possible to at least support the Stripe Checkout, which acts like PayPal's non-merchant systems as well?

You're correct. The problem is that the current way Blesta works, it doesn't let you use the stripe.js file. While I can't comment on Stripe Checkout, I'll forward this thread to Cody so he can shed some light on this. If such features can work, then it'll solve my issue as well. I can't say anything on how Blesta handles things, but I do agree a warning and such should be stated that the current module requires PCI-B or A compliance (since the fee for not being compliant is very high [$50-100k USD]).

PCI compliance, depending on the level of compliance you need/want, is pretty easy. I can't talk about WorldPay or ePDQ because I don't know them or anything, and I don't want to provide false information. To be PCI compliant currently, the best way to describe it is to have Blesta's database be on a separate server that is not accessible outside of a local Intranet and stripped down to the absolute necessaries. PCI level B would be the minimum I'd say due to the lax that C still allows that puts your user's information at risk. PCI level A is fine, but is more so if you handle a lot of transactions a day (4 mil. +). If you would like consultation for this I'm happy to assist. This is one of those things that a lot of people don't think about until its too late, so you looking into this now is very wise.

I've talked to Cody on this about a similar service (Balanced Payments). Right now the way the plugin works, it requires your server(s) to be PCI compliant because it stores sensitive card data. Though, i have suggested that gateways have the ability to inject HTML into the order form so things like Stripe's javascript can be included which changes the PCI requirement from A/B to C/D, which would make it far more viable for those who want the features of Stripe and similar. If you keep the card info, like you have to now, then you have to follow the QSA guidelines set in by PCI. If you're interested in learning more, feel free to contact me. I used to work for a hosting company who performed these tests all the time and I can offer some guidance. Either ask here (preferably so information can be shared to others) or PM me.

Does this query: SELECT * FROM `staff` LEFT JOIN `users` ON `users`.`id`=`staff`.`user_id`; Return anything? If so, try doing a "reset password" if you set up the mail server info (if needed).

What did you try, exactly?

Happens then too. :/ Thought I made it clear but I didn't, my bad. o.O

My question is what makes 5.3 special for this? I'm not familiar w/ the changes, but if its a function you could just do if(function_exists('some_func')){ .. verbose logging stuff ... }

If you want me to help you on this feel free to shoot me an email.

This doesn't work for me. My Blesta install is a subdirectory (http://www...com/accounts/) and even when I fix that (i.e.: URL is https://www.....com/accounts/plugins/live_chat/vendors/blc/index.php/site_admin/ ) I get a blank page (enabling display_errors gives this: Parse error: syntax error, unexpected '{' in /var/www/accounts/plugins/live_chat/vendors/blc/settings/settings.ini.php on line 76). Fixing that gives this: Cannot connect to database. If you are installing application please use /index.php/install/install url. If you keep getting this error please check that application can write to cache folder and cgi.fix_pathinfo = 1 When I visit /accounts/plugins/live_chat/vendors/blc/index.php/install/install I get this: Please advise.

You should always use <?php ?> and not shorttags (<? ?>) or ASP tags (<%= %>). <?php ?> is supported universally.

Besides Blesta, anything else required to be installed?

I haven't installed it yet but curious, is there a way to get this to show on a regular website as well through JavaScript or is it just loadable on Blesta? I don't have a dynamic website so doing something through PHP isn't viable for me.