Production Orders webhooks not generated for one OAuth seller while working for another seller

We are experiencing what appears to be a seller-specific Orders webhook issue in Production.

We have one Square production application connected through OAuth to multiple Square sellers.

The same application, webhook endpoint and Orders integration behave differently depending on the seller.

Seller A — working correctly

Merchant ID: MLE4286F28JKV

Orders webhook events are received normally by our production endpoint.

Seller B — affected

Merchant ID: MLPJ5B9DKZSE0

OAuth authorization is valid and includes ORDERS_READ. Orders belonging to this seller can be retrieved successfully through the Orders API, so API authorization and access to the merchant are working correctly.

However, equivalent order activity for this seller does not generate/deliver the expected Orders webhook events to our application.

Our webhook ingress receives Square events normally for Seller A, but we do not see corresponding incoming webhook requests for Seller B.

Both sellers use:

  • the same Square production application
  • the same webhook endpoint
  • the same backend infrastructure
  • the same Orders Hub integration

This makes a general endpoint, TLS, routing or application configuration issue unlikely.

We can reproduce the difference consistently between these two merchants.

Could the Square Developer team please verify whether Orders webhook events are being generated for Merchant MLPJ5B9DKZSE0 and whether this merchant is correctly associated with the application’s production webhook subscription?

We can provide specific Order IDs, Location IDs, UTC timestamps and additional webhook logs if required.

Environment: Production
APIs: Orders API / Webhooks API / OAuth
Affected merchant: MLPJ5B9DKZSE0
Working comparison merchant: MLE4286F28JKV

I can look into this. What is the app id of your app connected to both merchants?

A couple of order IDs for each merchant alongside a timestamp would help me pinpoint any specific issues!

Thanks!

The production App ID is:

sq0idp-p6eNSvmX9eTS4GLWdp_zvA

Here are a couple of examples for each merchant.

Affected merchant — FLOREA
Merchant ID: MLPJ5B9DKZSE0
Location ID: L4C9PV3F9K918

1. Order ID: pqUZnCqnRmCozCAypuvbsbVM7Q8YY
Created at: 2026-09-27T18:38:24.324Z
Updated at observed: 2026-09-27T18:43:09.591Z
Square Online reference ID: 1260290577

We did not receive an Orders webhook for this order.

2. Order ID: DRNZuzqHAx05SygNbXFmoLSEtCNZY
Square Online timestamp: 2026-09-28T09:32:57Z (11:32:57 Europe/Madrid)
Square Online reference ID: 615210827

Again, we did not observe an Orders webhook from the FLOREA merchant.

Working comparison merchant — ACRE
Merchant ID: MLE4286F28JKV
Location ID: LV5HRAHKV8JVY

1. Order ID: 6qqmUAenh5FUGMCbKJvJmHwi4bFZY
order.created webhook received: 2026-09-27T18:39:16Z
Event ID: 159dadc4-b11f-3c7a-a08a-772584b88bf9

Subsequent order.updated events were also received normally.

2. Order ID: kRr0nntK6IbhulcYmjTd1bQeBGHZY
order.created webhook received: 2026-09-27T18:47:11Z
Event ID: 1b062c60-d195-3aa6-aac5-90cdb83f2089

Subsequent order.updated events were also received normally.

One potentially useful comparison: the first FLOREA order was created at 18:38:24Z, while the working ACRE order.created webhook arrived at 18:39:16Z.

During the 18:35Z–18:50Z window our production provider endpoint received 10 Square POST requests, all successfully handled with HTTP 200. All 10 verified requests belonged to ACRE and 0 belonged to FLOREA.

So the webhook endpoint itself was healthy and receiving Square traffic during the exact period in which the FLOREA order was being created/updated.

Please let me know if you need the webhook subscription ID or any additional timestamps/logs.

I do not see a webhook subscription for the app id you posted. I only see one for sq0idp-HXgMh6qQEKLF1JKSFnPtOA which also has the event ids you posted.

Please confirm the correct app is connected to the other merchant’s account and check the order webhooks again.

Outside of that, we generally recommend subscribing to the Payments webhooks and retrieving the payment’s status and associated order.

Thank you — we found the discrepancy.

sq0idp-p6eNSvmX9eTS4GLWdp_zvA is actually our ACRE Pricing Manager application.

Our ACRE Hub SQ Connector application is:

sq0idp-HXgMh6qQEKLF1JKSFnPtOA

This explains your findings.

We confirmed through /oauth2/token/status that the affected FLOREA merchant MLPJ5B9DKZSE0 is currently authorized against the Pricing Manager application (sq0idp-p6eNSvmX9eTS4GLWdp_zvA), not the Hub Connector application.

The webhook events we provided from the working ACRE merchant belong to the Hub Connector application (sq0idp-HXgMh6qQEKLF1JKSFnPtOA), as you observed.

Therefore this now appears to be an OAuth/application binding issue on our side rather than a Square webhook delivery issue.

We will authorize FLOREA against the ACRE Hub SQ Connector application and retest.

Could you please confirm that the existing webhook subscription under sq0idp-HXgMh6qQEKLF1JKSFnPtOA should receive the subscribed events for FLOREA once Merchant MLPJ5B9DKZSE0 OAuth-authorizes that application?

Thanks for spotting this.

That app is still not configured to receive order updated webhooks. Once it is, any connected seller will post events to that endpoint.

https://developer.squareup.com/console/en/apps/sq0idp-HXgMh6qQEKLF1JKSFnPtOA/webhooks

Thanks Zac, that clarifies it.

So the issue is at the application-level webhook subscription, not with the individual OAuth seller.

We’ll enable order.updated (and verify order.created) on the Production webhook subscription for this application and retest with both connected sellers.

Just to confirm:

  1. Once these Orders events are enabled for the app, all OAuth sellers connected to this application should send those events to the same webhook endpoint.
  2. There is no additional webhook configuration required per seller or per location.
  3. Existing OAuth sellers do not need to re-authorize the application after enabling the webhook event types.

Is that correct?

Thanks again.

Correct, correct, correct!