MikePitta Posted March 15 Share Posted March 15 I thought that whatever is the issue related to this behaviour, a solution could be a hook that creates a txt file containing client and order details each time the "complete order" button is pressed: it would then be easy to recreate the client account and order whenever we find an "uncaptured" payment in stripe for a new order. Anyone would like to try? 0 Quote Link to comment Share on other sites More sharing options...
mikeos Posted March 18 Share Posted March 18 On 2/19/2025 at 10:46 PM, wsa said: 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. Try placing an order without a state specified, as I discovered this. They auth a payment before any validation takes place (totally brain-dead that they don't validate the form itself). In typical WHMCS tone deaf fashion, they're ignoring the issue. 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted March 19 Share Posted March 19 (edited) Another day another ignored WHMCS bug as this thread surpasses 60k views. Today I had a client create an order, pay via PayPal. No client account created, no order created in WHMCS. No payment received to PayPal. Client sees the transaction in PayPal which disappears within a couple of hours. Very bad look as a user of WHMCS who has seen constant price rises for software that supposedly is all about automation and ease of use. This is 100% a WHMCS bug as I've seen the exact same with Stripe. Other times the client account is created, the order created but the payment is "uncaptured" No point submitting a ticket as WHMCS refuse to accept this is an issue with their software. I now use almost stock WHMCS. Just Fraud Record in terms of modules and I have a very simple child theme of twenty one. Edited March 19 by zomex 1 Quote Link to comment Share on other sites More sharing options...
MikePitta Posted March 20 Share Posted March 20 (edited) I insist with my idea: track any "attempted" submission with a hook, for mainly 2 reasons: 1. The misbehaviour could be caused by other hooks or plugins, and in that case whmcs team should check every single case (not convenient) 2. The misbehaviour might depend on customers who close the page too soon or stripe being unable to immediately capture the payment. In any case, all the data is available once "submit order" is clicked and, while I wouldn't like to find a new order for each attempted and failed order payment, I would find useful to have it in a txt file or a db table under, for example "missed orders". It might populate quite quickly with a lot of useless orders, but at least we would, somewhere, find the details we need to recreate client account and order unintentially missed. Edited March 20 by MikePitta 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted March 20 Share Posted March 20 16 hours ago, zomex said: Another day another ignored WHMCS bug as this thread surpasses 60k views. Today I had a client create an order, pay via PayPal. No client account created, no order created in WHMCS. No payment received to PayPal. Client sees the transaction in PayPal which disappears within a couple of hours. Very bad look as a user of WHMCS who has seen constant price rises for software that supposedly is all about automation and ease of use. This is 100% a WHMCS bug as I've seen the exact same with Stripe. Other times the client account is created, the order created but the payment is "uncaptured" No point submitting a ticket as WHMCS refuse to accept this is an issue with their software. I now use almost stock WHMCS. Just Fraud Record in terms of modules and I have a very simple child theme of twenty one. That is true. I talked to both vendors, and they told me to contact WHMCS.com 1 Quote Link to comment Share on other sites More sharing options...
MikePitta Posted March 28 Share Posted March 28 (edited) I've added my idea in the "ideas" section. Vote it please: if accepted it would add a way to keep record of lost orders https://requests.whmcs.com/idea/keep-record-of-unpaid-new-orders-from-new-clients-after-complete-order-is-clicked Edited March 28 by MikePitta 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted March 28 Share Posted March 28 8 hours ago, MikePitta said: I've added my idea in the "ideas" section. Vote it please: if accepted it would add a way to keep record of lost orders https://requests.whmcs.com/idea/keep-record-of-unpaid-new-orders-from-new-clients-after-complete-order-is-clicked Don't want to be a glass half empty kind of guy but WHMCS do not care. This has been a issue since 2019, 54k views on this thread. The only thing they want to do is bless us with more Marketconnect junk that no one wants. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted April 18 Share Posted April 18 Does anybody get this same error? One of my staff members chatted with Stripe today, and this is what I got Chat started: 2025-04-08 15:26:09 UTC (03:35:29 PM) Ashley: Hi WHMCSServices, this is Ashley from Stripe support. Hope you're doing great today. (03:35:32 PM) WHMCSServices: I see that you charged me extra money and then refunded it to the client. (03:35:35 PM) Ashley: I'm sorry you've had to deal with this. (03:36:03 PM) WHMCSServices: np (03:36:25 PM) Ashley: I completely understand how important to determine what happened on the refund, and I’m here to make sure we find the right solution. (03:37:14 PM) WHMCSServices: I see it do this to all clients (03:37:31 PM) WHMCSServices: u charge me extra for each client (03:37:40 PM) WHMCSServices: $19.99 was captured, and the remaining $0.91 was released to the customer (03:37:44 PM) Ashley: I can definitely understand the confusion here! This charge wasn't actually refunded, rather it was an authorization that was never captured. (03:38:09 PM) Ashley: Only $19.99 USD was collected from your customer. (03:38:21 PM) WHMCSServices: no (03:38:23 PM) Ashley: Instead of the supposed $20.90 USD. (03:38:29 PM) WHMCSServices: I see 20.99 (03:38:52 PM) WHMCSServices: https://dashboard.stripe.com/payments/pi893RBMSNBCFj2pk6Yn1y7kJJAS (03:39:29 PM) Ashley: The payment requested was initially $20.90 USD. However, the payment collected and captured is only $19.99 USD. (03:41:04 PM) Ashley: The amount_to_capture was set to $19.99 USD, as you can see on the logs here: https://dashboard.stripe.com/logs/req_jh8EarvGO4YQbVDpC (03:41:52 PM) Ashley: The value for the amount_to_capture came from your end. It would be great if you can reach out to your developers on why they sent a request to capture only $19.99 USD instead of $20.90 USD. (03:42:39 PM) WHMCSServices: It is supposed to be 19.99 (03:42:46 PM) WHMCSServices: That's how much I charge (03:43:33 PM) WHMCSServices: https://dashboard.stripe.com/payments/pi893RBKuXBCFj2pk6Yn01iKyUi5 (03:43:46 PM) WHMCSServices: I charged the client 19.99 (03:44:36 PM) Ashley: I really do apologise for the confusion this has caused. However, this is something that you'll need to sort out with your developers. (03:44:49 PM) Ashley: They were the ones who specified the amount to be collected. (03:46:14 PM) WHMCSServices: Can you email me this chat (03:46:20 PM) Ashley: Absolutely. (03:46:30 PM) WHMCSServices: I can forward to whmcs.com (03:46:30 PM) Ashley: I understand this may not be the response you may have hoped for, but please let me know if you have any more questions. (03:46:51 PM) WHMCSServices: That means you tell that whmcs module is doing this? (03:47:04 PM) Ashley: That's correct. (03:47:08 PM) WHMCSServices: I am using the WHMCS Stripe module (03:47:29 PM) WHMCSServices: I see this happened to all clients (03:47:34 PM) WHMCSServices: It charges extra (03:47:44 PM) Ashley: Please contact whmcs.com (03:48:07 PM) Ashley: You can also show them this log on their request post to capture only $19.99 USD: https://dashboard.stripe.com/logs/reqjhK63CFERGxr46gc (03:50:15 PM) Ashley: In the meantime, is there anything else that I may help you with today? (03:53:34 PM) Ashley: Alright. (03:53:39 PM) Ashley: It was great chatting with you! I will be sending you an email after we end this chat. If any other questions and concerns arise, simply reply to my email, and I will be more than happy to assist you. (03:53:42 PM) Ashley: Once again, my name is Ashley, and thanks for contacting Stripe Support. Have an excellent day ahead! 0 Quote Link to comment Share on other sites More sharing options...
Easy Green Hosting Posted June 24 Share Posted June 24 (edited) Hi. Same problem here. Last one was a few days ago: - a client entered an order - clicked to pay via stripe - failed to use its first card and re-attempted the payment - the second payment was confirmed on his side, but uncaptured in Stripe - whmcs just cleared all the data and did not register anything. We had to contact the customer, confirm his payment manually and re-create both client account and order in whmcs. This is just a bug! Why WHMCS does not register the order when the payment is confirmed on the client side and pending in our side?? Consider that NONE of us in this case (client and us) receive any communication via email: if the client does not contact us and we do not check stripe for uncaptured payments, we can't know that there was a new order. One of the first doubts a client can have after seeing a "paid" message from our website and his money blocked, and does not receive any confirmation whatsoever, is that we are a fraud. This is a very important thing to fix Edited June 24 by Easy Green Hosting 0 Quote Link to comment Share on other sites More sharing options...
Son123231 Posted October 24 Share Posted October 24 It's been 2025 since this error happened from 2019 now even though we use the latest update from whmcs the error still happens randomly my clients have people spamming the card i mean they retry continuously and after 1 night i see a bunch of invoices in uncapture status we refunded immediately but that can't restore our reputation What whmcs need to do is just change their module from "manual" capute to "automatic" this is what stripe mentioned last time i asked stripe support they told us there are few cases like that they are handling related to stripe whmcs module 0 Quote Link to comment Share on other sites More sharing options...
Administrators WHMCS John Posted November 3 Administrators Share Posted November 3 @wsa, This is intentional behaviour and unrelated to the uncaptured payments discussed in this thread. For your information, the system sets up a PaymentIntent at Stripe when the checkout page is loaded. This must specify the maximum possible amount the card could be charged for the cart contents (before credits and taxes are applied). So the SetupIntent request could be greater than the final amount actually captured in the end. After the client selects their country + state and decides whether to use credit towards the payment, the system knows the final total and this then gives the final amount the client pays and what is captured. On 4/18/2025 at 11:09 PM, wsa said: (03:37:40 PM) WHMCSServices: $19.99 was captured, and the remaining $0.91 was released to the customer (03:37:44 PM) Ashley: I can definitely understand the confusion here! This charge wasn't actually refunded, rather it was an authorization that was never captured. (03:38:09 PM) Ashley: Only $19.99 USD was collected from your customer. In this case the client might have briefly seen a pre-auth for $20.90 on their online banking, but the actual amount charged matches exactly with the records in the system. Hi @Son123231, Possible causes for this behaviour could be: - The client abandoning checkout before submitting the order successfully (ie. At the 3D Secure stage). - A customisation affecting the in-browser processing of Stripe.js, such as a theme or javascript modification. If you are still encountering the issue with after-market modules and hooks removed on the stock Theme (Twenty-One) and Order Form Template (Standard Cart), please open a support ticket so we can investigate the specific issue on your instance. On 10/24/2025 at 4:14 PM, Son123231 said: What whmcs need to do is just change their module from "manual" capute to "automatic" this is what stripe mentioned last time i asked stripe support they told us there are few cases like that they are handling related to stripe whmcs module This is inappropriate and unhelpful advice on their part. Stripe provides this API functionality for the precise purpose of inserting bespoke business logic before charging a client's card. In this case WHMCS uses the manual capture_method option to perform fraud checks and custom code at corresponding hook points; important functionality I'm sure we all agree. 0 Quote Link to comment Share on other sites More sharing options...
mikeos Posted November 3 Share Posted November 3 8 hours ago, WHMCS John said: @wsa, This is intentional behaviour and unrelated to the uncaptured payments discussed in this thread. For your information, the system sets up a PaymentIntent at Stripe when the checkout page is loaded. This must specify the maximum possible amount the card could be charged for the cart contents (before credits and taxes are applied). So the SetupIntent request could be greater than the final amount actually captured in the end. After the client selects their country + state and decides whether to use credit towards the payment, the system knows the final total and this then gives the final amount the client pays and what is captured. In this case the client might have briefly seen a pre-auth for $20.90 on their online banking, but the actual amount charged matches exactly with the records in the system. Hi @Son123231, Possible causes for this behaviour could be: - The client abandoning checkout before submitting the order successfully (ie. At the 3D Secure stage). - A customisation affecting the in-browser processing of Stripe.js, such as a theme or javascript modification. If you are still encountering the issue with after-market modules and hooks removed on the stock Theme (Twenty-One) and Order Form Template (Standard Cart), please open a support ticket so we can investigate the specific issue on your instance. This is inappropriate and unhelpful advice on their part. Stripe provides this API functionality for the precise purpose of inserting bespoke business logic before charging a client's card. In this case WHMCS uses the manual capture_method option to perform fraud checks and custom code at corresponding hook points; important functionality I'm sure we all agree. What's mental here is you have the solution, and that is to validate the checkout fields before processing any kind of request to the payment provider, but you ignore it and continue to let it be an issue. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted Monday at 01:54 PM Share Posted Monday at 01:54 PM John, All I can tell you that Stripe.com kept telling me to contact your people, the issues with the module. 0 Quote Link to comment Share on other sites More sharing options...
Administrators WHMCS John Posted Tuesday at 08:22 AM Administrators Share Posted Tuesday at 08:22 AM On 11/3/2025 at 8:52 AM, mikeos said: validate the checkout fields before processing any kind of request to the payment provider Our UI research shows that users unequivocally want the payment fields on the checkout page, as opposed to a separate step after validating the checkout or completing fraud checks. As a result we must load the Stripe payment fields on checkout page load. 19 hours ago, wsa said: All I can tell you that Stripe.com kept telling me to contact your people, the issues with the module. Can you hep me understand the issue here for you? The client's card was pre-authorised for an extra dollar, but the final amount they are charged is exactly $19.99 as expected. 0 Quote Link to comment Share on other sites More sharing options...
Easy Green Hosting Posted Tuesday at 10:40 AM Share Posted Tuesday at 10:40 AM Hi. Thank WHMCS John for your explanations. Wouldn't a log of all the attempted orders be a solution? The issue here happens when the payment button is triggered and the website interrogates stripe: when the transaction doesn't work under certain circumstances the whole order process is lost in whmcs, is that correct? What I am suggesting is to add a way to record anything (client and order details) that happens during the process order, even as only a text log file, also when there is no payment attempt at all. This way we would at least have something to look up. What do you think? thanks again 0 Quote Link to comment Share on other sites More sharing options...
mikeos Posted Thursday at 01:15 AM Share Posted Thursday at 01:15 AM On 11/4/2025 at 4:22 PM, WHMCS John said: Our UI research shows that users unequivocally want the payment fields on the checkout page, as opposed to a separate step after validating the checkout or completing fraud checks. As a result we must load the Stripe payment fields on checkout page load. I'm sorry, but what are you talking about? What I'm saying is you can check if the fields are even filled out prior to initiating any payment pre-auth. It has nothing to do with stripe being on the same page of not. This is a code issue, as it's not just stripe that is affected here. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.