Paul

There will always be bad players, whether malicious or negligent. Unfortunately, it will result in calls for government regulation. Rather, I suggest people do their research on exchanges before doing business with them, and diversify. Never put all your coins in the same place. Don't leave large deposits in exchanges, transfer them out into wallets you control. Never use a hosted wallet.

My recommendation is to start local. Friends, family, local businesses. Treat them well and they will tell other people. Do not underestimate word of mouth. You won't see results overnight, but you're building a lasting business, right? People like to do business with those they feel like they can trust, and people trust their friends advice far more than a Google ad (Don't advertise on Google).

We are aiming for a beta in a matter of weeks.

Mike, did you change your invoice draft format? DRAFT-{num} is the default. I'm still not able to duplicate this in my environment, can anyone else confirm?

It's unresolved, but it's currently a blocker for 3.2. I discussed this one with Cody last week, and he seemed confident that it wouldn't take much time to implement and that it is likely to be included in 3.2. This is assigned to CORE-852 and can be tracked there.

Interesting idea. I think this would work better if services were displayed on their own page though. In the future, I'd like the client area to be more customizable, staff can determine which widgets should be displayed as well as which pages. Then, the services widget could be disabled, and a services page could be enabled that categorizes them by group and has more advanced filtering options.

If it needs to appear on all invoices, you might consider putting it in the Terms section. Settings > Billing/Payment > Invoice Customization.

Is that the only error? Normally this error will occur because of a previous error being output to the browser first.

Turn on error reporting and see if an error is output To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1);

Maybe you need to put the full path to your php in there? ie /usr/bin/php or /usr/local/php?

MariaDB definitely looks promising, time will tell how close they stay with MySQL compatibility-wise. But, if anyone finds an issue with it we'll do our best to correct it.

As we continue to grow, there will be more trolls, it's how they operate.

Email sales and we can issue you a new trial key. Actually, I'll PM one to you.. one moment.

It can happen, and probably will, but it's not as likely as the other guys due to our code base and build process.

Anyone else find this to be a useful addition? Personally, I like the idea of custom client fields being available to invoices. I can see many cases where these might need to be displayed on an invoice. I'm just not sure the Terms section is the best/only place for them. The alternative would be a much more complex system, whereby invoices can be customized by drag-n-drop of elements, allowing custom client fields, and default fields to be placed visually. This scenario is much more involved, and less likely to happen soon, but it's certainly a possibility.

There's something in the works via a third party that would effectively add this, among other things, but this could be a good standalone option as well. Do you want this to appear in the client area, related to a specific service? ie, a dedicated server? If you can provide more context, it may help moving things forward.

What about the "Billing at a Glance" widget under Billing > Overview. We could detect if the PayPal gateway is installed, and add an option in here to display the balance. *Potentially EDIT: Or, a new PayPal plugin that registers a widget for display on the billing overview, or dashboard.

Maybe you can clarify PCI levels. I understand PCI Level 1, 2, 3, 4 to be largely based on transaction volume. See http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp. Levels 2-4 require the annual SAQ and quarterly network scan. Is this what you mean? If you are a Level 4 merchant, based on your transaction volume, you still have to fill out the SAQ, and get a quarterly network scan. I think the question is, what exactly is the difference in terms of what you have to do by using stripe.js versus passing the data through without storage. If all merchants must fill out the SAQ, and get a quarterly network scan for PCI compliance, and using stripe.js does not exempt you from these requirements, what is the difference?

I predict that in the future, stripe.js and other javascript implementations will no longer be exempt from PCI. While the card details technically don't touch the server, the server is responsible for serving the markup. An attacker with access to the server could modify the javascript in order to intercept those details.

You make good points.

I think what he's saying is that most of the PCI requirements are related to infrastructure. We're not saying that you're off the hook from such requirements, you're certainly not if the card data touches the system in any way.

I don't believe so no, you might start a new feature request thread. Rather than HTML, we would be more likely to accept markdown syntax... that is, if it's feasible. Because our invoices are not generated from HTML, it would probably be some subset of markdown.

Patches are cumulative, you can install the 3.1.2 patch on 3.1.0 or 3.1.1. The patch includes 3.1.1 in it.

@iamp, fair enough

It requires PCI compliance, sure. I agree that pass-through maintains that requirement and I understand and acknowledge the benefit and need for the stripe.js implementation.