flangefrog

Please read the first post, the reason why you couldn't request UDAI, change nameservers etc is because each domain needs to be moved to a correctly named sub account. There are a few reasons for this, one main one is as following: Web Drive does not have separate contact info for each domain. You can have one contact which is set as the registrant (or other) contact for several domains. This means that when a client edits contact info for their domain they will also edit the contact info for any other domains that contact is assigned to, some of which may be your own or another client's. Running API commands as a specific user makes this less of a problem by limiting changes to contacts within their own subaccount. This won't usually be a problem for domains created by this extension (e.g. registered through Blesta) as it creates three separate contacts per domain.

You need to download vQmod from the link in my signature and look at the very top of the thread for installation instructions. Once it is installed copy the xml to /vqmod/xml and it should work.

I just upgraded to 3.3.2 and I don't think there was a problem before. /admin/widget/order/admin_main/index/accepted/ PHP 5.5.18 MySQL 5.5.40 Undefined property: stdClass::$date_added on line 108 in /var/www/blesta/plugins/order/views/default/admin_main_orderinfo.pdt

Your ability to get approved for a merchant account etc is something I didn't think of, but surely there's no way you could get fined unless your payment processor required required you to be compliant and mentioned the fines in it's terms and conditions?

No, I don't purge the logs manually. The date from Logs::getCronLastRun() is correct now, but there was a task lock on process renewing services earlier today. This might have something to do with it. I only have a few small core changes as vQmods and I'm confident the changes are not related.

See these two posts: http://www.blesta.com/forums/index.php?/topic/3353-accepting-credit-cards/?p=24599 http://www.blesta.com/forums/index.php?/topic/3353-accepting-credit-cards/?p=24638 As I understand it, the way PCI compliance is enforced is that credit card companies tell the gateways to make sure the merchants are compliant, and those gateways usually hold the merchant to the requirements. I'm sure that companies such as PayPal would not force you to complete an SAQ although it may technically be required. They would have the risk of being fined for non compliance but would't fine the merchant as they weren't held to the requirements. I haven't actually had any experience with PCI compliance though so take this with a grain of salt. The PCI security standards are not the law. So you only have to do what is layed out in the terms of your contract with Stripe. It is still a good idea to follow the standards as much as possible.

Sorry, you're right. Stripe chekout is just a JavaScript app built using stripe.js so it is the same in regards to PCI compliance. Blesta recives the data and passes it on to stripe like Daniel has described. Although in the latest PCI specifications you are supposed to be compliant even when using stripe.js

The checkout method doesn't send data directly to Stripe, it sends it to Blesta and then to Stripe. The stripe.js method sends it directly from the users's browser to Stripe.

Blesta uses the Checkout method. There are some other threads about Stripe and PCI compliance, you might want to search for them.

The graph caclculates each month from 2014-01-01 00:00:00 to 2014-02-31 23:59:59 when it should be from 2014-01-01 00:00:00 to 2014-01-31 23:59:59. This results in double the actual yearly revenue when each month is added up. The solution is to move $end = strtotime($date_start . " +1 " . $interval); below $date_end = $this->Date->cast($end, "Y-m-" . ($month_interval ? "t" : "d") . " 23:59:59"); A vQmod is attached as a temporary workaround. fix_billing_graph.xml

Here are a couple of local registrars that support monthly billing: http://www.webdrive.co.nz/ http://metaname.net/ Both support it through the interface, no API needed.

Ok, the problem is that the date_last_renewed was not updated. This is indirectly related to http://www.blesta.com/forums/index.php?/topic/3565-0-invoice-not-paid/ The $0 credit transaction that I added was not applied to the invoice (that's why the date_last_renewed was not updated) but it did allow the invoice to be marked as paid. I think there should be a safeguard in place, such as the Cron::processRenewingServices() method updating the service's date_last_renewed so this does not ever happen again. Edit: I'm not sure this is completely correct. What I do know is that Services::getAllRenewablePaid() was returning the service (and still does) until Oct 17, 2014 3:57:45 PM. So it looks like the run_date passed to Services::getAllRenewablePaid() is wrong in Cron::processRenewingServices(). Here is the timeline: Apr 02, 2014 5:02:54 AM Service added Sep 21, 2014 5:22:31 PM Service last renewed Oct 17, 2014 5:05:02 AM Invoice created Oct 17, 2014 3:57:45 PM Credit applied Oct 17, 2014 3:57:45 PM Invoice closed Oct 17, 2014 4:00:03 PM Started renewing every 5 min Oct 18, 2014 4:56:06 AM Stopped renewing Nov 21, 2014 6:22:31 PM Service renews

Actually I just looked at my logs and it last renewed at 4:55am

I commented it out in the module for now, It is probably still calling the renewal method though. I will check.

The service is active and the renewal date was updated correctly.

So I've just woken up to a $215 $343 bill from my registrar. Turns out a domain was being renewed every 5min until it hit the 10 year limit. Under what circumstances would Blesta continually renew something like this? Is it possible it could be something to do with my module? It is actually the same service I mentioned in http://www.blesta.com/forums/index.php?/topic/3565-0-invoice-not-paid/ and started renewing after I manually applied the credit to it.

I wasn't suggesting to remove numbers after the decimal, floatval() just removes the extraneous 0s. e.g. floatval(1.1234) = 1.1234 floatval(1.1230 ) = 1.123 floatval(1.0000) = 1 $amount + 0 or (float)$amount do the same thing.

Forgot to mention the version. It is 3.3.0. Didn't see anything related in 3.3.1.

One of my clients was sent an automatic invoice for $0 (free service) but it wasn't paid, and I had to manually apply $0 of in house credit to it. The previous invoice worked, just not this one. I did notice that this invoice is affected by CORE-1390 while the previous one wasn't. I'm not sure if that could have anything to do with it though.

Please format the tax rate on display. Instead of displaying GST (15.0000%) I want it to display GST (15%). Probably something like floatval($tax_rate) would be fine, I can't think of a reason anybody would need extra 0s. As a workaround I've changed the database column to be an INT.

That may be true for some or even most people, but if you look around the forum you will find others who probably are startups who choose the registrar based on what is available. I don't see why Blesta needs to "Lose the ego". They are a business with limited resources and have to decide where to spend them to get the most return. Right now they are busy working on core features which are a lot more important than modules. Any business looking at Blesta can pay a developer to make a module, but if the core features are not there then that can stop potential users from switching.

Sorry, should be visible now.

I made a spreadsheet showing the extensions supported and their prices for several registrars. It's a few months out of date though. https://docs.google.com/a/michaellawton.co.nz/spreadsheets/d/1N4X--5eBkme8yax36Tk2qJdPWvG85ruXcxM6GA6kyzs/edit?usp=sharing

Yes Web Drive This is the first invoice that's been generated. The from date - Jun 18, 2014 is actually the service creation date. If I have time tonight I'll see if I can do some debugging.

I also have an issue with the service dates on the invoice. The due date is Oct 21, 2014, but the service description says Jun 18, 2014 - Oct 21, 2014 when it should say Oct 21, 2014 - Oct 21, 2015