Symfony Ideal Laravel Package

Technical Evaluation

Architecture fit. The headline finding is a stack mismatch that a TPM must surface before any engineering time is committed: lensmedia/symfony-ideal is a Symfony bundle, not a Laravel package. It assumes symfony/framework-bundle, a Symfony DI container, a bundle configuration tree, and auto-registration — none of which exist in a standard Laravel application. Laravel ships Symfony components (HttpFoundation, Console, Process, Routing) but not the framework bundle. Practically, there is no supported "composer require and go" path for a Laravel target. The two viable routes are (a) extract the underlying payment client and discard the bundle glue, or (b) treat the repository as reference material only. Which route is available depends entirely on how tightly the iDEAL transaction logic is coupled to container wiring — if business logic lives in AbstractController subclasses or container-aware services, extraction is a rewrite, not a lift. That is the first discovery task, not an implementation task.

Integration feasibility. Composer resolution is the first hard gate. The bundle will pull symfony/http-kernel and symfony/dependency-injection at minimum; a framework-bundle requirement makes it unbootable in Laravel regardless of version alignment. Run composer why-not lensmedia/symfony-ideal in a throwaway branch before any design work is socialized. Secondary feasibility signals are also weak: zero stars, zero dependents, a single release in January 2024, a typo in the package description ("handeling"), and a changelog whose only visible entry fixes "old/new status conversion tables." That is a single-maintainer artifact with no peer-review signal.

Technical risk.

Key questions (blocking — answers gate the decision).

1. Which API does it actually talk to — legacy iDEAL Acquirer/Hub, a PSP (Mollie/Adyen/Buckaroo/Stripe), or a bespoke bank integration?
2. Does it implement iDEAL 2.0, and what is the migration story away from classic iDEAL?
3. Is the payment core separable from Symfony DI, or is it container-coupled at the service level?
4. Are callbacks/push notifications cryptographically verified? Is there idempotency on payment create?
5. Is there a test suite, CI, sandbox fixtures? What is the license?
6. Who is the maintainer, and is there any stated maintenance commitment?
7. Does the package's PHP constraint align with our Laravel + PHP 8.2/8.3 baseline?
8. Does it support refunds, partial refunds, and status reconciliation?

Integration Approach

Stack fit. Poor as a dependency; usable as reference. The TPM recommendation is to build against a maintained PSP SDK that already abstracts iDEAL 2.0 (Mollie, Stripe, Adyen, Buckaroo) and use this repository only to understand protocol shape or borrow specific parsing/status-mapping logic. Payments is the wrong place to accept a zero-signal package on a scheme that is itself mid-migration. Frame the decision to stakeholders as build vs. buy, with "buy via PSP" as the default and this bundle as an optional prototype input.

If we must use the underlying code (extract, don't install).

• Vendor the payment client into app/Domain/Payments/Providers/Ideal or a private Composer package; strip DI/container coupling; replace the Symfony HTTP client with Laravel's Http facade or Guzzle.
• Wrap behind a first-party interface: PaymentGateway::createPayment / getStatus / refund / handleCallback, with DTOs at the boundary. No package types leak into domain code.
• Isolate behind a feature flag and a config-driven provider selector so swapping to a PSP is a config change, not a refactor.

Compatibility checks before design sign-off. Validate the package PHP constraint against the runtime; validate transitive Symfony component versions against Laravel's pinned set; confirm whether framework-bundle is a hard requirement (if so, the bundle is unbootable in Laravel and only extraction is viable).

Migration path (if already running this package). Strangler pattern: place the domain interface in front of existing calls, add contract tests against the iDEAL/PSP sandbox covering create, status, refund, and callback, then swap implementations behind that interface. No big-bang cutover.

Sequencing.

Add a parallel track for the buy option: PSP contract, onboarding, and pricing negotiation typically run 2–4 weeks and should not be blocked by the spike.

Operational Impact

Maintenance. Plan as if unmaintained: no dependents, no stars, no visible community, nothing since January 2024. We own every bug and every security fix from day one. Budget a named internal owner, a quarterly review, and a private fork in our own registry so upstream disappearance is not an incident. Add the Symfony→Laravel extraction to the maintenance burden — it is now our code, not theirs.

Support. No vendor, no SLA, no CVE channel. When a scheme-mandated change lands — iDEAL 2.0 endpoint retirement, TLS/certificate requirement, signature algorithm change — we learn via failed payments, not a changelog. Mitigation: subscribe directly to PSP and scheme bulletins rather than relying on the library's release notes.

Scaling. iDEAL itself scales fine (redirect plus asynchronous status); the risk is our integration shape. Requirements: idempotency keys on every create call, a durable queue for callbacks and status polling, DB-level uniqueness on transaction reference, no synchronous polling inside a web request, a sweeper for stale pending transactions, and monitoring for certificate expiry and clock skew.

Failure modes to design for.

• Double charge — client retries POST without an idempotency key, producing two transactions. Highest severity.
• Lost callback — user returns but the push never lands; order stuck pending indefinitely. Needs a reconciliation poller.
• Forged callback — unauthenticated return URL treated as authoritative. Always re-verify server-side; never trust the redirect.
• Amount/currency tampering — trust the PSP status response, not the form post.
• Certificate rotation outage — merchant certificate expires; all payments 500.
• Scheme/API deprecation — classic iDEAL endpoints retired; integration dies with no code change on our side.
• Silent failure — no alerting on payment success-rate drop; revenue leaks undetected for days.

Ramp-up. Two to three days for a PHP engineer to be productive in the code, plus one to two days of iDEAL/PSP domain onboarding (status model, refunds, reconciliation). Add finance/ops for reconciliation sign-off and an on-call runbook. Because the stack is Laravel and the package is Symfony, add the extraction effort — realistically one to two weeks before a first production payment.

Bottom line for the roadmap. The problem (iDEAL support for NL customers, typically 60–70% of Dutch e-commerce volume) is worth solving; this package is not the recommended production solution. Leverage it as a spike and a reading reference, keep payment risk off the critical path by defaulting to a PSP, and only reconsider if the source audit reveals a cleanly separable client plus evidence of iDEAL 2.0 support.