I ran into two separate issues with Square Bill Pay that seem like they could be fixed with relatively small UI and backend changes.
First, when I opened Bill Pay, Square immediately displayed a verification pop-up. The problem was that the original Bill Pay screen underneath it was still interactive. When I tried to enter the verification code, I couldn't reliably select the code field. Pressing Tab would move the focus through fields on the Bill Pay form behind the verification window instead of through the verification fields.
The verification overlay also appears to be something that could potentially be hidden client-side with browser tools or an ad blocker while leaving the underlying Bill Pay interface accessible.
The verification step should probably fully lock the underlying page until verification is completed so users cannot interact with both interfaces at the same time.
The more serious issue happened after I refreshed the page, completed verification, and tried to submit my bill payment.
I clicked Pay and nothing visibly happened. There was no confirmation, loading indicator, disabled button, or other indication that Square had received the request. I clicked Pay several more times because it appeared that the button wasn't working.
Eventually, I refreshed the page and checked my scheduled payments.
Six identical bill payments had been created.
They were all for the same payee and amount..
I was able to cancel three of them, but the other three had already progressed far enough that my credit card had been charged and the ACH payment process had started. I am currently working with Square Support to resolve those transactions.
This seems like an idempotency issue that should be handled at the backend level.
When a user creates a bill payment, that payment attempt should receive a unique transaction/request ID. Repeated clicks on the Pay button during the same submission should reference the same payment request rather than creating an entirely new scheduled payment every time the button is clicked.
The UI could also help prevent this by:
- Immediately disabling the Pay button after the first click
- Showing a clear "Processing..." state
- Preventing additional submissions while the original request is pending
- Displaying a confirmation once Square receives the request
- Detecting identical payment submissions made within the same session
- Requiring the verification modal to fully block interaction with the underlying Bill Pay page
A payment interface should be especially defensive against duplicate submissions because an unresponsive button can naturally cause users to click it again.
In my case, that behavior resulted in six scheduled payments and three payments progressing before I realized what had happened.
I wanted to report this because it seems very reproducible and potentially preventable with both frontend submission locking and backend idempotency protection.
