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.