Tyson

In short, you need to take the payment as a transaction and then apply it to the invoice.

This should be resolved in CORE-1132.

You can't define custom rules like that on the Universal Module through the interface. There is no way to define the callback validation method. If you don't mind writing custom code that you will need to maintain between Blesta releases, you can update the Universal Module directly under /components/modules/universal_module/universal_module.php and add your callback method.

You should double check that your new server meets the system requirements. Blank white pages usually indicate a php error or 500 internal server error. You can enable error reporting, and then take a look at the blank white page again and see if an error is displayed, which would help us debug the problem.

I think we already did that!

As with any custom changes, you will need to merge/update them into any upgrades you perform on your Blesta installation in the future. That's pretty much unavoidable. Even if you use vQmod to avoid editing core files, you'll always have to check that changes to the core don't have adverse affects on your custom changes. vQmod will probably be the best way to integrate your custom changes into core files, assuming you can get it to work properly. Combine that with a custom plugin that registers your new cron task, and you could probably get this to work.

If invoices are not generating, check your cron logs under [Tools] -> [Logs] for that task. There may be an error occurring that is preventing invoices from being created automatically.

The ability to change which client template to use has been added for v3.2 in CORE-961. You'll always want to keep backups of core template files you modify, and merge them into new releases accordingly. Even if you were using custom templates, you would still need to check them on new releases since data, structure, and language definitions can be added, changed, or removed that has the potential to break things in your templates. The beta releases would be a good time to update your custom templates with these kinds of changes.

Closing this thread as CORE-1105 is not reproducable. Please create a new bug report if you can reproduce this issue.

Closing as fixed in CORE-1104.

Blesta needs the "order-id" associated with that service in order to fetch the information for the other three tabs. It will retrieve this automatically once you activate the pending service, but you are now experiencing a bug where unchecking "Use Module" still uses the module to provision the service, as also described in another thread. This has been fixed in CORE-1133, and you can take a look at that task for instructions on pre-patching your Blesta installation with that fix. Let me know if you need any help with that. After pre-patching your install of Blesta, you should be able to activate the pending service and view content in the other tabs.

This issue has been fixed in CORE-1133. You can take a look at that task for instructions on patching this yourself in the meantime.

Thanks. What's your timezone, and at what time do you have these tasks set to run?

Thanks for the list. Are you running v3.1.3 also?

Are you using the Shared Login plugin? And taken a look at its documentation?

Non-merchant gateways take the customer off-site to complete payment, after which the gateway will only notify Blesta that a payment has been made. Neither Blesta nor your server are passed customer payment information. No ETA yet on Stripe tokenization.

No, the input rules in the Universal Module couldn't handle this because it would require the use of a custom, user-defined, method to evaluate the uniqueness of a field by querying the database.

If you were able to manually add it into ResellerClub and now want to link it up with the client's account in Blesta, make sure that when you add the service you uncheck "Provision using the Interworx module". Then you shouldn't receive that error because the service will only be added in Blesta. Be sure to fill out all of the other fields (username, password, etc.), though.

Ah. Non-merchant gateways can only be used through the client interface, not the admin interface. You could only record payment from a non-merchant gateway manually through the admin interface.

No, the error is isolated to Blesta. There must be something else that is preventing Blesta from fetching the PayPal gateway. Has the gateway ever worked before? At what step do you receive the error as a client? Have you tried other non-merchant gateways to see if you can get passed that step? Do you have multiple companies setup? Did you ever make any custom changes to Blesta, or the PayPal gateway? What version of Blesta and the PayPal gateway are you using?

Typically you'd receive that error if the gateway was not installed on the company, or the currency you're trying to use with the gateway has not been enabled. You could double check that the invoice's currency matches a currency the paypal gateway is set to accept. If everything seems good, you can always uninstall the gateway and reinstall it through the admin interface.

Assuming you have no other open invoices on the account in the currency of the credit, then the answer to the first question is 'before'. If you create a credit before the invoice is sent, the credit remains on the account until open invoices exist for which to apply it to. You can think of the credit as waiting to be applied to the first open invoice(s), and as soon as an unpaid invoice exists, the credit will be applied. As for the cron, it will first create invoices if necessary, apply any credits to those invoices, and then deliver the invoices to the customer.

If you waited for the invoice to exist before applying a credit, then that may be why it did not apply a credit before it was delivered. Invoices that get automatically created by cron also get automatically delivered at the same time. So if you wanted a credit to be attached to it, the credit would need to have already been available on the client's account.

Credits are applied automatically before invoices are delivered via cron, but your Automation settings for how often the credits task and invoice delivery tasks should run might affect this. For example, if credits are applied once every 30 minutes, but invoices are delivered every 5 minutes, then some invoices (at 5, 10, 15, 20, and 25 minutes) may be delivered before credits are applied.

Can you give an example of a domain name that causes this error? Some domain names can be denied based on reserved words. See the resellerclub documentation for more details.