Laravel Sepay Laravel Package

Product Decisions This Supports

• Build vs. buy on payments: The Laravel 13 compatibility in v1.2.3 removes a hard blocker on "buy/adopt" for teams planning or currently on the newest Laravel major. Without it, the realistic alternative was a custom SePay integration (several dev-weeks of work plus ongoing webhook/VA reconciliation maintenance) — so this release shifts the calculus toward adoption.
• Upgrade timing and sequencing: If Laravel 13 is on the roadmap, this dependency no longer forces a "wait for the vendor" caveat in the platform upgrade plan. Conversely, if the team stays on Laravel 11/12 this quarter, v1.2.3 is a low-risk, non-urgent bump.
• Release-scope judgement: v1.2.3 is dependency hygiene (Dependabot CI actions), a docs typo fix, and framework support — no API, config, or behavior changes. That means no migration plan, no regression surface in application code, and no need to re-run payment reconciliation tests beyond standard smoke coverage. Treat it as a routine patch.
• Feature/use-case viability: Supports checkout and bank-transfer flows with SePay (Vietnamese payment gateway; QR/bank transfer and webhook-driven reconciliation). Useful for evaluating whether SePay covers the payment methods your target market actually uses before committing to a provider.
• Vendor-risk tracking: Two first-time contributors plus sustained Dependabot-only activity signals a small maintainer base. That is a standing input for a "single-maintainer dependency" register and justifies pinning the version and keeping a thin internal adapter layer around the package.

When to Consider This Package

Consider it when:

• You are on Laravel (11–13) and need SePay as a payment gateway, particularly bank-transfer/VietQR-style flows and webhook-driven order reconciliation.
• You want to avoid building and maintaining gateway signature verification, webhook handling, and retry logic in-house.
• You are doing a market-entry or MVP build for Vietnam and need a payments path in days, not months.
• You want a small, well-scoped integration you can isolate behind your own PaymentGateway interface.

Look elsewhere when:

• Your market/currency is outside SePay's coverage, or you need card processing, subscriptions, or multi-provider routing — use a broader gateway abstraction (e.g., Laravel Cashier or a PSP with local acquiring).
• You require enterprise support, SLAs, or a security review with a named vendor contact; this is a community package with a thin maintainer bench.
• Your compliance posture forbids direct handling of payment webhooks without a vendor DPA and audit trail.
• You need guaranteed long-term maintenance — pin the version and budget for the possibility of forking.

Caution on this release: Laravel 13 support is claimed via a community PR. Verify it in a staging environment on your actual Laravel 13 setup (including your webhook route and queue config) before relying on it in the upgrade plan. The docs-only typo fix also suggests webhook setup instructions were previously unclear — re-read them when integrating.

How to Pitch It (Stakeholders)

For executives: We evaluated laravel-sepay, a small Laravel package that integrates the SePay payment gateway. The new release (v1.2.3) is a maintenance release — it adds support for the latest Laravel version, plus routine tooling updates and a documentation fix. No behavior changes, no breaking changes, no migration required. The strategic point is narrow but real: it unblocks our Laravel upgrade path if we adopt SePay, and it lets us avoid building a payment integration ourselves. Recommendation: adopt behind an internal abstraction, pin the version, and treat the single-maintainer risk as a tracked dependency rather than a blocker.

For engineering: v1.2.3 is safe to take — dependency bumps to GitHub Actions, a webhook-instructions typo fix, and Laravel 13 support. Nothing touches runtime payment logic, so a standard CI run plus a webhook smoke test is sufficient. Please (1) confirm Laravel 13 support on our actual app in staging, (2) wrap the package behind our own gateway interface so a swap or fork stays cheap, and (3) review the corrected webhook setup docs rather than our older internal notes.