Follow-up: 502 Bad Gateway (Payments API) – No payment_id Returned After Successful Charge

Questions
1

Hi Square Team,

I’m following up on my previous discussion regarding the 502 Bad Gateway response from the /payments API, as I haven’t received a response to my last update.

In the previous thread, I shared that:

  • The incident occurred on 12-06-2026, not during the service disruption on 22-06-2026 that was referenced.

  • Our Application ID is: sq0idp-IbtUpw5WWJkQOIPL8qTOtQ.

  • The customer was successfully charged, but the API returned a 502 HTML error page instead of the expected JSON response.

  • Because the response did not contain a payment_id, our application was unable to reconcile or update the transaction status.

  • We are already subscribed to payment webhooks, but our current flow depends on the payment_id returned by the synchronous /payments API response.

Our main questions are:

  1. Is there any way to identify or retrieve the payment when the /payments API returns an HTML 502/503 response after the payment has already been processed?

  2. What could cause Square to return a Cloudflare 502 HTML page instead of the standard JSON error response?

  3. What is the recommended integration pattern for handling these scenarios so that successful payments are not left unreconciled when the synchronous API response is lost?

If anyone from the Square team could investigate this using the Application ID above or provide guidance on the recommended recovery strategy, it would be greatly appreciated.

Previous Post : Bad gateway Error code 502(payments api)

Also if your team can add below email addresses to Slack channel then it will be more helpful.
[email protected]
[email protected]

Thank you.

2

A 502 after a successful charge should be treated as an unknown outcome. If you used an idempotency key, retry with the same key and rely on webhooks to reconcile the payment. The Square team should also be able to trace the transaction using your Application ID, timestamp, and idempotency key, and hopefully explain why a Cloudflare HTML 502 was returned instead of a JSON error.

3

A 502 after a successful charge usually means the request reached Square, but the response was lost. Make sure you’re using idempotency keys and treat 502/503 responses as an unknown state, then reconcile the payment via webhooks or a payment search using your own reference. Hopefully the Square team can check the logs for your Application ID and explain why Cloudflare returned an HTML 502 instead of the normal JSON response.

5

@kishanv Yes, in general I’d recommend handling these errors by retrying the request (and leveraging idempotency keys to ensure that a duplicate request is not processed by accident).

Unfortunately this specific incident from 12-06-2026 is out of the retention window for the logs we have on our side. Have there been any more recent occurrences since then? If so, if you can provide the timestamp (date, time, and timezone) I’m happy to see what I can find in the traces.