Jump to content

yggdrasil

Valued Contributor
  • Content Count

    859
  • Joined

  • Last visited

  • Days Won

    6

yggdrasil last won the day on November 10 2018

yggdrasil had the most liked content!

Community Reputation

58 Excellent

2 Followers

About yggdrasil

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. The cron will trigger the automation actions, it will suspend an account depending on in the settings you have. Here: https://docs.whmcs.com/Automation_Settings
  2. WHMCS will sync expired domains as far as I know, setting them back to Active and updating the new expiration date. It will not sync domains set to Cancelled, but this state is not something WHMCS sets or uses. It's a status that has to be changed manually on your WHMCS. If your domains had the Cancelled state, then sure, they will not sync but that means someone with access to your WHMCS installation manually changed every domain to Cancelled, as WHMCS will never change domains to that status.
  3. There is no Inactive state for domains on WHMCS. Do you maybe mean Pending or Cancelled? All domains in the same registry will be synchronized, that is how WHMCS works right now. And yes, it will sync all active domains, pending transfer, expired, etc. If a domain was expired and then it was renewed, it should sync that and change back the status.
  4. I want to update this, the bug is still not solved. Still losing Stripe sales and customers 🤬🤬🤬 On the description of charges the cart title is still displayed when not using the default English language. The statement descriptor while it does not show the cart title page any more its still wrong and shows something else like twice the company name and then adds C or Cart in the end instead of the WHMCS setting for Stripe. This is also causing failed or rejected payments with banks fraud systems as its constantly using a different description for the company charges. This seems to be happen only with the card and not automated cron payments. I also report that the bug that rejects credit cards (without actually sending them to Stripe for processing) still exists. I still get complaints about people that try multiple cards which are rejected on WHMCS, but they are not even logged on Stripe. This means WHMCS is not sending the data properly to the Stripe API. I suspect when WHMCS fixed this they did not consider people using other languages in the cart. It seems I did all the upgrade for nothing.
  5. This is something that surprises me. Customers expect instant replies from a small company but then have no issues waiting 3 days for a reply from a big brand that is horrible when it comes to support and customer service.
  6. I never saw that specific issue regarding notes but the URL rewrites and WHMCS settings do tend to cause all sort of weird bugs like breaking the admin search and other strange things I noticed before. It also likes to break links on the customer front end 🤬
  7. Welcome to the world of closed source code for user frontends.
  8. You just registered to post that? Seems like self-promotion.
  9. Thank you. I will look into that module. I'm not sure in terms of accounting how this works since as you mentioned, you are creating extra income out of air which does not really exist but still I think in general there are good ideas here about different approaches.
  10. How many domains do you have? If I remember correctly, it runs on batches, per XX number of domains, so it might not sync all of them in one cron run.
  11. How is this related to WHMCS? WHMCS will not magically set up your hosting service, or DNS servers. Do you have a hosting server setup and working already? Not a server on which WHMCS is running, but a second server just for your customers, WHMCS is just a billing software, it's not actually hosting the sites for your customers.
  12. Yes, WHMCS cannot transfer domains between registrars (I wish that was possible) but it also usually requires confirmation by the registrant and other manual actions. You need to handle them outside WHMCS and then update the registrar for the domain manually.
  13. Well that addon sounds interesting but it might be an accounting nightmare because invoices paid with credits on WHMCS are internally 0, WHMCS counts instead the upload credit invoice for the total value. And unless you add credits with an invoice on WHMCS, they will not be accounted and you will end up with ghost balances or missing numbers. Said that, giving users back credit in a reward sort of system seems really messy once you need to close your yearly books. My idea was more simple. Invoice X is paid with X payment method (apply discount). If this is before or after payment is irrelevant, the idea is just to give a discount based on the payment method used. I consider credits just one method, but this could be PayPal or anything else. My idea is trying to pass some savings back to users trying to promote more the credit use. The reasons behind that are simple. Every payment takes a fee per transaction, if the user can instead make a bigger one time payment, he can save the fees instead of paying every single item with a unique transaction fee. Hence, I was trying to give them a discount if they pay with credits but now that I think about it, the add-ons that add the extra fees on before payment probably have the similar result. If people realize they have to pay extra fees for each payment, they might just as well start using credits but I never liked the idea of passing the payment fees back to the users, I have them included in the price, hence I absorb them. I'm not even sure if that is legal. As far as I'm aware, PayPal or credit cards for example don't allow that, to pass the fees back to the user and prices have to be advertised with them included. Except if the payment involves just credits for future use, I think only in those cases companies are allowed to calculate the fees as separated before payment. The reason I say this is that some companies do this. To make it more simple. Another easy way would be to restrict a discount coupon per payment method. I guess this is not possible today. I guess I will have to make a hook or API page. Example: users enter coupon code on cart. Discount is applied if X payment method is selected. If the user the switches the payment method, coupon is invalided or deleted. I guess there are multiple approaches but I always found this a bit lacking with WHMCS when it comes to payment methods. Like restricting a product to only X payment method, or a customer banned from using specific payment method, or discounts per payment methods. I think you get the idea. WHMCS should be more granular on how it can manage payment methods, as they all have different costs structure and are processed different. It would make a huge difference on mixing things and creating different business scenarios.
  14. Yes, that was my idea. Pay with credits a specific product and you get a small discount since credits means no merchant fees for each payment. It's the opposite to gateway charges. You pass the savings to the users instead of adding the extra fee on top of the payment. The problem with giving a wide permanent discount to some users for specific products is that you can't do this if they use a different payment method. Hence, it should be restricted to a specific payment method.
  15. Password should not be readable in the mail history users account. There should be a special variable field for email templates for secrets of sensitive data. Passwords should be inside those brackets. When composing email templates, the data should be sent top the user but afterwards removed if it's contained with the sensitive/secret variables tags. WHMCS should detect this and erase or replace them, so they are not displayed in the emails history on the users account or registered in the SQL database in plain text anymore. Ideally they should be replaced with ******* This would avoid an attack that compromises an account in the future just looking at the mail history to get server and account logins. I know, I know, users are supposed to change them after first login but some don't and it looks just very bad in terms of security to be able to permanently see the login details by looking at the mail history. This also defeats the sub user account permissions if they can just look at the mails history and get the logins for accounts which they don't have access.
×
×
  • 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