Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CRPR: stack-auth/stack-auth#0File: AGENTS.md:0-0Timestamp: 2025-10-20T22:25:40.427ZLearning: Applies to apps/backend/src/app/api/latest/**/route.ts : In backend API routes, use the custom route handler system to ensure consistent API responses

apps/dashboard/src/components/data-table/transaction-table.tsx (1)

131-139:USD-only handling remains unresolved.

This issue was already flagged in a previous review. The function still only displays USD amounts and shows '—' for all other currencies, which blanks the amount column for non-USD tenants. Please refer to the previous review comment for the proposed solution.

apps/dashboard/src/components/data-table/transaction-table.tsx (2)

51-58:Consider simplifying the redundant check.

The condition at line 56 returns'other' when aproductGrant exists without subscription or purchase IDs, but line 57 also returns'other' as the default. Since both paths lead to the same result, line 56 can be removed.

Apply this diff:

 function deriveSourceType(transaction: Transaction): SourceType {   if (transaction.entries.some(isItemQuantityChangeEntry)) return 'item_quantity_change';   const productGrant = transaction.entries.find(isProductGrantEntry);   if (productGrant?.subscription_id) return 'subscription';   if (productGrant?.one_time_purchase_id) return 'one_time';-  if (productGrant) return 'other';   return 'other'; }

---

86-89:Improve type safety in the default fallback.

Theas any cast suppresses type checking. SincetransactionType is typed asTransactionType | null, the default case should only handlenull. Consider using a type-safe fallback.

Apply this diff:

     default: {-      return { label: (transactionType as any) ?? '—', Icon: CircleHelp };+      return { label: transactionType ?? 'Unknown', Icon: CircleHelp };     }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/dashboard/src/components/data-table/transaction-table.tsx (2)

131-139:Fix amount display for non-USD charges.

This issue was flagged in a previous review and remains unresolved.pickChargedAmountDisplay only returns USD amounts; all other currencies render as'—', which blanks the amount column for non-USD tenants.

---

192-218:Fix critical type mismatch in transaction filtering logic.

This issue was flagged in a previous review and remains unresolved. The column returnsSourceType values but the toolbar populates the filter dropdown withTransactionType values fromTRANSACTION_TYPES. These value sets don't overlap, so filtering will never match and always return empty results.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

125-146:Net amount is forced to USD "0" for non‑USD charges.

This issue was flagged in a previous review and remains unresolved. If a purchase is denominated solely in a non-USD currency (e.g., EUR), this code emitsnet_amount: { USD: "0" }, causing downstream reporting to falsely record zero revenue.

This is compounded by the schema constraint inpackages/stack-shared/src/interface/crud/transactions.ts (lines 90-92) that only allows USD innet_amount.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

263-291:Unused parameter in buildItemQuantityChangeTransaction.

Thetenancy parameter is accepted but never used in the function body. Consider removing it if it's not needed, or add a comment explaining why it's reserved for future use.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

124-145:Net amount is forced to USD "0" for non‑USD charges.

This issue was already identified in a previous review. When a purchase is denominated solely in EUR or another non-USD currency, this code still emitsnet_amount: { USD: "0" }, falsely recording zero revenue. Thenet_amount should reflect the actual charged currencies instead of fabricating zero USD values.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (2)

30-52:Consider validating the fallback structure.

Theas ProductSnapshot cast on line 41 bypasses type checking. While the structure appears complete, ifProductSnapshot evolves, this could lead to runtime type mismatches.

Consider using a schema validator or ensuring all fields match the expected type explicitly:

   return {     display_name: options.displayName,     customer_type: options.customerType,     prices: {},     stackable: false,     server_only: false,     included_items: {},+    client_metadata: null,+    client_read_only_metadata: null,+    server_metadata: null,-  } as ProductSnapshot;+  };

---

172-260:Consider extracting shared logic from subscription and one-time purchase builders.

buildSubscriptionTransaction andbuildOneTimePurchaseTransaction share nearly identical logic (~45 lines of duplication), differing only in which ID field they pass tocreateProductGrantEntry. Extracting common logic would improve maintainability.

Consider creating a shared helper:

functionbuildPurchaseTransaction(options:{entity:Subscription|OneTimePurchase,idField:{subscriptionId?:string}|{oneTimePurchaseId?:string},}):Transaction{const{ entity, idField}=options;constcustomerType=typedToLowercase(entity.customerType);constproduct=entity.productasInferType<typeofproductSchema>|null;constproductSnapshot=ensureProductSnapshot(product,customerType);constselectedPrice=product ?resolveSelectedPriceFromProduct(product,entity.priceId??null) :null;constquantity=entity.quantity;constchargedAmount=buildChargedAmount(selectedPrice,quantity);consttestMode=entity.creationSource==="TEST_MODE";constentries:TransactionEntry[]=[createProductGrantEntry({      customerType,customerId:entity.customerId,productId:entity.productId??null,product:productSnapshot,priceId:entity.priceId??null,      quantity,      ...idField,}),];constmoneyTransfer=createMoneyTransferEntry({    customerType,customerId:entity.customerId,    chargedAmount,skip:testMode,});if(moneyTransfer){entries.push(moneyTransfer);}return{id:entity.id,created_at_millis:entity.createdAt.getTime(),effective_at_millis:entity.createdAt.getTime(),type:"purchase",    entries,adjusted_by:[],test_mode:testMode,};}exportfunctionbuildSubscriptionTransaction(options:{subscription:Subscription}):Transaction{returnbuildPurchaseTransaction({entity:options.subscription,idField:{subscriptionId:options.subscription.id},});}exportfunctionbuildOneTimePurchaseTransaction(options:{purchase:OneTimePurchase}):Transaction{returnbuildPurchaseTransaction({entity:options.purchase,idField:{oneTimePurchaseId:options.purchase.id},});}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/stack-shared/src/interface/admin-interface.ts (1)

598-611:Method signature correctly updated to new Transaction model.

The method signature, query construction, and return type are all correctly updated to useTransaction andTransactionType. The implementation properly handles optional parameters and builds the query string as needed.

Consider extractingcustomerType to a type definition similar toTransactionType for consistency:

Inpackages/stack-shared/src/interface/crud/transactions.ts, add:

exportconstCUSTOMER_TYPES=['user','team','custom']asconst;exporttypeCustomerType=(typeofCUSTOMER_TYPES)[number];

Then update this method signature:

-async listTransactions(params?: { cursor?: string, limit?: number, type?: TransactionType, customerType?: 'user' | 'team' | 'custom' }): Promise<{ transactions: Transaction[], nextCursor: string | null }>+async listTransactions(params?: { cursor?: string, limit?: number, type?: TransactionType, customerType?: CustomerType }): Promise<{ transactions: Transaction[], nextCursor: string | null }>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro