Laravel Payment Laravel Package

Product Decisions This Supports

• Multi-gateway abstraction as a product lever. One facade plus config-driven gateway names means we can add a second or third PSP (regional wallets, local card acquirers, failover acquirer) without new payment code paths — it directly de-risks roadmap items like geographic expansion, local payment methods, and acquirer redundancy.
• Build vs buy on payment plumbing. This is a thin Laravel glue layer over League Omnipay. Adopting it means checkout integration becomes configuration plus driver selection instead of bespoke request-signing code. Keep PSP-specific business logic — refund policy, reconciliation, dunning, retry rules — in our domain layer so the abstraction stays swappable.
• Platform-currency forcing function. 4.0.0's floor of PHP ^8.3 and Laravel ^13.30 makes this package a dependency of our framework-upgrade epic, not a standalone line item. It should be scheduled with that workstream, and its release cadence should be an input to our support-matrix commitments.
• Low-churn upgrade story. The release explicitly preserves gateway names, payment alias, facade, option argument expansion, default precedence, gateway caching, and the factory implementation. That means the 4.0.0 upgrade is a maintenance task we can slot into a sprint, not a feature project — a meaningful scheduling and cost input.
• Where PM must add investment. The package's own suite is 17 tests / 48 assertions against a dummy gateway with no live payments: that is wiring coverage, not money-movement coverage. Budget our own sandbox end-to-end tests, reconciliation checks, and a driver-compatibility gate before any gateway is enabled in production.

When to Consider This Package

Consider it when:

• The app is on PHP 8.3+ and Laravel 13.30+, and product needs more than one PSP behind a single internal interface.
• The team already standardizes (or will standardize) on Omnipay drivers and wants Laravel-native config, facade, DI, deferred providers, and gateway caching.
• You need fast coverage of regional gateways and aliases, and you value a stable public surface — 4.0.0 keeps the developer-facing API intact, so integration knowledge transfers across the upgrade.
• You can absorb an upgrade cadence that tracks Laravel majors rather than spanning them.

Look elsewhere or defer when:

• You are still on PHP <8.3 or Laravel ≤12 — 4.0.0 is simply unavailable; decide between pinning 3.x with a dated migration plan and not adopting.
• Your gateway is not covered by a maintained Omnipay driver. 4.0.0 pins Omnipay ^3.2.1, Common ^3.5.1 and Guzzle 7 adapter ^1.1, and separately installed drivers must be checked; an unmaintained driver is the real risk here, not this package.
• Payments are core revenue under strict PCI/audit obligations requiring vendor SLAs, live-transaction test evidence, and formal security review — this is a small open-source wrapper, so tokenization/hosted fields, key management, audit trails and pen testing remain ours to own.
• You need subscriptions, invoicing, tax, dunning or reconciliation out of the box — that is a payments platform decision, not an abstraction-layer decision.
• You require long-term support across multiple Laravel majors, or single-maintainer bus-factor risk is unacceptable for a tier-1 dependency. Mitigate with pinned versions and a documented fork plan.

How to Pitch It (Stakeholders)

For executives: This is a small, free Laravel adapter that lets us put multiple payment providers behind one internal interface instead of writing provider-specific code each time we add a market or a payment method. Release 4.0.0 modernizes it — PHP 8.3+, Laravel 13.30+, current Omnipay and Guzzle — and deliberately leaves the developer-facing interface unchanged, so our application code is not rewritten. The cost is an upgrade task bundled into the platform upgrade we are already planning, not a new project. The trade-offs are honest ones: it is community-maintained, its tests use a dummy gateway with no live payments, and it only supports the newest Laravel. We therefore hold it to our standard bar — our own sandbox end-to-end tests, a reviewed driver-compatibility list, and pinned versions — before any real gateway is enabled. Decision requested: approve adoption/upgrade as part of the Laravel/PHP platform workstream with that validation gate, or defer if we need multi-major Laravel support and vendor SLAs.

For engineering: 4.0.0 breaks on platform only — PHP ^8.3, Laravel ^13.30, Guzzle 7 adapter ^1.1, Omnipay ^3.2.1, Omnipay Common ^3.5.1; Laravel 12 and earlier are unsupported. The public surface is explicitly preserved: gateway names, payment alias, facade, option argument expansion, default precedence, gateway caching, and an unchanged factory. Internal changes are Laravel's deferred-provider contract and explicitly nullable gateway names. Migration steps: bump constraints; audit every installed gateway driver against the pinned Omnipay versions; update call sites where a single array argument now needs an outer array; run sandbox end-to-end tests per gateway. Known noise: oldest allowed transitive dependencies emit upstream deprecations on PHP 8.4+ and these are not suppressed — either move to latest dependencies or filter in CI knowingly. Coverage reality: 17 tests / 48 assertions (six original unit tests plus Laravel 13 integration, dummy gateway, no live payments) — treat as wiring coverage and own the payment-path tests. CI is green on PHP 8.3 with lowest secure dependencies and on 8.3/8.4/8.5 with latest, including strict validation, lint and default Composer audit. See PR #18 and the README upgrade guide.