Subbase Payment Laravel Package

Product Decisions This Supports

• Build vs. buy for subscription billing. This package is a candidate answer to "do we build plans, proration, trials, dunning, and webhook plumbing ourselves?" A PM can frame the decision as: buy the commodity mechanics (billing cycles, subscription state, webhook signature verification) and spend engineering capacity on differentiation (pricing model, packaging, entitlements) — provided the vendor-risk questions below clear.
• Time-to-market for a paid tier. The fluent plan/price/interval API and Eloquent subscription traits mean a paid plan can plausibly ship in a sprint rather than a quarter. That directly affects whether a monetization experiment (e.g., a Pro tier) lands in this planning cycle or the next.
• Roadmap sequencing for pricing changes. Because proration, trials, and renewal logic are configurable rather than hand-rolled, the cost of a roadmap item like "annual plans," "14-day free trial," or "mid-cycle upgrades with proration" drops from a project to a configuration-and-QA task. That changes what can be committed to in a quarterly plan.
• Experimentation velocity. Pricing and packaging tests (trial length, plan mix, upgrade paths) become cheap to run if billing mechanics are already abstracted. This is the strongest product argument for the package: it converts pricing strategy from an engineering-constrained decision into a product-led one.
• Scope boundary for MVP. It gives a defensible answer to "what is not in v1": no custom invoicing engine, no tax/VAT engine, no multi-currency, no revenue recognition, no dunning UX — those stay on the roadmap until validated.
• Where it does not help. Nothing here informs entitlement/feature-gating logic, usage-based metering, or churn analytics. If the product strategy depends on metered billing or a hybrid seat+usage model, this package is not the decision lever.

When to Consider This Package

Consider it when:

• The product is a conventional Laravel application and the team is already fluent in Eloquent, service providers, and config publishing — the integration cost is genuinely low.
• The billing model is the common case: a small number of flat-rate plans, monthly/annual intervals, trials, upgrades with proration, cancel-at-period-end.
• The requirement is to validate willingness-to-pay quickly, and the alternative is delaying launch to build billing.
• There is an in-house backend engineer who can own a written evaluation and, if needed, a fork. A 6-star, single-maintainer package on a revenue path is acceptable only with that safety net.
• You can keep the integration behind an internal adapter so billing state remains reconcilable against the gateway as source of truth.

Look elsewhere when:

• Usage-based, metered, or hybrid pricing is core to the model — that is not what "opinionated flat-plan billing" is built for.
• Multi-currency, multi-tenant, or multi-gateway requirements exist. The package's assumptions here are unverified, and retrofitting them is expensive.
• Compliance obligations (PCI scope, SOC 2 vendor review, tax/VAT jurisdiction logic, revenue recognition) apply. A package with no visible security disclosure process will fail procurement, and forcing it through is a schedule risk, not a technical one.
• Release governance matters. v1.3.0 shipped with an auto-generated compare link and no changelog. If your org requires reviewable upgrade notes for anything touching revenue, this package cannot currently meet that bar without you doing the diff review yourself.
• The team cannot absorb a fork. Single-maintainer concentration plus rapid minor iterations on a payments code path is a bus-factor exposure. If no one internally can patch it under time pressure, the true cost of adoption includes a contingency you may not want to fund.
• Long-horizon stability is the priority over speed — e.g., billing that must survive multiple framework LTS upgrades with minimal attention.

Recommended posture: treat it as a pilot-grade dependency, not a platform commitment. Validate in a sandbox against your real scenario list (create, upgrade with proration, cancel-at-period-end, failed-payment recovery, refund), pin the version explicitly, and gate any production rollout to a low-risk tier or internal accounts first.

How to Pitch It (Stakeholders)

For executives — the one-liner: This is a Laravel package that provides the standard subscription-billing mechanics — plans, trials, renewals, proration, webhook handling — so we can launch and test a paid tier in weeks instead of building billing from scratch. It is MIT-licensed and free, with no vendor contract.

Then the honest caveat in the same breath: It is maintained by a single author with a small user base, and its latest release has no changelog. We should adopt it as a time-to-market accelerator behind an internal abstraction layer, keep it version-pinned, and be prepared to fork or replace it. It is not a decade-scale platform commitment.

Frame the decision as speed now, optionality preserved — not "we are betting the revenue system on an unknown package." The adapter layer and explicit reconciliation against the gateway are what make the bet reversible, and that reversibility is the thing to ask execs to fund (roughly: one engineer for one spike plus ongoing ownership of the pin/upgrade runbook).

For engineering — what you are actually asking for:

• A timeboxed spike: read the v1.2.1 → v1.3.0 diff directly (do not trust the release page), confirm the Laravel/PHP version floor, determine whether the package owns the subscription schema or operates against ours, and verify webhook idempotency and the retry model. The deliverable is a short written evaluation, not working code.
• A thin internal adapter so domain code never calls the package's API directly — this is the single highest-leverage risk control and it costs little if designed in from the start.
• Hard version pinning with a scheduled upgrade ritual; no composer update drift on the billing path.
• A gateway-independent reconciliation job so billing truth never depends solely on the package's tables.

For product/GTM — what this unlocks and what it does not: it unlocks paid-plan launch, trial experiments, and upgrade/downgrade flows with proration. It does not unlock usage-based pricing, multi-currency, tax handling, or self-serve invoicing. Set the roadmap expectation accordingly so those requests are scoped as future work rather than assumed as free.

The ask: approve a contained pilot (non-production, sandbox gateway, low-risk tier or internal accounts) with a documented exit trigger — for example, six months without a release, an unanswered security issue, or a gateway API version going end-of-life. That gives us the launch date without taking on unbounded platform risk.