apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (1)

68-75: Consider namespacing by Stripe account to avoid hypothetical cross-account collisions.

Low risk, but adding account scoping can aid debugging and resilience.

Example:

• trackSale:stripe:acct:${stripeAccountId}:invoice:${invoiceId}
• dub_sale_events:acct:${stripeAccountId}:invoice:${invoiceId}

apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (2)

215-230: Add a fallback idempotency key when invoiceId is absent.

For one-time payments or edge cases where invoiceId is null, there’s no dedup today. Use checkout.session id or payment_intent id.

Example (outside the if (invoiceId) block):

• payment mode: key = trackSale:stripe:pi:${charge.payment_intent}
• subscription mode: key = trackSale:stripe:cs:${charge.id}
  Then apply the same SET NX pattern.

---

217-224: Optional: namespace keys by account for clarity.

Same suggestion as invoice-paid.

Use: trackSale:stripe:acct:${stripeAccountId}:invoice:${invoiceId}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (1)

215-233: Make the dedupe guard atomic, respect the legacy key, and robustly derive invoiceId.

• Handle cases where charge.invoice is an object (expanded) to avoid [object Object] key collisions.
• Keep the atomic SET NX, but also gate on the legacy key to avoid reprocessing invoices that were already handled before this change.
• If the legacy key is present, roll back the new claim to avoid blocking the other webhook.

Apply this diff:

   if (invoiceId) {
-    // Skip if invoice id is already processed
-    const ok = await redis.set(
-      `trackSale:stripe:invoiceId:${invoiceId}`, // here we assume that Stripe's invoice ID is unique across all customers
-      charge,
-      {
-        ex: 60 * 60 * 24 * 7,
-        nx: true,
-      },
-    );
-
-    if (!ok) {
-      console.info(
-        "[Stripe Webhook] Skipping already processed invoice.",
-        invoiceId,
-      );
-      return `Invoice with ID ${invoiceId} already processed, skipping...`;
-    }
+    // Robustly resolve the invoice ID (can be string or expanded object)
+    const invoiceIdStr =
+      typeof invoiceId === "string" ? invoiceId : invoiceId?.id;
+
+    if (!invoiceIdStr) {
+      console.warn(
+        "[Stripe Webhook] invoice present but missing id, skipping dedupe guard."
+      );
+    } else {
+      const trackSaleKey = `trackSale:stripe:invoiceId:${invoiceIdStr}`; // Stripe invoice IDs are globally unique
+      const legacyKey = `dub_sale_events:invoiceId:${invoiceIdStr}`;
+      const ttlSeconds = 60 * 60 * 24 * 7; // 7 days
+
+      // Claim atomically; also respect legacy key during migration window
+      const claimed = await redis.set(trackSaleKey, charge, {
+        nx: true,
+        ex: ttlSeconds,
+      });
+      if (!claimed || (await redis.exists(legacyKey))) {
+        if (claimed) await redis.del(trackSaleKey);
+        console.info(
+          "[Stripe Webhook] Skipping already processed invoice.",
+          invoiceIdStr
+        );
+        return `Invoice with ID ${invoiceIdStr} already processed, skipping...`;
+      }
+    }
   }

apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (3)

215-233: Add a fallback dedupe key when no invoice is present (one‑time payments).

For payment-mode sessions without an invoice, retries can double-count because no dedupe runs. Fall back to payment_intent or the session id.

Snippet (outside this hunk):

if (!invoiceId) {
  const paymentIntentId =
    typeof charge.payment_intent === "string"
      ? charge.payment_intent
      : charge.payment_intent?.id;

  const fallbackKey = paymentIntentId
    ? `trackSale:stripe:pi:${paymentIntentId}`
    : `trackSale:stripe:cs:${charge.id}`;

  const claimed = await redis.set(fallbackKey, "1", { nx: true, ex: 60 * 60 * 24 * 7 });
  if (!claimed) {
    console.info("[Stripe Webhook] Skipping already processed session.", fallbackKey);
    return `Session already processed, skipping...`;
  }
}

To confirm where one-time payments appear most, search for mode === "payment" usage and whether duplicates have been observed.

---

217-224: Consider storing a minimal marker instead of the full session object.

Storing the entire charge inflates Redis memory and egress. A constant like "1" (or a tiny JSON { at: <ts> }) is sufficient for dedupe.

---

217-224: TTL consistent; legacy dub_sale_events key still present — remove after migration

Both webhooks (apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts and checkout-session-completed.ts) set trackSale:stripe:invoiceId:${invoiceId} with ex: 60*60*24*7. apps/web/lib/api/conversions/track-sale.ts still mgets trackSale:${workspace.id}:invoiceId:${invoiceId} and dub_sale_events:invoiceId:${invoiceId} — drop dub_sale_events and/or align key naming after the migration window. Locations: invoice-paid.ts (~lines 69–74), checkout-session-completed.ts (~216–223), track-sale.ts (mget ~63–66; TTL ~567).

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (1)

68-85: Fix key pattern to workspace‑scoped and bridge legacy keys to avoid duplicate sales

Key uses trackSale:stripe:invoiceId:${invoiceId} which mismatches the workspace‑scoped pattern used elsewhere (e.g., track-sale and the other Stripe handler), breaking idempotency across paths. Also, without honoring legacy keys during the migration window, previously processed invoices can be reprocessed. Apply the workspace‑scoped key and add a one‑time legacy check (remove after September 23, 2025).

-  const ok = await redis.set(
-    `trackSale:stripe:invoiceId:${invoiceId}`, // here we assume that Stripe's invoice ID is unique across all customers
-    {
-      timestamp: new Date().toISOString(),
-      dubCustomerId: customer.externalId,
-      stripeCustomerId,
-      stripeAccountId,
-      invoiceId,
-      customerId: customer.id,
-      workspaceId: customer.projectId,
-      amount: invoice.amount_paid,
-      currency: invoice.currency,
-    },
-    {
-      ex: 60 * 60 * 24 * 7,
-      nx: true,
-    },
-  );
+  // Workspace‑scoped idempotency key to align with track‑sale and other handlers
+  const trackSaleKey = `trackSale:${customer.projectId}:invoiceId:${invoiceId}`;
+  const trackSaleValue = {
+    timestamp: new Date().toISOString(),
+    dubCustomerId: customer.externalId,
+    stripeCustomerId,
+    stripeAccountId,
+    invoiceId,
+    customerId: customer.id,
+    workspaceId: customer.projectId,
+    amount: invoice.amount_paid,
+    currency: invoice.currency,
+  };
+  const ok = await redis.set(trackSaleKey, trackSaleValue, {
+    ex: 60 * 60 * 24 * 7,
+    nx: true,
+  });
+  // Migration bridge — remove after September 23, 2025
+  const legacyExists =
+    (await redis.exists(
+      `trackSale:stripe:invoiceId:${invoiceId}`,     // wrong pattern from earlier change
+      `dub_sale_events:invoiceId:${invoiceId}`,      // pre‑migration key
+    )) > 0;
 
-  if (!ok) {
+  if (!ok || legacyExists) {
+    if (ok && legacyExists) {
+      // Respect legacy claims during the window
+      await redis.del(trackSaleKey);
+    }
     console.info(
       "[Stripe Webhook] Skipping already processed invoice.",
       invoiceId,
     );
     return `Invoice with ID ${invoiceId} already processed, skipping...`;
   }

Follow-up: Mirror the same workspace‑scoped key in apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts to keep both handlers consistent.

Run to find any remaining mismatched keys:

#!/bin/bash
# Find any usages of the old/mismatched key patterns
rg -nP "trackSale:(stripe|\$\{?workspaceId\}?):invoiceId" -C2 --type=ts
rg -n "dub_sale_events:invoiceId" -C2 --type=ts

Also applies to: 87-93

apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (1)

68-85: Optional: include livemode in the key namespace if Redis is shared across envs

If the same Upstash instance backs both test and live webhooks, consider namespacing by event.livemode (e.g., add :live/:test) to avoid extremely rare cross‑env collisions and to simplify debugging. If infra already isolates envs at the Redis level, ignore.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
PR: dubinc/dub#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.693Z
Learning: In the Dub codebase, multiple payout records can now share the same stripeTransferId because payouts are grouped by partner and processed as single Stripe transfers. This is why the unique constraint was removed from the stripeTransferId field in the Payout model - a single transfer can include multiple payouts for the same partner.