Revenue needs to fail closed when an O'ahu credit invoice cannot resolve an O'ahu Square integration

Why

Sales just sent an invoice for an O'ahu-market customer and the payment completed, but the Square invoice was issued through the Dallas Square location. The Revenue order, offering, and credit-account rows are O'ahu, so this is not a Sales lead-market assignment problem and not a Revenue ledger-market problem. The problem is provider routing at invoice creation time.

The affected paid order is ord_019f4887-cdef-7987-a2ed-bc4e6d205edb, paid at 2026-07-10T01:30:59.000Z, with originating Sales lead lead_019e1e7f-8d0a-74da-add7-342dd877d11d and person per_019e1de6-cc9b-7779-bb02-0422c5071a7a. Revenue recorded the active credit account and selected offering against O'ahu market mkt_019e393d-919e-7188-a183-24222ff92023, and the order item snapshot is 8 Lesson Package (30 minutes each).

The Square side used organization_integration org_int_019e426e-84f5-78be-9201-af8489eb13c1, whose externalLocationId is LFNJ2JY4S7N0A. Revenue's own Square market-location mapping treats that as Dallas. O'ahu maps to L6E9P1EK6M2QD, but production currently has no active production Square organization integration row for that O'ahu location.

What

Sales' credit drawer sends Revenue the lead's market context on invoice-link creation. Revenue's invoice-link route then resolves the Square organization integration with resolveSquareOrgIntegration(body.organization_id, body.platform_market_id ?? null). That resolver first tries to match the configured market location, but if no matching integration exists it falls through to environment and token-alias matching. Because production has only one active production Square integration, the O'ahu-scoped invoice fell through to the Dallas production integration instead of failing the invoice create.

The important operational distinction is:

1. Revenue credit/order state is O'ahu for this paid order.
2. Square provider location state is Dallas for this paid invoice.
3. The customer-facing invoice can therefore look and settle under the wrong Square location even though internal Revenue market facts are correct.

Asks

1. Please add or repair the active production Square organization integration for O'ahu location L6E9P1EK6M2QD under organization org_01900000-0000-7000-8000-000000000001.

2. Please harden resolveSquareOrgIntegration so a market-scoped invoice create fails closed when the market maps to a Square location but no active integration exists for that location. For this incident shape, O'ahu should not silently fall back to the Dallas integration.

3. Please audit recent paid invoice-link orders where the order/offering/account market differs from the Square organization_integration.externalLocationId, starting with ord_019f4887-cdef-7987-a2ed-bc4e6d205edb. Sales needs to know whether this is a one-off from missing O'ahu config or whether other paid invoices were issued through the wrong provider location.

4. Please reply on this thread with the repair taken, the audit result, and whether Sales should hold off on sending more O'ahu invoice links until the fail-closed path and O'ahu integration are live.

References

Sales observed the incident from the live Revenue rows on 2026-07-09. Relevant Sales code is modules/workbenches/workbench-credit-orders.service.ts, where platformMarketId is sent into createInvoiceLinkOrder. Relevant Revenue code is modules/order/routes/invoice-link.routes.ts, where invoice-link order creation calls resolveSquareOrgIntegration, and modules/square-customer-bridge/service.ts, where the market-to-Square-location mapping is applied before environment fallback.