Getting Started

Treat this as a legacy Symfony bundle, not a Laravel package. It is archived, read-only, last released in 2016, and tied to the Elcodi e-commerce stack. As a Laravel developer, your realistic use cases are: maintaining an existing Symfony/Elcodi application, mining the domain model, or porting payment-method concepts into a modern Laravel codebase.
Do not start a new Laravel project by installing this bundle. Composer will likely conflict with modern PHP, Symfony, and Doctrine versions. Use a locked Docker image with the original PHP/Symfony constraints if you must run it.
Minimal legacy setup:
1. Work from the elcodi/elcodi monorepo or a locked composer.json, not the read-only split repo alone.
2. Require elcodi/payment-bundle (or the monorepo equivalent) under the compatible PHP/Symfony version.
3. Register Elcodi\Bundle\PaymentBundle\ElcodiPaymentBundle in AppKernel.
4. Configure Doctrine and the bundle’s required Elcodi dependencies; clear cache after config changes.
5. Inspect Resources/config for service IDs and Entity/PaymentMethod plus the provider/manager classes before writing code.
First practical use case: display enabled payment methods at checkout and attach the selected method to an order. Use the bundle’s provider/repository services rather than writing direct Doctrine queries.

Implementation Patterns

Use payment methods as configuration/catalog data. Create PaymentMethod records with a code, display name, and enabled flag; filter through the bundle’s provider service so checkout only sees active methods.
Inject services through Symfony’s container. Avoid instantiating managers or repositories directly. Run debug:container to confirm service IDs because names vary across Elcodi versions.
Checkout flow: load enabled methods → validate the selected method → create/persist payment intent → call the gateway adapter → record the result and transition the order. Keep gateway credentials in environment-specific config, never in code.
Extend through decoration and interfaces where possible. Prefer a custom provider or gateway adapter over editing vendor files; the bundle is read-only and vendor edits will be lost.
For admin CRUD, reuse the bundle’s forms/controllers if they still fit, or build a thin admin layer around the same entity/repository. Keep payment-method lifecycle changes out of checkout request code.
Testing: mock the payment-method provider and gateway adapter in unit tests. Use fixtures for enabled/disabled methods and never hit a live gateway in CI.
Laravel integration pattern: do not composer-require this into a Laravel app. Either keep the legacy Symfony app behind an internal API and call it from Laravel, or port only the small domain model—payment method entity, provider filter, manager service—into Laravel-native services.

Archived/EOL status is the main risk. There are no security fixes, no PHP 8/Symfony 6 support, and likely no compatible dependency graph. Freeze versions and isolate the legacy app.
The split repo is read-only. Issues and PRs belong to elcodi/elcodi, but the project is archived, so do not expect upstream support.
Dependency hell is common: the payment bundle pulls in multiple Elcodi components. A partial composer update can break Doctrine mappings or container compilation. Keep a committed lock file.
Service IDs and namespaces differ by version. Confirm them with Symfony’s container/router debug commands before wiring checkout code.
Doctrine mapping and entity overrides are fragile. If you extend PaymentMethod, verify mapping inheritance and clear metadata cache after changes.
Payment-method changes may be cached in the container or provider layer. Clear cache and rebuild after config or fixture updates.
PCI and logging: never log raw card data or gateway secrets. Prefer hosted payment pages or tokenization; log only payment IDs and status transitions.
Debugging checklist: inspect the payment_method table, check container compilation errors, enable the Symfony profiler in non-production, and trace gateway request/response through your adapter.
Extension points to look for: custom payment-method providers, gateway adapters, order/payment events, and service decoration. Prefer these over modifying bundle code.