Billing SDK Refactor #2722

ItzNotABug · 2025-12-18T14:40:35Z

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

Summary by CodeRabbit

New Features
- Unified organization/team listing and navigation across public and console flows.
- Consistent plan naming and improved plan selection/plan comparison UI.
Bug Fixes
- More reliable payment confirmations and retries; clearer error states and better coupon apply/remove feedback.
- Improved address and payment method flows (create/update/delete) with clearer notifications.
Refactor
- Billing and payment flows migrated to consolidated organization/account APIs and Appwrite Models for consistent behavior.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

…anual types.

…types!

replace: `billing.listOrganization` calls with `organizations.list`.

…tionDeleteOrganization`, `getOrganizationPlan` and `getRoles`.

appwrite · 2025-12-18T14:40:41Z

Console (appwrite/console)

Project ID: 688b7bf400350cbd60e9

Sites (1)

Site	Status	Logs	Preview	QR
console-stage `688b7cf6003b1842c9dc`	Ready	View Logs	Preview URL

Tip

Storage files get ClamAV malware scanning and encryption by default

coderabbitai · 2025-12-18T14:40:45Z

Walkthrough

The diff migrates the codebase from a legacy billing SDK surface to Appwrite Console Models and new console/account/organizations endpoints. It centralizes team/organization listing with getTeamOrOrganizationList, converts many positional SDK calls to object-shaped parameters, replaces tier utilities with billingIdToPlan and new plan helpers, and switches route/url construction to resolve-based paths. Many Svelte components, stores, and route loaders updated exported prop/types to Models.*, removed or reduced the old billing SDK types, and adjusted Stripe/confirmPayment and payment-method flows to account-scoped APIs.

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~150 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 15.79% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Billing SDK Refactor' clearly summarizes the main change—a refactoring of the billing SDK—and accurately reflects the extensive modifications throughout the codebase.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

📝 Generate docstrings

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

…od and its usages.

…hods and its usages.

coderabbitai

Actionable comments posted: 17

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (7)

src/routes/(console)/organization-[organization]/billing/availableCredit.svelte (1)
36-51: Add error handling to the API request.

The request() function lacks error handling. If the API call fails, the UI remains in an inconsistent state with no feedback to the user. This is inconsistent with similar components in the billing directory, which all wrap SDK calls in try-catch blocks.
🔎 Proposed fix to add error handling
 async function request() {
 if (!$organization?.$id) return;
 
 // fast path return!
 if (!areCreditsSupported) return;
 
 /**
 * The initial `creditList` from `+page.ts` can include up to 25 items by default.
 *
 * Technically, we could reuse that for offsets < 25 (i.e., the first 5 pages with limit = 5)
 * to avoid an extra request. But for now, we always fetch fresh data.
 */
- creditList = await sdk.forConsole.organizations.listCredits({
- organizationId: $organization.$id,
- queries: [Query.limit(limit), Query.offset(offset)]
- });
+ try {
+ creditList = await sdk.forConsole.organizations.listCredits({
+ organizationId: $organization.$id,
+ queries: [Query.limit(limit), Query.offset(offset)]
+ });
+ } catch (error) {
+ console.error('Failed to load credits:', error);
+ // Consider showing user feedback (toast/alert) here
+ return;
+ }
 
 creditList = {
src/lib/components/billing/selectPaymentMethod.svelte (1)
25-29: Avoid manually constructing SDK model objects.

Manually spreading and reconstructing Models.PaymentMethodList violates the principle that SDK models should be treated as immutable data from the API. This pattern can break if the SDK type has readonly properties, class methods, or internal state.

Consider refetching the payment methods list after adding a new card, or check if the SDK provides a method to update the list. The existing invalidate calls on lines 32-35 suggest this data will be refreshed anyway.
💡 Suggested refactor

Since you're already invalidating dependencies, consider removing the manual update and relying on the data refetch:
 async function cardSaved(card: Models.PaymentMethod) {
 value = card.$id;
 
- if (value) {
- methods = {
- ...methods,
- total: methods.total + 1,
- paymentMethods: [...methods.paymentMethods, card]
- };
- }
-
 await Promise.all([
 invalidate(Dependencies.UPGRADE_PLAN),
 invalidate(Dependencies.ORGANIZATION)
 ]);
 }
If immediate UI update is required before refetch, verify that the SDK models support this mutation pattern or use a local state approach that doesn't mutate the SDK model.
src/lib/stores/billing.ts (1)
534-552: Use organizations.getPaymentMethod instead of account.getPaymentMethod.

checkForMandate retrieves an organization's payment method but uses sdk.forConsole.account.getPaymentMethod without passing the organization ID. This differs from paymentExpired (line 470) which uses sdk.forConsole.organizations.getPaymentMethod with organizationId. For consistency and to ensure proper organization-level access control, use the same endpoint pattern as paymentExpired:
const paymentMethod = await sdk.forConsole.organizations.getPaymentMethod({
 organizationId: org.$id,
 paymentMethodId: paymentId
});
src/routes/(console)/create-organization/+page.ts (1)
45-57: Missing await in getCoupon causes the function to return a Promise instead of resolving it.

The try/catch block won't catch any errors from the SDK call because the promise is returned directly without awaiting. This means errors will propagate as unhandled promise rejections rather than being caught and returning null.
🔎 Proposed fix
 async function getCoupon(url: URL): Promise<Models.Coupon | null> {
 if (url.searchParams.has('code')) {
 const coupon = url.searchParams.get('code');
 try {
- return sdk.forConsole.account.getCoupon({
+ return await sdk.forConsole.account.getCoupon({
 couponId: coupon
 });
 } catch (e) {
 return null;
 }
 }
 return null;
 }
src/routes/(console)/organization-[organization]/billing/wizard/addCredit.svelte (1)
26-31: Incorrect error wrapping loses error details.

throw new Error(error) will call error.toString() which typically results in [object Object]. This loses the original error's stack trace and structured information.
🔎 Proposed fix
 } catch (error) {
 couponData.code = coupon;
 couponData.status = 'error';
 $wizard.interceptorNotificationEnabled = false;
- throw new Error(error);
+ throw error;
 }
src/routes/(public)/sites/deploy/+page.ts (1)
72-77: Inconsistent API call syntax - uses positional arguments instead of object syntax.

This file uses positional arguments for organizations.create:
await sdk.forConsole.organizations.create(
 ID.unique(),
 'Personal Projects',
 BillingPlan.FREE,
 null
);
Other files in this PR (e.g., src/routes/(public)/template-[template]/+page.ts lines 43-47 and src/routes/(public)/sites/deploy/+page.ts lines 88-92) use object syntax:
await sdk.forConsole.organizations.create({
 organizationId: ID.unique(),
 name: 'Personal Projects',
 billingPlan: BillingPlan.FREE
});
This positional syntax may be incorrect or deprecated. Please verify and align with the object-based syntax used elsewhere.
🔎 Suggested fix using object syntax
 if (isCloud) {
- await sdk.forConsole.organizations.create(
- ID.unique(),
- 'Personal Projects',
- BillingPlan.FREE,
- null
- );
+ await sdk.forConsole.organizations.create({
+ organizationId: ID.unique(),
+ name: 'Personal Projects',
+ billingPlan: BillingPlan.FREE
+ });
 } else {
src/routes/(public)/functions/deploy/+page.ts (1)
67-85: Same API syntax inconsistency as sites/deploy.

This file has the identical issue with positional arguments for organizations.create (lines 72-77) that was flagged in src/routes/(public)/sites/deploy/+page.ts. Please apply the same fix to use object syntax.
🔎 Suggested fix using object syntax
 if (isCloud) {
- await sdk.forConsole.organizations.create(
- ID.unique(),
- 'Personal Projects',
- BillingPlan.FREE,
- null
- );
+ await sdk.forConsole.organizations.create({
+ organizationId: ID.unique(),
+ name: 'Personal Projects',
+ billingPlan: BillingPlan.FREE
+ });
 } else {

🧹 Nitpick comments (19)

src/lib/flags.ts (1)

8-20: Consider removing unused code or clarifying its purpose.

The isFlagEnabled function is marked as unused and never called or exported. The file also exports an empty flags object (line 22), suggesting incomplete or placeholder implementation. Consider either:

Removing the unused function to reduce clutter

Adding a comment explaining why this code is being retained for future use
src/routes/(console)/organization-[organization]/billing/taxId.svelte (1)
20-23: LGTM! SDK refactor is correct.

The migration from sdk.forConsole.billing.updateTaxId to sdk.forConsole.organizations.setBillingTaxId with named parameters is well-executed and aligns with the PR objectives.

Optional: Consider adding null-safety for consistency.

Lines 15 and 49 use optional chaining on $organization, but line 21 directly accesses $organization.$id. While the route likely ensures the organization is loaded, adding optional chaining or an early return would improve consistency and defensive coding:
🔎 Optional refactor for null-safety
 async function updateTaxId() {
+    if (!$organization) return;
+    
     try {
         await sdk.forConsole.organizations.setBillingTaxId({
             organizationId: $organization.$id,
             taxId
         });
src/routes/(public)/(guest)/login/+page.ts (1)
8-27: API migration looks good; consider explicit typing for consistency.

The migration to console.getCoupon and console.getCampaign with object-based parameters is correct and matches the patterns in register/+page.ts and apply-credit/+page.ts.

For consistency with similar files in this refactor (e.g., register/+page.ts lines 7-8, apply-credit/+page.ts lines 6-7), consider explicitly typing couponData as Models.Coupon.
🔎 Optional: Add explicit type for consistency
     if (url.searchParams.has('code')) {
         const code = url.searchParams.get('code');
         let campaign: Models.Campaign;
+        let couponData: Models.Coupon;
         try {
-            const couponData = await sdk.forConsole.console.getCoupon({
+            couponData = await sdk.forConsole.console.getCoupon({
                 couponId: code
             });
src/lib/components/billing/alerts/paymentMandate.svelte (1)
10-15: Consider adding error handling for payment operations.

Payment verification failures should provide clear feedback to users. Wrapping the async operations in try-catch would improve the user experience.
🔎 Suggested error handling
 async function verifyPaymentMethod() {
+    try {
         const method = await sdk.forConsole.account.updatePaymentMethodMandateOptions({
             paymentMethodId: $paymentMissingMandate.$id
         });
         await confirmSetup(method.clientSecret, method.providerMethodId);
+    } catch (error) {
+        // Handle error appropriately (e.g., show toast notification)
+        console.error('Payment verification failed:', error);
+    }
 }
src/lib/components/billing/alerts/selectProjectCloud.svelte (1)
45-47: Consider typing the caught error for type safety.

The caught exception e is not typed, and accessing e.message directly is not type-safe. Consider typing it explicitly or using a type guard.
🔎 Suggested improvement
-} catch (e) {
-    error = e.message;
+} catch (e) {
+    error = e instanceof Error ? e.message : String(e);
 }
src/routes/(console)/account/payments/editPaymentModal.svelte (1)
30-32: Consider awaiting invalidate before showing the notification.

The invalidate(Dependencies.PAYMENT_METHODS) call is not awaited. If the user performs another action immediately after closing the modal, the payment methods list might not yet be refreshed, leading to stale data being displayed.
🔎 Proposed fix
             trackEvent(Submit.PaymentMethodUpdate);
-            invalidate(Dependencies.PAYMENT_METHODS);
+            await invalidate(Dependencies.PAYMENT_METHODS);
             show = false;
src/lib/components/billing/emptyCardCloud.svelte (1)
20-20: proPlanName is not reactive to store changes.

proPlanName is assigned once when the component initializes. If plansInfo store updates after mount (e.g., due to data refresh), this value won't update. Consider using $derived if reactivity is needed:
🔎 Proposed fix using $derived
-    const proPlanName = getBasePlanFromGroup(BillingPlanGroup.Pro).name;
+    const proPlanName = $derived(getBasePlanFromGroup(BillingPlanGroup.Pro).name);
However, if plan names are stable after initial load, the current implementation is acceptable.
src/routes/(console)/organization-[organization]/billing/deleteOrgPayment.svelte (1)
18-37: Inconsistent await usage for invalidate().

In removeDefaultMethod (line 30), invalidate() is called without await, while in removeBackupMethod (line 53), it's awaited. This inconsistency could lead to different behaviors—the backup method waits for cache invalidation before proceeding, while the default method does not.
🔎 Proposed fix for consistency
         trackEvent(Submit.OrganizationPaymentDelete);
-        invalidate(Dependencies.ORGANIZATION);
+        await invalidate(Dependencies.ORGANIZATION);
         showDelete = false;
Also applies to: 40-59
src/routes/(console)/organization-[organization]/domains/domain-[domain]/settings/+page.ts (1)
8-16: Add type annotation for the load function.

The load function is missing its PageLoad type annotation which other route loaders in the codebase use for type safety.
Suggested fix
+import type { PageLoad } from './$types';
-export const load = async ({ params, parent, depends }) => {
+export const load: PageLoad = async ({ params, parent, depends }) => {
src/routes/(console)/create-organization/+page.ts (1)
35-43: Simplify redundant conditional check.

The if (plan) check is redundant since url.searchParams.get('plan') returns null if the param doesn't exist, and the outer if already confirms the param exists.
🔎 Proposed simplification
-function getPlanFromUrl(url: URL): string | null {
-    if (url.searchParams.has('plan')) {
-        const plan = url.searchParams.get('plan');
-        if (plan) {
-            return plan;
-        }
-    }
-    return BillingPlan.FREE;
-}
+function getPlanFromUrl(url: URL): string {
+    return url.searchParams.get('plan') ?? BillingPlan.FREE;
+}
src/routes/+page.ts (1)
37-49: Inconsistent path construction between resolve() and base.

Line 39 uses resolve('/') while lines 43-48 use ${base}/.... This inconsistency could lead to different behavior depending on how the app is deployed.

Consider standardizing on one approach throughout the function for maintainability:
     if (userVisitedEducationPage()) {
         await handleGithubEducationMembership(account.name, account.email);
         redirect(303, resolve('/'));
     } else if (organizations.total && !isApplyingCredit) {
         const teamId = account.prefs.organization ?? organizations.teams[0].$id;
         if (!teamId) {
-            redirect(303, `${base}/account/organizations${url.search}`);
+            redirect(303, `${resolve('/(console)/account/organizations')}${url.search}`);
         } else {
-            redirect(303, `${base}/organization-${teamId}${url.search}`);
+            redirect(303, `${resolve(`/(console)/organization-${teamId}`)}${url.search}`);
         }
     } else if (!isApplyingCredit) {
-        redirect(303, `${base}/onboarding/create-project${url.search}`);
+        redirect(303, `${resolve('/(console)/onboarding/create-project')}${url.search}`);
     }
src/routes/(console)/account/organizations/+page.svelte (2)
40-47: Stale comment references old function name.

The comment on line 41 says "use tierToPlan" but the code now uses billingIdToPlan.
🔎 Proposed fix
-        // For known plans, use tierToPlan
+        // For known plans, use billingIdToPlan
         const tierData = billingIdToPlan(billingPlan);
76-84: Union type Models.Preferences | Models.Organization seems overly broad.

The function accepts Models.Preferences but then passes the value to isCloudOrg and isOrganizationOnTrial which expect Models.Organization. This works due to the type guard, but the signature is misleading since the function only returns a meaningful result for Models.Organization.

Consider narrowing the parameter type or documenting why Preferences is accepted:
     function isPayingOrganization(
-        team: Models.Preferences | Models.Organization
+        team: Models.Organization
     ): Models.Organization | null {
src/routes/(console)/organization-[organization]/billing/paymentMethods.svelte (1)
88-104: Missing error handling in reactive payment method fetches.

The reactive blocks that fetch payment methods don't handle errors. If the API calls fail, the promises are silently rejected which could leave the UI in an inconsistent state.
🔎 Proposed fix
     $: if (organization?.backupPaymentMethodId) {
         sdk.forConsole.organizations
             .getPaymentMethod({
                 organizationId: organization.$id,
                 paymentMethodId: organization.backupPaymentMethodId
             })
-            .then((res) => (backupPaymentMethod = res));
+            .then((res) => (backupPaymentMethod = res))
+            .catch(() => (backupPaymentMethod = null));
     }

     $: if (organization?.paymentMethodId) {
         sdk.forConsole.organizations
             .getPaymentMethod({
                 organizationId: organization.$id,
                 paymentMethodId: organization.paymentMethodId
             })
-            .then((res) => (defaultPaymentMethod = res));
+            .then((res) => (defaultPaymentMethod = res))
+            .catch(() => (defaultPaymentMethod = null));
     }
src/routes/(console)/organization-[organization]/change-plan/+page.ts (1)

31-36: Address the TODO or remove it.

The TODO comment questions the current implementation logic. If there's a known simplification, consider implementing it; otherwise, add context or remove the comment.
src/routes/(console)/organization-[organization]/billing/retryPaymentModal.svelte (1)
127-134: Inconsistent invalidate await pattern.

Line 97 awaits invalidate(Dependencies.PAYMENT_METHODS), but lines 133-134 do not await the invalidation calls. Consider awaiting these for consistency, or if intentional fire-and-forget, add a brief comment explaining why.
🔎 Suggested fix for consistent await pattern
-            invalidate(Dependencies.ORGANIZATION);
-            invalidate(Dependencies.INVOICES);
+            await invalidate(Dependencies.ORGANIZATION);
+            await invalidate(Dependencies.INVOICES);
src/lib/stores/stripe.ts (1)
88-94: Hardcoded base URL should use environment configuration.

The URL https://cloud.appwrite.io/console is hardcoded here and again at line 226. Consider using an environment variable or the existing base import from $app/paths combined with window.location.origin for consistency and flexibility across environments.
🔎 Suggested approach
-        const baseUrl = 'https://cloud.appwrite.io/console';
+        const baseUrl = `${window.location.origin}${base}`;
         const accountUrl = `${baseUrl}/account/payments?clientSecret=${clientSecret}`;
         const orgUrl = `${baseUrl}/organization-${organizationId}/billing?clientSecret=${clientSecret}`;
Apply the same pattern at line 226.
src/lib/components/billing/estimatedTotalBox.svelte (1)
27-31: Consider consistent couponId null handling.

The two estimation functions handle empty couponId differently:

getEstimate: couponId === '' ? null : couponId

getUpdatePlanEstimate: couponId && couponId.length > 0 ? couponId : null

Both approaches work, but the first could pass undefined as-is while the second explicitly converts to null. Consider unifying the logic for maintainability.
🔎 Suggested unified approach
 async function getEstimate(
     billingPlan: string,
     collaborators: string[],
     couponId: string | undefined
 ) {
     try {
         estimation = await sdk.forConsole.organizations.estimationCreateOrganization({
             billingPlan,
             invites: collaborators ?? [],
-            couponId: couponId === '' ? null : couponId
+            couponId: couponId?.length ? couponId : null
         });
Also applies to: 57-62
src/routes/(console)/onboarding/create-project/+page.ts (1)
64-64: Consider using union type for nullable assignment.

The variable is typed as Models.ProjectList but initialized to null. While TypeScript non-strict mode tolerates this, a more accurate type would be Models.ProjectList | null.
🔎 Proposed fix
-let projects: Models.ProjectList = null;
+let projects: Models.ProjectList | null = null;

src/lib/components/billing/alerts/selectProjectCloud.svelte

src/lib/components/billing/planComparisonBox.svelte

src/lib/components/billing/usageRates.svelte

src/lib/components/creditCardInfo.svelte

src/routes/(console)/organization-[organization]/billing/replaceAddress.svelte

src/routes/(console)/organization-[organization]/change-plan/+page.ts

src/routes/(console)/organization-[organization]/settings/deleteOrganizationModal.svelte

src/routes/(console)/project-[region]-[project]/settings/usage/[[invoice]]/+page.ts

src/routes/(public)/template-[template]/+page.ts

coderabbitai

Actionable comments posted: 8

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (6)

src/routes/(console)/organization-[organization]/billing/paymentMethods.svelte (1)

68-86: Add missing success analytics event for backup payment method.

The addBackupPaymentMethod function lacks the trackEvent(Submit.OrganizationPaymentUpdate) call on success, while the identical addPaymentMethod function includes it on line 57. Add trackEvent(Submit.OrganizationPaymentUpdate); after the invalidate call on line 78 for consistency.
src/routes/(console)/create-organization/+page.svelte (1)
80-85: Potential null dereference when extracting URL parameters.

Both organizationId and invites parameters are extracted without null checks. If a user navigates to ?type=payment_confirmed&id=xxx without the invites param, calling .split(',') on null will throw a TypeError.
🛠️ Suggested fix with null guards
         if (type === 'payment_confirmed') {
             const organizationId = page.url.searchParams.get('id');
-            const invites = page.url.searchParams.get('invites').split(',');
-            await validate(organizationId, invites);
+            const invitesParam = page.url.searchParams.get('invites');
+            if (organizationId && invitesParam) {
+                const invites = invitesParam.split(',').filter(Boolean);
+                await validate(organizationId, invites);
+            }
         }
src/routes/(console)/account/payments/editPaymentModal.svelte (1)
37-51: Critical: Duplicate trackEvent and invalidate calls will cause double tracking and unnecessary cache invalidation.

Lines 43-44 and 46-47 contain duplicated code that will:

Track the PaymentMethodUpdate analytics event twice per submission

Call invalidate(Dependencies.PAYMENT_METHODS) twice (once sync, once awaited)

This appears to be a merge conflict artifact or copy-paste error.
🐛 Proposed fix
 async function handleSubmit() {
     try {
         await sdk.forConsole.account.updatePaymentMethod({
             paymentMethodId: selectedPaymentMethod.$id,
             expiryMonth: parseInt(month),
             expiryYear: year
         });

-        trackEvent(Submit.PaymentMethodUpdate);
-        invalidate(Dependencies.PAYMENT_METHODS);
-        show = false;
         trackEvent(Submit.PaymentMethodUpdate);
         await invalidate(Dependencies.PAYMENT_METHODS);
+        show = false;
         addNotification({
             type: 'success',
             message: 'Your payment method has been updated'
         });
     } catch (e) {
         error = e.message;
         trackError(e, Submit.PaymentMethodUpdate);
     }
 }
src/routes/(public)/sites/deploy/+page.ts (1)

100-105: Silent failure may leave user without feedback.

If organization creation fails, the error is only logged to console. The user receives no notification, and organizations remains empty, which could cause confusion or downstream issues in the UI.

Consider propagating the error or showing a user-facing notification.

src/routes/(public)/functions/deploy/+page.ts (1)

67-88: Same getBasePlanFromGroup undefined risk and code duplication.

This organization creation logic is nearly identical to src/routes/(public)/sites/deploy/+page.ts (lines 83-105). Both have the same potential TypeError if getBasePlanFromGroup returns undefined.

Consider extracting this shared logic into a helper function (e.g., ensureOrganizationExists() in $lib/stores/organization) to reduce duplication and centralize error handling.
src/routes/(console)/organization-[organization]/billing/replaceCard.svelte (1)
97-117: Error handling doesn't propagate to caller.

Both addPaymentMethod and addBackupPaymentMethod catch errors and set the error state but don't rethrow. In handleSubmit (line 79-81), these functions are awaited but errors won't propagate to the outer try-catch, potentially allowing the success notification and show = false to execute even after a failure.
🐛 Suggested fix
     async function addPaymentMethod(paymentMethodId: string) {
-        try {
-            await sdk.forConsole.organizations.setDefaultPaymentMethod({
-                organizationId: organization.$id,
-                paymentMethodId
-            });
-        } catch (err) {
-            error = err.message;
-        }
+        await sdk.forConsole.organizations.setDefaultPaymentMethod({
+            organizationId: organization.$id,
+            paymentMethodId
+        });
     }

     async function addBackupPaymentMethod(paymentMethodId: string) {
-        try {
-            await sdk.forConsole.organizations.setBackupPaymentMethod({
-                organizationId: organization.$id,
-                paymentMethodId
-            });
-        } catch (err) {
-            error = err.message;
-        }
+        await sdk.forConsole.organizations.setBackupPaymentMethod({
+            organizationId: organization.$id,
+            paymentMethodId
+        });
     }

🤖 Fix all issues with AI agents

In @src/lib/stores/billing.ts:
- Around line 570-572: The call to
getBasePlanFromGroup(BillingPlanGroup.Starter).$id may be undefined; first call
getBasePlanFromGroup(BillingPlanGroup.Starter) into a local variable (e.g.,
basePlan) and check for null/undefined before using .$id, then build the queries
array conditionally so you only include Query.notEqual('billingPlan',
basePlan.$id) when basePlan and basePlan.$id exist (otherwise omit that filter
or use a safe default), and pass the resulting queries to
sdk.forConsole.organizations.list to avoid accessing .$id on undefined.
- Around line 532-540: In checkForMissingPaymentMethod, avoid directly accessing
getBasePlanFromGroup(BillingPlanGroup.Starter).$id because getBasePlanFromGroup
can return undefined; first assign const basePlan =
getBasePlanFromGroup(BillingPlanGroup.Starter) and if basePlan is undefined
either return/exit early or throw/log an error, then use basePlan.$id in the
Query.equal call passed to sdk.forConsole.organizations.list; alternatively
guard using optional chaining and a fallback value before building the query so
you never dereference undefined.
- Around line 88-100: getBasePlanFromGroup can return undefined when proPlans is
empty; change its signature to Models.BillingPlan | undefined and explicitly
handle the empty case instead of assuming [0] is defined. In
getBasePlanFromGroup, compute const base =
proPlans.sort((a,b)=>a.order-b.order)[0]; then return base ?? undefined (or
return a sensible fallback plan found from plansInfoStore if intended), and
update callers to handle a possible undefined result; reference: function
getBasePlanFromGroup, variable proPlans, plansInfoStore, and
BillingPlanGroup.Starter.
- Around line 102-111: The function billingIdToPlan silently falls back to
BillingPlanGroup.Pro when billingId is missing from plansInfo; instead make
failures explicit by validating plansInfo.has(billingId) and throwing a
descriptive error (or returning a Result/optional) rather than defaulting to
Pro. Update billingIdToPlan to check plansInfo (via get(plansInfo)) and if the
id is absent throw an Error like "Unknown billingId: <id>" (or change the
signature to return undefined/null or a Result type), and remove the silent
fallback to getBasePlanFromGroup(BillingPlanGroup.Pro) to avoid incorrect
billing/UI behavior.

In @src/routes/(console)/create-organization/+page.svelte:
- Around line 90-97: The validatePayment branch in the validate() flow currently
preloads and navigates to `${base}/console/organization-${org.$id}` which is
inconsistent with the create() flow; update the two references in the
validatePayment success path (the calls around
sdk.forConsole.organizations.validatePayment and the subsequent preloadData and
goto) to use `${base}/organization-${org.$id}` instead so both validate() and
create() navigate to the same canonical `/organization-{id}` URL.

In @src/routes/(console)/organization-[organization]/billing/+page.ts:
- Around line 15-20: The redirect uses a 301 permanent status in the
redirect(...) call which can be cached by browsers; change the status code from
301 to a temporary redirect such as 302 (or 307 if preserving method) in the
redirect(resolve(...)) invocation so authorization-based redirects aren’t
cached—update the redirect(301, resolve(...)) call to redirect(302,
resolve(...)) (or 307) where the redirect(...) and resolve(...) symbols are
used.

In
@src/routes/(console)/organization-[organization]/billing/paymentMethods.svelte:
- Around line 36-39: The exported props backupMethod and primaryMethod are
declared as non-optional but are used with optional chaining (e.g.,
primaryMethod?.lastError, primaryMethod?.userId), so update their types to be
optional/nullable (e.g., Models.PaymentMethod | undefined) in the export
declarations (export let backupMethod and export let primaryMethod) to match
runtime usage and avoid type errors; ensure any other references to those
symbols (backupMethod, primaryMethod) continue to use safe checks or optional
chaining.

In @src/routes/(public)/sites/deploy/+page.ts:
- Around line 88-92: The create call uses
getBasePlanFromGroup(BillingPlanGroup.Starter).$id which can be undefined in the
(public) route because plansInfo is only populated in the (console) layout;
update the organization creation to guard for undefined by calling
getBasePlanFromGroup(BillingPlanGroup.Starter), check its return value (from the
getBasePlanFromGroup helper) and use a safe fallback billing plan id (e.g., a
DEFAULT_PLAN_ID constant or a known starter plan id) or fetch/populate plansInfo
before calling; ensure you reference getBasePlanFromGroup and the organization
creation block (await sdk.forConsole.organizations.create) when adding the
null-check/fallback and logging an informative error if neither a plan nor
fallback exist.

🧹 Nitpick comments (6)

src/routes/(console)/account/payments/editAddressModal.svelte (1)
36-46: API migration looks correct.

The transition from billing.updateAddress to account.updateBillingAddress with named parameters is properly implemented.

Minor optional simplification for the ternary expressions:
✨ Optional simplification
             await sdk.forConsole.account.updateBillingAddress({
                 billingAddressId: selectedAddress.$id,
                 country: selectedAddress.country,
                 streetAddress: selectedAddress.streetAddress,
                 city: selectedAddress.city,
                 state: selectedAddress.state,
-                postalCode: selectedAddress.postalCode ? selectedAddress.postalCode : undefined,
-                addressLine2: selectedAddress.addressLine2
-                    ? selectedAddress.addressLine2
-                    : undefined
+                postalCode: selectedAddress.postalCode || undefined,
+                addressLine2: selectedAddress.addressLine2 || undefined
             });
src/routes/(console)/organization-[organization]/billing/deleteOrgPayment.svelte (1)
40-59: Optional: Inconsistent dialog dismissal timing between the two methods.

Pre-existing behavior: removeBackupMethod sets showDelete = false at line 42 before the async operation completes, causing the dialog to close immediately. In contrast, removeDefaultMethod uses a finally block to close the dialog after the operation.

Consider aligning the two methods for consistent UX where the dialog remains open until the operation completes or fails.
♻️ Suggested alignment
 async function removeBackupMethod() {
     if ($organization?.billingPlan !== BillingPlan.FREE && !hasOtherMethod) return;
-    showDelete = false;

     try {
         await sdk.forConsole.organizations.deleteBackupPaymentMethod({
             organizationId: $organization.$id
         });
         addNotification({
             type: 'success',
             message: `The payment method has been removed from ${$organization.name}`
         });
         trackEvent(Submit.OrganizationBackupPaymentDelete);
         await invalidate(Dependencies.PAYMENT_METHODS);
-        showDelete = false;
     } catch (e) {
         error = e.message;
         trackError(e, Submit.OrganizationBackupPaymentDelete);
+    } finally {
+        showDelete = false;
     }
 }
src/lib/components/support.svelte (1)
22-29: Type assertion is acceptable but consider adding a type guard for safety.

The (team as Models.Organization) assertions work because the runtime objects contain billing details when in cloud mode. However, this relies on implicit knowledge that organizationList.teams contains Organization objects rather than plain Team objects.

Consider extracting a type guard or helper function if this pattern is used elsewhere:
💡 Optional improvement
// In a shared helper file
function hasOrganizationBilling(team: Models.Team): team is Models.Organization {
    return 'billingPlanDetails' in team;
}
src/routes/(console)/onboarding/create-organization/+page.svelte (1)
24-34: Inconsistent null safety between creation and analytics.

Line 27 accesses getBasePlanFromGroup(BillingPlanGroup.Starter).$id without null safety, while line 31 uses optional chaining (?.name). If the function can return undefined (warranting the ?. on line 31), the same protection should be applied on line 27.
♻️ Suggested fix for consistency
             organization = await sdk.forConsole.organizations.create({
                 organizationId: ID.unique(),
                 name: organizationName,
-                billingPlan: getBasePlanFromGroup(BillingPlanGroup.Starter).$id
+                billingPlan: getBasePlanFromGroup(BillingPlanGroup.Starter)?.$id
             });
src/routes/(console)/organization-[organization]/billing/+page.ts (1)

31-39: Repeated type casts suggest incomplete type propagation.

Multiple lines cast organization to Models.Organization (lines 31, 53, 65). If organization from parent() is already typed correctly, these casts are unnecessary. If not, consider fixing the type at the source (in the parent layout's return type).

Also applies to: 46-56, 63-66

src/lib/stores/billing.ts (1)

113-141: TODOs indicate incomplete refactoring.

Lines 113 and 128 contain TODOs suggesting these functions should return BillingPlan objects instead of strings. Consider addressing these before merging or creating tracking issues.

Would you like me to help refactor these functions to return Models.BillingPlan objects, or open an issue to track this work?

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cfd4636 and 5cc88f6.

📒 Files selected for processing (22)

src/lib/components/archiveProject.svelte
src/lib/components/billing/alerts/paymentMandate.svelte
src/lib/components/billing/alerts/selectProjectCloud.svelte
src/lib/components/support.svelte
src/lib/stores/billing.ts
src/lib/stores/sdk.ts
src/routes/(console)/+layout.svelte
src/routes/(console)/+layout.ts
src/routes/(console)/account/payments/editAddressModal.svelte
src/routes/(console)/account/payments/editPaymentModal.svelte
src/routes/(console)/create-organization/+page.svelte
src/routes/(console)/onboarding/create-organization/+page.svelte
src/routes/(console)/organization-[organization]/+layout.ts
src/routes/(console)/organization-[organization]/billing/+page.svelte
src/routes/(console)/organization-[organization]/billing/+page.ts
src/routes/(console)/organization-[organization]/billing/deleteOrgPayment.svelte
src/routes/(console)/organization-[organization]/billing/paymentMethods.svelte
src/routes/(console)/organization-[organization]/billing/replaceAddress.svelte
src/routes/(console)/organization-[organization]/billing/replaceCard.svelte
src/routes/(console)/project-[region]-[project]/databases/+page.ts
src/routes/(public)/functions/deploy/+page.ts
src/routes/(public)/sites/deploy/+page.ts

💤 Files with no reviewable changes (1)

src/lib/stores/sdk.ts

✅ Files skipped from review due to trivial changes (1)

src/routes/(console)/organization-[organization]/+layout.ts

🚧 Files skipped from review as they are similar to previous changes (3)

src/routes/(console)/organization-[organization]/billing/replaceAddress.svelte
src/lib/components/archiveProject.svelte
src/lib/components/billing/alerts/selectProjectCloud.svelte

🧰 Additional context used

📓 Path-based instructions (7)

**/*.{ts,tsx,js,jsx,svelte}