Cody

Version 3.2.1 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.2.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.2.1. See all Change Logs.

I like the consistency, but these might be a problem due to the simple fact that the buttons don't mention "PayPal" in any capacity. Personally (and this is me speaking as an individual and not in any official capacity as a Blesta dev), I like the idea of not using graphical buttons at all. I think they should just be regular UI buttons that say either "Pay with PayPal" or "Pay with PayPal Subscription". And similarly for all other non-merchant gateways (i.e. "Pay with Stripe", "Pay with Skrill", etc.). That would be, by far, the most consistent implementation, and the most graphically pleasing. On a side note, PayPal has some of the ugliest buttons ever imagined. They were ugly in 1998, and even more so today. This only fuels my desire to do away with graphical buttons altogether.

Yeah, but I'm just trying to highlight that this doesn't really add any additional security to clarify for those that may be under the impression that Blesta will magically read their PGP key-ring or something. That said, using asymetric keys is preferable to passwords for requesting shell access so I guess CORE-1272 is a net positive.

You do realize this can't work using your PGP key-ring, right? You would have to give Blesta the full server path to the SSH private key that exists on your Blesta server. That means the private key can't be encrypted... So... still want to +1 this?

That looks like a bunch of old unrelated to Blesta log entries. You sure you have error logging currently enabled?

He means you create two packages. One package with your publicly available terms, another that is restricted. Only staff can add restricted packages (thus restricted terms) as services for a client.

Such a feature would require a lot more verification than just a staff email from address, as that would be trivial to spoof, and my guess is you wouldn't want random viruses appearing in your client's documents section. Something like this would require you to use signed email messages. This means you'd need to use PGP message signing for the email you send, which would then need to be verified by the web server when it's received to ensure the content of the message really did come from you, and that is hasn't been altered when in transit.

Why would a user ever choose the more expensive option for the same term and period? Use configurable options to adjust prices.

What do you see in your PHP error log?

Closed as not a bug.

Why are we still talking about this? As I've already said, it's in the works. CORE-1085. /thread.

http://verticalvm.com/client/index.php/order/ redirects to http://verticalvm.com/client/index.php/client/order/main/index/OpenVZ which results in the 404. Instead, it should redirect to http://verticalvm.com/client/index.php/order/main/index/OpenVZ The question is, where is that additional '/client' coming from, and is nginx somehow involved? I haven't seen this issue with apache.

I need the actual URL, so I can visit your site and see where it's redirecting.

What's the URL to the order form you're trying to set as default?

If you're experiencing an issue related to CORE-1246 then all you need to do is go to [Packages] > [Order Forms] > [settings] and select the default order form and click save.

Sounds like CORE-1246 resolved for 3.2.1.

I think what this thread should be requesting is the ability to show currency equivalence. For example, package is $100 USD, user uses GBP, so they could see on the order form: $100 USD (approx. £78.73).

Yup. I remember thinking, "what a ridiculous thing." WHMCS also has a "feature" that allows you to change the currency of all previously submitted transactions by changing the client's currency.

This is completely irrelevant. If the CC number field is sent by your webserver, it can be compromised regardless of where you load stripe.js from if your server is vulnerable. The point Paul is making is that your webserver is serving content to the client for a page that requests credit card information. As long as that is the case you are at risk if your server is vulnerable. This is why it is inevitable that stripe.js and other work-arounds will be squashed by PCI compliance.

Blesta will not store the card number in that case. Blesta has to store some card information, though. This includes the card type, last 4 of the card, and expiration date. This is required so that Blesta can send card expiration notices to clients, identify the card to the user for proper selection, and process refunds and voids.

If you check "Store Card Information Offsite" when configuring Strip in Blesta, Blesta will not store card details locally. You must enforce the HTTPS protocol. An SSL cert itself is useless if you're not forcing people to use it. See Forcing HTTPS in the User Manual. You still need to perform PCI compliance scans if you accept credit card payments. The only way you can get around that is if you only use non-merchant gateways (paypal, skrill, etc.).

We have something in the works, but it's a big change to the inner workings of the payment system so will take some time.

The problem with this is that users may end up paying a different amount than they expect. For example the service is $100 USD but is converted when submitting to the gateway to €85 EUR. So the invoice and transaction end up being €85 EUR. This is a problem if the invoice already exists for $100 USD, since the invoice can not be paid by any other currency.

Hipchat is one such service. Super popular and maintained by Atlassian.