Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Please check your internet connection #696

Open
renanstuchi opened this issue Dec 3, 2024 · 11 comments
Open

[BUG]: Please check your internet connection #696

renanstuchi opened this issue Dec 3, 2024 · 11 comments
Labels
bug Something isn't working

Comments

@renanstuchi
Copy link

What happened?

Hey everybody,

We have some integrations with Stripe for a very long time (old Checkout, old Card Elements) and we introduced "Payment Elements" recently into our platform. During the past 6 months we've been receiving complaints from our customers saying "they can't pay". After months of investigation and adding logs to most variety of places we finally found stripe sdk is returning error below:
{"message":"We are experiencing issues connecting to our payments provider. Please check your internet connection."}

I've been tracking this during past months and i can't find a single evidence that our customers were having internet issues...

  • we can see they going back and forward, trying to load the payment form multiple times.
  • all requests are fine, not a single one failing
  • all react components being loaded fine, no delays
  • customer interactions with buttons / sections / etc ... all fine, no delays.
  • some customers were able to try many times and it suddenly loads and he is able to pay.
  • we have print-screens from customers using wifi, mobile 4G, mobile 5G... basically every kind of network

Tracking the issue, seems the most users have issues during the Payment Elements load. See our code below.
BUT i need to mention that i've found customers having the same issue during the payment form submit.

Payment Elements Form load.

this._elems.link = StripeElements.create('linkAuthentication', { defaultValues: { email: email, phone: phone } });
    this._elems.payment = StripeElements.create('payment', {
      layout: {
        type: 'accordion',
        defaultCollapsed: false,
        radios: true,
        spacedAccordionItems: false
      },
      fields: {
        billingDetails: {
          address: {
            line1: addressFieldsConfig,
            line2: addressFieldsConfig,
            city: addressFieldsConfig,
            country: addressFieldsConfig,
            postalCode: addressFieldsConfig,
          },
        },
      },
      defaultValues: {
        billingDetails: {
          phone: phone,
          email: email,
          address: {
            country: this.options.country,
          },
        },
      },
      wallets: {
        applePay: 'never',
        googlePay: 'never',
      },
    });

    // callbacks
    this._elems.link.on('change', this.handleLinkElementChange.bind(this));
    this._elems.payment.on('change', this.handlePaymentElementChange.bind(this));
    this._elems.payment.on('loaderror', this.onErrorLoadingElements.bind(this));
    this._elems.link.on('loaderror', this.onErrorLoadingElements.bind(this));
    this._elems.payment.on('ready', this.onFormLoaded.bind(this));
    this._elems.link.on('ready', this.onFormLoaded.bind(this));

    // render
    this._elems.payment.mount(`#${this.$element.id}`);
    this._elems.link.mount(`#${this.$linkElement.id}`); 

Note1: loaderror listener is not catching this error. The error is being throw globally.

Note2: worth to mention that we have Card Elements and Checkout from Stripe running in the same platform, same code... and we can't see the same errors being throw there in the past 1 year. So seems restricted to Payment Elements only ?

Note3: it doesnt affect a large number of customers, so for the past 3 days we have 8 errors (thousand of payments).

Note4: unfortunately i was only able to see the right error recently thats why i only have occurrences from Windows 10+ and iOS. But i m pretty sure the error was hidden in an unparseable error message before... so i wouldn't say it only occurs in those devices.

Dev Stacks:
"react": "18.2.0"

We are injecting https://js.stripe.com/v3/ inline during platform load.

We were never able to reproduce this using any of our devices.
Also, reaching out for "Stripe support" didnt help much... they said we were unable to detect any ongoing issues on our site ... thats not clear enough. Would really appreciate a deep looking into this issue, please.

Regards.

Environment

Chrome on WIndows 10+, Safari on iOS 17, 18

Reproduction

No response

@renanstuchi renanstuchi added the bug Something isn't working label Dec 3, 2024
@renanstuchi
Copy link
Author

Again, just to be clear enough... issue is there for a long time, probably since we introduced "Payment Elements" into the platform.
But the error was hidden in the logs. So i can't see old occurrences.

@brendanm-stripe
Copy link
Contributor

How does this manifest for customers? At what point in your integration does this happen (initialization, payment confirmation, etc)? Have you noticed any patterns about affected customers?

Broadly speaking, transient network connection issues can block Stripe.js (or pieces of it) from loading, and this is expected to happen a low frequency. When happening reliably, this is usually due to either network blocking/filtering or connection reliability.

@renanstuchi
Copy link
Author

renanstuchi commented Dec 3, 2024

@brendanm-stripe

  1. When it occurs during form initialization: Customers can't see the payment form. Does not load.
  2. When it occurs during form submit: Customers click "pay" but see an error (our generic error message for non human readable messages for the customers).
  3. i couldn't find any patterns. During a long time i thought it was related to iOS but i have Windows occurrences now too.

So, i absolutely understand the fact that "network issues" can happen but i can't see any indicative this is happening to the majority of these customers. The fact that customers are using fine our platform during the entire flow and suddenly gets stuck in the payment form its a bit weird... We have so many examples of customers that tried to re-create their entire basket 4, 5 times before they gave up (this means a lot of requests to our server, including validations, connections with third party libs in the frontend and in the backend, connections with at least 3 APIs)

Also, how come i can't see same errors for old Stripe forms ? We have years of usage of those components... we supposed to have a small number of issues, right ? But not a single one ?

If we at least could listen events or callbacks that could potentially prove the "network issue" thing...i would be fine. But seems there is nothing ? How can we dive deep to debug this ?

@brendanm-stripe
Copy link
Contributor

This error is directly associated with connectivity to Stripe's API and suggests issues with network stability or ability to reach Stripe's servers. Intermittent failures are likely to be network stability related, while persistent errors are more likely to be related to reachability (ability to contact Stripe's servers).

There are API calls that are part of initializing Payment Element that are not part of Card Element, so it's possible the errors are surfacing there, but confirming this would require reproducing the issue and investigating. Reachability would likely also affect confirming payments using Card Element.

Taking a step back, this is not an issue with this loader helper module, but a communication with issue between Stripe.js and Stripe's servers when used. Diagnosing this will require sharing reproduction steps if you've been able to reproduce this, and sharing in a reply to our support team to investigate.

@renanstuchi
Copy link
Author

We are not able to reproduce it, no.

Is there any way that we could catch this error and maybe retry the Elements reload 1 or 2 times before we actually fail everything ? Right now i can't find a way to capture the error using listeners... So the error is being catch on a global level.

Also, changing from inline script injection to react/stripe module would give me any extra options here ? hooks ? anything ?

@brendanm-stripe
Copy link
Contributor

brendanm-stripe commented Dec 10, 2024

changing from inline script injection

Not sure what you mean, this loader module is already doing that. You should already be able to catch errors from loadStripe() and retry in cases of failure, since #518 .

That's for the script initialization, though, so it depends where you're observing errors. Is it later in the process of creating and mounting elements? Confirming payments? Methods like stripe.confirmPayment() already surface errors in the result (const {error} = await stripe.confirmPayment(...)), but it's hard to offer more specific guidance without knowing the shaping of the failure.

You can mimic network instability using browser developer tools to block specific requests or artificially slow your connected, which might be a way to reproduce the end result here.

@renanstuchi
Copy link
Author

renanstuchi commented Dec 10, 2024

changing from inline script injection

Not sure what you mean, this loader module is already doing that. You should already be able to catch errors from loadStripe() and retry in cases of failure, since #518 .

we are not using ES modules right now. We inject as a html <script> during platform load. Thats why i asked maybe the ES module with 'loadStripe()' feature would give me more control about the load/injection ? Im not sure...

That's for the script initialization, though, so it depends where you're observing errors. Is it later in the process of creating and mounting elements? Confirming payments? Methods like stripe.confirmPayment() already surface errors in the result (const {error} = await stripe.confirmPayment(...)), but it's hard to offer more specific guidance without knowing the shaping of the failure.

During mounting (100% sure) and elements.submit(). Im not sure yet about 'confirmPayment()' ... i just did an update to the code to get this info.

You can mimic network instability using browser developer tools to block specific requests or artificially slow your connected, which might be a way to reproduce the end result here.

yeah i tried that already, but since i can't see whats the request throwing the error its a bit hard to reproduce it correctly.

@brendanm-stripe
Copy link
Contributor

In that case yes, using this module would help because you have programmatic control over the loading (even more so using the pure variant). Similar to confirmPayment, you can access error in the elements.submit() result.

@ashtonlclark
Copy link

Thank you for logging this @renanstuchi. I have been experiencing a very similar issue with my integration of Stripe Payment Elements for the last several months. This occurs at least 1-2 times per week. A customer will see in the Stripe Payment Element, 'We are experiencing issues connecting to our payments provider. Please check your internet connection.'

I am unsure if this is because of the Stripe API connection or the user's internet connection. Unfortunately, Stripe still processes the charge successfully for the customer without the order properly completing in our e-commerce platform. This presents an issue because some of these customers complain that they have been charged without the order completing on their screen, resulting in an estimated 4-8 missed orders per month. In this case, we have no idea that the customer was charged unless we go through all of the orders that occurred for the day, which is tedious and sometimes impossible, depending on volume.

Our current workaround is to inform the customer on their screen to submit their order again on the same page. When this occurs the order is completed in our e-commerce platform and is correctly tied to the payment. This is not a long-term solution because there is no guarantee that the customer will even follow our instructions to complete their payment again. As you can imagine, the customer has probably received a notification on their phone that they have been charged and by asking them to complete the may get confused and think they will be charged again. This is the only way that we have identified to lessen the impact of this issue.

Additionally, I have been able to replicate this issue by placing a test order and then turning the WIFI off on my phone/laptop. As soon as I do this, the message I mentioned earlier appears. The payment is completed in Stripe with no record of it occurring in our commerce tool.

Any thoughts or ideas about how I can fix this?

Ideally, when this error occurs:

  1. I do not want the customer to have to complete their payment again. In this case, I would prefer for the order to complete when their internet or Stripe's API is back up again.
  2. I would like to be notified of this specific error so I can be proactive in ensuring there are no charges that occur outside of our e-commerce platform.
  3. I would prefer to resolve this from the start so that it no longer occurs in this specific scenario.

Thanks in advance for your help/guidance @brendanm-stripe or anyone from Stripe/this community.

@renanstuchi
Copy link
Author

hey @ashtonlclark
im not sure i fully understand your issue. Whats the step triggering it ? would be the 'confirmPayment()' step ?

Scenarios i have here are triggered before the paymentIntent is created... so user is not being charged, no.
But its a bit odd because 90% of the users drop their order when they see such error.

So far i was not able to reproduce the issue.

@ashtonlclark
Copy link

I see @renanstuchi.

My issue occurs during the 'confirmPayment()' step (stripe.confirmCardPayment). It does not happen all the time, but when it does, it's not the easiest to uncover when it happened. Once the user confirms payment they receive the 'We are experiencing issues connecting to our payments provider. Please check your internet connection' error. At this point, their payment was executed on Stripe but not in our e-commerce platform. I can reproduce the issue by turning my wifi off once I click the pay now button or in the browser console by updating the network to offline in Chrome as an example. When this occurs for users, I imagine they may be disconnected for a few seconds or so due to poor network performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants