The latest updates on your projects. Learn more about Vercel for Git ↗︎

Walkthrough

This change introduces comprehensive payout limit validation across backend and frontend components. It ensures that the total payout amount, combined with existing usage, does not exceed the workspace's payout limit. Enhanced error handling and user-facing tooltips are added to inform users when limits are exceeded, with suggestions to upgrade their plan.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant UI
    participant Backend
    participant DB

    User->>UI: Initiate payout confirmation
    UI->>Backend: Request to confirm payout (with amount)
    Backend->>DB: Fetch workspace payoutsUsage and payoutsLimit
    Backend->>Backend: Calculate new total payout amount
    alt Exceeds payoutsLimit
        Backend->>UI: Return exceededLimitError
        UI->>User: Show tooltip with upgrade suggestion
    else Within limit
        Backend->>DB: Update payoutsUsage
        Backend->>UI: Confirm payout success
        UI->>User: Show confirmation
    end

Possibly related PRs

• dubinc/dub#2572: Modifies the same confirmPayouts function for SEPA debit payout currency conversion, directly overlapping the payout logic.
• dubinc/dub#2485: Switches payout limit tracking fields and logic, directly related to the enhanced payout usage and limit validation in this PR.
• dubinc/dub#2569: Implements dynamic payout fee calculation and workspace-level payoutFee integration in the confirmPayouts function, complementing the limit validation here.

Poem

A rabbit hops and checks the sum,
No payouts past the limit come!
If you try to leap too high,
A tooltip gently tells you why.
Upgrade, upgrade, the carrot’s near—
With limits clear, there’s naught to fear!
🥕✨

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

@CodeRabbit final review

#!/bin/bash
# Get the diff for this PR to understand what changes were made
echo "=== PR DIFF ==="
git diff HEAD~1..HEAD

echo -e "\n=== FILES CHANGED ==="
git diff --name-only HEAD~1..HEAD

echo -e "\n=== DETAILED CHANGES PER FILE ==="
for file in $(git diff --name-only HEAD~1..HEAD); do
    echo "=== Changes in $file ==="
    git diff HEAD~1..HEAD -- "$file"
    echo -e "\n"
done

#!/bin/bash
# Let's examine the files mentioned in the PR directly
echo "=== Reading confirm-payouts.ts (API cron job) ==="
cat "apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts"

echo -e "\n=== Reading confirm-payouts.ts (actions) ==="
cat "apps/web/lib/actions/partners/confirm-payouts.ts"

echo -e "\n=== Reading errors.ts ==="
cat "apps/web/lib/api/errors.ts"

echo -e "\n=== Reading payout-invoice-sheet.tsx ==="
cat "apps/web/ui/partners/payout-invoice-sheet.tsx"

@steven-tey I've completed a comprehensive review of the payouts limit implementation. Here are my findings:

🚨 Critical Issues

1. Logic Error in Server Action (High Priority)

// apps/web/lib/actions/partners/confirm-payouts.ts:30-34
if (
  workspace.payoutsUsage + workspace.payoutsLimit >
  workspace.payoutsLimit
) {

Issue: This condition will always be true when payoutsUsage > 0, which is incorrect.
Fix: Should check against the actual payout amount:

// Need to fetch payout amount first, then check:
if (workspace.payoutsUsage + payoutAmount > workspace.payoutsLimit) {

2. Inconsistent Limit Checking Logic

The limit checking appears in 3 different places with different implementations:

• Server action (incorrect logic)
• API cron job (correct logic)
• UI component (correct logic)

This creates maintenance risk and potential bugs.

🔧 Recommendations

Consolidate Limit Checking

Create a centralized utility function:

// lib/partners/payout-limits.ts
export function checkPayoutLimits({
  currentUsage,
  limit,
  additionalAmount,
}: {
  currentUsage: number;
  limit: number;
  additionalAmount: number;
}) {
  return currentUsage + additionalAmount <= limit;
}

Improve Error Handling

In the API cron job, consider handling these edge cases:

• What happens if Stripe payment intent creation fails after invoice creation?
• Database rollback strategy for partial failures during email sending

Security Enhancement

Consider adding rate limiting to the confirm payouts action to prevent abuse.

✅ What's Working Well

1. Excellent Error Messaging: The exceededLimitError function provides user-friendly, contextual error messages
2. Proper Transaction Management: Good use of Prisma transactions in the API cron job
3. Currency Conversion Logic: Well-implemented with proper error handling for exchange rates
4. UI/UX: The payout invoice sheet provides excellent user experience with real-time calculations
5. Type Safety: Consistent use of TypeScript and Zod validation throughout
6. Email Notifications: Smart batching and conditional sending based on payment method type

🎯 Minor Improvements

1. Constants: Move magic numbers like 100 (batch size) to constants
2. Logging: Consider adding more structured logging for debugging
3. Testing: The complex currency conversion logic would benefit from unit tests

Summary

This is a well-architected implementation of a complex financial feature. The primary concern is the critical logic error in the server action that needs immediate attention. Once fixed, the limit checking logic should be centralized to prevent future inconsistencies.

The code demonstrates good practices in error handling, user experience, and payment processing. With the suggested fixes, this will be a robust payouts system.

@CodeRabbit final review

#!/bin/bash
# Read all the files involved in the payouts limit implementation to provide final review
echo "=== 1. API Cron Job - confirm-payouts.ts ==="
cat "apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts"

echo -e "\n=== 2. Server Action - confirm-payouts.ts ==="
cat "apps/web/lib/actions/partners/confirm-payouts.ts"

echo -e "\n=== 3. Error Handling - errors.ts ==="
cat "apps/web/lib/api/errors.ts"

echo -e "\n=== 4. UI Component - payout-invoice-sheet.tsx ==="
cat "apps/web/ui/partners/payout-invoice-sheet.tsx"

echo -e "\n=== 5. Check for any related test files ==="
fd -t f -e ts -e tsx . | grep -i "payout.*test\|test.*payout" || echo "No payout test files found"

echo -e "\n=== 6. Check if there are any utility functions for payout limits ==="
fd -t f -e ts . | xargs grep -l "payoutLimit\|payout.*limit" | head -10

@steven-tey Here's my final comprehensive review of the payouts limit implementation:

🚨 Critical Issue Still Present

The server action contains a critical logic error that must be fixed before deployment:

// apps/web/lib/actions/partners/confirm-payouts.ts:30-36
if (workspace.payoutsUsage > workspace.payoutsLimit) {
  throw new Error(
    exceededLimitError({
      plan: workspace.plan,
      limit: workspace.payoutsLimit,
      type: "payouts",
    }),
  );
}

Problem: This only checks current usage against the limit, but doesn't validate that the new payout amount won't exceed the limit.

Security Risk: Users could potentially bypass limits by staying under the current limit while adding payouts that would exceed it.

Required Fix:

// Need to fetch pending payout amount first, then check:
const pendingPayoutAmount = await calculatePendingPayoutAmount(workspaceId, cutoffPeriod);
if (workspace.payoutsUsage + pendingPayoutAmount > workspace.payoutsLimit) {
  // throw error
}

✅ What's Working Correctly

API Cron Job - Excellent Implementation

• Correct Logic: workspace.payoutsUsage + payoutAmount > workspace.payoutsLimit
• Proper Transaction Management: Uses Prisma transactions correctly
• Currency Conversion: Well-implemented with Stripe FX quotes and fallback handling
• Email Handling: Smart batching for direct debit notifications
• Error Handling: Comprehensive error handling with proper rollback

UI Component - Great User Experience

• Correct Logic: payoutsUsage + amount > payoutsLimit
• Excellent UX: Disabled button with informative tooltip when limits exceeded
• Real-time Calculations: Dynamic fee and total calculations
• Upgrade Path: Direct link to billing upgrade when limits hit

Error Handling - Professional Implementation

• Currency Formatting: Proper formatting for payout limits (currencyFormatter(limit / 100))
• Contextual Messaging: Clear, actionable error messages
• Consistent API: Well-structured error response format

🔧 Recommendations

1. Immediate Fix Required

Fix the server action logic before deployment to prevent security vulnerabilities.

2. Centralize Limit Checking

Create a shared utility to prevent future inconsistencies:

// lib/partners/payout-limits.ts
export async function validatePayoutLimits({
  workspaceId,
  currentUsage,
  limit,
  cutoffPeriod,
}: {
  workspaceId: string;
  currentUsage: number;
  limit: number;
  cutoffPeriod?: string;
}) {
  const pendingAmount = await calculatePendingPayoutAmount(workspaceId, cutoffPeriod);
  return {
    isValid: currentUsage + pendingAmount <= limit,
    pendingAmount,
    wouldExceedBy: Math.max(0, (currentUsage + pendingAmount) - limit),
  };
}

3. Add Unit Tests

The complex currency conversion and limit validation logic would benefit from comprehensive test coverage.

Summary

This is a well-architected financial feature with excellent error handling, user experience, and payment processing logic. The implementation demonstrates good practices in transaction management, currency handling, and user feedback.

However, the critical logic error in the server action creates a significant security vulnerability that must be addressed immediately. Once fixed and the limit checking logic is centralized, this will be a robust and production-ready payouts system.

The quality of the API cron job, UI components, and error handling gives me confidence that this team can deliver excellent financial software with the proper attention to security details.

@CodeRabbit that's fine cause we check again in /cron/payouts, and it'll fail if the amount + usage exceeds limit

@steven-tey Ah, that makes perfect sense! Thank you for the clarification. You're absolutely right - this is a well-designed two-stage validation pattern:

1. Server Action: Quick sanity check (payoutsUsage > payoutsLimit) for immediate user feedback
2. Cron Job: Authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing

This is actually a smart architectural approach for financial systems where you want to:

• Give users immediate feedback without expensive calculations
• Ensure final validation happens at the point of actual transaction processing

I appreciate you taking the time to explain the design intent. The implementation is solid, and the comprehensive validation in the cron job with proper transaction management ensures the limits are enforced correctly where it matters most.

Great work on this payouts system! 🚀

Learnt from: steven-tey
URL: https://github.com/dubinc/dub/pull/2577

Timestamp: 2025-06-25T21:20:59.785Z
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.