Max

Implementing it as MerchantAch module should be fine. Just need to have some extra input fields in the "add account" screen as mentioned before. SEPA direct debit needs a couple fields more than American ACH.

Still think it would be better to bump the existing threads, instead of creating a new one. So you do support multiple payment methods for the other 10%, in which case I think I misunderstood your comment. For consumers it is pretty common here (the Netherlands) as well. Not so much for companies. Often the person placing the order needs approval from someone else to get the payment done, and wants an invoice first for that. --- Billing systems that were written for the European market (e.g. wefact.nl) typically have a module for it by default. For most others there are third-party extensions.

Existing thread: http://www.blesta.com/forums/index.php?/topic/1983-extra-fields-for-sepa-direct-debit-european-ach/ 100% of your customers agree to SEPA direct debit? Here most corporate customers would refuse that, and demand an invoice they can pay by normal bank transfer instead.

Problem is not all gateways do notifications. Some require polling the status of the transaction initiated after some time if the user wasn't redirected back.

Think you should do something about the pdf size of each invoice before implementing this. The -only embed the unicode characters actually used in the invoice- issue.

Only if you are American. Paypal Europe does allow them. Not withstanding that charging a surcharge is usually more pain than it is worth. Keep in mind that you also have to collect sales tax over any extra charges likes this, and if the invoice was generated already (e.g. when it is a renewal invoice, and you didn't know the payment method when that was created), you may have to write out a separate second invoice just for the charges, as you are not allowed to change any existing invoice...

Perhaps Blesta is trying to set admin-c, tech-c and billing-c while those do not exist for .co.uk domains? Those should be set to contact ID -1 according to logicboxes API documentation. http://manage.logicboxes.com/kb/answer/752 The Administrative Contact of the domain name. NotePass -1 for the following TLDs: .EU .NZ .RU .UK Or perhaps it is not using the right contact type as registrant. Other modules (like eNom) also make the mistake of only having special handling for 2nd-level .uk domains, while most of these things apply equally to .co.uk.

Does have other downsides though. All the modules being totally independent are a pain if you want to translate Blesta to another language. You end up with each module having e.g. 100 translatable strings, will only 10 are really specific to that module. Would rather see inheritance being used more. And it would also be nice if it was possible to assign more than one module to a service (e.g. one main module that handles the actual server provisioning, and a completely different one to offer monitoring through Observium)

That's incorrect. Only the hostname is sent unencrypted (by the SNI TLS extension, so the server knows which certificate it should use, if more than one site shares the IP). All HTTP communication including URL and request headers does is sent over encrypted SSL. Only problems are the GET parameters ending up in web browser history, and that URLs including GET parameters are usually logged in web server logs. Do note that this module is not the only one with security flaws regarding to GET parameters. When you enable Blesta's two-factor-authentication it submits your secret master seed code -of which all TOTP codes derive from- as GET parameter to chart.googleapis.com in order to generate a QR code of it... Reported over a year ago, but apparently it was not considered worth fixing.

Note that in other EU countries "simplified invoices" -aka cash register receipts- are only allowed for small purchases in retail stores, and not for distance sales. Even if that does is allowed in Germany, you may still have a problem if you have a single foreign customer.

Screenshots sure look nice. But I do think you should at least document that: FTP function is not implemented in module itself, but outsourced to https://file-manager.cyandark.com/ meaning the password the customer enters is sent there. SSH function is not implemented in module itself, but outsourced to https://ssh.cyandark.com/ meaning user's password is sent there. Furthermore the SSH function submits the user's password as GET parameter, meaning it can end up in the web browser history... <iframe style="width: 100% !important; height: 500px; margin-top: -10px; border: 1px solid #ccc; backround: #000;" border="0" src="https://ssh.cyandark.com/?host=<?= base64_encode($host) ?>&puerto=<?= base64_encode($port) ?>&user=<?= base64_encode($user) ?>&password=<?= base64_encode($pass) ?>"></iframe> I do not doubt your good intentions, but I do am pretty uncomfortable with the concept of sending customer's passwords through any third-party... Not a big fan of including resources from external sites either (like "@import url(https://fonts.googleapis.com/css?family=Inconsolata);") Some browsers like IE and Firefox allow Javascript inside CSS. If external site is compromised, so will your panel be.

Ok. Thought that may not be always the case, because of the ifSet() == You did include your class name in the callback URL, so that the request gets routed to your class? As in: $callbackurl = Configure::get("Blesta.gw_callback_url").Configure::get("Blesta.company_id")."/".strtolower(get_class($this))."/"; In case you are not able to find your problem, you may also able to use Paypal Express through our Omnipay module.

I don't know if that's the problem here, but if you use Blesta's log function with the first (url) parameter empty -which could happen here if $post_to is empty-, nothing gets logged and it terminates the script with a fatal Error: a:1:{s:3:"url";a:1:{s:5:"empty";s:12:"Missing URL.";}} exception. We have had an issue with that as well. In our module log() was being called with empty first parameter only when run under crontab. One of those places where nobody sees error messages being printed, and nothing got logged.

Do you have special needs such as that the fields need to be generated dynamically, that you put it there? If not, it might be easier to add the conditional logic code to the configurable options instead. As in: add a couple extra columns to "package_options" table. E.g. "depends_on_option_name" "depends_on_option_value" adds some code to generate the Javascript based on the database information and attach it to the form with $fields->setHtml() in app/models/package_options.php PackageOptions::getFields() - or set the right attributes of the individual form elements there if using a solution like conditionize.js. Downside does is that it requires changing core files, but chances are you need to do that anyway.

Can already add price tags to options: http://docs.blesta.com/display/user/Creating+Configurable+Options

If Javascript is not your thing, there are standard jQuery plugins to simplify that and let you describe form dependencies in the form HTML. E.g. https://github.com/renvrant/conditionize.js

Hmm, you are right, there do is some code. Doesn't always seem to work though. E.g. if you use "add service" as admin, and do everything well, the boxes to ask for the extra info never appear: Do can provoke them to appear, by making an error in this screen, "forgetting" to select the "term", and pressing "continue": And .co.uk still does not work even then. The code only seems to cover name.uk, not name.co.uk

But can the module actually register the domain, like the TS asked, or only check its availability? Note that .ca is one of those domain extensions that require some extra information to be filled in for registration. And somebody else reported extra information fields didn't work for .co.uk...

Nope. Too little demand.

Do note that our NOC-PS software is only suitable for providers that have their own servers and network, and not for resellers that resell servers from another provider.

Looks like something they made themselves. That they call the Ubersmith API internally to generate the bandwidth graph you asked for, and pass it thru, does not mean you are using the Ubersmith API.

Don't think they extended it, but added something on top. As in: you <-> Quadranet API <-> Ubersmith API / other backend systems for the action requested. I have my doubts your module is talking to Ubersmith directly at all. Did you make it clear to them that you want to write a module that CUSTOMERS from providers that run Ubersmith can use to RESELL dedicated servers? As opposed to a module for providers running Ubersmith themselves?

Wonder if that isn't something Quadranet added on top, rather than normal Ubersmith functionality. Things like (null) routing do not exist in their public API documentation And IP assignment used to cover the administrative part only (marking them in-use in the database), rather than the technical part (configuring router, so that packets end up at the right server). WHMCS did not bother to document their SQL helper functions until recently, and PDO was not guaranteed to be available on the average WHMCS installation either in the past. So practically all older third-party modules call mysql_query directly.

Ubersmith's API for dedicated servers? Is that something new? They did not offer anything more advanced than power on/power off, and switch port data traffic graphing in the past.

Wonder if "ordering parts" doesn't scare some customers away. They might be concerned you do not have any spare parts either if something breaks. Sometimes it is better to have a little less accurate status tracking.