Billing Laravel Package

Product Decisions This Supports

• Build vs. buy for billing primitives. The package supplies plans, subscriptions, swap/cancel/resume, and payment tracking as Eloquent-friendly Laravel code under MIT. The real decision it informs isn't "billing or no billing" but "do we own the subscription state machine and payment ledger ourselves, or adopt a small dependency we can extend?" For a team already on Laravel, the answer is usually adopt the schema and lifecycle, keep the money-movement logic in-house.
• Feature gating and entitlement roadmap. Because v0.4 makes "active" a settlement-confirmed state rather than an intent-to-pay state, it forces a product decision that outlives the package: which features unlock on subscription creation (onboarding, trial, limited access) versus on confirmed payment (full entitlements). Any roadmap item that assumes "signed up = paying customer" needs revisiting.
• Payment method and market strategy. The EFT-first activation model is a deliberate product stance: bank transfer, manual or reconciled confirmation, delayed access. That fits invoiced B2B, education, government, and markets where card penetration or fees make cards unattractive. It works against self-serve consumer funnels where instant activation is the expectation. This package effectively votes for the former; choosing it is a market-segment decision as much as a technical one.
• Pricing and plan-change flexibility. Swap/cancel/resume support means plan changes, upgrades, and downgrade-at-period-end can be scoped as configuration rather than new engineering. Useful for deciding whether tiered plans, seat-based pricing, or annual/monthly mixes are feasible in the near term.
• Finance operations as a product surface. The pending-EFT window creates real product requirements: a payment reference the customer can transcribe, an "awaiting payment" screen, an admin confirmation action with audit trail, a reconciliation workflow. These are product backlog items, not implementation details — and they should be sized before committing.
• Scope boundary for checkout and gateways. The package is gateway-agnostic and extensible rather than a full payments integration. That supports an early decision to keep checkout, PCI scope, and gateway relationships out of the subscription engine — reducing the compliance and vendor-lock-in surface of the first release.
• Risk posture on pre-1.0 dependencies. At v0.x with zero stars, sparse release notes, and a behavioral change shipped in a minor version, this is a decision about tolerance for unstable dependencies on a revenue-critical path. The product answer is usually: fine for an internal or low-volume MVP behind a feature flag, not fine for a system where "paid but locked out" is a headline incident.

When to Consider This Package

Consider it when:

• You are building on Laravel/PHP and want subscription and payment records as first-class Eloquent models rather than a bolted-on external service.
• Your commercial model is invoiced or bank-transfer based, or you have a finance team that already reconciles payments manually or via bank feeds. The v0.4 pending → active model matches how your money actually arrives.
• You need plans, swaps, cancels, resumes, and a transaction ledger and can live without a bundled gateway — you intend to own the payment integration layer.
• You want a small, readable, MIT-licensed dependency you can read, fork, or wrap in your own service classes, rather than a large billing platform with its own opinions and pricing.
• You can gate adoption behind a feature flag, have a staging environment to validate the activation contract, and can pin the version.

Look elsewhere when:

• You need instant card-based self-serve checkout — the delayed-activation model is the wrong shape, and you'd be fighting the package's core lifecycle rule.
• You need tax, invoicing compliance, dunning, proration, or revenue recognition handled for you. This package tracks payments; it does not appear to be a billing compliance system.
• You require vendor-backed support, SLA, or a security review trail — zero stars, pre-1.0, and one-line release notes don't provide that.
• Your team has no Laravel depth or you'd be adopting it for a non-PHP service.
• You cannot absorb the migration risk to existing subscribers: v0.4 changes the meaning of "active," and any pre-existing subscription created under the old semantics needs a deliberate backfill or grandfathering policy. If you have live subscriptions and no appetite for that audit, wait.
• The documentation gap is disqualifying for your risk tolerance — the activation contract, event model, and partial-payment behavior are not fully documented and would need to be reverse-engineered from source before you could commit.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT) Laravel component that gives us subscription and payment records without buying a billing platform. The tradeoff is that it's young — pre-1.0, minimal documentation, no support contract — so it's a fit for a scoped MVP, not for something we'd stake revenue reporting on without a pilot. It's strongest if we're selling to customers who pay by bank transfer rather than card, because the latest version deliberately holds a subscription inactive until the money is actually confirmed as received. That's financially safer than granting access on an unpaid invoice, but it does mean we need a payment confirmation and reconciliation process on our side — mostly an admin workflow plus a scheduled matching job, not a large engineering lift.

For engineering: Adopt it as the subscription state machine and payment ledger; keep checkout, gateway integration, and reconciliation in our code. Do not edit vendor code — wrap activation in our own ConfirmEftPayment action so we control idempotency, audit logging, and partial-payment policy. Pin to v0.4, validate in staging first. The main technical risks are duplicate activation from retried or double-clicked confirmations, missed reconciliation events leaving customers paid-but-locked-out, and bulk status updates that skip model events and therefore skip provisioning. Treat the pending → active transition as an explicit state machine, gate all features on isActive() rather than on the subscription record existing, and make every transition logged and replayable. Budget for a migration audit of any existing subscription creation paths.

Decision requested: Approve a time-boxed evaluation — upgrade in a branch, add tests for pending/received/duplicate/delayed payment, wire one reconciliation path in staging, and pilot with a small cohort behind a flag. Success criteria: no active subscription without a traceable receipt event, no customer left inactive after confirmed payment, and every confirmation safely replayable. If the activation contract doesn't hold up under those tests, we fall back to building the state machine in-house — the schema and workflow decisions we make here carry over either way.