Ezehstart Laravel Package

Product Decisions This Supports

• Build vs. buy for the SaaS foundation. v2.2.1 reinforces the core value proposition of a batteries-included Laravel starter: the unglamorous but revenue-critical plumbing (checkout reconciliation, subscription sync, webhook retries, two-factor challenge) is maintained upstream so your team spends its roadmap on differentiation instead of billing edge cases.
• Investing in payments observability vs. building it. The dedicated payments.log channel — with record id, vendor, and error per failure — is a concrete answer to "how would we debug a failed charge at 2am?" If your roadmap had a "payments ops/alerting" epic, this release reduces its scope to routing and alerting on an existing log, not building the instrumentation.
• Support tier and on-call design. Previously, unverifiable checkouts and unrefreshable subscriptions only incremented a command's error count — silently. That is now a durable, greppable, admin-visible record. This directly changes the staffing assumption behind a support rotation: tier-1 can triage from the Logs screen without engineering escalation.
• Compliance and audit-readiness conversations. Payment failures, abandoned webhook retries, and trace-write failures landing in a dedicated, retained log is the kind of artifact security questionnaires and finance reviews ask about. It supports "yes, we can evidence payment failure handling" in a customer or auditor conversation.
• A deliberate UX/perf tradeoff on the public site. Home, blog, header, and the two-factor challenge move off wire:navigate to full page loads. That is a product decision as much as a technical one: slower perceived navigation on marketing pages in exchange for predictable analytics, SEO crawlability, and third-party script behavior. Worth confirming against your acquisition metrics before you accept it wholesale.
• Feature-flag and configuration hygiene. The production warning for disabled webhook signature checks is now logged rather than buried in the main log. That makes "is signature verification on?" an auditable fact rather than a config-review hope — useful evidence for a security review gate in your release process.

When to Consider This Package

Adopt when:

• You are building a subscription or one-off-payment SaaS on Laravel and would otherwise spend the first quarter on auth, billing, webhooks, admin, and member dashboards.
• You want payment failure handling that is observable by default — this release means you inherit a log channel and admin screen without wiring one.
• Your team is small enough that "someone reads the error count after a cron run" is a real risk you want closed.
• You need a two-factor challenge and a public content surface (home, blog) alongside the authenticated app, and you are comfortable with server-rendered public pages.
• You value low-friction upgrades: no migrations, no renames, one config-cache rebuild.

Look elsewhere when:

• You need multi-tenant isolation, complex org hierarchies, or billing models this package does not model — you will fight the scaffold more than you save.
• You are not on Laravel/PHP, or your platform team has standardized observability on structured logs shipped to an external aggregator. File-based storage/logs/payments.log is a good default but is not a substitute for centralized tracing; plan to ship it.
• You require SPA-style instant navigation across the public marketing site for measured conversion reasons. This release intentionally removes it there; verify the impact rather than assuming.
• Your compliance posture demands immutable, tamper-evident audit storage — file logs on the app server will not satisfy that on their own.
• You expect to rewrite the payments layer substantially; a scaffold you immediately fork loses much of its upgrade-path value.

How to Pitch It (Stakeholders)

To executives: This is a low-risk maintenance release on our SaaS foundation — no database changes, nothing renamed, roughly a one-command upgrade with a config cache rebuild. Its business value is risk reduction: payment failures that were previously invisible (checkouts the reconciliation job couldn't verify, subscriptions the hourly sync couldn't refresh, webhooks that exhausted retries) are now written to a dedicated payment log that support can read from the admin screen without engineering help. In practical terms, it shortens the time between a customer's payment going wrong and someone knowing about it — and it gives us evidence of payment-failure handling for security and finance reviews. It also makes a disabled webhook signature check in production a logged warning rather than a silent configuration drift.

To engineering: Straightforward bump. composer update then php artisan config:cache in the deploy — the new log channel is registered via config, so skipping that step means the channel silently won't exist. No migrations, no renames. Two behavior notes: several previously main-log entries (payment trace write failures, the production signature-check warning) now route to the payments channel, so update any log-based alerts that keyed off laravel.log; and the public site — home, blog, header, two-factor challenge — now does full page loads instead of wire:navigate. Verify that against your analytics and any client-side assumptions before rollout. Admin and member dashboard navigation is unchanged.

To product and design: The public-site navigation change is the only user-visible item and it is intentional. Expect marginally slower transitions on marketing and blog pages, and validate that this does not move your acquisition or signup funnel metrics. In exchange we get more predictable analytics and crawl behavior. Everything inside the authenticated product is untouched.