Jump to content

Tom Catchesides

Senior Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Tom Catchesides

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. For transactions made by customers via our shopping cart, the statement descriptor is being set to "{StripeStatementDescriptorPrefix} SHOPPING CART". No invoice number, but we can at least identify ourselves.
  2. The problem that I reported in the original post was fixed by 7.8.3: WHMCS is now setting the Stripe statement descriptor correctly.
  3. I've seen this same "invalid positive integer" error when attempting to check out a zero-value shopping cart, which is something that clients sometimes need to do if we give them a 100% discount code. In that case, it looks like WHMCS is mistakenly trying to use Stripe to collect a zero-value payment when in reality no payment is required.
  4. It's very disappointing to hear that it might be another 10 days until this bug is fixed, because that will mean that this problem is still affecting us three weeks after I first reported it. Upgrading to WHMCS 7.8 has been a frustrating and disappointing experience. My company felt forced into the upgrade because of the need for SCA compliance, but a number of frustrating Stripe-related bugs made it into the release. This particular bug is especially frustrating because it's something that directly affects our customers.
  5. I totally agree: I feel like my company has been forced into doing this update way before it's ready, and we're suffering from a couple of Stripe-related bugs that are hurting our customer relationships.
  6. FYI, WHMCS have acknowledged the problem via my support ticket and say that they're working on a fix. Case number MODULE-7114 .
  7. The description in Stripe is fine for us. It's the statement descriptor that's a serious problem. I've attached screenshots of what I see in our Stripe dashboard for a charge made this week compared to one made last month with WHMCS 7.6.
  8. I submitted a support ticket about this a couple of hours ago but am hoping that someone might be able to answer this more quickly here. We upgraded to WHMCS 7.8.2 at the weekend to ensure compliance with SCA via WHMCS's own Stripe gateway. Since then, the statement descriptors on our customers' bank statements read "FALSE" for regular subscription payments. I'm obviously concerned that this is going to lead to unnecessary chargebacks. We haven't changed any settings at the Stripe end and have a default statement descriptor set on there. In WHMCS, the statement descriptor is set to "{CompanyName}" and our company name field is set. Has anyone else seen this problem with WHMCS 7.8 and Stripe? Does anyone have any ideas for workarounds?
  9. We've occasionally seen "Remote Transaction Failure. Please Contact Support" errors from Stripe when customers have tried to add a new card. We've always been able to fix these errors by: 1) Checking their payment method setting (i.e. checking the tblclients.defaultgateway is set to "stripe"). 2) Clearing any existing card details and the tblclients.gatewayid field. However, I'm currently failing to work out why I'm seeing this error when I'm trying to add my own card details to a new, dummy customer record for testing purposes. I'm using the 'credit card information' link in the Blend admin interface, so that rules out any shopping cart template customisations interfering with this. We don't have a /includes/hooks/stripe.php file. Stripe is our default payment gateway. All I see in the WHMCS gateway log is: UserID => 10244 (screenshot attached, no other information about the attempt apart from the result being "Remote Storage" rather than "Remote Storage Success") At Stripe's end, their logs for the attempt look identical to those for customers who have successfully added card details. Does anyone have any ideas as to why this might be failing for my test customer record?
  10. It seems to be random for our installation. Some days we get no notifications, others it’s more like 20 over the course of a day. I had wondered whether it could have anything to do with other uses for the relevant email account (e.g maximum number of logins over a certain period) but we sometimes get notifications overnight when that’s much less likely.
  11. Thanks, John! I might have misunderstood your reply but I turned off the 'Display Errors' option in Setup > General Settings > Other tab, but I'm still receiving "POP3 Connection Error" emails from WHMCS 7.6.0. To be clear, our POP3 email import works well the vast majority of the time, but these notification emails reveal that it intermittently fails. I agree that being notified if support email import has catastrophically failed is a very good thing, but if it fails 1% of the time then that's really not a big deal for us.
  12. We upgraded to WHMCS 7.6.0 yesterday and have received about eight of these "POP3 connection error" emails since then. This didn't happen before the upgrade. Our email import cron job is working well most of the time, and if just one or two import runs fail then that's not too big a deal. If WHMCS thinks it needs to notify us when there's a problem fetching emails, perhaps it could be configured so that it will only do so if the last X imports have failed?
  13. Welcome to WHMCS.Community Tom Catchesides! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.

  • 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