Tyson

You don't have to modify URLs. You will need to reissue your license though. See the documentation.

So you do not charge tax for any customers that are outside of India? You should be able to handle that by configuring your tax rules to only apply to India rather than "-- All --" in the system settings. Any orders placed by customers with addresses outside of India would then not be charged the tax.

I don't think that module log error is causing the initial issue. The problem is that the cron is failing to complete running. Even if the cPanel service failed to provision due to that error, it still completed the attempt to do so. What you need to find is the module that not only failed to provision a service, but failed such that it caused php to stop executing on the server, such as a php Fatal Error. You can check your php error log files for that info as described in the link in my last post.

You can view packages assigned to their package groups from the Packages > Package Groups page by clicking the package group table row, which will list them all. Some packages may not be assigned to a package group, so those will not be displayed in that list, but will be available under Packages > Browse Packages.

You may be using a module that is trying to provision a service that continuously fails due to an error, but also stops php execution, thus the cron job to run services fails. You should identify the offending service since it may be stopping other services from being provisioned automatically. Check your server error logs for any fatal errors. You can also check your Pending Services list to see what services have not been automatically provisioned, one of those is likely the culprit. The associated module may not be working properly.

Glad to hear that helped. I'm not sure what you mean exactly about the package listing, it will list all packages in the system. You can view Packages > Package Groups if you would like to see all package groups and what packages are assigned to those groups.

Did Blesta suspend the service or did you do it manually? If Blesta did not suspend the service, then that explains why the service is still active in Blesta. Blesta needs to suspend the service itself, otherwise you will have to perform manual action against the service. If Blesta suspended the service in WHM, but did not mark the service suspended in Blesta, then there may be some communication issues with the API, like an error response from WHM. You should check your module log for errors under Tools > Logs > Module tab and click the row corresponding to the request that would have suspended that service (you may have to search for it). The module log may point out why the action failed which can lead you to resolving it.

It's standard practice to use TLS over HTTP to secure payload transmissions. All API requests are expected to be made over HTTPS. The Blesta UI will also send plain-text passwords in POST requests from the browser to the server, just like every other web application. Any time you are dealing with sensitive information, requests should be transmitted over HTTPS. This not only includes all API requests, but all requests through Blesta in general since any log-in data or cookies should be secure too.

The Order plugin doesn't have the capacity to list each of its forms in the navigation. It would likely break the navigation if you had more than a few in any case. I think what most would do is edit the order form settings under Packages > Order Forms > Settings tab and change the Default Order Form to "None - Show Listing". Then when you click the Order link in the nav it will show you a list of all order forms.

You should take a look at the gateway logs under Tools > Logs > Gateway, and click a row for Authorize.net or any of the other failing gateways to look for errors. Since Authorize.net and Stripe Payments are merchant gateways, you can only use one of them for a selected currency. If you happened to change from one to the other for a particular currency, then any pre-existing payment accounts on the old gateway could not be processed by Blesta for the new gateway. If that is the case, you should create a new payment account for the client to pay using the new gateway. There was an issue resolved in CORE-3280 for v4.7.1 to address a problem completing payment using a non-merchant gateway. I'm not aware of that issue still persisting. What is the issue you encounter exactly?

It sounds like you have a few issues with configuration. The module's log-in link assumes port 2031 is your secure port. You could update the templates that render that log-in link if this is a problem, but normally setting the CWP port to 2031 should suffice. For account suspension, it sounds like you may need to white-list your Blesta web server's IP address to be allowed to perform that action. Regarding the gateway timing out, that is not a response Blesta displays, so it must have come from CWP. I would expect that to be logged under the Module Log, but in any case, there may be a configuration issue on CWP that is causing that issue and I am not familiar enough with their system to diagnose the exact cause.

You should check the logs under Tools > Logs > Module tab. There may be some API request errors shown there that could point to the problem. Also, the number of accounts in use only updates after a service is added/cancelled.

There may be an error with the request, or something is not configured correctly. You should go to add a new package, select Direct Admin, and when no reseller packages show up, take a look a the module logs Logs under Tools > Logs > Module tab. There may be some details/errors in the API requests logged there that could point to the issue.

Blesta comes with an .htaccess file in the root web directory and you should use that one. There is already a rule in it to force HTTPS and all you need to do is uncomment it to make it active.

You may want to re-upload all files for Blesta and/or check your web server configuration. I notice that the CSRF token changes on every page load, which indicates the server is recreating a session each time. It's possible your web server does not have permission to write session data.

Take a look at using the Order plugin's Embed Code field to add HTML to the footer. You can specify your JS there (i.e. Packages > Order Forms > Settings tab) and add a conditional to display content only when on the checkout/complete page. There are fields for order number and total price that you can use too, but there is no coupon code field. You could try to parse the coupon code field from the {{invoice.line_items}} if you really needed it, via other custom JS. e.g. {% if order_page == 'checkout/complete' %} <p>Total: {{order.total}}</p> <p>Order #: {{order.order_number}}</p> <p>Currency: {{order.currency}}</p> {% endif %}

You can update the invoice created for the service and decrease the cost by half. The customer can then pay that while the service, which is tied to that invoice, will be activated automatically since the service's invoice is paid in full. Then, create a new invoice manually for the other half, and make it due in a couple weeks. You'll need to check back in a couple weeks to ensure that that invoice gets paid, otherwise you may need to take manual action against the service for lack of payment.

Blesta follows the ISO 3166-2 standard for provinces/states for ISO-3166-1 countries, and the ISO lists the states' codes numerically where Johor is "01". If there is a better 2 or 3-character standard abbreviation, you can update the states in your system to reflect your needs better by using the States & Countries plugin. Note that third-party APIs may operate on the use of the ISO 3166-2 standard, such as when Blesta makes payments to a payment gateway and includes the customers address with that ISO-3166-2 state code. It's possible that such APIs may encounter errors if the state is invalid.

Sure, upgrade to Blesta v4.7.0+ and ensure the Order plugin is using v2.20.0+. The domain module should then make the service's domain field available via ::getServiceName or the configuration value service.name_key.

Thanks, we'll update this as apart of CORE-3275.

A comparison to DigitalOcean doesn't really apply here since they are not a payment gateway. The transaction statuses in use by Blesta cover the basic statuses one might expect given the breadth of statuses some payment gateways use. For instance, GoCardless responds with any of the following statuses: Payment Created Customer Approval Granted Customer Approval Denied Payment Cancelled Payment Confirmed Payment Paid Out Payment Retried Payment Autoretried Late Failure Settled Chargeback Settled Test Failure Insufficient Funds Refer to Payer Bank Account Closed Direct Debit Not Enabled Invalid Bank Details Bank Account Transferred Mandate Canceled Mandate Expired Authorisation Disputed Refund Requested

This is in 4.7.0.

This is fixed in v4.7.0.

This fix is in 4.7.0.

I think the best question is, what are you intending to use the transactions for? You don't have to use a status like "Returned" if you don't want to or your payment processor does not support a similar status. Different payment gateways provide different transaction statuses, and the statuses Blesta supports covers pretty much all of them in a generic way. Typically: Approved - payment received Declined - payment declined/refused Voided - payment voided/invalid Error - payment error occurred Pending - payment may be received but awaiting confirmation; on it's way; authorized but not yet captured Refunded - payment was probably Approved in the past, but has now been refunded back to the client Returned - payment was probably not Approved in the past, but any money received was returned back to the client Use, or don't use, those statuses to your liking, but "Approved" should be your successful payment received status and all of the others are not.