fix(widgets): modal contrast, contact-support clickability, BUY/PAID status tiers (p2pdotme#6)

* fix(modal): pipe themeStyle through portal so card respects host palette

Modal portals to document.body, escaping the calling widget's root where
`themeToCssVars(theme)` is applied. The card's `background: var(--p2p-color-bg, #ffffff)`
fell back to white, while inner content (which reaches the host's CSS vars
via the inner themeStyle div) renders text in near-white — producing
white-on-white text on dark integrators.

Each Modal caller now passes its `themeStyle` to Modal, which spreads it
on the backdrop. CSS cascade carries the vars to the card so the surface
matches the integrator's palette. Also pins `color: color.text` on the
card so descendants without an explicit color inherit a readable token.

Verified on merchant-app demo: dialog bg now resolves to integrator dark
surface, text near-white — proper contrast restored.

* fix(contact-support): always render the button so users always have a recourse

Previous behavior only rendered the Contact Support chip when the order
was inside the dispute window or after a dispute was filed. PLACED /
ACCEPTED / PAID / COMPLETED states showed status text with NO action —
leaving users with no way to contact support when an order was stuck (e.g.
PAID waiting on a merchant-confirm-completion watcher that hasn't fired).

Now every row renders a Contact Support button. Variant depends on state:
- In dispute window → chip with countdown, click opens report flow
- Dispute open / resolved → plain button with dot, click opens chat
- Everything else → plain button, click opens chat (or surfaces
  "Support not available yet" if the order isn't bound to an inbox yet)

End users always have a way to reach support, even when no on-chain
dispute path is currently valid.

* Revert "fix(contact-support): always render the button so users always have a recourse"

This reverts commit f57f0bf.

* fix(contact-support): in-window chip is always clickable, falls back to chat when no txSigner

Previous behavior: the in-window report chip rendered with disabled={!txSigner}.
When the embedder didn't wire txSigner (or it was somehow undefined), the
chip appeared visibly greyed out and the HTML disabled attribute blocked
the click — leaving the user with a visible but non-functional button.

Now: the chip is always clickable. Click target depends on txSigner:
- txSigner present → opens the on-chain report flow (raiseDispute)
- txSigner missing → opens chat (will surface "Support not available yet"
  if the bridge has no inbox bound, but the user is never left without a
  response on click)

* fix(order-action): surface stale-PLACED + processing-payment countdown

Two related smart-action machine improvements:

1. **PLACED past 5min → "still matching, taking longer than usual"** —
   the chain's status field stays PLACED until an `autoCancelExpiredOrders`
   keeper sweep runs, which lags the actual accept-window expiry. The
   widget now surfaces the staleness so users don't keep staring at
   "Placed · matching" forever when no merchant can pick the order up
   anymore.

2. **BUY/PAID renders a countdown** — "Paid · processing payment ·
   completes within <X>m" while inside the 30-min processing window
   (matches contract's placedAt + orderExpiry envelope). Past the
   window we fall back to the plain "Paid · processing payment" label.

Constants exported:
- `PLACED_STALE_THRESHOLD_MS = 5 * MIN`
- `BUY_PAID_PROCESSING_WINDOW_MS = 30 * MIN`

71 node:test cases pass, 55 vitest pass, typecheck + build clean.

* fix(order-action): three-tier BUY/PAID status (no countdown in middle band)

Revise the BUY/PAID label tiers per UX spec:

  < 5min   → "Paid · processing payment"
  5–30min  → "Paid · processing payment · taking longer than usual"
  ≥ 30min  → "Paid · processing payment · will resolve within <countdown>"

The middle tier is a gentle warning without a countdown (drops the noise of
a constantly-changing timer for orders that are merely a few minutes
overdue). The outer tier anchors the countdown on BUY_DISPUTE_CLOSE_MS
(24h) — the chain's outermost resolution deadline, so the user always sees
a hard upper bound on the wait.

---------

Co-authored-by: gitchadd <gitchad@icloud.com>

Author: gitchadd

src/core/order-action.test.ts

@@ -76,6 +76,15 @@ test("placed: status only, no action", () => {
   assert.deepStrictEqual(out.action, { kind: "none" });
 });
 
+test("placed: past staleness threshold surfaces 'taking longer'", () => {
+  const out = computeOrderAction(
+    baseOrder({ status: "placed" }),
+    PLACED_AT_MS + 6 * 60 * 1000, // 6 minutes after placement, past 5-min threshold
+  );
+  assert.match(out.statusText, /taking longer than usual/);
+  assert.deepStrictEqual(out.action, { kind: "none" });
+});
+
 // ─── accepted ──────────────────────────────────────────────────────────
 
 test("accepted BUY: resume action surfaces", () => {
@@ -113,18 +122,29 @@ test("accepted PAY: status only", () => {
 // no-action terminal-ish state where the user waits for the merchant
 // to complete OR for the order to auto-cancel.
 
-test("paid BUY: no action regardless of elapsed (chain requires CANCELLED)", () => {
-  for (const elapsed of [
-    5 * 60 * 1000,
-    BUY_DISPUTE_OPEN_MS,
-    10 * 60 * 60 * 1000,
-    BUY_DISPUTE_CLOSE_MS + 1,
-  ]) {
+test("paid BUY: status escalates by elapsed, no action (chain requires CANCELLED)", () => {
+  const cases: ReadonlyArray<{ elapsed: number; expect: RegExp | string }> = [
+    // < 5min: plain
+    { elapsed: 60 * 1000, expect: "Paid · processing payment" },
+    // 5–30min: taking longer than usual
+    { elapsed: 10 * 60 * 1000, expect: "Paid · processing payment · taking longer than usual" },
+    { elapsed: 29 * 60 * 1000, expect: "Paid · processing payment · taking longer than usual" },
+    // ≥ 30min: will resolve within <countdown>, anchored on BUY_DISPUTE_CLOSE_MS
+    { elapsed: 30 * 60 * 1000, expect: /^Paid · processing payment · will resolve within / },
+    { elapsed: 10 * 60 * 60 * 1000, expect: /^Paid · processing payment · will resolve within / },
+    // Past BUY_DISPUTE_CLOSE_MS (24h): countdown clamps, falls back to plain
+    { elapsed: BUY_DISPUTE_CLOSE_MS + 1, expect: "Paid · processing payment" },
+  ];
+  for (const { elapsed, expect } of cases) {
     const out = computeOrderAction(
       baseOrder({ status: "paid", type: "buy", paidAt: 1n }),
       PLACED_AT_MS + elapsed,
     );
-    assert.strictEqual(out.statusText, "Paid · processing payment");
+    if (typeof expect === "string") {
+      assert.strictEqual(out.statusText, expect, `elapsed=${elapsed}ms`);
+    } else {
+      assert.match(out.statusText, expect, `elapsed=${elapsed}ms`);
+    }
     assert.deepStrictEqual(out.action, { kind: "none" });
   }
 });

src/core/order-action.ts

@@ -82,6 +82,21 @@ export const BUY_DISPUTE_CLOSE_MS = 24 * HOUR;
 export const SELL_PAY_DISPUTE_OPEN_MS = 30 * MIN;
 export const SELL_PAY_DISPUTE_CLOSE_MS = 7 * DAY;
 
+// Threshold past which a still-unmatched PLACED order is "taking longer than
+// usual". Anything beyond this is past the chain's typical accept window, so
+// the row's status text reflects the staleness even when the on-chain status
+// hasn't flipped to CANCELLED yet (the chain only flips on
+// `autoCancelExpiredOrders` keeper sweeps, which can lag).
+export const PLACED_STALE_THRESHOLD_MS = 5 * MIN;
+
+// BUY/PAID staleness threshold (5min handled by PLACED_STALE_THRESHOLD_MS):
+//   < 5min  → "Paid · processing payment"
+//   5–30min → "Paid · processing payment · taking longer than usual"
+//   ≥ 30min → "Paid · processing payment · will resolve within <countdown>"
+// The "will resolve within" countdown is anchored on `BUY_DISPUTE_CLOSE_MS`
+// (24h after placement) — the chain's outermost resolution deadline.
+export const BUY_PAID_PROCESSING_WINDOW_MS = 30 * MIN;
+
 export function computeOrderAction(
   order: Order,
   nowMs: number,
@@ -109,6 +124,16 @@ export function computeOrderAction(
 
   switch (order.status) {
     case "placed":
+      // The chain's status field is sticky on PLACED until an explicit
+      // `autoCancelExpiredOrders` sweep runs, which can lag the actual
+      // accept-window expiry. Past `PLACED_STALE_THRESHOLD_MS` we surface
+      // the staleness in the row so users don't keep waiting on an order
+      // that no merchant can pick up anymore.
+      if (elapsed >= PLACED_STALE_THRESHOLD_MS) {
+        return noAction(
+          "Placed · still matching, this is taking longer than usual",
+        );
+      }
       return noAction("Placed · matching");
 
     case "accepted":
@@ -123,6 +148,28 @@ export function computeOrderAction(
         // raiseDispute rejects this status (contracts-v4 #raiseDispute
         // gates BUY on status=CANCELLED). The user waits for completion
         // or auto-cancellation.
+        //
+        // Three tiers of urgency:
+        //   < 5min   → plain "Paid · processing payment"
+        //   5–30min  → "· taking longer than usual" (gentle warning)
+        //   ≥ 30min  → "· will resolve within <countdown>" anchored on
+        //              the contract's auto-cancel deadline. Gives the
+        //              user a hard upper bound when the merchant has
+        //              clearly missed the typical window.
+        if (elapsed >= BUY_PAID_PROCESSING_WINDOW_MS) {
+          const remaining = BUY_DISPUTE_CLOSE_MS - elapsed;
+          if (remaining > 0) {
+            return noAction(
+              `Paid · processing payment · will resolve within ${formatRemaining(remaining)}`,
+            );
+          }
+          return noAction("Paid · processing payment");
+        }
+        if (elapsed >= PLACED_STALE_THRESHOLD_MS) {
+          return noAction(
+            "Paid · processing payment · taking longer than usual",
+          );
+        }
         return noAction("Paid · processing payment");
       }
       // SELL or PAY in PAID state means the user has been paid; they

src/ui/Modal.tsx

@@ -29,6 +29,14 @@ interface ModalProps {
   ariaLabelledBy?: string;
   /** Fallback accessible name when no labelling heading exists. */
   ariaLabel?: string;
+  /** Theme CSS vars applied to the backdrop so the card surface + inner
+   *  content render against the integrator's palette. The Modal portals
+   *  to `document.body`, escaping the calling widget's root — without
+   *  this, the card's `var(--p2p-color-bg, #ffffff)` falls back to white
+   *  on dark themes, producing white-on-white text. Pass the same
+   *  `themeToCssVars(theme)` result the calling widget applies to its
+   *  root. */
+  themeStyle?: React.CSSProperties;
   children: React.ReactNode;
 }
 
@@ -37,6 +45,7 @@ export function Modal({
   onClose,
   ariaLabelledBy,
   ariaLabel,
+  themeStyle,
   children,
 }: ModalProps) {
   const dialogRef = useRef<HTMLDivElement | null>(null);
@@ -100,6 +109,10 @@ export function Modal({
   return createPortal(
     <div
       style={{
+        // Theme CSS vars first so `color.surface` (`var(--p2p-color-bg, …)`)
+        // on the card resolves against the integrator's palette instead of
+        // the white fallback.
+        ...themeStyle,
         position: "fixed",
         inset: 0,
         zIndex: 999999,
@@ -121,6 +134,7 @@ export function Modal({
         aria-label={ariaLabelledBy ? undefined : ariaLabel}
         style={{
           background: color.surface,
+          color: color.text,
           borderRadius: radius.xl,
           boxShadow: shadow.pop,
           width: "100%",

src/widgets/Cashout.tsx

@@ -572,6 +572,6 @@ export function Cashout(props: CashoutProps) {
     </div>
   );
 
-  if (mode === "modal") return <Modal open={open} onClose={onClose}>{content}</Modal>;
+  if (mode === "modal") return <Modal open={open} onClose={onClose} themeStyle={themeStyle}>{content}</Modal>;
   return <div style={{ ...S.card, overflow: "hidden" }}>{content}</div>;
 }

src/widgets/Checkout.tsx

@@ -714,6 +714,6 @@ export function Checkout(props: CheckoutProps) {
     </div>
   );
 
-  if (mode === "modal") return <Modal open={open} onClose={onClose}>{content}</Modal>;
+  if (mode === "modal") return <Modal open={open} onClose={onClose} themeStyle={themeStyle}>{content}</Modal>;
   return <div style={{ ...S.card, overflow: "hidden" }}>{content}</div>;
 }

src/widgets/ContactSupport.tsx

@@ -124,17 +124,15 @@ export function ContactSupport(props: ContactSupportProps) {
     effectiveDispute === "resolved";
 
   const handleClick = useCallback(() => {
-    if (inWindow) {
-      if (!txSigner) {
-        // No signer wired → embedder hasn't enabled the report flow.
-        // Nothing to do; the chip would have already been styled
-        // disabled at render time.
-        return;
-      }
+    // In-window with a tx signer → open the on-chain report flow.
+    // In-window without a tx signer → fall through to chat. The embedder
+    // hasn't wired the dispute write path, but the user still needs a
+    // recourse, and chat will surface "Support not available yet" if the
+    // bridge has no inbox bound. Better than a dead-button experience.
+    if (inWindow && txSigner) {
       setModalState({ kind: "report" });
       return;
     }
-    // Otherwise click opens the chat thread.
     setModalState({ kind: "chat-signing" });
     setChatAttempt((a) => a + 1);
   }, [inWindow, txSigner]);
@@ -247,7 +245,6 @@ export function ContactSupport(props: ContactSupportProps) {
             windowOpenMs,
             windowCloseMs,
           })}
-          disabled={!txSigner}
           onClick={handleClick}
         />
       ) : (
@@ -259,6 +256,7 @@ export function ContactSupport(props: ContactSupportProps) {
       <Modal
         open={modalState.kind !== "closed"}
         onClose={closeModal}
+        themeStyle={themeStyle}
         ariaLabelledBy={
           modalState.kind === "report"
             ? "report-problem-title"
@@ -302,22 +300,19 @@ export function ContactSupport(props: ContactSupportProps) {
 interface ReportChipProps {
   remainingMs: number;
   filled: number;
-  disabled: boolean;
   onClick: () => void;
 }
 
 function ReportChip({
   remainingMs,
   filled,
-  disabled,
   onClick,
 }: ReportChipProps) {
   return (
     <button
       type="button"
       data-contact-support-chip
       aria-label="Contact Support"
-      disabled={disabled}
       onClick={onClick}
       style={{
         display: "inline-flex",
@@ -332,8 +327,7 @@ function ReportChip({
         fontSize: font.sm,
         fontWeight: weight.regular,
         fontFamily: "var(--p2p-font, inherit)",
-        cursor: disabled ? "not-allowed" : "pointer",
-        opacity: disabled ? 0.55 : 1,
+        cursor: "pointer",
       }}
     >
       <Doughnut filled={filled} />

src/widgets/Support.tsx

@@ -176,6 +176,7 @@ export function Support(props: SupportProps) {
         open={open}
         onClose={handleClose}
         ariaLabelledBy="p2p-support-title"
+        themeStyle={themeStyle}
       >
         <DialogContent
           orderId={orderId}