PAC funded by Guardian but Attik shows "failed" — client double-charged

Objective

• Identify why Guardian successfully funds a PAC order and reports it as complete, but Attik receives or processes that webhook notification as a failure status, leaving the order showing unpaid.
• Prevent the downstream double-payment scenario where a client — seeing the order as unpaid — pays again by card after Guardian has already funded the inspection.
• Establish a reliable reconciliation path when PAC funding status and Attik order status diverge.

Background

• PAC (Pay at Close) relies on Guardian sending a webhook notification to Attik when a FlexFund order has been funded. Attik's payment status is derived from that inbound signal.
• In two confirmed incidents — the first investigated prior to the ATT-1495 fix, the second reported June 19 by Michelle at Residential Inspector (inspection 1008595199) — Guardian processed the PAC and funded the company, but Attik's order remained in a failed/unpaid state.
• Because the order showed unpaid to the client, the client paid again by card — resulting in double payment. Both incidents required manual resolution.
• The ATT-1495 fix (shipped June 8) addressed duplicate payments on Guardian card/ACH paths but did not cover the PAC-specific path where funding confirmation is inbound from Guardian rather than initiated by the client.
• Catherine Lemoine (Residential Inspector) confirmed the first incident was traced to a webhook communication failure from Guardian's side. The root cause of the second incident is uninvestigated as of June 22.
• The "failed" status in Attik on a PAC order most commonly reflects Guardian canceling the order on their end — but in these cases Guardian did not cancel; they funded. This suggests the funded event either was not received, was misrouted, or was mapped to an incorrect status transition.

Product Decisions

Locked

(None — pending engineering investigation)

Open

1. Webhook failure handling — When a Guardian PAC webhook is not received or fails to process, should the system flag the order for staff review rather than silently leaving it in a failed state? What should that surfacing look like?
2. Payment gate on already-funded orders — If Guardian has funded a PAC order, should a subsequent client-initiated card payment be blocked at the server level as a safeguard, independent of what Attik's UI shows? ATT-1495 shipped server-side duplicate payment guards for card/ACH paths — it is unknown whether the PAC-funded inbound path was covered by that fix.
3. Reconciliation tooling — Should there be a way for staff to manually trigger a PAC status re-sync from Guardian for a specific order without requiring a developer to query the database?

Scope

Backend

• src/routes/webhooks/flexfund/flexfundWebhook.ts — Primary entry point for inbound Guardian PAC webhook events; investigate whether a funded event type is being mishandled, dropped, or mapped to a failed status transition.
• src/routes/webhooks/webhook.ts — Webhook routing entry point; verify funded events are being dispatched to the correct handler.
• src/util/functions/payments/pacIsnFlexFundStatuses.ts — Status mapping between Guardian/FlexFund PAC statuses and Attik internal payment states; verify funded maps correctly and isn't being overridden downstream.
• src/util/functions/payments/paymentStatusValidator.ts — Validates payment state transitions; check whether a funded PAC order can be incorrectly transitioned back to a failed/unpaid state.
• src/util/functions/forecast/deriveInspectionPaidState.ts — Derives the composite paid state for an inspection; verify PAC-funded orders resolve to paid correctly.
• src/models/paymentSchema.ts — Payment schema definition; confirm the funded PAC state is modeled explicitly and not collapsed into a generic failed state on unexpected webhook payloads.

Frontend

• src/app/client/job/[slug]/pay-beta/components/PayAtCloseTab.tsx — Client-facing PAC payment tab; should not present a payment action when the order has already been funded by Guardian. Investigate whether funded status correctly suppresses the payment UI.

References

• Related: ATT-1962 — PAC cancellation leaves order unable to accept payment (different failure mode, same webhook surface)
• Related: ATT-1495 — Prevent duplicate/overpayments after inspection is already fully paid (prior fix; does not cover inbound Guardian PAC funded path) — Done
• See also: ATT-953 — See Pay at Close transaction status post-inspection (adjacent feature gap; staff visibility into Guardian processing status)
• Confirmed affected order: inspection 1008595199 — reported June 19, 2026 by Michelle (Residential Inspector)
• SW/SE <> ATTIK meeting transcript, June 22, 2026 — second incident surfaced by Michelle; first incident confirmed by Catherine Lemoine