Controls intermittently are disabled

[trein-homeroom]

We have several reports from customers that the Stripe credit card fields are disabled.

In every case we've heard about it, the placeholder text is missing (in addition to the fields being disabled/not accepting input).

I've been able to simulate the issue by throttling the network (via Chrome's network tab). When the Stripe credit card fields are rendered, you can see a lot of network requests being made, and throttling (or stopping) those requests results in the same behavior - no placeholder text, fields disabled.

I suppose you can say that you can't help when the internet is slow, but it could very well be the Stripe servers that are causing the issue. But I also wonder why these assets are being downloaded and not baked directly into this package. It also seems like a large number of requests.

This is probably related to #35 #237, but #35 is closed, and #237 is described as an issue when the stripe domain is blocked, and that's not the case with the issue we are seeing. Switching to a different browser often works for our customers. But I suspect that refreshing the page would do the same thing.

[asolove-stripe]

Hi @trein-homeroom: oof, that sounds pretty painful for you and your customers! I believe you've correctly identified the problem: if the network requests are rejected or timeout, there isn't much we can do to render the Elements. We monitor our performance pretty seriously, so I think we would notice if our own CDN were the cause of this issue. But if you can recreate this issue with network settings that are realistic for your customers, we'd love to hear more detail and try to troubleshoot.

Please note that this package is just a React-friendly API around Stripe.js, which is always loaded from the network, because it is updated frequently and not open source.

[oliver-stripe]

Also note that many of the requests are for the same files (due to multiple iframes that leverage the same assets) and will normally leverage the browser cache, so it's not quite as many requests as it seems.

[tkrein321]

I can't reproduce w/o the network throttling. Do you have any advice on capturing information you might find relevant when this happens in our app to our customers?

On leveraging the browser cache - the URLs look like they have some kind of UUID in them. Often that's used to avoid the browser from caching. Can you confirm that these URLs with the random numbers in them are somehow static and not changing each time?

Are we allowed to bake Stripe.js into our app and build our own components to avoid this issue?

[asolove-stripe]

@tkrein321:

• If you can reproduce with throttling to a level like 2g/3g, which ought to work and just take a while, we would definitely look into that. I just tried with 3g settings and things seemed to work fine, so that would be news to us! Also, if there's anything in common among users who have this problem (geography? device?) that would be interesting.
• The URLs do have cache-busting version ids, but those versions are the same for each request to the same resource, since we are trying to load the same thing into each of the four iframes. So of those 20 requests in the network log above, there's only 5 real network requests going out.
• Stripe.js has to be loaded from the network: baking it into your app will not work, both technically and for compliance reasons. (Stripe is certified by a group called PCI that controls online use of credit cards: unless you want to do reams of paperwork, we need to be able to prove that credit cards are collected by our code that hasn't been tampered with.)

[tkrein321]

Yea, if I throttle to "slow 3g" (the slowest Chrome offers w/o creating a new one) it eventually works.

Also, if there's anything in common among users who have this problem (geography? device?) that would be interesting.

Not that I've been able to deduce so far. The only thing is that input placeholders are missing.

Stripe.js has to be loaded from the network: baking it into your app will not work

We do load stripe.js when the webapp first starts (though I can't tell if it actually loaded with customers who had the issue). Is it possible to preload the others? Would rendering the controls, hidden, pre-fetch the 5 other network requests you mention above?

Anything else we should consider? We're getting about 1 customer a day contacting us about this issue. Our customers are fairly motivated, but I imagine for everyone that does contact us, there is others who don't. Are we able to detect in code if things haven't loaded in the Stripe controls so that we can do something (albeit not so good) like ask the user to refresh the page?

[asolove-stripe]

Yeah, if you create and mount an Element but just don't make it visible, that would trigger the requests to start sooner.

You could use the Element's ready event to listen for when the Element is focusable before showing it in the UI, or to log timing information between when you mount it and when it's interactive.

We'll also poke at our logging to check that we are catching instances where the Element is requested to mount but doesn't actually complete successfully. (Obviously if the networking is broken when the mount request fires, we'll never get logging on that, but maybe we can tell how often the network works then but breaks before the Element finishes loading.)

[tkrein321]

ok, thanks for the help! feel free to close this.