Jump to content

jacksony

Member
  • Content Count

    89
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jacksony

  • Rank
    Member

Recent Profile Visitors

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

  1. Hi Brian, Thank you again. Wow that is some workaround which I didn't thought of. Thank you. We will consider activating Weebly free using your work around. But anything stand-alone which is free is not good.. 🙂
  2. Thanks Chris! I see. If that is the case we will just disable the free option for now. 🙂
  3. Dear All, Is it possible to prevent customer from signing up stand-alone Weebly free plan? As we only want to provide it, if customer signs up a shared hosting package. Is that possible? As there have been much abuse when customer just sign up for free plan.
  4. Hi, I understand this update is for WHMCS 8.0. But is it possible to update stripe-php to 7.34.0 for WHMCS 7.10? The reason is it is still using 2019 older version Stripe API, when the latest is already based on 2020.
  5. Hi, Anyone running WHMCS on PHP 7.4 yet? I have tried to do so, but strangely, it shows Service Unavailable 503 Error.
  6. Thanks for the explanation. But the concern is, if WHMCS takes the transaction fee which is based on full amount, then it will mean inaccurate data in WHMCS. Since the transaction fee captured in WHMCS should be the nett amount taking to be effect of the credit?
  7. Hi, 1. hard to get my point across to WHMCS team. 2. further more our support just expired, think even to submit a bug is difficult.
  8. Thanks have reported it. Will see what WHMCS says.
  9. I want to confirm if anyone face such an issue first? As if it is a bug, and using credit and stripe seems to be common among some of us, it can't be only us being affected by this bug. Anyone can confirm or WHMCS side can verify before we submit a bug report?
  10. Yes this is confirmed. Previously there was no such issue. The reason we detected because we are doing accounts recon. The transaction fee is higher, but a second line of transaction in Stripe report actually refunds the credit and credit the fee, making it right actually. But thr problem is this second line is not reflected in WHMCS transation, therefore making it "unbalanced" if you try to recon the transaction.
  11. Thanks Brian, As usual, sad that it seems to be only us again, facing such issue. But yes, it is an absurb issue. eg: setting compulsory fields for custom fields for domains, but ended up, causing default domain fields (deactivated) to throw errors due during domain transfer.
  12. Hi, I discovered this month, while we are closing accounts, there is a change in how Stripe/WHMCS works with Credit, and makes the WHMCS reporting wrong. When customer in WHMCS use a credit to settle partial payment, what I'm seeing is Stripe deduct the full amount first, charge fee based on this amount. Then there will be a 2nd transaction which refunds the credit amount and the transaction fee charged in the 1st transaction for this credit. However this cause mistake in WHMCS transation and thus, its reporting. As WHMCS ONLY capture the original amount and the Stripe fee charged for this ORIGINAL amount. It does not record the refunded transaction fee (due to the amount offset by credit in WHMCS). How can we fix this?
  13. Hi all, For a domain extension eg. .com.XXX, we have already use additonal fields to remove the default fields for it. We noted the default fields for .com.XXX has 2 required fields for it. For the 2 custom fields we have added for .com.XXX, if we did not make the fields compulsory, there is no issue for domain registration and domain transfer. However, once we set '"Required" => true,' for for these custom fields, the strange thing is for domain transfer, it suddenly displayed error saying that the required fields for the DEFAULT fields is missing. However it shouldn't be there since it was removed initially already. There is no issue for domain registration if '"Required" => true,' is set for the 2 custom fields. This seems to be an obvious bug? Since if the default fields are removed, it should not be referenceing to default fields at all (as displayed by the error when we tried to transfer domain with compulsory custom fields). Or is there any thing we have missed out for custom fields?
  14. Thanks for answering the same question many times. Is there a way to check if it works? Instead of waiting for the 1200am for the whmcs cron to run?
  15. Hi, We have a strange problem. Our setting in WHMCS is to run cron at 00:00 hours. Our server is on +8 GMT. I'm realising the Cron Report/Summary is sent out at 08:00 +GMT instead of 00:00 +8 GMT. Is this a bug?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated