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 · 8 comments
Open

[BUG]: Please check your internet connection #696

renanstuchi opened this issue Dec 3, 2024 · 8 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.

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

2 participants