apps/e2e/tests/snapshot-serializer.ts (1)

1-259: Redact Stripe account IDs in snapshots
We discovered raw acct_ tokens in your e2e tests—which will leak real Stripe account IDs into CI logs and snapshots. We need to ensure they’re always stripped by the serializer (and tests use placeholders).

• Locations to fix:

• apps/e2e/tests/backend/endpoints/api/v1/internal/payments/setup.test.ts (lines 105, 124, 138) contain "acct_1PgafTB7WZ01zgkW" in URL strings.
  • Serializer changes:

1. In apps/e2e/tests/snapshot-serializer.ts, extend stringRegexReplacements (or add a new regex override) to match /(acct_[A-Za-z0-9]{6,})/g and replace with "<stripped stripe account id>".
2. Ensure this runs before falling back to default serialization.
   • Test updates:

• Replace hard-coded acct_ IDs in those tests with a stable placeholder (e.g. <stripped stripe account id>) so snapshots remain consistent and don’t leak secrets.

Making these changes will prevent unredacted Stripe account IDs from slipping through snapshots or logs.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sidebar-layout.tsx (1)

263-279: Fix breadcrumb link: Webhooks detail points to Teams

The hidden breadcrumb for a webhook detail page sets href to /teams/... instead of /webhooks/..., leading to incorrect navigation.

-        href = `/teams/${match[1]}`;
+        href = `/webhooks/${match[1]}`;

packages/stack-shared/src/utils/numbers.tsx (1)

2-6: Fix magnitude suffixes for trillion and quadrillion

The current mapping in packages/stack-shared/src/utils/numbers.tsx treats 1 × 10¹² as “bln” (billion) and 1 × 10¹⁵ as “trln” (trillion), but by short-scale convention:

• 1 × 10¹² should be “trln” (trillion)
• 1 × 10¹⁵ should be “qdln” (quadrillion)

Please update both the magnitude definitions and the corresponding tests.

• File: packages/stack-shared/src/utils/numbers.tsx
– Lines 2–3 (magnitudes array entries)
• File: packages/stack-shared/src/utils/numbers.tsx
– Lines 31–34 (unit tests for 1e12 and 1e15)

 const magnitudes = [
-  [1_000_000_000_000_000, "trln"],
-  [1_000_000_000_000, "bln"],
+  [1_000_000_000_000_000, "qdln"], // quadrillion
+  [1_000_000_000_000, "trln"],     // trillion
   [1_000_000_000,       "bn"],
   [1_000_000,           "M"],
   [1_000,               "k"],
 ] as const;

-  expect(prettyPrintWithMagnitudes(1000000000000)).toBe("1bln");
-  expect(prettyPrintWithMagnitudes(1500000000000)).toBe("1.5bln");
-  expect(prettyPrintWithMagnitudes(1000000000000000)).toBe("1trln");
-  expect(prettyPrintWithMagnitudes(1500000000000000)).toBe("1.5trln");
+  expect(prettyPrintWithMagnitudes(1000000000000)).toBe("1trln");
+  expect(prettyPrintWithMagnitudes(1500000000000)).toBe("1.5trln");
+  expect(prettyPrintWithMagnitudes(1000000000000000)).toBe("1qdln");
+  expect(prettyPrintWithMagnitudes(1500000000000000)).toBe("1.5qdln");

If your product copy uses alternative abbreviations (e.g., “tn” for trillion or “q” for quadrillion), please apply them consistently across both code and tests.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/dummy-data.tsx (1)

1-279: Wrap dummy-data import in a development-only guard

The static import of DUMMY_PAYMENTS_CONFIG in your payments page is unguarded and will be bundled into production builds. You should only load this file when running in development mode.

• apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/payments/page-client.tsx:16

import { DUMMY_PAYMENTS_CONFIG } from "./dummy-data";

– Move this into a process.env.NODE_ENV === "development" check or switch to a dynamic import() so it isn’t included in production.

Suggested refactor example:

- import { DUMMY_PAYMENTS_CONFIG } from "./dummy-data";
+ let DUMMY_PAYMENTS_CONFIG: typeof import("./dummy-data").DUMMY_PAYMENTS_CONFIG;
+
+ if (process.env.NODE_ENV === "development") {
+   // dynamically load dev-only dummy data
+   import("./dummy-data").then(mod => {
+     DUMMY_PAYMENTS_CONFIG = mod.DUMMY_PAYMENTS_CONFIG;
+   });
+ }

apps/backend/src/app/api/latest/payments/items/[customer_type]/[customer_id]/[item_id]/update-quantity/route.ts (1)

60-82: Ensure balance check occurs after ledger insertion within the same transaction

This route still performs the “read → check → insert” flow, which allows two concurrent requests to both observe a non‐negative balance and each insert a debit, potentially driving the total negative despite allowNegative = false. To guarantee correctness under concurrency, move the insufficient‐funds check to after tx.itemQuantityChange.create(...) within the same transaction so that any negative resulting total triggers a rollback.

Files to update:

• apps/backend/src/app/api/latest/payments/items/[customer_type]/[customer_id]/[item_id]/update-quantity/route.ts (around lines 60–82)

Suggested minimal diff:

-    const changeId = await retryTransaction(prisma, async (tx) => {
-      const totalQuantity = await getItemQuantityForCustomer({
-        prisma: tx,
-        tenancy,
-        itemId: req.params.item_id,
-        customerId: req.params.customer_id,
-        customerType: req.params.customer_type,
-      });
-      if (!allowNegative && (totalQuantity + req.body.delta < 0)) {
-        throw new KnownErrors.ItemQuantityInsufficientAmount(req.params.item_id, req.params.customer_id, req.body.delta);
-      }
-      const change = await tx.itemQuantityChange.create({
+    const changeId = await retryTransaction(prisma, async (tx) => {
+      const change = await tx.itemQuantityChange.create({
         data: {
           tenancyId: tenancy.id,
           customerId: req.params.customer_id,
           itemId: req.params.item_id,
           quantity: req.body.delta,
           description: req.body.description,
           expiresAt: req.body.expires_at ? new Date(req.body.expires_at) : null,
         },
       });
+      const totalQuantity = await getItemQuantityForCustomer({
+        prisma: tx,
+        tenancy,
+        itemId: req.params.item_id,
+        customerId: req.params.customer_id,
+        customerType: req.params.customer_type,
+      });
+      if (!allowNegative && totalQuantity < 0) {
+        // rollback this transaction
+        throw new KnownErrors.ItemQuantityInsufficientAmount(req.params.item_id, req.params.customer_id, req.body.delta);
+      }
       return change.id;
     });

No other usages of getItemQuantityForCustomer combined with allowNegative checks were found in the payments API, so this is the sole location requiring update.

apps/backend/src/app/api/latest/integrations/stripe/webhooks/route.tsx (1)

69-77: Handle Stripe “customer” Expandable correctly.

In many events, data.object.customer can be an Expandable (object) or a string. Current typeof check rejects valid webhook payloads when it’s an object.

Apply this diff to support both:

-        const customerId = (event.data.object as any).customer;
+        const rawCustomer = (event.data.object as any).customer;
+        const customerId = typeof rawCustomer === "string" ? rawCustomer : rawCustomer?.id;
         if (!accountId) {
           throw new StackAssertionError("Stripe webhook account id missing", { event });
         }
-        if (typeof customerId !== 'string') {
+        if (typeof customerId !== 'string' || !customerId) {
           throw new StackAssertionError("Stripe webhook bad customer id", { event });
         }
         await syncStripeSubscriptions(accountId, customerId);

apps/backend/src/app/api/latest/internal/payments/setup/route.ts (1)

36-56: Prevent race conditions when creating Stripe accounts

The current code unconditionally checks for a null stripeAccountId, calls stripe.accounts.create, then immediately does a project.update. Two concurrent requests can both see stripeAccountId == null, each create an account, and the last update “wins,” leaving the other account orphaned.

To fix:

• Use an optimistic conditional update so only one request “wins” setting the ID, and the loser re-reads the stored ID.
• Add an idempotency key to stripe.accounts.create so duplicate API calls within a short window return the original account instead of creating a second one.

Locations to update (apps/backend/src/app/api/latest/internal/payments/setup/route.ts around lines 36–56):

     if (!stripeAccountId) {
       // Create a new Stripe account with an idempotency key
-      const account = await stripe.accounts.create({
+      const account = await stripe.accounts.create(
+        {
           controller: { stripe_dashboard: { type: "none" } },
           capabilities: {
             card_payments: { requested: true },
             transfers:     { requested: true },
           },
           country: "US",
           metadata: { tenancyId: auth.tenancy.id },
-      });
-      stripeAccountId = account.id;
-
-      await globalPrismaClient.project.update({
-        where: { id: auth.project.id },
-        data: { stripeAccountId },
-      });
+        },
+        { idempotencyKey: `project-${auth.project.id}` }  // prevents duplicate account creation ([github.com](https://github.com/stripe/stripe-node/wiki/Passing-Options?utm_source=openai))
+      );
+      stripeAccountId = account.id;
+
+      // Only set stripeAccountId if still null (first-writer wins)
+      const { count } = await globalPrismaClient.project.updateMany({
+        where: { id: auth.project.id, stripeAccountId: null },
+        data: { stripeAccountId },
+      });
+      if (count === 0) {
+        // Another request already set it; reuse that ID
+        const existing = await globalPrismaClient.project.findUnique({
+          where:  { id: auth.project.id },
+          select: { stripeAccountId: true },
+        });
+        stripeAccountId = existing?.stripeAccountId ?? stripeAccountId;
+        // Optional: enqueue cleanup of the now-unreferenced account
+      }

This ensures only one Stripe account is ever tied to the project, and redundant API calls within the idempotency window return the same account rather than creating extras.

apps/dashboard/src/components/payments/price-editor.tsx (1)

58-62: Bug: toFormValue returns a string but schema expects an object.

When value is a string, returning it directly will break FormDialog defaults (schema requires id/USD/interval). Return a normalized object instead.

Apply this diff:

-        toFormValue: (id: string, value: OfferPrice) => typeof value === "string" ? value : ({
-          id,
-          USD: value.USD,
-          interval: value.interval,
-        }),
+        toFormValue: (id: string, value: OfferPrice | string) => (
+          typeof value === "string"
+            ? { id, USD: value, interval: undefined }
+            : { id, USD: value.USD, interval: value.interval }
+        ),

apps/backend/src/app/api/latest/payments/purchases/create-purchase-url/route.ts (2)

45-47: Escape customer_id in Stripe search query

Unescaped quotes in customer_id can break the Stripe search filter. Escape single quotes.

Apply:

-    const stripeCustomerSearch = await stripe.customers.search({
-      query: `metadata['customerId']:'${req.body.customer_id}'`,
-    });
+    const customerIdEscaped = req.body.customer_id.replaceAll("'", "\\'");
+    const stripeCustomerSearch = await stripe.customers.search({
+      query: `metadata['customerId']:'${customerIdEscaped}'`,
+    });

---

51-55: Add support for CUSTOM customer type in metadata mapping and validation

The CustomerType enum includes CUSTOM, so we must handle it in both the purchase URL creation and the Stripe metadata validation.

• apps/backend/src/app/api/latest/payments/purchases/create-purchase-url/route.ts (around line 53)

 metadata: {
   customerId: req.body.customer_id,
-    customerType: customerType === "user" ? CustomerType.USER : CustomerType.TEAM,
+    customerType:
+      customerType === "user" ? CustomerType.USER :
+      customerType === "team" ? CustomerType.TEAM :
+      CustomerType.CUSTOM,
 }

• apps/backend/src/lib/stripe.tsx (around line 54)
Update the guard so that CUSTOM is accepted rather than treated as invalid:

 if (
-    customerType !== CustomerType.USER &&
-    customerType !== CustomerType.TEAM
+    customerType !== CustomerType.USER &&
+    customerType !== CustomerType.TEAM &&
+    customerType !== CustomerType.CUSTOM
 ) {
   throw new StackAssertionError("Stripe customer metadata has invalid customerType");
 }

apps/backend/src/lib/stripe.tsx (2)

72-86: Bug: using item.current_period_ (undefined) instead of subscription.current_period_**

Stripe’s SubscriptionItem has no current_period_end/start; those fields are on Subscription. This yields invalid dates (NaN). Use subscription.current_period_end/start for both update and create.

   update: {
     status: subscription.status,
     offer: JSON.parse(subscription.metadata.offer),
     quantity: item.quantity ?? 1,
-    currentPeriodEnd: new Date(item.current_period_end * 1000),
-    currentPeriodStart: new Date(item.current_period_start * 1000),
+    currentPeriodEnd: new Date(subscription.current_period_end * 1000),
+    currentPeriodStart: new Date(subscription.current_period_start * 1000),
     cancelAtPeriodEnd: subscription.cancel_at_period_end,
   },
   create: {
     tenancyId: tenancy.id,
     customerId,
     customerType,
     offerId: subscription.metadata.offerId,
     offer: JSON.parse(subscription.metadata.offer),
     quantity: item.quantity ?? 1,
     stripeSubscriptionId: subscription.id,
     status: subscription.status,
-    currentPeriodEnd: new Date(item.current_period_end * 1000),
-    currentPeriodStart: new Date(item.current_period_start * 1000),
+    currentPeriodEnd: new Date(subscription.current_period_end * 1000),
+    currentPeriodStart: new Date(subscription.current_period_start * 1000),
     cancelAtPeriodEnd: subscription.cancel_at_period_end,
     creationSource: "PURCHASE_PAGE"
   },

Also applies to: 97-101

---

67-75: Validate presence and shape of metadata.offer/offerId before JSON.parse

Upsert unconditionally parses subscription.metadata.offer and reads offerId; if missing or malformed, we’ll throw an opaque JSON error. Add targeted validation and clearer errors.

 for (const subscription of subscriptions.data) {
   if (subscription.items.data.length === 0) {
     continue;
   }
   const item = subscription.items.data[0];
+  if (!subscription.metadata?.offer || !subscription.metadata?.offerId) {
+    throw new StackAssertionError("Stripe subscription metadata missing 'offer' or 'offerId'", {
+      stripeSubscriptionId: subscription.id,
+      metadata: subscription.metadata,
+    });
+  }
+  let parsedOffer: unknown;
+  try {
+    parsedOffer = JSON.parse(subscription.metadata.offer);
+  } catch {
+    throw new StackAssertionError("Invalid JSON in subscription.metadata.offer", {
+      stripeSubscriptionId: subscription.id,
+    });
+  }
   await prisma.subscription.upsert({
     // ...
     update: {
       status: subscription.status,
-      offer: JSON.parse(subscription.metadata.offer),
+      offer: parsedOffer as any,
       quantity: item.quantity ?? 1,
       // ...
     },
     create: {
       // ...
-      offer: JSON.parse(subscription.metadata.offer),
+      offer: parsedOffer as any,
       quantity: item.quantity ?? 1,
       // ...
     },
   });
 }