Resolved 7.9.0 Stripe "Uncaptured" Payments

[leemahoney3]

On 10/31/2023 at 9:00 AM, Vox said:

Hi Guys,

Updating this thread as WHMCS have confirmed the above post regarding the change of IP address. If the clients IP address changes during the payment process it will not complete.

This means that any customers using services such as "iCloud Private Relay" may be prone to payment failures.

I guess that makes sense 😶

[HostXNow]

I notice the same issue Its been happening for several months..

One existing client seems to trigger it whenever he registers a new domain. Today, he was charged 4x. One goes through, and three others show as Uncaptured. It happened for months after a WHMCS update, but I'm unsure what update caused the problem.

Captcha Form Protection is set to off when logged in. So we can rule out Captcha.  Still, it is set to

reCAPTCHA v2 (Google's reCAPTCHA system)

Captcha for Select Forms is not selected for

Shopping Cart Checkout

Domain Checker

Login Forms

 

only enabled for

Client Registration

Contact Form

Login Forms

Disable Session IP Check is enabled, so that not causing issue either.

 

 

 

 

[sahostking]

I have always had "Disable Session IP Check" = enabled

So dont think its that.

[HostXNow]

On 12/15/2023 at 5:30 PM, sahostking said:

I have always had "Disable Session IP Check" = enabled

So dont think its that.

It isn't anything to do with the mentioned settings. I've tried lots of different options. It's an issue with WHMCS/Stripe itself.

[bear]

15 minutes ago, HostXNow said:

It's an issue with WHMCS/Stripe itself.

I'd agree, based on it falling over with the updated files to fix a flaw causing it, and the updated file provided again fixing it. That  implies they know what causes it, perhaps....or the updated file that fixed it was simply the pre-exploit file unchanged. 😉

[niels]

Does WHMCS recommend a specific Stripe API version?

I noticed that my business using API 2020-08-27 suffers the issue most. Two other businesses using 2019-08-14 and 2023-10-16 very rarely have the issue. It's hard to exclude other factors though. Guess I'll bump the failing WHMCS to API version 2023-10-16.

[ratandalez]

We started having a lot of uncaptured payments. All the uncaptured payments appeared twice in the Stripe Dashboard.

[HostXNow]

On 12/19/2023 at 3:52 PM, bear said:

I'd agree, based on it falling over with the updated files to fix a flaw causing it, and the updated file provided again fixing it. That  implies they know what causes it, perhaps....or the updated file that fixed it was simply the pre-exploit file unchanged. 😉

 I tried many different things and even did test orders using the default Twenty-One theme and still got Uncaptured payments.

I use a single-page checkout for the theme, and it was that causing the issue.  I'm still using the same theme but selected the option to use the regular checkout steps that WHMCS uses and no more Uncaptured payments for days.

So, in this case, it looks to be an issue with the theme, and I'll let the developer know about the issue, which affects the single-checkout page only.

I'll use the regular checkout pages, which still look good on the theme. It does seem that WHMCS changed something at some point, which has affected a lot of custom themes, and developers did not know about it.

Anyway, hopefully, resolved now.

[zomex]

2 minutes ago, HostXNow said:

 I tried many different things and even did test orders using the default Twenty-One theme and still got Uncaptured payments.

I use a single-page checkout for the theme, and it was that causing the issue.  I'm still using the same theme but selected the option to use the regular checkout steps that WHMCS uses and no more Uncaptured payments for days.

So, in this case, it looks to be an issue with the theme, and I'll let the developer know about the issue, which affects the single-checkout page only.

I'll use the regular checkout pages, which still look good on the theme. It does seem that WHMCS changed something at some point, which has affected a lot of custom themes, and developers did not know about it.

Anyway, hopefully, resolved now.

Hopefully you have got it sorted.

With that said I have always used the recommended Standard WHMCS cart and had the same uncaptured payments.

[Stormster]

Dealing with this exact issue still, Croster theme.
Test and live stripe, both result in Uncaptured. Customer gets sent to the invoice being required to pay (again), once they pay it there, it works.

See this error in Stripe in API Logs. Secret key is provided, I've reset / regenerated it multiple times as well.
 

{

 

"error": {

 

"code": "secret_key_required",

 

"doc_url": "https://stripe.com/docs/error-codes/secret-key-required",

 

"message": "This API call cannot be made with a publishable API key. Please use a secret API key. You can find a list of your API keys at https://dashboard.stripe.com/account/apikeys.",

 

"request_log_url": "https://dashboard.stripe.com/test/logs/req_viiblah blah blah",

 

"type": "invalid_request_error"

 

}

 

}

[HostXNow]

23 hours ago, HostXNow said:

Anyway, hopefully, resolved now.

Hopefully! Fingers crossed.

[HostXNow]

21 hours ago, Stormster said:

Dealing with this exact issue still, Croster theme.
Test and live stripe, both result in Uncaptured. Customer gets sent to the invoice being required to pay (again), once they pay it there, it works.

See this error in Stripe in API Logs. Secret key is provided, I've reset / regenerated it multiple times as well.
 

{

 

"error": {

 

"code": "secret_key_required",

 

"doc_url": "https://stripe.com/docs/error-codes/secret-key-required",

 

"message": "This API call cannot be made with a publishable API key. Please use a secret API key. You can find a list of your API keys at https://dashboard.stripe.com/account/apikeys.",

 

"request_log_url": "https://dashboard.stripe.com/test/logs/req_viiblah blah blah",

 

"type": "invalid_request_error"

 

}

 

}

I'm using the Croster theme too. It was doing it when using single-checkout. As soon as I disabled that, the Uncaptured payments stopped happening. It's been fine for several days now.

 

I guess they need to fix the single checkout page for Croster. Maybe they can have it fixed for the next version of WHMCS 8.9, which will be released soon to also update PayPal payments.

[wsa]

It is not only Croster I have a friend who uses Twenty-one and has the same problem. He talked to Stripe they told them something to do with the module to contact whmcs.com

[zomex]

Got the same error again today. New client, uncaptured payment using Stripe.

[wsa]

Hi,

I talked to Stripe also they all told me to contact whmcs.com for something with the API that is used.

[Fabskf]

This also happens to me. Do you know if it improved in version 8.9? I haven't updated yet.

[HostXNow]

I had not seen any uncaptured payments since March but it did it again today.

[mikeos]

This happens randomly for me too. It could go 2 weeks without any issue, then happen again. I reached out to Stripe, and they said it's an issue with WHMCS.

Honestly surprising, there is no fix or acknowledgment from the WHMCS team about this.

I've tried to:

• Disable Captcha for Select Forms
• Disable CSRF
• Turn off Disable Session IP Check
• Double-checked Cloudflare proxies
• Disabled CAPTCHA
• Tried a different Stripe account

[mikeos]

Did some more testing again after the above. Everything was done on the same day.

• Stock theme
• NO hooks
• Removed Cloudflare totally
• Upgraded our VPS (Digital Ocean - When we very first had the issue it was on shared hosting so we assumed it was getting overloaded, so it's been different technology stacks now)

It was perfectly fine until the 27th of July rolled around, and then it's been around 2 or 3 orders that need to be processed manually per day due to payments being uncaptured. Again. No changes.

 

@WHMCS John you guys need to do something about this. There are pages on multiple forums of people with issues. You can't just keep playing the blame game of "It's because you're running a theme". We can't have someone sitting there baby sitting payments because something is broken in WHMCS. 

 

From my other thread about Stripe, it's clear there are some issues with the stock Stripe module and an audit needs to be done.

 

[sahostking]

really not sure what to do anymore. We never had this for a year but it started creeping up the last month or 2.

Weird example.

 

Looks like customers are trying twice to get payment through. Its so random which is strange. Here it shows south african rands.

We use Lagom Theme though but we always have any never had this before. This is definitely some recent change in last update or 2 that has now caused this.

[zomex]

Still having major issues with this.

My system only uses 1 3rd party module which is FraudRecord. I have a custom template which is a child theme of Twenty One. Everything else is stock latest version of WHMCS with no warnings under system health.

Over the last month I've had 3 situations where there is a uncaptured payment in Stripe and absolutely no record of the order in WHMCS. I'm now having to manually create the order, capture the payment and apply the payment manually to the invoice. With has happened with and without the client account being created.

It's rare but 3 times in a month is something that needs to be addressed. With 50k+ views on this thread I am shocked that WHMCS still believes this is a non-issue. No issues with PayPal, only Stripe.

Edited February 9 by zomex

[niels]

After A/B testing with a different payment solution I can tell you that it is absolutely a WHMCS issue. Long story short: we moved card payments to a different billing system. Even with the added cost is still saves us money.

[wsa]

Hi,

Yes is a whmcs issue I talked to Stripe they told me something to do with the whmcs module I got 2 last night.

[russkulas]

On 2/9/2025 at 6:33 PM, zomex said:

Still having major issues with this.

My system only uses 1 3rd party module which is FraudRecord. I have a custom template which is a child theme of Twenty One. Everything else is stock latest version of WHMCS with no warnings under system health.

Over the last month I've had 3 situations where there is a uncaptured payment in Stripe and absolutely no record of the order in WHMCS. I'm now having to manually create the order, capture the payment and apply the payment manually to the invoice. With has happened with and without the client account being created.

It's rare but 3 times in a month is something that needs to be addressed. With 50k+ views on this thread I am shocked that WHMCS still believes this is a non-issue. No issues with PayPal, only Stripe.

We are facing some problem like you it will not solve  yet if you get any good answer please tell us we are health care services provider, we need to solve this as soon as possible 

[MikePitta]

Same here. 2 in 1 one month. I opened a ticket with whmcs and they answered:

The code on the WHMCS page will always attempt to make a capture against the Stripe Payment intent and then record the order details in the WHMCS database.
If the payment capture doesn't happen it indicates something about the visitor's browser session has prevented that code from running in their browser; it could be a template issue or a restriction/plugin in the visitor's browser stopping Stripe's javascript from being executed correctly, or if the visitor navigated away/closed their browser after submitting the order.

In my case the new clients were able to clic "pay now" and stripe started the payment process, leaving it pending and waiting for my authorisation: I had a record in stripe and nothing in whmcs. I was able to accept the payment, but I had nothing to activate in whmcs. 

 Whmcs is designed, as far as I understand, to create records only after the payment is authorised, and has no way to create the invoice, and therefore both the client account and the order, before the payment succedes. 

If this picture is correct, whmcs definitely has room for improvement. 

Edited March 14 by MikePitta