Jump to content

niels

Member
  • Content Count

    151
  • Joined

  • Last visited

Community Reputation

1 Neutral

About niels

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. Technically "Never" applies to your current version. You're allowed to use your current version forever. Of course no sane person would do that, as there's bound to be security issues that only get solved in future versions. That's why there was an Update/Support option that you could purchase yearly. Anyway, if WHMCS is short on cash I understand pricing needs to go up. But charging based on the number of Active Clients ignores the reason why someone might have a lot of Active Clients. In our case: WHMCS allows only 1 currency per client, so to offer clients the option to pay in multiple currencies as they see fit we generate additional WHMCS Clients for them on-the-fly and move their service between them accordingly. (Note: they can distribute different services over different currencies. It's not as simple as activating one client and de-activating another.) Due to the political situation in our original country of incorporation we're slowly moving clients to a new company elsewhere. Both companies have an owned WHMCS license and keep a full copy of all clients. We try to support some good in the world by providing our service for free to NGO's. It's unclear whether Free (but Active) accounts are also counted, but I think they shouldn't. Just seems wrong to tax something someone does for free. Similar to #3 - how about Clients that sign up but do not order anything (yet)? Or who get a full refund? Perhaps most important to me personally: I'm worried about the measures WHMCS will take to enforce this new licensing. Its trivial for someone to simply mark their Clients Inactive and mark them Active again when renewal comes up. WHMCS will have to do all kinds of double-checking to prevent abuse. Something which I can just see wreaking havoc for anyone writing their own modules or customization's with the assumption that WHMCS works in a certain way.
  2. They went from 99/year down to 59/year and now to nearly 500/year. That’s pretty erratic. I would actually be (somewhat) OK with a bait and switch, but this feels more like a panic move, which is worrying.
  3. WHMCS version: 8.1.3 Module: PayPal Checkout The module works fine most of the time: it creates subscriptions, processes payments, etc. Where it fails is when it receives a payment that's pending first, completed later. The "PAYMENT.CAPTURE.PENDING" event is processed correctly, which is to say, WHMCS recognizes this as a "Payment Pending" event in the Gateway Log. But when the "PAYMENT.CAPTURE.COMPLETED" event comes in, WHMCS does nothing. It just lists it in the Gateway Log as "Information Only". Am I doing something wrong? Or is this issue going unnoticed because it's relatively rare for a payment to go through these 2-steps. (Basically only payments that PayPal deems high-risk and wants to review first.) I'm copying a "completed" event below, just in case someone sees anything unusual: id => WH-HIDDEN-HIDDEN event_version => 1.0 create_time => 2021-03-06T00:23:32.105Z resource_type => capture resource_version => 2.0 event_type => PAYMENT.CAPTURE.COMPLETED summary => Payment completed for $ HIDDEN USD resource => id => HIDDEN amount => currency_code => USD value => HIDDEN final_capture => 1 seller_protection => status => ELIGIBLE dispute_categories => 0 => ITEM_NOT_RECEIVED 1 => UNAUTHORIZED_TRANSACTION seller_receivable_breakdown => gross_amount => currency_code => USD value => HIDDEN paypal_fee => currency_code => USD value => HIDDEN net_amount => currency_code => USD value => HIDDEN invoice_id => HIDDEN status => COMPLETED create_time => 2021-03-05T00:23:26Z update_time => 2021-03-06T00:23:32Z links => 0 => href => https://api.paypal.com/v2/payments/captures/HIDDEN rel => self method => GET 1 => href => https://api.paypal.com/v2/payments/captures/HIDDEN/refund rel => refund method => POST 2 => href => https://api.paypal.com/v2/checkout/orders/HIDDEN rel => up method => GET links => 0 => href => https://api.paypal.com/v1/notifications/webhooks-events/WH-HIDDEN-HIDDEN rel => self method => GET 1 => href => https://api.paypal.com/v1/notifications/webhooks-events/WH-HIDDEN-HIDDEN/resend rel => resend method => POST
  4. Alright. "Fixed" it. Here's the secret sauce: visit paypal.com and delete all cookies after each try. That improves linking odds from 1 in 100 to 100 in 100. It did not guarantee the webhook creation, but made retrying a lot less frustrating and after a few retries the webhook was properly created. Still wish WHMCS would just allow for us to enter all this stuff manually and document how to do so. Dealing with this, even if it's PayPal's fault, is a waste of time.
  5. I decided to unlink and re-link PayPal to see if that would create the missing webhook. But it doesn't. All it does is create a PayPal nightmare because 99 out of a 100 times the linking procedure just opens the PayPal Dashboard and PayPal starts throwing captcha's at you when you login in that many times. I then decided to manually create a webhook and point it at the paypalwebhooks.php file. This gets the webhooks going, but of course WHMCS rejects the signature. Somewhere in WHMCS I need to store the Webhook ID, but I cannot figure out where to do this. Rather frustratingly (sadistically?) WHMCS shows various fields when configure the PayPal Checkout module, but they're all read-only and the one for a Webhook ID is missing entirely. Any ideas where to store this?
  6. I have the same issue, using WHMCS 8.10 and PayPal Checkout. In https://developer.paypal.com/developer/dashboard/webhooks/live there are no webhooks listed for the WHMCS app. But in the old IPN history I do see PayPal posting the PayPal Checkout payments to the URL I configured for IPN's - exactly like @Liam. Either the WHMCS PayPal Checkout module is not properly passing the relevant webhook, or PayPal decides that the IPN overrules any such webhook. There are no errors in any of the logs. Everything looks fine. It's just that PayPal uses an IPN instead of a webhook for some reason. @Liam, did you end up solving this one?
  7. Looks like MyWorks went all-in on shopping platforms and ditched WHMCS. Probably a good choice for them business-wise, but would've appreciated a simple heads-up e-mail. Guess it's back to classic PayPal for now.
  8. Had the same issue when using MyWorks PayPal Billing Agreements. It only happens for certain customers, and deleting their stored PayPal card info always resolves it.
  9. When I create a child theme, consisting only of theme.yaml and no other files, the Stripe gateway settings complain that Required Template Changes are Not Found. My theme.yaml contains only this for now: name: "My Website" author: "Me" config: parent: twenty-one Of course I want to make more changes to my theme than just create a theme.yaml, but it's unclear why Stripe breaks at this point already or how I should fix it. It is my understanding that WHMCS will look at the parent theme for all files not present in the child theme. And when I play with the theme itself, it does indeed work that way. But the Stripe settings don't seem to pick up on this? EDIT: the cart theme is standard_cart, unmodified.
  10. Looks like their website is back. And my paypal billing module works again. Worrying that the module de-activates so quickly though. I assumed there would a longer period where it retries to contact their website before invalidating the license.
  11. MyWorks' various websites seem to be down and their paypal billing module is failing for me as it cannot verify the license. Are they gone for good? or am I just unlucky to run into this during a temporary outage?
  12. Did you (or anyone else reading this) ever figure out how to do this? WHMCS continues to create renewal invoices, even with the "skip --CreateInvoices" parameters. In my crontab: */5 * * * * php7.3 -q /home/www/myanuson/crons/cron.php skip --CreateInvoices
  13. We run 7.9.2 as of yesterday. The last duplicates that I've found occured while using 7.9.1 and 7.9.0.
  14. Problem: When using the Sequential Paid Invoice Numbering feature WHMCS will assign an invoicenum (in addition to the id) when an invoice gets paid. It appears that, when WHMCS receives a lot of transactions at the same time, it will happily assign the same invoicenum two, three or more times. This is not a good thing, for obvious reasons. As WHMCS shows id, not invoicenum, in most places it's easy to go unnoticed. If you're not processing a lot of transactions in batches, the occurrence may be very rare too. The database schema does not enforce uniqueness on the invoicenum column and WHMCS doesn't seem to do any double-checking after it inserts the record either. Solution? Any suggestions how to resolve this? I've considered changing the database schema to require invoicenum to be unique. But this might cause WHMCS to simply throw an error. And it's difficult to test what will happen as I can't reliable reproduce the problem. Related: I found this old thread with a similar problem: Which in turn also links to this issue: But neither have a satisfactory resolution. For all intents and purposes the feature is currently not usable and may get those that are not aware of the issue in trouble with their accountant or worse.
  15. Did you find any solution? Do you have this with all customers? We're having the same issue, but only for some customers. There's no discernible difference between the customers that fail and those that succeed. (No old tokens or payment methods, no theme changes, etc.)
×
×
  • 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