Weave Code
Paymenter Laravel Package
paymenter/paymenter
Paymenter is an open-source billing and client management platform built on Laravel for hosting providers. It handles invoicing, subscriptions, payment gateways, automated server provisioning, and support tickets through an extensible module system.
Paymenter is a self-hosted, open-source, and free invoicing and billing software built with Laravel.
Frequently asked questions about Paymenter
- Is Paymenter a Laravel package I install with Composer, or a full application?
- Paymenter is a self-hosted Laravel application, not a drop-in library you import into an existing app. It ships as a Composer package named paymenter/paymenter, but adopting it means running a full Laravel runtime with its own database, queue worker, and scheduled tasks. Treat it as production infrastructure rather than a dependency you pull into a controller.
- What are the server requirements for self-hosting Paymenter?
- You need PHP 8.x, MySQL or MariaDB, a queue worker, and a scheduler entry in cron or a supervisor-managed worker in containers. Redis is advisable for queues and caching under load. Docker is a supported deployment path, so containerized hosting is a reasonable target as long as you pin the image tag explicitly instead of tracking latest.
- Which PHP and Laravel versions does Paymenter 1.5.9 support?
- Paymenter 1.5.9 is a Laravel application requiring PHP 8.x and a Filament-based admin panel. The exact minimum supported Laravel version for this release should be confirmed against the release's composer.json and lock file before you set your runtime baseline. Verify this explicitly, because it directly constrains which PHP image and framework version your platform standard can hold.
- How does Paymenter handle payment gateway integrations?
- Payment gateways are implemented as extensions through Paymenter's module system, so each gateway is a separate module you enable and configure. Any gateway webhook endpoint must be publicly reachable and idempotent, since payment providers retry callbacks. Budget real effort for webhook reconciliation and for compatibility testing of each gateway extension, not for the base installation.
- Is Paymenter safe to run in production after the 1.5.9 security release?
- Version 1.5.9 is a patch bump that bundles eight GHSA security advisories plus one Docker extension-installation fix, so any instance on 1.5.8 or earlier should be treated as exposed until triaged. Because all eight fixes ship together, you cannot selectively mitigate, making the upgrade effectively all-or-nothing. Review each advisory for pre-auth versus authenticated access and whether exploitation requires admin panel, customer-facing, or webhook access before deciding urgency.
- How do I upgrade Paymenter from 1.5.8 to 1.5.9?
- Pull the release, run the database migrations, clear compiled views plus config and route caches, then restart queue workers. In Docker, rebuild the image so the extension-installation fix takes effect, and re-verify that every previously installed extension is still present and functional. Take a database snapshot immediately before migrating, because billing schema migrations are not cheaply reversible.
- Can I deploy Paymenter with Docker in production?
- Yes, Docker is a supported deployment path, and this release specifically fixes extension installation in containerized environments. That fix also means anyone who scripted around the old install behavior should re-test their custom extension images after rebuilding. Pin an explicit image tag rather than tracking latest so a patch release never lands unreviewed on your billing system.
- How does Paymenter automate server provisioning for hosting and game panels?
- Provisioning is handled by server module extensions that call downstream panel APIs to create, suspend, and terminate services when orders are paid or cancelled. These modules hold privileged API credentials to your infrastructure, which makes them the main supply-chain surface of the platform. Check whether each module you depend on is published by the core team or by unvetted community authors, and scope its API credentials to the minimum required permissions.
- How should I test a Paymenter deployment before going live?
- Run a staging instance that mirrors production, including PHP version, database, queue worker, and scheduler, and restore a copy of real data rather than seeding from scratch. Exercise checkout flows, webhook retries and idempotency, and every extension you rely on, since extension compatibility is where most upgrade failures appear. If you also reconcile customer accounts with an existing auth system or CRM, test that identity mapping in staging first.
- What are the alternatives to Paymenter for Laravel billing, and is it well maintained?
- The main alternative is a managed SaaS billing platform, which removes the PHP runtime, database, queue, and cron surface entirely but gives up self-hosting and deep customization. Paymenter's advantage is its open-source, extension-driven architecture for hosting providers, at the cost of operating that stack yourself. Before committing long term, look for a published security policy, a disclosure SLA, and maintainer count, and weigh the patch cadence of this codebase as a bigger operational concern than its feature roadmap.
Weaver
How can I help you explore Laravel packages today?