Laravel Billing Core Laravel Package

Product Decisions This Supports

• Accelerate SaaS Monetization: Reduces time-to-market for subscription-based features by providing a pre-built billing infrastructure, allowing the team to focus on core product differentiation (e.g., UX, integrations, or niche workflows).
• Multi-Gateway Strategy: Enables a "build vs. buy" decision in favor of buying for payment gateways (Paystack/PayPal), avoiding custom integration debt while retaining flexibility to swap providers via .env.
• Roadmap Alignment: Supports future-proofing for:
  • Plan Experimentation: Fluent API for A/B testing subscription tiers (e.g., "Premium" vs. "Enterprise") without gateway-specific logic.
  • Churn Reduction: Built-in dunning and grace periods align with retention-focused roadmap items (e.g., "Reduce involuntary churn by 20%").
  • Compliance: Event-based architecture simplifies audit logging for PCI/DSP2 requirements.
• Tech Stack Consolidation: Leverages Laravel’s ecosystem to avoid reinventing billing wheels, reducing maintenance overhead for a critical but non-differentiating feature.

When to Consider This Package

• Adopt When:

  • Your SaaS has subscription models (B2B/B2C) and needs to avoid custom billing spaghetti.
  • You require multi-gateway support (e.g., regional Paystack for Africa + PayPal for global) but want to avoid vendor lock-in.
  • Your team lacks payment gateway expertise or wants to offload dunning/grace-period logic.
  • You’re using Laravel and prioritize developer velocity over customization (e.g., startups, MVPs, or internal tools).
  • You need plan swapping (e.g., "Upgrade from Pro to Team") without manual webhook management.

• Look Elsewhere If:

  • You need highly customized pricing (e.g., usage-based billing, complex metered plans) beyond tiered subscriptions.
  • Your stack isn’t Laravel/PHP (e.g., Node.js, Ruby, or headless frontend).
  • You require advanced fraud detection or 3D Secure 2.0 integrations not covered by Paystack/PayPal drivers.
  • Your compliance needs exceed PayPal/Paystack’s scope (e.g., crypto payments, ACH for US markets).
  • You’re building a marketplace with payouts to third parties (this package focuses on customer-facing billing).
  • The package’s maturity (0 stars, minimal docs) is a dealbreaker for your risk tolerance (consider alternatives like Spatie Billing or Stripe Laravel).

How to Pitch It (Stakeholders)

For Executives (TL;DR)

"This package lets us launch subscriptions in weeks instead of months by plugging in Paystack/PayPal with a single config change. It handles the boring but critical stuff—like failed payments, plan upgrades, and compliance events—so our team can focus on growing revenue, not debugging billing code. The MIT license and driver-based design mean we can pivot gateways without rewriting logic, and the event system gives us visibility into churn risks. For a one-time integration cost, it’s a force multiplier for monetization."

Key Metrics to Track:

• Time Saved: "X weeks less dev time on billing vs. custom build."
• Churn Reduction: "Automated dunning could recover Y% of lost revenue from failed payments."
• Flexibility: "Swap gateways in 10 minutes if PayPal’s fees become prohibitive."

For Engineering (Technical Value)

*"This is a batteries-included Laravel billing layer that abstracts away gateway-specific quirks. Here’s why it’s worth adopting:

• Driver Pattern: Swap Paystack ↔ PayPal by updating .env—no refactoring.
• Subscription Lifecycle: Built-in methods for subscribe(), cancel(), swapPlan(), and dunning (e.g., invoice.payment_failed → past_due status).
• Events & Observers: Hook into SubscriptionStarted, PlanSwapped, etc., for analytics or workflows (e.g., trigger onboarding emails on upgrade).
• Billable Trait: Add \Emeroid\Billing\Contracts\Billable to your User model to auto-generate billing fields (e.g., subscription_id, current_period_end).
• Grace Periods: No more edge cases for ‘cancel at end of period’—handled automatically.

Tradeoffs:

• Limited Gateways: Only Paystack/PayPal out of the box (but extensible).
• Early Stage: 0 stars = untested in production (recommend piloting with a non-critical feature).
• Migrations: Requires running php artisan migrate after install.

Proposal:

1. Pilot: Use this for a secondary subscription tier (e.g., ‘Team’ plan) to validate the API.
2. Extend: Add a custom gateway driver if needed (e.g., Stripe via a community PR).
3. Monitor: Track webhook reliability and performance vs. alternatives like Spatie Billing.

Alternatives Considered:

• Spatie Billing: More mature but PayPal-only.
• Stripe Laravel: Stripe-specific, less flexible for multi-gateway.
• Custom Build: High maintenance, risk of payment failures.

Next Steps:

• Review the migrations for schema compatibility.
• Test the fluent API with a sandbox PayPal/Paystack account.
• Align with legal/finance on dunning event requirements (e.g., GDPR for past_due notifications)."*