How can I find out what's happening with Web Payments?

Questions
1

Since late last week, we are getting reports of customers who seem unable to enter payment data correctly and are unable to complete payments using the Square Payments widget.

We know the widget works, as I have used it myself and we have also seen payments go through, although the volume is very low and it leads us to suspect that something is not quite right.

The customers have not reported any error messages that they see from the widget, and we are not seeing any of these payment attempts hitting the backend, so everything is stalling in the widget.

I am at a loss to explain to our customers (the merchants) why it’s not working, and at this stage my only suggestion is that they consider switching payment providers.

We are aware that Square are making a lot of changes to the Web Payments widget code, and it leads to the conclusion that perhaps there’s something that’s not working quite right.

2

:wave: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
https://developer.squareup.com/docs/app-marketplace/requirements/web-payments-sdk

Additional Documentation

Payment API: Process Online and In-Person Payments
Payments Pricing with Square APIs and SDKs
Troubleshoot In-App Payments SDK Problems

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

3

I’m not sure I fully understand the issue. You said:

we are getting reports of customers unable to enter payment data correctly and are unable to complete payments using the Square Payments widget.

What widget are you referring to? Is this the Web Payments SDK or an integration your connected to? Also what exactly is the customer experience? Is the form field not letting them input there card information or is it not appearing at all? :slightly_smiling_face:

4

This is getting very frustrating. You do understand that I have our customers (merchants) using out platform to process payments using the Web Paymentds SDK payment widget, and they are yelling at me because a lot of their customers cannot complete their checkout because the Square system is failing!

As referenced in another topic, the customer experience is that the checkout just hangs and never responds.

Our analysis shows that the tokenize routine is called, and never returns, so the checkout process just sits there waiting. I have experienced the problem myself, but it is random. I obviously cannot monitor or get direct feedback on something that is happening in a customer’s browser.

I’m am astounded by the lack of concern on Square’s behalf. We have a situation where the payments system has been broken for a part of the population of users, and nobody seems to care or take responsibility, and this has been going on for about a week now. In fact we can almost determine when something at the Square end happened last week, when our successful payments data took a dive and dropped off a cliff when nothing else changed.

I don’t know why it’s affecting only some customers randomly, but it directly caused by something that Square is doing. I am having to urgently advise my merchants to switch to a different payments platform if they can, because this looks like it won’t be fixed for a long time.

I’d also suggest that any other Web Payments SDK users look carefully at their production stats, as they may be losing customer payments and they may not be aware that it’s affecting them as well.

5

Are the effected customer using the same browser? Also what’s there internet connection like? Is it weak or strong. Transient issues that are entirely out of anyones control can potentially cause issues described here. :slightly_smiling_face:

6

Hi Bryan,

This is not an environmental issue.

Can you please go to your developers and ask them why I can call tokenize and it never returns?
We have monitoring on this that proves the call never returns.

7

Is the page that your seeing this behavior live? If so what’s the URL to the page so the team can take a look? :slightly_smiling_face:

8

It’s no use trying to resolve the issue from the US, as it appears the problem is IP based.

This is why we see some payments go through, but a lot of others are being blocked.

For example, we saw an instance of a customer with the following details have the problem -

  • IP address 124.148.94.193 (Australia)
  • City: Brisbane
  • State/Province: Queensland
  • Country: Australia
  • Browser: Safari 18.1.1
  • Platform: iOS (iPhone) 18.1.1
  • Device: iPhone

On my own work IP address, I don’t have a problem.

I can try and get details of other customers with issues, but it is difficult as we need to rely on them contacting the merchant, who then reports the issue to us. Getting enough information to find the associated cart records in the checkout is challenging.

9

Sounds good. I know it’s difficult to get information from customers but it really does help the investigation. :slightly_smiling_face:

10

This is happening for us as well in the US. This is our implementation of the Square web payment, using the react-square-web-payments-sdk npm package: GitHub - laviddichterman/wcp-react-order-fe: Ordering front end written in ReactJS

Randomly, customers will report a given device is unable to complete the payment process on our website (Place your order | Windy City Pie). They hit the submit button and then it just hangs without hitting our server, so the hang happens before tokenization finishes. I cannot reproduce on any of my devices, so I’m at a loss.

11

Are there A/B tests happening that might give certain people a different file when they hit https://web.squarecdn.com/v1/square.js ? Perhaps based on the IP address and/or user agent? It consistently happens on a given device (per my customer’s experiences).

12

I’ve been spending the day looking at the network traffic in the browser developer tools for our checkouts, and I’m noticing something interesting that may be relevant.

There are a bunch of POSTs to send what looks like monitoring/metric info, which includes the following events -

“metrics”: [
{
“appLocation”: {
“origin”: “https://…”,
“pathname”: “/store/checkout2”
},
“avt”: “eb8bd4f3-2bc5-43b5-8c1d-…”,
“browserData”: {
“innerHeight”: 667,
“innerWidth”: 1722,
“isSecureContext”: true,
“language”: “en-AU”
},
“event”: “PROOF_OF_WORK:START”,
“eventSource”: “WebSDK”,
“sdkVersion”: “1.64.1”,
“session”: {
“applicationId”: “sandbox-sq…”,
“hostname”: “checkout…”,
“locationId”: “QD2RKE83…”,
“instanceId”: “5debc137-c542-43a2-8e45-…”,
“sessionId”: “uT-Ev9CwJk-…”
}
},

There’s another “PROOF_OF_WORK:OK” at the end of a successful payment.

Now this is interesting, because a quick look at Wikipedia (Proof of work - Wikipedia) shows that a Proof of Work is a cryptographic problem that requires a client to perform some calculations and then present the result to the server for verification that the correct answer was obtained.

This might explain why all of a sudden, the tokenization routine has started experiencing delays and even worse, never returning. By changing the parameters of the problem, perhaps Square can cause the problem solving task to be more difficult, or even make it impossible to solve.

If my hunch is correct, then this would explain why we are having these issues with the Web Payments widget.

13

The team is still investigating. :slightly_smiling_face:

1 Like