Jump to content

Remitur

Member
  • Content Count

    513
  • Joined

  • Last visited

  • Days Won

    5

Remitur last won the day on November 15 2020

Remitur had the most liked content!

Community Reputation

45 Excellent

3 Followers

About Remitur

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. I guess you should try to do it using ClientDetailsValidation: when a user register, you check the country and assign to client group accordingly. You can also evaluate this free module: https://www.modulesgarden.com/products/whmcs/geolocation-hook (in order i.e. to remove from the template the "register" public function for foreign customers , leaving it just for logged users)
  2. Different way to fix the issue: - do not allow unregistered user to begin orders: one user is required to register, and then he will be allowed to insert an order or - as "default" client group set the prices reserved for foreigners; if a user begins registration process, he will be forced to pay the higher fee. Later, after registration you will set renewal fee accordingly or - use some kind of cart hook (i.e. PreShoppingCartCheckout ) to dinamically modify prices before checkout (note: this may be rather difficult, and far from error-proof...)
  3. Where're you from? If your company is somewhere European based, you can't do it because it's forbidden. To do it: - create a client group (i.e. "foreigners") and associate the domain price list with preferred prices - create a hook that, just after registration, assign the user to the "foreigners" client group whenever the country is not your own homecountry
  4. I'm realizing an external html landing page that, using a form, allows the user to try to register a selected domain. Submit button calls: mydomain.com/cart.php?a=add&domain=register&sld=domainname&tld=.com The issue is that doing so, I'm getting a white page with just the message {"result":{"error":"The characters you entered didn\u0027t match the image shown. Please try again."}} Note: If I do the very same, but from a .php page inside WHMCS, it works quite good: - if the user is asked for recaptcha compiling, everything works fine - if the user is not asked for recaptcha compiling, he gets just a quick message " The characters you entered didn't match the image shown. Please try again" that disappears immediately, and everything go on regularly... Any idea on how to fix this recaptcha issue? (By the way: there's any way to call /cart.php bypassing recaptcha request? I could move recaptcha from /cart.php to the first page...)
  5. Does this happen just to a single user, or to every user? If single user: check the data he's submitting and his personal data (special characters in name or email address, or so on) If every user: ask to WHMCS support, there should be something wrong in your install.
  6. Enable PHP error logging and then check the detailed error
  7. Issue: having a custom theme is great for public pages, but it's a mess when a user visits his client area... css conflicts, updates overwriting your custom code, continuous necessity to update your code according to WHMCS updates... lot of wasted time. So, my idea is: using custom theme for any public page (index . php, index . php ? rp=announcements, index . php ? rp=knowledgebase , contact . php etc.) but switch to six (or twentyone, or another standard theme) just for client area ( clientarea . php ? action=whatever) Being not possible to edit clientarea . php, I guess that the only way is some kind of hook... but I can't imagine how switching the theme inside of it. (I guess that just a simple $ _ SESSION [ 'Template' ] = 'six'; wouldn't be enough...) Any idea?
  8. Yes: just mark it as "hidden" in products management https://docs.whmcs.com/Hiding_and_Retiring_Products
  9. No, it shouldn't. Although, I guess, we can expect anything from Oakley...
  10. Price discrimination is forbidden just for EU citizens and residents. So, your prices need to be the very same for France, Italy, Germany... But for Japan, USA, UK you're free to charge whatever prices you want.
  11. It's ALWAYS somehow possible. Registrars are forced to provide support to registrants when necessary...
  12. It's what happens with any credit card gateway. Look at the fees you're paying to Stripe (less than half the amount you're paying to PayPal) ... 😄
  13. I was abducted by aliens so, I guess, I don't care about this: I have much more serious matters to worry about... 😉
  14. The issue is not about "paying with credit", but about "paying with credit card" ...
  15. Unusual (and unwanted) behavior from WHMCS, using STRIPE module (but, I guess, it may happen with any other credit card gateway): user has no credit card registered user inserts an "add funds" order for 100 shells, but does not pay it; system issues invoice n. 300 (unpaid) user inserts another "add funds" order for 100 shells, and pay it using credit card; WHMCS process it fine (100 shells credited to the user, invoice 301 (paid) is issued So the invoice # 300 stays unpaid... During the main cron /few hours later, during the night) the system process the payment of (still unpaid) invoice n. 300, using the credit card data used few hours before to pay invoice 301 (the credit card data has been registered by Stripe) And so the user did TWO different payments, of the very same amount (one of them unwanted). Any idea about how to prevent this behaviour?
×
×
  • 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