Jump to content


Level 2 Member
  • Content count

  • Joined

  • Last visited

  • Days Won


malfunction last won the day on September 28 2017

malfunction had the most liked content!

Community Reputation

46 Excellent

About malfunction

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. malfunction

    Unable to get Apple Pay to work

    I'm using a third party cart template and while I was prepared for problems as a result, yes, it worked right out of the box and I was successfully able to make an order and pay from my iPhone. The only fiddly part was the Apple verification file thing, but everything else was just as expected. My checkout is very light with soft gray tones and a big fat black ApplePay button right in the middle might lead folks to conclude that was the only thing available, so I'm going to have a play with the CSS (thanks @brian!) and see if I can get a 'White with Outline' look that's in line with Apple's style guide https://developer.apple.com/design/human-interface-guidelines/apple-pay/buttons-and-marks/buttons/ From the Stripe docs theme: 'dark' | 'light' | 'light-outline', // default: 'dark' I had expected a simple theme switch somewhere to cope with different colored checkouts (WHMCS would have thought of that, right?) but I can hack the CSS if I need to.
  2. malfunction

    Unable to get Apple Pay to work

    The default dark ApplePay button is a rather overpowering and overshadows the other options in our template; how can we change to use the lighter options? elements.create('paymentRequestButton', { paymentRequest: paymentRequest, style: { paymentRequestButton: { type: 'default' | 'donate' | 'buy', // default: 'default' theme: 'dark' | 'light' | 'light-outline', // default: 'dark' height: '64px', // default: '40px', the width is always '100%' }, }, });
  3. No conclusion given here, did this ever get written? I could sure use it.
  4. malfunction

    Trail period for products

    OK, well maybe not always a mistake, but in my experience it's generally better to hide something for a while and see if they will pay, rather than just deleting everything at the first possible opportunity. The latter makes for fed up customers and extra support workload So, just another WHMCS disappointment, I guess. You think you have some useful product trial functionality but when you go to actually implement it you discover that it's just half baked and not properly thought out.
  5. malfunction

    Trail period for products

    from the related feature request: "Once the trial period if the customer does not pay for the service, the account will be suspended." WHMCS response: "I'm pleased to be able to advise this is possible using the Auto Terminate/Fixed Term option under the product Pricing tab." Actually I don't believe this is is possible, SUSPEND being the operative word. Whatever the product is, if the trial customer has spent a bunch of time building/configuring/whatever with his trial product, he's not going to be real impressed if his work gets deleted on termination. Much better to be a bit softer, suspend for a period in the hope he will convert to paid once he sees the product is deactivated, then terminate later if he doesn't. Just trashing it at the first opportunity because he wasn't quick enough to make the first payment is not the way to begin a profitable relationship. Auto deletion of accounts without some sort of grace period is ALWAYS a mistake.
  6. malfunction

    Marketplace SSL expirys query

    That's OK in theory, but in practice GeoTrust will issue the renewal certificate for a period that's 1-2 months longer, so after several years the billing date and the expiration date will be six months apart. Which creates angry customers wanting to know why you are billing them in January for a certificate that doesn't expire until July, and consequent support workload. There should be a sync process similar to domain management.
  7. That's funny, mine still says this: Your PHP version 7.0.24 is supported by WHMCS. Your PHP version is actively supported by PHP for both bug fix and security releases. Which of course is not strictly accurate as since PHP 7.2 stable was released right on time a couple of days ago, PHP 7.0 is now in a "critical fix only" mode and is no longer in active support. Hope WHMCS are enjoying their nap. Added: Oh, I see you're the other side of the dateline from me. So I guess my admin panel, together with everyone else's, will throw a similar warning tomorrow when it gets to be December 3 (2 year anniversary of PHP 7.0 release) over here. Perhaps a warning about unsupported PHP versions being displayed to 100% of users will encourage the release of at least PHP .7.1 support in WHMCS.
  8. malfunction

    WHMCS Cron Job Activity Email

    Yes it is, pretty much worthless. If only they had spent the time they used to stuff their logo in there on considering how to actually make the report more useful to users... Instead we have chase around all over the place to find what got suspended, terminated, cancelled, what failed etc. There was frequently actionable information in the old cron report, now it's just fluff.
  9. You're seeing this as some sort of an oversight on the part of WHMCS, when the lack of current Windows support is actually deliberate policy. They used to support Windows and at some point in the last several years took a decision to cease doing so. It should still work at the moment, does for us, but don't be surprised if you can't get any help with more complex problems as you go on. We own our own equipment and so can't readily switch our WHMCS server to *nix on their whim, but for sure if I was starting out I wouldn't choose a Windows box for WHMCS, as sooner or later you're going to come up against something that doesn't work and you'll be completely on your own. That's fine, there's already too many people in this space.
  10. So when PHP 7.2 stable drops on November 30 we'll be three versions behind the latest. Nice.
  11. malfunction

    Live Chat plugin, recommendation?

    Wasn't that the whole point of the integration with WHMCS? Isn't it just "yet another chat app" without it, or is there some other useful/unique functionality remaining?
  12. malfunction

    life-time license?

    From the perspective you described, there isn't really any difference between monthly and the no longer available perpetual licensing. They both call back to the WHMCS licensing servers, so in the event WHMCS close shop then you are s.o.l. either way. The system is somewhat resilient in that it will survive up to about a week of the licensing system going down completely before it actually fails at your end, so minor network glitches should pass unnoticed.
  13. Not sure why WHMCS would decide to remove useful functionality like that. If a customer has a couple dozen random domains we can convince him to transfer, he's soon going to change his mind if he has to enter them into the cart one at a time. Way too much trouble, he will just leave them where they are. Also after doing a domain search for a transfer domain (i.e. comes back as already registered), switching to the "transfer" tab reloads the page causing the domain name that was entered to be lost and need re-entering. Again makes more work and less likely the client will bother. This doesn't really sound like "a more intuitive and optimised user experience" to me
  14. malfunction

    Regarding New Pricing Model.

    OK, found the feature request thing: https://requests.whmcs.com/topic/stripe-payment-gateway-module That "announcement" from a month ago has about as much substance as the prior offerings, we're working on it, it's in progress, it's a bit difficult, sheesh. You guys are supposed to be software developers, if you actually wanted to it could be written, tested and released by the end of the week. But all we get is more foot dragging.
  15. malfunction

    Regarding New Pricing Model.

    Well I can't think of any other reason why for FIVE years you'd pass over Stripe, one of the most popular payment processors in the US and long ago integrated into pretty much every shopping cart out there, while merrily promoting your own affiliate income based solutions here: http://www.whmcs.com/partners/ I don't know where the Stripe "feature request" is now, the embarrassment that was the feature request system seems to be nowhere to be found these days, but it's good hear that after claiming to be "working on it" for years, you now have actually started working on it. But of course there's no guarantee of when 7.1 might be available, whether Stripe will definitely be it or what might happen to tokenized client data already used with the existing ServerPing Stripe mod, so while it's a bit less vague than previously it's still not much help for planning purposes

Important Information

By using this site, you agree to our Terms of Use & Guidelines