Build a Complete Billing & Account Operations System

Scan my entire Base44 app first so you fully understand how it currently works before making changes.

Act like a senior product engineer, system architect, and Base44 implementation expert. Don't guess. Inspect existing app structure, pages, components, entities, schema, workflows, auth logic, backend functions, automations, email flows, roles, permissions, admin areas, and current billing-related logic before building.

JOB: 1) Understand how the app currently works, 2) Find the cleanest way to add billing and account operations, 3) Implement so they fit the current app, 4) Reuse existing patterns/styles/entities/permissions/admin architecture, 5) Avoid breaking current flows.

BEFORE WRITING CODE: Scan all pages, routes, layouts, navigation, backend functions, entities, automations, integrations, user/account logic. Identify whether the app has subscriptions/payments/trials/plans/invoices/account status, the payment provider if any, roles with billing access, current admin tools to extend, and notification/email systems to reuse.

BILLING AND ACCOUNT OPERATIONS:
1. SUBSCRIPTION STATUS VIEW — current status (active/trialing/past_due/canceled/expired/unpaid/paused), plan, billing cycle, renewal/expiration date, access based on status.
2. INVOICE/PAYMENT STATUS — recent invoices/payments (number, date, amount, status, payment method reference). Statuses: paid/pending/failed/refunded/disputed/void. Admin sees full history; users see their own if it fits.
3. FAILED PAYMENT ALERTS — detect failed/past due, admin alerts, user-facing warning, status labels + dates, clear post-failure workflow, reuse existing notification patterns, optional email alert.
4. MANUAL BILLING NOTES — internal notes on account/billing record, private, created-by + date, note history, follow existing internal notes pattern.
5. PLAN UPGRADE/DOWNGRADE TOOLS — admins change plan manually, self-service if supported, show current + target plan, effective date, who made the change, audit logging, respect existing roles.
6. TRIAL STATUS TRACKING — on-trial flag, start/end date, days remaining, expired state, admin adjust/review, trial filters in admin.
7. CANCELLATION REQUEST WORKFLOW — user submits if direct cancellation not supported, reason, admin review/approve/deny/complete, statuses new/under_review/approved/completed/denied, request + resolution dates, notify staff, history tied to account.
8. REFUND REQUEST HANDLING — user or admin submits, capture reason/amount/related invoice/notes, admin workflow new/under_review/approved/denied/refunded, internal notes + decision history, who handled + when, audit trail.

IMPLEMENTATION: Map the current app first and explain where features live. Use existing design/component patterns/naming. Extend the existing admin area or create in the cleanest place. Protect sensitive billing behind role-based access. Users see only their own info; internal notes/refund tools/plan controls staff-admin only. Audit log plan changes, trial edits, cancellation handling, refund decisions, and billing note creation. Reuse status badges, tables, forms, detail layouts.

DATA/ENTITY EXPECTATIONS (create cleanly and relate properly if missing): Subscription, BillingProfile, Invoice, PaymentRecord, BillingNote, TrialStatus, CancellationRequest, RefundRequest, BillingAuditLog. Link to user/account/client/workspace/organization.

ADMIN FEATURES: Billing overview, search/filtering, status filters, failed payment queue, trial tracking, cancellation requests, refund requests, billing notes, plan change tools, account timeline/history.

USER FEATURES (if applicable): current subscription/plan/trial status, payment/invoice history, failed payment warning, request cancellation/refund/plan change.

SECURITY: No internal notes to users; no cross-user billing data; don't break auth/role logic; no duplicate billing systems; no hardcoded provider assumptions; integrate with existing provider logic if present, otherwise build app-side structure ready for later integration.

OUTPUT IN PHASES: 1) Audit + current area summary + implementation plan; 2) Entities/fields/relationships/backend functions/permissions; 3) UI for admins and users; 4) Workflows, notifications, audit logs, status handling; 5) Final review — permissions correct, flows work, statuses right, nothing broken, design consistent.

IMPORTANT: Don't stop after analysis — implement. Don't replace working billing features unnecessarily. Prefer extending. Keep code/schema/UI consistent.