apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts (3)

112-114: Critical: Zero balance scenario still lacks proper handling.

The zero balance condition continues without updating payout statuses, leaving them in an inconsistent state. This was previously flagged but remains unaddressed.

Apply this fix to handle the zero balance scenario properly:

 if (updatedBalance <= 0) {
+  await prisma.payout.updateMany({
+    where: {
+      id: {
+        in: payoutIds,
+      },
+    },
+    data: {
+      status: "processed",
+    },
+  });
+
+  console.log(
+    `Skipping payouts for partner ${partner.id} - insufficient balance after withdrawal fee (${currencyFormatter(updatedBalance / 100)})`,
+  );
+
   continue;
 }

---

117-128: Critical: Stripe transfer creation lacks error handling.

The Stripe API call can fail and leave payouts in an inconsistent state. This was previously flagged but remains unaddressed.

Wrap the transfer creation in proper error handling:

-const transfer = await stripe.transfers.create(
-  {
-    amount: updatedBalance,
-    currency: "usd",
-    transfer_group: invoiceId,
-    destination: partner.stripeConnectId!,
-    description: `Dub Partners payout for ${payouts.map((p) => p.id).join(", ")}`,
-  },
-  {
-    idempotencyKey: `${invoiceId}-${partner.id}`,
-  },
-);
+let transfer;
+try {
+  transfer = await stripe.transfers.create(
+    {
+      amount: updatedBalance,
+      currency: "usd",
+      transfer_group: invoiceId,
+      destination: partner.stripeConnectId!,
+      description: `Dub Partners payout for ${payouts.map((p) => p.id).join(", ")}`,
+    },
+    {
+      idempotencyKey: `${invoiceId}-${partner.id}`,
+    },
+  );
+} catch (error) {
+  console.error(
+    `Failed to create Stripe transfer for partner ${partner.id}:`,
+    error,
+  );
+  continue;
+}

---

137-174: Consider adding transaction safety for database operations.

While Promise.allSettled handles individual promise failures, wrapping the payout and commission updates in a database transaction would ensure atomicity and prevent partial updates.

+await prisma.$transaction(async (tx) => {
   await Promise.allSettled([
-    prisma.payout.updateMany({
+    tx.payout.updateMany({
       where: {
         id: {
           in: payoutIds,
         },
       },
       data: {
         stripeTransferId: transfer.id,
         status: "sent",
         paidAt: new Date(),
       },
     }),

-    prisma.commission.updateMany({
+    tx.commission.updateMany({
       where: {
         payoutId: {
           in: payoutIds,
         },
       },
       data: {
         status: "paid",
       },
     }),
+  ]);
+});

+await Promise.allSettled([
     partner.email
       ? sendEmail({
           variant: "notifications",
           subject: "You've been paid!",
           email: partner.email,
           react: PartnerPayoutProcessed({
             email: partner.email,
             program: latestInvoicePayout.program,
             payout: latestInvoicePayout,
           }),
         })
       : Promise.resolve(),
-  ]);
+]);

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.654Z
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.

Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.

Learnt from: devkiran
PR: dubinc/dub#2448
File: packages/email/src/templates/partner-program-summary.tsx:0-0
Timestamp: 2025-05-29T04:45:18.504Z
Learning: In the PartnerProgramSummary email template (packages/email/src/templates/partner-program-summary.tsx), the stat titles are hardcoded constants ("Clicks", "Leads", "Sales", "Earnings") that will always match the ICONS object keys after toLowerCase() conversion, so icon lookup failures are not possible.

Learnt from: devkiran
PR: dubinc/dub#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.654Z
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.

Learnt from: devkiran
PR: dubinc/dub#2448
File: packages/email/src/templates/partner-program-summary.tsx:254-254
Timestamp: 2025-05-29T04:49:42.842Z
Learning: In the Dub codebase, it's acceptable to keep `partners.dub.co` hardcoded rather than making it configurable for different environments.

Learnt from: devkiran
PR: dubinc/dub#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.654Z
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.

Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.

apps/web/app/(ee)/partners.dub.co/(dashboard)/payouts/partner-payout-settings-sheet.tsx (3)

147-148: TypeScript ignore comment is acceptable but document the reasoning.

The @ts-ignore for trailingZeroDisplay is reasonable since it's a newer API not yet reflected in TypeScript definitions. Consider adding a brief comment explaining this is a legitimate newer option.

-                    // @ts-ignore – trailingZeroDisplay is a valid option but TS is outdated
+                    // @ts-ignore – trailingZeroDisplay is a valid Intl.NumberFormat option but TS definitions are outdated
                     trailingZeroDisplay: "stripIfInteger",

---

205-205: Consider removing autoFocus for better accessibility.

Auto-focusing the business name input when the sheet opens can be jarring for users, especially those using screen readers or keyboard navigation. Consider letting users naturally tab to the first field they want to interact with.

-                    autoFocus
                     className="block w-full rounded-md border-neutral-300 text-neutral-900 placeholder-neutral-400 focus:border-neutral-500 focus:outline-none focus:ring-neutral-500 sm:text-sm"

---

268-284: Simplify the hook implementation.

The current pattern with useCallback wrapping the component and then useMemo for the return value is overly complex. This can be simplified while maintaining the same functionality.

 export function usePartnerPayoutSettingsSheet() {
   const [showPartnerPayoutSettingsSheet, setShowPartnerPayoutSettingsSheet] =
     useState(false);

-  const PartnerPayoutSettingsSheetCallback = useCallback(() => {
-    return (
-      <PartnerPayoutSettingsSheet
-        showPartnerPayoutSettingsSheet={showPartnerPayoutSettingsSheet}
-        setShowPartnerPayoutSettingsSheet={setShowPartnerPayoutSettingsSheet}
-      />
-    );
-  }, [showPartnerPayoutSettingsSheet, setShowPartnerPayoutSettingsSheet]);
-
-  return useMemo(
-    () => ({
+  const PartnerPayoutSettingsSheetComponent = () => (
+    <PartnerPayoutSettingsSheet
+      showPartnerPayoutSettingsSheet={showPartnerPayoutSettingsSheet}
+      setShowPartnerPayoutSettingsSheet={setShowPartnerPayoutSettingsSheet}
+    />
+  );
+
+  return {
     setShowPartnerPayoutSettingsSheet,
-    PartnerPayoutSettingsSheet: PartnerPayoutSettingsSheetCallback,
-  }),
-  [setShowPartnerPayoutSettingsSheet, PartnerPayoutSettingsSheetCallback],
-);
+    PartnerPayoutSettingsSheet: PartnerPayoutSettingsSheetComponent,
+  };
 }

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.654Z
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.

Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.

apps/web/app/(ee)/api/stripe/connect/webhook/balance-available.ts (1)

99-119: Consider handling pagination for transfers.

The code fetches only up to 100 transfers. If a partner has more than 100 transfers, some payouts might not get their stripePayoutId updated.

Implement pagination to handle all transfers:

-const transfers = await stripe.transfers.list({
-  destination: stripeAccount,
-  limit: 100,
-});
+const allTransfers = [];
+let hasMore = true;
+let startingAfter = undefined;
+
+while (hasMore) {
+  const transfers = await stripe.transfers.list({
+    destination: stripeAccount,
+    limit: 100,
+    starting_after: startingAfter,
+  });
+  
+  allTransfers.push(...transfers.data);
+  hasMore = transfers.has_more;
+  if (hasMore && transfers.data.length > 0) {
+    startingAfter = transfers.data[transfers.data.length - 1].id;
+  }
+}
+
 await prisma.payout.updateMany({
   where: {
     status: "sent",
     stripePayoutId: null,
     stripeTransferId: {
-      in: transfers.data.map(({ id }) => id),
+      in: allTransfers.map(({ id }) => id),
     },
   },
   data: {
     stripePayoutId: payout.id,
   },
 });

apps/web/app/(ee)/api/stripe/connect/webhook/balance-available.ts (1)

12-14: Minor: Improve error message clarity.

The error message refers to stripeAccount in the message but it could be null, which might be confusing in logs.

-    console.error(
-      `Stripe connect account ${stripeAccount} not found. Skipping...`,
-    );
+    console.error(
+      "Stripe connect account not found in webhook event. Skipping...",
+    );

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.654Z
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.

Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.

Learnt from: devkiran
PR: dubinc/dub#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.654Z
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.

Learnt from: devkiran
PR: dubinc/dub#2448
File: packages/email/src/templates/partner-program-summary.tsx:0-0
Timestamp: 2025-05-29T04:45:18.504Z
Learning: In the PartnerProgramSummary email template (packages/email/src/templates/partner-program-summary.tsx), the stat titles are hardcoded constants ("Clicks", "Leads", "Sales", "Earnings") that will always match the ICONS object keys after toLowerCase() conversion, so icon lookup failures are not possible.

Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.