Max

Ah, wasn't aware of that. Didn't look into it, as we do not have to comply with 3.0 yet. Your "this document" link doesn't work. It used to be the case that SAQ C was essentially SAQ D missing all the questions about storage and databases. Wonder how that works out in 3.0 then, and if they expect us to implement all the security for a database that doesn't contain card holder data.

In order to also get router redundancy (not just network link), one network cable goes from our switch (directly or indirectly through another switch) to router A, the other to router B. Network architecture isn't part of my job, but my understanding is that the routers talk to each other using a protocol like HSRP or VRRP and decide which one plays default gateway for our servers, and responds to ARP requests from our servers trying to get the MAC of the default gateway IP. Only one router at a time handles traffic from our servers to the Internet, that's why you only see a green line in one of the graphs. However both can forward traffic from the Internet to our servers. Servers do not care very much where incoming traffic comes from, it doesn't have to come from the MAC of the default gateway. Not sure what routing policy setting exactly causes that the incoming traffic is send mostly over the router connected to the other port -it can come from both- but apparently the routers decided that was the shortest/least-congested path.

Typical use-case would be colocation by the rack instead of by the unit. Most colo providers here provide 2 uplinks to your own switch for redundancy. For illustrative purposes, attached the graph for one of our own racks at a large colo provider. As you can see, there are two switch ports Due to the network configuration used one is mostly doing incoming, and the other doing mostly outgoing traffic. They are combined into one aggregate graph, and that one is used for billing. Results in a charge for 8 mbit of datatraffic according to the 95 percentile method. If the graphs were calculated separately, the charge would be more (and we would have unplugged one cable :-) )

Only need C if you transmit but do not store. If you want to store card holder data, you do need D, and note that it has all kinds of extra requirements the typical Blesta user does not meet. Like that your database server must be on a private network, and that the software should only access the database through stored procedures and not be allowed to perform direct queries.

Would personally just use a single field with the most common configurations. "2x250 GB RAID 1" "2x500 GB RAID 1" "2x750 GB RAID 1" "3x250 GB RAID 5" "3x500 GB RAID 5" "3x750 GB RAID 5"

The way Hostbill adds up ports is fine if you are billing by total traffic in TB. You also mentioned the desire for 95 percentile billing in your initial post though. That cannot be done in the same way, or you would overcharge the customer. Need aggregate graphs to do that right.

We do have data traffic graphs that can be viewed by the customer in our (commercial) module. It doesn't actually bill the overage though. Be aware that combining ports is not that trivial when using the 95% billing method. You cannot pull already computed numbers out of a monitoring program, and add them up. If the monitoring program says port A did 10 mbit this month, and port B did 5 mbit, that does not mean you can bill 10+5 = 15 mbit. No, the data traffic on the ports could have peaks at different times, and the real figure is somewhere between 10 and 15 mbit... You would need to create a new graph combining all the individual data points from the RRD of port A and the RRD of port B, and use that to recalculate. Tends to be easier to create combined graphs when collecting the data, instead of doing it afterwards...

Install Firebug and check what is being send by your browser to Blesta. Does it send the e-mail address you entered?

...making that library unsuitable for use in non-GPL applications like Blesta.

Preferably a solution that doesn't require a user to login. Person in charge of approving payment for the invoice, may not know the password and doesn't like to jump through hoops. And while the TS only requested the attachment to be attached when e-mailed, I would like to be able to print them out in batches as well for ink and paper invoicing. That's why my own feature request suggested appending it to the invoice pdf: http://www.blesta.com/forums/index.php?/topic/2032-option-to-add-attachment-invoice-specification-to-invoice/

Hour specification attached to an invoice for "123 hours of webdesign/development/other work" And if billing overage usage is added some day, it would be nice to be able to attach a data traffic graph to the invoice as well. Believe the competition (Ubersmith) does that as well.

You can try this unofficial module: http://www.blesta.com/forums/index.php?/topic/1960-various-payment-gateways-through-omnipay/

Apply patch, and change: if (!filter_var($email, FILTER_VALIDATE_EMAIL)) to: if (!filter_var($email, FILTER_VALIDATE_EMAIL) || !preg_match('/\.ac\.uk$/i', $email) )

There is an unofficial Virtualmerchant driver for Omnipay on github. No idea if that one actually works though. If you would like to try it, in short you would need to: Extract the .zip file above to your Blesta installation. Copy the files from the following github repo: https://github.com/zburke/omnipay-virtualmerchant to /vendors/omnipay/virtualmerchant Create a file /components/gateways/nonmerchant/virtualmerchant/virtualmerchant.php with the following contents to make it known to Blesta: <?php require_once(__DIR__."/../../lib/omnipay_nonmerchant_gateway.php"); class Virtualmerchant extends OmnipayNonmerchantGateway { protected $gwname = "VirtualMerchant"; } Backup your existing installation first.

Actually, we do support hypervisors other than KVM, such as Vmware vSphere and Citrix Xenserver HVM. However only real hardware virtualization in which a virtual machine acts like a real server, and can perform a network boot like one is supported, and not container technology such as OpenVZ.

Yes, what integration method is used by Blesta exactly should be better documented. Not just for Stripe, but also for the other processors like Authorize.net, BluePay, eWay, Quantum Gateway and PayJunction Virtually all gateways support multiple integration methods, which require a different number of requirements one needs to comply with.

Read the SAQs carefully. The security scans need to be done quarterly at a very minimum and after any software upgrade or network/firewall settings change. Some other things need to be done less or more often. E.g. if you are storing card holder data yourself (SAQ D), you need to review the log files of all your systems daily. The SAQ itself needs to be done annually. Again, if you process a low number of transactions they are not going to ask for proof you are actually doing all that beforehand. But it is still a requirement, and if things go wrong, they might. Yes, and that goes for other payment modules that Blesta is offering as well. What integration method is used by each module and what the consequences are may not be sufficiently clear. I think most smaller providers are better off with the non-merchant integrations all major processors offer. Even if that means less pretty, less integrated payment pages.

That merely tests your SSL settings, not the rest of your server. Need a quarterly scan from an approved provider from this list: https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php Starts at around $ 250 / year (Comodo)

From that site: Stripe.js is not used, nor is Checkout. The payment information is not transmitted directly to Stripe's servers, but it is transmitted indirectly to them through your servers instead. This has the consequence that your servers are the ones needing quarterly security testing. And you need to be able to answer "yes" to at least all the questions on: https://www.pcisecuritystandards.org/documents/pci_saq_c_v2.doc (and if you take the definition of "storing card holder data" literally these: https://www.pcisecuritystandards.org/documents/pci_saq_d_v2.doc ) Note that if you are processing a low number of transactions, compliance validation is not required, meaning your credit card processor is not required to ask you to submit proof that you actually did the testing or completed the SAQ. You still have to be in compliance though, meaning you can get into trouble if there is an incident, and it turns out you "forgot" to do them.

Would recommend against that. It is more professional to miss out on some languages, than have translations that are very poor. Not everyone seems to realize how bad they are, to the point that we even receive Google translated phishing e-mails here... They are quite funny, and contain language and sentence constructs a genuine organization would never use. One problem with translating Blesta is that there are so many strings. Would be nice if it was possible to only translate the clientarea, e-mail templates and order pages. Care less if the admin panel is in English.

Wouldn't call outsourcing the validation to a webservice native. Doing the validation locally is native: https://code.google.com/p/yubiclass/source/browse/#svn%2Ftrunk Main difference is that instead of storing a Yubikey ID in the database, you need to store the AES key you programmed into the Yubikey, and the counter that was last used during login (must always be higher on subsequent logins). 2 database columns instead of 1. I wouldn't blindly trust the security of the servers and integrity of the personnel of any third party organization, if it can be avoided. Same reason I disagree with Blesta currently sharing the secret seed key with Google (it is using Google charts to generate a QR code of it)

Dutch law makes a difference between retailers (and a couple other company types) which as a special exception are only liable for taxes over the amount actually paid, and everyone else that has to use accrual accounting. Is your reasoning that because the law doesn't recognize digital products, it could be argued that a web hoster is simply a retailer selling digital products and therefore qualifies? If so, that is the point we disagree on. I don't see hosting as a retail activity, nor do I agree with your statement that 99% of the companies fall under an exception. If you want the actual law articles, rather than the summary on the website linked earlier. See art. 13 Wet op de omzetbelasting 1968 for the normal situation. (accrual accounting, tax liability on the date an invoice is written out) art. 26 Wet op de omzetbelasting 1968 for the exception (tax liability the moment payment is received if you qualify) art. 26 Uitvoeringsbeschikking omzetbelasting 1968 for the exact list of companies qualifying for the exception. And do note that the tax office asks you to describe your company's activities every year on your IB/VPB tax return. Certainly not only the company register (chambre of commerce) that wants to know, and would be careful what you (or your accountant) put there.

Yeah, but most users have a nasty habit of entering passwords on their phone as well. So if your phone ever becomes compromised, the attacker has both access to your password and the second factor. People regard their phone as more secure than their computer, yet have more apps from unknown sources on them, than they would ever install on their regular computer. Real OTP tokens are much more secure.

Currently you use chart.googleapis.com to generate a QR code of the secret seed value used for TOTP. Besides the question whether it is a good idea to share your secret seed with Google, using an external service also means you cannot control the response headers send, and therefore cannot do anything to prevent the image ending up in the user's browser cache, which is also undesirable. Either let Blesta generate the QR code in PHP code and set proper response header for both the image and page it is on. Or let the browser generate a QR code with random seed in Javascript, with a library like: http://davidshimjs.github.io/qrcodejs/

WHMCS does not have native Yubikey support but outsources the validation to the Yubikey webservice. Meaning your secret seed value has to be stored by Yubico in their central database, rather than stored locally in your WHMCS installation. Wouldn't recommend that, given what happenend to the central database of another OTP vendor (Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks) Blesta does support storing seeds locally. It only supports time based TOTP and not event based OTP though. Meaning you have to install a helper program (that is only available for Windows) for the Yubikey to work, as it doesn't have a clock. Not perfect either.