Jump to content

flangefrog

Members
  • Posts

    282
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by flangefrog

  1. So far so good yes with 3.6.

     

    in webdrive.php comment out all '$this->setSubaccountUser($api, $service->client_id);' lines.

     

    I've not fully tested this yet but after doing that I'm able to request UDAI, change nameservers and get whois info.

     

    Once I've done more testing, as I'm not sure what this change effects properly yet, I'll update this post.

     

    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.

  2. While they may not be federal laws (yet...though they already are in some states), PCI is required by all major credit cards networks (Visa, Master Card, Discover, American Express)...and if you are found in breach of them you can face hefty fines and expulsion from said credit networks.  Not complying with PCI Standards and being caught could easily mean that you'll never be able to accept credit cards or get approved for a merchant (or non-merchant) account again.  If you get blacklisted by the credit networks you are screwed as a business.

     

    It's not something that many sole proprietor's or small business think about, but PCI Compliance is a serious issue and should be viewed as such.

    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?
  3. Do you purge your cron task logs often? My guess is no, so the date passed to Services::getAllRenewablePaid should be within the last interval for that cron task (last 5 minutes?), so it should only fetch services that were paid (invoice was closed) since that time. You can debug to see if the date is correct.

     

    But if you are still receiving that service as a paid renewable service, then it must be an active service with a line item on an invoice that was closed within that interval, otherwise there is something else going on that should be debugged. Have you made any custom changes that might be related to this?

     

    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.

  4. Do you have a reference? I predicted this in one of those previous threads. Logically, your server sends the markup for stripe.js, so if your server was compromised an attacker could modify that javascript to capture the card data anyway. It was a loophole that has apparently been closed as I suspected.

     

    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.

    So you have to be compliant now even if we end up getting stripe.js implemented?

    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.

  5. 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

  6. 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

  7. 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
    
  8. 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.

  9. I know of at least one province in Canada that has a provincial sales tax rate of 9.975%, so it definitely needs the decimal places.

    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.
  10. 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.

  11. 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.

  12. The commun factor here is term of 12 mounth converted in 6 mounth in pdf .

    Question : the service show renew date correct ?

    This service is related to any module ?

    The old invoice imported , has the same case ?

    This questions can help in identificating the probleme .

    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.

×
×
  • Create New...