Tyson

Padding the exchange rate increases the rate value by that set percentage over the current exchange rate received from the exchange rate processor. If you think the value is wrong, can you provide the exchange rates you're seeing? Whether you should set it to 0 or 5, or some other value, is entirely up to you. Setting the pad value to 0 would not modify the exchange rate at all.

What do your coupon settings look like? Below is what I see when making an order:

This will get you more info for context, or you can remove the fields just for the email addresses: SELECT `contacts`.`client_id`, `contacts`.`id` AS `contact_id`, `contacts`.`first_name`, `contacts`.`last_name`, `contacts`.`email`, `services`.`status`, `services`.`date_canceled`, COUNT(`services`.`id`) AS `number_of_services` FROM `contacts` INNER JOIN `services` ON `services`.`client_id` = `contacts`.`client_id` WHERE `services`.`status` = 'active' AND `services`.`package_group_id` = '1' GROUP BY `contacts`.`id` ORDER BY `contacts`.`client_id`, `contacts`.`id`

The div's look fine--just one too many. Delete the "</div>" from line 26 and it will probably be back to normal.

Invoices for new services are created in the currency of the selected term/pricing. What you could do is allow EUR to be accepted on the order form so that they can select that currency, which would then perform the pricing conversion and allow them to checkout in EUR.

The client's preferred currency can change if changed directly by an admin or the client, or if the client orders something from a different currency on an order form.

There is no setting to adjust the number of decimal places shown for taxes. We will be updating them to only show the most significant digits, so your example would appear is "19%" rather than "19,0000%" once CORE-1483 is complete.

What version of Blesta are you using? The error you received shouldn't have occurred, but may have been possible in much older versions. A module in Blesta represents the product/service you are selling. Most modules perform remote actions, so configuring the module may require you to specify account credentials so that API requests can be made with the module. If you do not intend to make use of any of the existing modules (e.g. cPanel), then you might be able to create a product using the Universal Module. A package represents your configuration of a product. You would select which module you want the package to use, any other module settings, and configure pricing. A service represents an instance of the package that a client purchases, which is a specifically-configured product/service based on the module. So you would start by determining what you're selling (i.e. the module). Then configure the product and its pricing (i.e. the package). You can then create an order form that uses the package so that customers can order them from your website. As LicenseCart mentioned, if you're experiencing that error on the order form, you might want to try changing the order form's template to Standard or Wizard instead of AJAX.

The "merchantAccountId" is the Mercant ID you have set for the gateway in Blesta, correct? This is necessary to make the payment over the API. I imagine they would already know this information, so I'm curious why it would need to be given again. In any case, that could be added. Although, I'd prefer to see API support for a 'currency' field we can set ourselves.

I'm partial to just making the original content available in plain-text. Whether that is in the docs, or in the UI itself, so long as it can be copied. Automatically resetting content could end up causing more problems than it solves.

This is how I interpret the steps in that graph: Client tries to pay an invoice using your gateway Client is redirected to the payment processor's website where they make a payment The payment processor contacts Blesta (via the callback URL) to tell Blesta a payment has been made. Your Blesta gateway performs any required validation necessary to ensure the payment is legitimate. Normally, validating step 4 would be an API request to acknowledge and confirm the payment with the payment processor. You can perform a remote request over the API from your validate method before returning from this method. The payment processor receives your confirmation request and would reply with some information indicating whether the payment details were correct. Steps 7-9 shouldn't be anything you need to worry about in your gateway. After the client is redirected back to Blesta, they will see a page indicating the payment is being processed. This can suffice as the success and failure pages. You shouldn't need to generate any "page" to send to the payment processor for confirmation. Make an API request however their API dictates, for example, via cURL to POST the fields "status=success&c=mail-trade&s=signature" to them. Take a look at the validate method in PayPal Payments Standard to get a better idea of how it confirms the payment.

I've added a task for us to remove the unnecessary white-space in searches as apart of CORE-1978.

Are you referring to the page that the client is sent back to after they make a payment with the processor? If so, you can use the return_url I mentioned above. The client will be redirected to the generic payment-success page in Blesta when they come back from making a payment.

We will likely be updating the UI to make it clearer when table rows are expandable. Right now, table rows that are expandable are highlighted when you mouse over them, and your mouse icon will change from the arrow to a pointing hand.

Ideally, an import/reversion script would be necessary to ease the switch back from the other module. Such a script should map the module_row_id and service fields over for every service. A somewhat generic script could be written to handle this transition. It's good to hear you were able to handle that manually, though. If you update the service from the admin UI, the "cpanel_confirm_password" will be saved again, and the password fields encrypted if they weren't already from the other module.

If you look at the cron logs under [Tools] -> [Logs], is there a recent entry for the Auto Debit task? Does it contain any information?

The service will only be activated under the following conditions: Your cron is setup to run automatically at a certain interval, or you run the cron manually The automation task "Provision Paid Pending Services" is enabled The invoice, if any, associated with the service is paid in full The service is in "Pending" status. If it is "In Review", then the order form you ordered it from is set to "Require Manual Review and Approval of All Orders". This requires an admin to accept the order before it can be changed to Pending status, and this can be done on the [billing] -> [Overview] page in the Orders widget. If you don't see the orders widget on this page, you can add it using the link on the left to "Manage Widgets". I would recommend checking the Module logs under [Tools] -> [Logs] to see if any requests were made to Multicraft. There may be an error preventing Multicraft from adding the server, and you will be able to find more details by looking at the raw Input/Output when clicking on the table row.

Any validation of a payment's success should be done in the validate method, not the success method.

The gateway name is stored in the database still, so updating it in the language file would have no effect. You can re-install the gateway for the name change to take effect. Alternatively, you could update Blesta's core to use the language file instead as naja7host demonstrates in another thread. Does your gateway support making a callback to one URL while redirecting the client to another URL? I assume so, in which case you should redirect the callback to the callback URL: Configure::get("Blesta.gw_callback_url") . Configure::get("Blesta.company_id") ."/paypal_payments_standard/?client_id=" . $this->ifSet($contact_info['client_id']); Then you would tell the gateway to redirect the customer to the return URL: $this->ifSet($options['return_url']); If the gateway does not send data to the callback URL without redirecting the customer back at the same time, then you must use the callback URL instead. When the processor returns data back to your gateway, it will be available in your validate and success methods. Check the $get and $post data for the values you need to save. Make sure your validate method returns the correct data. If you have a special ID to save, you might save it as the reference_id. When the gateway processor returns data back to your gateway, it will come in through validate. You do not need to call success at all.

Do have support tickets in your system? If so, then there should be records in the `support_replies` table. If they are missing, they were somehow inadvertently deleted. In this case, it would be best to restore the table from a backup, if you have one. If you do have a record resulting from this query: SELECT * FROM `email_groups` WHERE `action` = 'SupportManager.staff_ticket_assigned'; ..then your SupportManager was successfully upgraded to add the new email templates. For whatever reason, then, the only thing that appears to be missing is the contact_id field for the `support_replies` table. You can try to resolve that issue manually by running this query: ALTER TABLE `support_replies` ADD `contact_id` INT(10) UNSIGNED NULL DEFAULT NULL AFTER `staff_id`; After you do that, try to see if you encounter an error when you view support tickets in Blesta.

The translations were updated today and now show 95% complete for Spanish.

I forgot to mention you can have the gateway return the client (success/failure page) to the return URL given to you in the buildProcess method. i.e. $this->ifSet($options['return_url']); I'm a little surprised the email is not included. We should probably add that. However, you can query for it yourself: public function buildProcess(array $contact_info, ...) { Loader::loadModels($this, array('Contacts')); $contact = $this->Contacts->get($contact_info['id']); $email = $contact->email; ... }

Version 3.4 of Blesta came with v2.8.0 of the Support Manager. Between v3.4 and v3.6.1 of Blesta, there have been no database upgrades to the Support Manager. I suspect the problem would have existed for you since v3.4. Can you provide an SQL dump of the `support_replies` table schema in your database? Can you also take a look at the `email_groups` table and see if any records are returned from the following query: SELECT * FROM `email_groups` WHERE `action` = 'SupportManager.staff_ticket_assigned';

Your template looks fine. I take it your $post_to variable is set to the payment gateway's expected payment URL? A transaction is created once a payment is made. The URI you included is the review page before making a payment, so there is no transaction ID or order ID, etc., available. If your gateway needs one, you can generate a unique identifier yourself. Your confirmation callback can be sent to the callback URL. PayPal's callback URL defined in the buildProcess method is: Configure::get("Blesta.gw_callback_url") . Configure::get("Blesta.company_id") ."/paypal_payments_standard/?client_id=" . $this->ifSet($contact_info['client_id']) You would simply replace "paypal_payments_standard" with your gateway's name.

Your license is valid for whatever term you ordered it for (monthly/yearly/etc.), so no, it will not be terminated. The only potential issue is if you reinstall Blesta in a different location (different domain, subdomain, or directory), then you will likely need to re-issue the license so that it will then be tied to your new install location. You can login to your account with us and re-issue the license yourself at any time by clicking "Manage" next to your license in the Services table. Then check the "Reissue" checkbox and save. When you try to login to your Blesta installation it will validate the new license location and you can login.