Laravel Razorpay Billing Laravel Package

Product Decisions This Supports

• Feature scoping — Razorpay-native recurring billing in Laravel. The package targets the "subscriptions + mandates (UPI/AutoPay) + webhooks" slice of an India-first product, the part that is expensive and error-prone to hand-roll (mandate lifecycle, retries, webhook idempotency, proration). It supports a build-vs-buy decision in favour of buy/borrow a thin Laravel-native layer rather than writing bespoke gateway glue or porting Laravel Cashier to Razorpay.
• Build vs buy. The realistic comparison set is: (a) this package, (b) official razorpay-php SDK + a hand-written service class, (c) a Cashier-style port you maintain yourself. Choose this package when the abstraction it ships (Eloquent models, Laravel events, config-driven keys/webhooks) matches your domain; choose (b) if you only need one-time payments.
• Platform/roadmap constraints. CI passing on PHP 8.2–8.5, Laravel 12 and 13, across SQLite, MySQL, MariaDB and PostgreSQL means the package does not pin your runtime or database choice — no infra argument against adoption, and no forced upgrade project.
• Release risk assessment (this release). v0.1.1 is explicitly runtime-identical to v0.1.0: no code changes, no breaking changes, no deprecations. The only consumer-visible detail is internal (test helper fixture() → jsonFixture()), which does not touch the public API. This is a no-op for product decisions — a green light to ship the same evaluation build, not a reason to re-plan.
• Maturity signal for gating. Positive: maintainer is actively modernising the test suite (Pest 4), widening PHP/Laravel coverage, and keeping CI green — indicates maintenance intent rather than an abandoned drop. Negative: still v0.1.x, pre-1.0, so the public API is not yet promised stable and there is no long-term support commitment. Treat as pilot-grade, not revenue-critical-grade, until 1.0.

When to Consider This Package

Adopt (pilot / behind an internal interface) when:

• Your app is Laravel 12 or 13 on PHP 8.2+, and Razorpay is your PSP for INR customers.
• You need subscriptions, recurring mandates, or webhook-driven billing state in Eloquent rather than a raw SDK.
• You are pre-scale and can absorb API churn: your integration sits behind your own BillingGateway interface so a swap to Stripe/Cashier or a direct SDK is a contained change.
• You want to avoid owning mandate/webhook plumbing for an MVP or a single-market launch.

Look elsewhere (or defer) when:

• You are Stripe-first or multi-PSP: use Laravel Cashier, or evaluate a gateway-agnostic billing layer.
• You need a 1.x+ API stability guarantee, published security-review artefacts, an SLA, or a multi-maintainer bus factor. v0.1.x with a single maintainer is a procurement blocker for enterprise.
• Your billing model is metered/usage-based, or you need GST invoicing, tax engine, dunning orchestration, or revenue recognition — likely out of scope; plan a separate layer.
• You need only one-time payments: the official Razorpay SDK plus a small service class is lower risk than a pre-1.0 wrapper.
• Your compliance posture requires audited release cadence and coordinated disclosure policy that you cannot yet verify.

How to Pitch It (Stakeholders)

This is a small, Laravel-native wrapper for Razorpay subscription billing, aimed at India-first products that need recurring payments without building mandate and webhook handling from scratch. The v0.1.1 release changes nothing at runtime — it is a test-infrastructure update (Pest 4 helper rename, CI on actions/checkout@v5), so there is no re-qualification work and no migration risk; the build we evaluated at 0.1.0 is the build we ship.

Two things matter for the decision. First, integration risk is low: the package's CI is green across PHP 8.2–8.5, Laravel 12 and 13, on SQLite, MySQL, MariaDB and PostgreSQL — so it will not constrain our stack or force an upgrade project. Second, product risk is moderate: it is pre-1.0, single-maintainer, with no API stability promise. Engineering recommendation is therefore a time-boxed pilot (one sprint) behind our own BillingGateway interface, which caps the cost of reversal at roughly the interface implementation. Gate general availability on two conditions: a 1.0 release, and a short security/maintenance review (release cadence, disclosure policy, dependency footprint).

Ask: approve the pilot scope and the interface-layer guardrail; defer any commitment to this package as the core revenue path until 1.0.