Jump to content
hkhost

Stripe "Uncaptured" Payments

Recommended Posts

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.

Share this post


Link to post
Share on other sites

Yes because it kept doing this 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

Has anyone opened a ticket with whmcs about it?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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 Nightingale
Technical Analyst II
WHMCS, Ltd.
www.whmcs.com

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)

look at at this  

 

 

Edited by wsa

Share this post


Link to post
Share on other sites

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 Nightingale
Technical Analyst II
WHMCS, Ltd.
www.whmcs.com

Share this post


Link to post
Share on other sites
Posted (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 N
Technical Analyst II

Edited by wsa

Share this post


Link to post
Share on other sites

I knew since the beginning it was a bug related to Captcha 😂

 

Share this post


Link to post
Share on other sites

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.


  • Similar Content

    • By Si
      With the upcoming charges for cPanel for individual hosting accounts I used the server sync tool to identify hosting accounts on my server which had no paying customers.  After running the sync, I was amazed at how many there were.   (Wondered why they weren't terminated and deleted by WHMCS automatically over the years).  Anyway,  so I checked about 20 of them manually (all the white banded ones)......and for all of them, they were correct.  So with about 60 to get rid off, I was satisfied (foolishly) that the sync tool was correct.  I then manually deleted the accounts in WHM > Terminate Accounts.
      Today I had a couple of customers contact me to tell me their website had disappeared and their email wasn't working.  Sure enough the paid for hosting accounts were gone.  
      I had to recreate them on the server, and running the sync tool again, the same sites appeared as 'not linked to any WHMCS account again'.  But they are.  Paying customers with accounts that use the cPanel auto-login to the server etc etc.
      It now seems that the only explanation I have is that the customer ordered the hosting account using a capital letter in the domain.  So the sync tool MUST be searching for the domain with all lower case and not allowing for (as WHMCS allows) the listing of capital letters in the client account.  So beware.
      Obviously, if my conclusion is correct, this is something WHMCS would need to address.  If it's not, then something else is going on which is more worrying.  
    • By Mechanic
      We haven't yet upgraded to 7.8.2 but I installed a fresh copy for a client today.  They are a reseller.
      I have added their reseller account as a server and clicked on the refresh icon and it shows they have Unlimited account limits, while they do have an account limit on our server.
      I was not impressed. This is going to result in some misunderstanding.
      Please fix the issue.
    • By melotel
      Using default 6 theme, contacts of an organization see a blank screen when they login.  Works OK for the primary account, but their contacts dont have the Security Settings page.

    • By melotel
      I have enabled Time Based Tokens for clients.
      However, when they navigate to security and attempt to enabled the setting they get an error.
      Loading...An error occurred while communicating with the server. Please try again.

    • By battles
      Hello,
      Can someone help me set this to project a better experience for our clients? My clients wonder why in their portal area - there are invoices that show as "overdue" when in fact they are not. See attached. It doesn't look very good and I get it from their perspective. It;s not "overdue" it's due in XX days. The attached are the 2 "overdue" and when they are actually due. We invoice 30 days in advance.


  • 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