DennisHermannsen Posted May 5, 2020 Share Posted May 5, 2020 We're also seeing this. WHMCS sees the invoice as paid, but the transaction hasn't been captured in Stripe. Would be nice if WHMCS would share some words about this. 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted May 12, 2020 Share Posted May 12, 2020 We really need a update on this WHMCS. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted May 12, 2020 Share Posted May 12, 2020 Yes because it kept doing this 0 Quote Link to comment Share on other sites More sharing options...
hkhost Posted May 15, 2020 Author Share Posted May 15, 2020 On 4/28/2020 at 8:45 PM, zomex said: It happens very rarely about 1 out of every 30. @zomex Any idea under what conditions does this happens? Maybe @WHMCS John can check further? 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted May 15, 2020 Share Posted May 15, 2020 11 hours ago, hkhost said: @zomex Any idea under what conditions does this happens? Maybe @WHMCS John can check further? I haven't seen any trends yet. I can confirm that it has happened for both existing and new orders. 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted July 1, 2020 Share Posted July 1, 2020 Still facing issues with this bug. Even worse is I have even seen 2 orders blocked by Maxmind manage to create 2 uncaptured transactions for the order. This is a very unprofessional look for WHMCS users who have to try and explain this to clients. This has happened twice now. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 1, 2020 Share Posted July 1, 2020 Am tell you man I get some problem now and nothing be done with whmcs.com. Stripe.com something wrong on whmcs module that they need to fix they end 0 Quote Link to comment Share on other sites More sharing options...
pjs32 Posted July 1, 2020 Share Posted July 1, 2020 Has anyone opened a ticket with whmcs about it? 0 Quote Link to comment Share on other sites More sharing options...
LicenseChef Posted July 1, 2020 Share Posted July 1, 2020 20 minutes ago, pjs32 said: Has anyone opened a ticket with whmcs about it? Yep, they wanted access to the whmcs and have the default template run on it. I declined.... as this is clearly an issue with the coding. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 1, 2020 Share Posted July 1, 2020 8 minutes ago, LicenseChef said: Yep, they wanted access to the whmcs and have the default template run on it. I declined.... as this is clearly an issue with the coding. But you can give access to the Dev machine that what I do when I open a ticket 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 2, 2020 Share Posted July 2, 2020 I think we need to open a new thread because this what I get on the ticket Hello, Thanks for reaching out to WHMCS. The thread you linked is quite old, it also details an old case that was resolved in version 7.9 of WHMCS. I do note however that other users are reporting uncaptured Stripe transactions in the most recent version of WHMCS. This is not something I can reprodce locally, as such, I am transferring this ticket over to our Technical Support team for further review. Could you please provide our team WHMCS access along with an invoice you notice an uncaptured transaction for inside Stripe, so we can advise further? To securely provide access details, please click the "View Ticket Online" button at the bottom of this email, then click the "Submit/Update Login Credentials" button. Finally, click the "Save/Update" button at the bottom of the page, and then reply here so we may continue our investigations. If you have a firewall or htaccess blocks in place, please grant access to the following IP to allow our staff access: 208.74.120.226 For information on the level of access I'll need to your server, please refer to https://www.whmcs.com/members/index.php/knowledgebase/301/FTP-UsernameorControl-Panel-Username-value-is-not-valid.html Best regards, Alex NightingaleTechnical Analyst II WHMCS, Ltd.www.whmcs.com 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted July 9, 2020 Share Posted July 9, 2020 Another day another uncaptured payments and rightly upset client. Client orders and the order if flagged by maxmind. Client is charged twice and money has left their bank account. Stripe shows 2 payments as "uncaptured", have to manually refund one and capture the second one. Then apologise to the client about this unprofessional situation. @whmcs when are we going to get a response regarding this? 0 Quote Link to comment Share on other sites More sharing options...
zomex Posted July 15, 2020 Share Posted July 15, 2020 Reporting this bug again. It's not possible to provide WHMCS access to check this when there's a client who is rightly frustrated and concerned when 2 payments have been taken from their account. In many cases this also ties into Maxmind where an order has been marked as fraud but the payments still go through as uncaptured. 0 Quote Link to comment Share on other sites More sharing options...
hkhost Posted July 17, 2020 Author Share Posted July 17, 2020 TODAY WE GOT A NEW COMPLAINT FROM A CLIENT ASKING FOR A REFUND FOR A "PAID" SERVICE THAT WAS NOT PROVIDED. BUT THE ORDER NOR THE INVOICE WAS GENERATED BY WHMCS! AFTER I CHECKED STRIPE, I SAW A NEW "UNCAPTURED" PAYMENT! PLEASE WHMCS, WE PAY YOU A PREMIUM MONTHLY FEE, FIX YOUR BUGS!!!!! @WHMCS Aaron @WHMCS Alex @WHMCS Andrew @WHMCS Anwar @WHMCS Arty @WHMCS Ben @WHMCS Brian @WHMCS BrianO @WHMCS CarlX @WHMCS Chance 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 17, 2020 Share Posted July 17, 2020 (edited) look at at this Edited July 17, 2020 by wsa 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 17, 2020 Share Posted July 17, 2020 Here some information I find that maybe your did not see yet https://stripe.com/docs/payments/capture-later 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 20, 2020 Share Posted July 20, 2020 This what I get from whmcs staff today. Hello, Thanks for your response. My colleague Jay is no longer on shift, so I will assist you from here. I am sorry for the way you feel ticket has been handled thus far. I would like to provide some explanation as to what you might see in Stripe under different scenarios, along with some further information that might help get to the bottom of it. Furthermore, I will also be doing some testing on your installation, however, I cannot confirm when exactly that testing will occur, but when it does, your installation will be in maintenance mode. Scenario 1 A client places an order however, it is marked as "Fraud" by Maxmind. Inside Stripe, you will see WHMCS created a PaymentIntent when the client reached the checkout, which will show as an uncaptured payment within Stripe. Once the client finished checking out and the order was marked as Fraud, WHMCS will send a request to cancel the PaymentIntent to Stripe with the "cancellation_reason" being "fraudulent". The status of this payment will then show as "Canceled" within Stripe. Scenario 2 A client places an order which passes the Maxmind fraud check. Inside Stripe, you will see WHMCS created a PaymentIntent when the client reached the checkout, which will show as an uncaptured payment within Stripe. Once the client finished checking out and the order passed the fraud check, WHMCS will send a request to capture the PaymentIntent to Stripe. The status of this payment will then show as "Succeeded" within Stripe. Scenario 3 A client places an order which is blocked by rules configured within Stripe, under the Radar section. Inside Stripe, you will see WHMCS created a PaymentIntent when the client reached the checkout, which will have failed due to the Radar rules. The client will see the error of "Your card was declined." within the checkout in a red banner. The status of this payment will then show as "Blocked" within Stripe. The order will not have been created, so there won't be any record of this within WHMCS. The decline is happening at Stripe, related to Stripes logic/features, configured otherwise outside of WHMCS. Our current integration does not presently support getting feedback about declined payment intents, to do so would require a different/additional integration with Stripe than we presently offer. Scenario 4 A client places an order but navigates away from the checkout or closes their browser whilst WHMCS is performing the Fraud check. Inside Stripe, you will see WHMCS created a PaymentIntent when the client reached the checkout, which will show as an uncaptured payment within Stripe. Without the fraud checking process completing, the status of this payment will continue to show as "Uncaptured" within Stripe. Further information We have known some banks to alert customers to pre-authorizations on their card, so it's important to note that some clients may think they have been charged when Stripe shows the PaymentIntent as "Uncaptured", due to the alert from their bank of the pre-authorization. Your most recent response where a payment shows inside Stripe, but not in WHMCS, indicates Scenario 3 to me. If you are seeing a difference to Scenario 2, in that, when the client makes payment, the PaymentIntent is not then captured, instead, a new one created (leaving the previous one uncaptured), that is the aspect we need to test as it does not happen locally. Best regards, Alex NightingaleTechnical Analyst II WHMCS, Ltd.www.whmcs.com 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted July 27, 2020 Share Posted July 27, 2020 (edited) ok they find out it is a bug 🙂 It appears that the combination of having the TOS acceptance checkbox and the captcha, can cause the validation of the captcha to not be performed within the attempt to create the PaymentIntent over with Stripe. This happens when the user does not tick the TOS acceptance, then after it errors informing them of such, they do tick the TOS checkbox but don't complete the captcha challenge again (which has reloaded). Essentially, an uncaptured transaction could show in Stripe, as a PaymentIntent is incorrectly created after the captcha is not completed following the failure to accept the TOS in the checkout. I have reproduced that situation and opened up case MODULE-7478 with our development team to have this reviewed. Whilst I cannot provide an estimated time for completion for this, once we resolve cases and push features they are available at our change log, here: http://changelog.whmcs.com/ I apologize for the inconvenience, and appreciate your patience as we work to resolve this. This was the only point of failure I could find, as such, could you please disable the "Shopping Cart Checkout" option next to "Captcha for Select Forms" This will prevent the captcha being displayed within the checkout, which I know is less than ideal, but doing so will verify the point of failure I have found is the issue you are presently encountering (as no further uncaptured transactions will occur after disabling that). Thanks! Best regards, Alex NTechnical Analyst II Edited July 27, 2020 by wsa 1 Quote Link to comment Share on other sites More sharing options...
hkhost Posted July 27, 2020 Author Share Posted July 27, 2020 I knew since the beginning it was a bug related to Captcha 😂 0 Quote Link to comment Share on other sites More sharing options...
SwiftModders Posted August 4, 2020 Share Posted August 4, 2020 Has this been fixed? I have been experiencing this as well. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted August 5, 2020 Share Posted August 5, 2020 They tell me it should be fix WHMCS V8.0 Stable 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted October 3, 2020 Share Posted October 3, 2020 Still they dont fix this on V8.0.1 I guess we going to wait a year like the mailchimp module that waiting close to year 1 Quote Link to comment Share on other sites More sharing options...
zomex Posted October 4, 2020 Share Posted October 4, 2020 21 hours ago, wsa said: Still they dont fix this on V8.0.1 I guess we going to wait a year like the mailchimp module that waiting close to year Shocking that one of the more serious bugs was not fixed. 0 Quote Link to comment Share on other sites More sharing options...
wsa Posted October 4, 2020 Share Posted October 4, 2020 3 hours ago, zomex said: Shocking that one of the more serious bugs was not fixed. Yes a waste time of me spent hrs with them giving login and show error. 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted October 4, 2020 Share Posted October 4, 2020 I wouldn't be surprised to see a v8.0.2 maintenance release long before the end of the month... there's already a hotfix for v8.0.1 and there are still other unresolved bugs that will need addressing. 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.