Payment Bundle Laravel Package

Product Decisions This Supports

• Owned-payments vs. hosted billing (build-vs-buy): This package is a starting point for the "own the payment domain, plug in PSPs" option. It provides payment and payment-method domain scaffolding plus gateway integration seams — the part of a payment build that is mostly design rather than differentiation. It does not settle the buy decision; it lowers the cost of the build path so the comparison can be made on evidence.
• PHP/Laravel stack strategy — read this carefully: Despite the "Laravel/PHP package" framing, softspring/payment-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no publishable config, no Eloquent models. In a Laravel codebase the realistic PM decision is not "adopt the package" but "use its domain model and gateway abstraction as a reference and build a stack-native internal payment layer." That reframes the roadmap item from a dependency to a design input, with a much smaller schedule benefit.
• Multi-gateway and geographic expansion: A gateway-agnostic abstraction supports routing by country/currency or PSP failover — relevant to EU/Spain rollouts where local acquirers must sit alongside international card processing. Worth citing in a market-expansion roadmap even if you don't take the code.
• Roadmap sequencing for monetization: Checkout, refunds, partial captures, webhooks, and reconciliation are prerequisites for subscriptions, invoicing, dunning, and marketplace payouts. Deciding whether this layer is "configure" or "build" gates every downstream monetization epic.
• Make-vs-fork: Zero stars, zero dependents, score of 0. Treat it as a fork-or-reference, not a dependency. Budget it as a small engineering project with a head start, not as a procurement line item.
• Portability/lock-in posture: A self-hosted, PHP-native payment layer keeps transaction data and PSP relationships portable, at the cost of owning compliance and maintenance. This is the tension to name explicitly in any architecture decision record.

When to Consider This Package

Consider it when:

• Your stack is Symfony with Doctrine ORM and the EventDispatcher, and you want payment entities to live in the existing domain rather than a separate service. This is the only context where the package is installable as intended.
• You need PSP abstraction — multiple acquirers, per-country routing, or a provider mainstream billing SaaS doesn't support.
• Your team accepts ownership of payment correctness: webhook idempotency, state machines, refund/partial-capture semantics, reconciliation.
• You can absorb maintenance risk: no community signals, no dependents, unknown release cadence, unknown test coverage, single-vendor origin. Treat it as unvetted source requiring security and license review before production.
• You are explicitly evaluating the owned-payments route and want a concrete artifact to price the build against.

Look elsewhere when:

• You need turnkey subscriptions, proration, tax, SCA/3DS, and dunning on day one — a hosted billing platform or a mature stack-native billing package wins on time-to-market.
• You are on Laravel. The integration cost is effectively a port (estimating one to three engineer-weeks before anything production-shaped, with no guarantee the original semantics survive). A first-party PSP SDK, an Omnipay-style abstraction, or your own Eloquent-backed payment layer is the better bet.
• You require an SLA, CVE response, or a vendor that will exist in three years.
• Payments sit in PCI scope and you have no appetite to audit code you cannot influence.
• The roadmap is a single gateway and one-time charges; the abstraction overhead exceeds the value.

How to Pitch It (Stakeholders)

To executives (2 minutes): We need to decide how we take payments. Rent a billing platform and accept per-transaction cost plus lock-in, or own the payment layer inside our application and control which acquirer handles each transaction. This package is a head start on the second path — it gives us a payment and payment-method domain model and gateway plug-in points, typically several weeks of design work. Two caveats matter. First, it is built for Symfony; our Laravel stack means we would be lifting the design, not installing the code, so the schedule saving is real but smaller than it looks. Second, it has zero adoption — no stars, no dependents — so we should treat it as a codebase to audit and fork, never as a dependency to trust. My recommendation: a time-boxed spike plus security and license review, followed by a go/no-go on owned payments, rather than committing engineering now.

To engineering: Symfony-native, Doctrine-backed, event-driven — architecturally it is a good fit conceptually, but not literally for a Laravel app. What's useful to us is the entity relationships, the payment state machine shapes, and the gateway abstraction seam; what's not usable is the DI extension, config tree, and framework wiring. Plan to vendor it as reference, then implement behind our own PaymentGateway interface so the choice stays reversible. Add our own test coverage around idempotency, webhook replay and signature verification, refunds, partial captures, and multi-currency rounding. Pin everything we copy and document that we own it.

The ask: Approve a time-boxed evaluation (roughly one week: source audit plus a PSP sandbox spike) with a security and license review, and make the build-vs-buy call on evidence rather than on the package's popularity.