niteshdass/billing-laravel

1. System shape

Liberu Billing is a Laravel 12 monolith for billing, invoicing, subscriptions, and hosting service automation. The core architecture is layered: HTTP/UI entry points at the top, a service/domain layer in the middle, and Eloquent models, queues, and scheduled commands at the bottom.

2. User-facing surfaces

The app exposes three major UI surfaces through Filament 5 panel providers: an Admin panel, an App panel for operational users, and a Client panel for customers. In addition, there are classic Blade pages, Livewire screens, and a small Vue layer for richer dashboard and search widgets.

3. HTTP and API boundary

Web traffic enters through routes/web.php, while machine-oriented access is concentrated in routes/api.php. Controllers under app/Http/Controllers handle authentication, invoices, customers, subscriptions, payments, tickets, reports, and webhooks. The API also includes an invoice resource and auth endpoints, suggesting first-class programmatic access rather than a thin internal API.

4. Domain and persistence layer

The business data is modeled with many Eloquent entities: users, teams, customers, invoices, invoice items, payments, subscriptions, products/services, hosting accounts, payment gateways, knowledge base articles, tickets, quotes, webhooks, and audit logs. The database schema shows a long-lived billing domain with multi-team support, recurring billing, and operational history tracking.

5. Service layer as the main business boundary

Most business logic is pushed into app/Services, not controllers. Key service groups include billing, payment gateway orchestration, reconciliation, subscription automation, refund/dispute handling, invoicing, reporting, knowledge base, menus, site settings, webhook dispatching, and service provisioning. This is the main place where domain workflows are coordinated.

6. Automation and asynchronous processing

Background work is a major subsystem. app/Jobs, app/Console/Commands, events, listeners, and mail classes together handle recurring billing, invoice reminders, overdue service suspension, webhook processing, audit pruning, and domain synchronization. This means the system is not purely request-driven; many billing outcomes are produced by scheduled and queued processes.

7. External integrations

The repo contains explicit adapters for payment gateways, domain registrars, and hosting control panels. Control panel clients cover cPanel, Plesk, DirectAdmin, Virtualmin, Softaculous, and a Liberu-specific control panel client. Registrar clients include Enom and ResellerClub. These adapters isolate vendor-specific APIs from the rest of the billing logic.

8. Authentication, teams, and access control

Identity and account management are built on Jetstream, Fortify, Sanctum, and Socialstream. The app supports two-factor auth, API tokens, social login, and team-based access. Middleware and policies enforce team scoping and role-based access, which is important because many resources are shared across teams rather than being globally visible.

9. Admin and support tooling

Filament resources cover administrative CRUD for users, settings, payment plans, payment gateways, subscriptions, recurring billing, audit logs, menus, and more. Client-facing Filament pages and widgets expose profile, dashboard, invoices, and social links. This admin tooling is a separate concern from the customer portal and is where most internal operations happen.

10. Modular extension system

The repo includes a module framework under app/Modules with a ModuleManager, module contracts, and at least one sample BlogModule. This is a clear architectural boundary: core billing logic remains in the main app, while optional features can be packaged as modules without changing the base product.

11. Notifications, email, and document generation

Invoice generation and payment workflows produce emails and PDFs through dedicated mail classes, Blade email templates, and PDF views. Notifications such as new tickets also live in their own subsystem. Output channels are therefore centralized and reusable across the billing workflows.

12. Runtime and deployment topology

The repository is container-first. Docker assets support a standard PHP/Nginx/FPM setup as well as Laravel Octane variants using FrankenPHP, RoadRunner, and Swoole. Supervisor configurations run the app, queue workers, Horizon-like processes, and the scheduler, so the deployment model assumes multiple cooperating processes rather than a single web server.

13. Data import/export, reporting, and auditability

There is a strong reporting and compliance layer: audit logs, saved searches, reports, bulk operations, and export services. These features indicate the system is designed not just to bill, but also to provide operational visibility and traceability over customer and financial events.