Jump to content

Stripe Problems After Upgrade


Recommended Posts

#1 I did open a ticket about this, thanks for the help but no solution has been made, our Stripe mod is offline still

After the upgrade last week, I noticed slow response from WHMCS which is installed on a server running WHM/cPanel and has about 20 other sites that all ran normal, even the main website WHMCS is on ran fine, only the WHMCS folder and anything in it was slow response and started coming up as a gateway error.

Checked the Apache logs and noticed  there were 300 requests and most all were for POST  /index.php ?rp=/stripe/payment/indent HTTP/1.1

 Checked Stripe.com dashboard and there were thousands of attempted charges , each minute new were coming in.  (see attached)  - has been going on for several hours at this point

 No clients are being created, Google captcha has been enabled for years, there is a option in WHMCS settings to  prevent clients from ordering without creating an account settings/other - UNCHECKED  (Tick this box to allow registration without ordering any products/services)  

- Notice in the screenshot the hacker is using different email addresses, none are anywhere in WHMCS

As soon as I figured out the new Stripe mod in WHMCS was causing this I changed the file module/gateway/Stripe to module/gateway/Stripe_1 the problem immediately stopped and hasn't happened since. I change it back to allow for cron run each day for a few minutes but something is wrong so have to keep it offline for now till solution is found

That Stripe mod caused this, there were over 8,000 attempts in 1 week alone, I sent all this to WHMCS and they still claim it's not their fault. Have had that Stripe  mod for 10+ years with no issues, then just after the update where WHMCS made several changes to the Stripe mod (all noted in their update log -- so some hacker must have spotted a hole and took advantage of it)

Didn't loose any money or anything , all the IP addresses came back to Russia. Stripe did send me a email but again none of the charges actually went through and Stripe does have security, they are the ones that blocked it. 

WHMCS says that since the CC charge didn't complete then by design, no order or customer is created in WHMCS. 

Is this WHMCS responsibility or do we have to set up a firewall as suggested? Is anyone else noticing anything? 

 

 

 

 

Screenshot 2021-07-29 065933.jpg

Screenshot 2021-07-29 071908.jpg

Edited by myautodj
Link to comment
Share on other sites

Yes, the Stripe mod  that comes with WHMCS,  --  When the server started to not respond, I went though it was cache related at first so I went to systemcleanup.php and cleared all the logs, I had no idea it was Stripe at this point. 

Then I looked at the Apache log (see attached below) and matched the IP address / timestamps with the ones the stripe log. 

 

 

 

 

  

 

Screenshot 2021-07-29 153537.jpg

Link to comment
Share on other sites

Lot of issues with stripe, has been for a few updates for some unfortunately! 

Regardless of what whmcs are telling you, search "stripe" on here and you'll see complaint after complaint... with no real desire to own the fact that its a mess! 

Yeah, I agree seeing the output would be interesting if you can! It's a drop in the ocean though! You're not alone 

Link to comment
Share on other sites

  • 2 weeks later...
  • WHMCS Support Manager

Hi @myautodj,

It sounds like the issue you're experiencing here is card testing, and in essence a small DDoS attack against your website.

 

Due to the way Stripe works, there will be some network traffic generated as the remotely hosted Stripe credit card fields are loaded into the checkout page and upon submission.

The visitor submits the order, which triggers the creation of the uncaptured PaymentIntent, which is blocked by rules configured within Stripe, under the Radar section.

Stripe communicates the failure to WHMCS and the visitor will see the error of "Your card was declined" within the checkout in a red banner.

No order will be created within WHMCS as they never managed to successfully checkout.

This leaves the uncaptured payment intent in your Stripe account, which will automatically be released in 7 days. To quote Stripe's documentation:

Quote

Card statements from issuers often do not distinguish between authorizations and captured (settled) payments, which can sometimes confuse customers.

If the visitor were to fail recaptcha or fraud checks on the WHMCS order form, then the payment intent is cancelled.

The one disadvantage of the Stripe.js v3 with Elements integration method we use, is that there are limitations to the response handling for radar rule failures, so PaymentIntents cannot be cancelled. However overall the more seamless integration these API facilitate is worth-while in our opinion. The alternative would be the hosted forms solutions like the Checkout API, which redirects visitors away from your website to complete payment.

 

The best way to harden your systems against this situation is the same as DDoS attacks; by blocking visitors submitting suspicious levels of requests  in a short space of time. Cloudflare or other such Web Application firewalls are very effective at defending against exactly this situation.

EDIT: I located your ticket in our system, and I see that our support team confirmed the above.

Link to comment
Share on other sites

  • 8 months later...
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • 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