- How do I install pushery/billing-for-laravel and set up its database tables?
- Install it with Composer, publish the package config, and run the migrations like any other Laravel package. Version 0.46.0 alone adds six migrations, including the collection_timing column, mandate consent tables, direct debit notices, AI spend, and expiring grants. Even if you skip metering, pause, direct debit, or AI spend, you should still run all migrations and explicitly set your collection-timing value rather than inheriting the default.
- Which Laravel versions does pushery/billing-for-laravel support?
- The package is built Laravel-native, relying on service providers, published config, migrations, scheduled Artisan commands, queued jobs, and events. The exact framework and PHP constraints are declared in the package composer.json, so check that file before upgrading a host application. Because the 0.46.0 release relies on queued jobs and scheduled commands for billing runs, confirm your scheduler and queue workers are configured as well.
- Why was a customer charged at the start of the billing period instead of the end?
- In v0.46.0 the billing.collection_timing setting defaults to in_advance, so new subscriptions on a package-billed driver are charged when a period begins. That means the first billing:run after the mandate exists, or at trial end, collects payment immediately. The code change is small but it moves first revenue earlier and changes trial-conversion and cash-flow behaviour, so set the value deliberately during rollout.
- Does upgrading to v0.46.0 change how existing subscriptions are billed?
- No. Subscriptions that already exist keep the timing they started with, so anything currently running in arrears continues to be collected at period end. The migration adds a collection_timing column that records the new behaviour for subscriptions created after the upgrade. Review your dunning, invoicing, and customer communication flows anyway, since new signups will behave differently from existing ones.
- How does mid-period proration work for upgrades, seat changes, and downgrades?
- A dearer tier or an added seat is charged immediately as its own order and invoice once the owner's available credit is spent. A cheaper tier or a removed seat leaves credit capped by what the period's payment holds for that portion of time, and each tier is valued over its own interval. If the provider refuses the charge, the plan change is not undone but stays open until a later paid cycle. This logic is intricate, so build a deliberate test matrix covering swaps, seat counts, and failed charges.
- What happens when a paused subscription is resumed or cancelled?
- Access is only granted again when unpause() is called, so pausing does not silently restore entitlements. On package-billed drivers, paused time is added to the current period. If a customer cancels while paused, the subscription ends immediately rather than at the end of the period. The PausesSubscriptions contract follows the container-bound extension pattern, so you must supply the bindings, persistence, and UI around it.
- How should I store SEPA direct debit mandate consent with this package?
- Consent is stored as a write-once record that captures the notice period and confirmation provenance, alongside IBAN validation and mandatory wording matched exactly to what the form displayed. Treat this as PII and legal exposure rather than a simple form field, and implement the erasure path that unlinks the consent record when required. The CollectsDirectDebits contract is container-bound, so your application owns the persistence and the customer-facing flow.
- Why is metered usage showing up on a Stripe invoice a full cycle later?
- A missing invoice.upcoming event can delay usage being rolled onto an invoice by an entire cycle without raising an error. Run billing:doctor to surface the gap, and check StripeWebhookEventMapper::EVENT_TYPES and StripeMarketplaceWebhookEventMapper::EVENT_TYPES when verifying deployment scripts. Add webhook monitoring so silent drops in event types are caught before they affect revenue timing.
- Why do invalid metering or Mollie environment values not raise errors?
- Invalid values for metering backoff, stall, and grace settings, and for Mollie timeouts and retries, silently fall back to the package's shipped defaults. That means a typo in your environment file can leave production running on values you never intended. Validate these settings explicitly in your own configuration or deployment checks instead of relying on the package to fail loudly.
- Is pushery/billing-for-laravel a good alternative to Laravel Cashier?
- It is a lightweight, Laravel-native billing toolkit covering plans, trials, invoices, payment tracking, configurable drivers, and metered usage, so it suits teams that want subscription plumbing without a heavy dependency. Be aware that it acts as the system of record for revenue timing: it decides when money is collected, how partial periods are prorated, and what a consent record must contain. Treat the upgrade as high technical risk, test the collection-timing default, proration, pause semantics, and direct debit flow before production, and compare the driver support you actually need against Cashier.