Payment Bundle Laravel Package

Product Decisions This Supports

• Choosing a payment-flow architecture (build vs. borrow the pattern): This package is most useful as a reference model for standardizing the payment lifecycle — intent → authorize → capture → complete → refund → reconcile — behind one internal interface instead of letting every integration own its own checkout state. The decision it informs is "do we adopt a generic flow abstraction?", not "do we adopt this dependency?"
• Provider-expansion roadmap: Its core idea — a generic orchestrator plus swappable provider adapters (SIPS/Atos, a fake/sandbox provider, or a custom one) — is directly reusable when planning for a second or third acquirer. It supports a roadmap where provider work is isolated and the checkout flow stays stable.
• Scope and risk framing for a payments epic: Because it is a Symfony 2.x-era bundle with 7 stars, 0 dependents, and no maintainer signal, it is a concrete artifact to justify why a payments component must be first-party-owned, idempotent, reconcilable, and covered by a fake-gateway test harness. Use it to argue for discipline, not to save time.
• De-risking via sandbox-first delivery: The Fake provider concept supports a product decision to ship the entire flow against a fake gateway (and a callback-replay test suite) before touching live money — a sequencing choice, not a library choice.
• Platform reality check for a Laravel product: This is a Symfony bundle — no service provider, no publishable config, no facades, Doctrine entities rather than Eloquent. For a Laravel product the decision it supports is explicit: treat it as design input and build a thin internal PaymentGateway contract bound to Omnipay or the acquirer's official SDK. Do not budget it as an install.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony (legacy bundle architecture), not Laravel, and need a generic payment-flow layer plus a provider-specific bundle.
• You want a worked reference implementation of instruction-as-state-machine — a persisted PaymentInstruction with amount, currency, state, and a free-form extended_data blob — to validate your own domain model before committing.
• A fake/sandbox provider is valuable to you as a template for an integration test harness (capture → redirect → return → complete, with duplicate-callback idempotency asserted).
• You are prepared to fork, vendor, and permanently own the code, including security patching — because upstream will not.
• You can run a time-boxed spike proving it installs and runs under your target PHP version (expect PSR-0 autoloading, PHP 5.x-era syntax, and PHP 8.x friction).

Look elsewhere — or rather, borrow the pattern and build — when:

• You need a Laravel-native integration; the equivalent work is a service provider, config publishing, an event bridge, and Eloquent persistence, which is re-platforming, not integration.
• You need production-grade payments: idempotency for capture/refund, webhook dedupe and replay safety, reconciliation against the gateway ledger, disputes, refunds, subscriptions, or marketplace splits.
• You are in PCI-DSS scope and need CVE monitoring, advisories, and an escalation path — none exist here.
• You want community validation; 7 stars and 0 dependents means no one has shaken out defects in production against modern PHP.
• An actively maintained option covers the same ground: league/omnipay for the generic-flow-plus-drivers pattern, or laravel/cashier (Stripe/Paddle) if the acquirer permits.

How to Pitch It (Stakeholders)

Executive summary. This is a small, generic Symfony payment-flow bundle — not a complete payment product, and not a Laravel package. It is architecturally sound in concept (one flow, swappable provider adapters) and weak as an asset (7 stars, 0 dependents, no maintainer, no release cadence, no security advisories). Recommendation: use it as a design reference, reject it as a dependency. We should adopt its pattern — a persisted payment instruction, an explicit state machine, provider work isolated behind an interface, a fake gateway driving the whole test suite — and implement it ourselves on a maintained foundation. Do not put an unmaintained, payment-path component in the critical path of a product that moves money.

Engineering summary. The bundle only orchestrates; it requires a separate provider bundle (Sips, Fake, or your own) to do anything. It assumes Symfony's DI container, bundle registration, and event dispatcher, and persists via Doctrine. Nothing in the repo targets illuminate/*, so a Laravel adoption means writing a service provider, bridging Symfony's dispatcher to Laravel's, and resolving persistence against Eloquent — days to weeks of glue on an unmaintained base, in exactly the code path where bugs cost money. The realistic plan: (1) document the reference model, (2) define a first-party PaymentGateway contract, (3) implement against Omnipay or the acquirer SDK, (4) ship behind a fake adapter with callback-replay and idempotency tests, (5) build reconciliation before production traffic. Gate any contrary decision on a time-boxed spike that exercises the Fake gateway end-to-end — and treat failure as the expected outcome.

The risks to put in front of the risk owner. Partial state after a gateway timeout (authorized but not recorded); missing idempotency keys enabling double capture; replayed callbacks with no dedupe; internal state drifting from the gateway ledger with no reconciliation job; silent exceptions from pre-modern error-handling conventions. Each is fixable with engineering discipline — none is fixed by an unmaintained library.