Adyen Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for recurring billing: This package sits at the extreme "build" end of the spectrum. It is a thin Symfony2 wrapper that creates Adyen recurring contracts and submits merchant-initiated charges — and stops there. It models no subscription state, no proration, no dunning, no retries, no invoices, no tax, no reconciliation. Reading it is the fastest way to price the true cost of hand-rolling a billing layer versus buying a managed product (Adyen's own subscription APIs, Chargebee, Recurly, Stripe Billing). The delta between this bundle's surface area and a production billing system is the build estimate.
• PSP selection and integration strategy: Evidence that Adyen recurring was historically integrated at the framework-bundle level, by third parties, without an official SDK path. That informs a real roadmap question — is our PSP well-supported for our stack, or will we own the integration forever? If the answer is "we own it," that belongs in the platform budget, not a ticket.
• Architecture reference, not a dependency: At 22 stars, zero dependents, and archived, its only durable product value is as a readable specification of the recurring-billing domain: initial authorisation → recurring contract reference → merchant-initiated charge → contract disable, plus webhook notification handling. That domain shape is worth lifting. The Symfony wiring is not.
• Subscription roadmap scoping: The concepts it touches (shopper references, stored payment methods, MIT charges, idempotency on retries) are exactly the checklist a PM should demand of any billing design review. Use it to interrogate engineering's proposal, not as the proposal.
• Roadmap risk flag: A candidate dependency that cannot receive a security patch is a compliance liability. That is a decision input, not a detail.

When to Consider This Package

Rarely — and never as a new dependency. It is viable only if all of the following are true:

• You maintain a legacy Symfony 2.x application that already depends on this bundle, and you are assessing migration or strangler-migration risk rather than greenfield adoption. (Symfony 2.8 reached end of life in 2018.)
• You specifically need a worked example of Adyen recurring contract creation and subsequent charge request/response shapes before implementing against the official adyen/php-api-library.
• You are doing an archaeological read of an existing PHP recurring-billing system whose original integration knowledge has been lost.

Look elsewhere if any of these are true — which, for most teams, is always:

• You are on Laravel. Despite the framing, this is a Symfony2 bundle. No service provider, no facade, no publishable config, no container compatibility. There is no port; it is a rewrite.
• You need anything maintained. Archived, zero dependents, no security response path. In payments, that is disqualifying.
• You need to confirm the Adyen endpoints it targets are still enabled for your merchant account. The bundle uses the legacy recurring model; Adyen's current model is Checkout API with shopper references and stored payment methods. If legacy endpoints are disabled for new accounts, this package has no viable path at all — and that is an account-level question only Adyen can answer.
• You are on a supported PHP version. Symfony2-era Composer constraints will not resolve against PHP 8.x or Laravel 10/11's Symfony 6/7 components.

Recommended path instead: official Adyen PHP SDK (or Checkout SDK) wrapped in a Laravel-idiomatic service provider with typed config, a gateway interface, queued webhook jobs, and idempotency keys — with subscription lifecycle owned by a billing platform rather than in-app code.

How to Pitch It (Stakeholders)

One line for executives: We evaluated sparkling/adyen-bundle and do not recommend adopting it. It is an archived, Symfony2-only wrapper for Adyen recurring billing with 22 GitHub stars and no downstream dependents — it cannot be used in our Laravel stack without a rewrite, and it will never receive a security patch. Recommendation: integrate Adyen through their official, maintained PHP SDK, and treat this repository as documentation only.

For engineering:

• Wrong framework, structurally. A Symfony bundle contributes a DI extension, config tree, and service definitions; Laravel has no kernel to consume them. The realistic reusable surface is a handful of classes wrapping Adyen's legacy recurring API.
• Small enough to rebuild, too risky to inherit. A competent payments engineer reimplements the happy path in 1–2 days and a production-grade version with error handling, idempotency, and tests in 3–5. Adopting it saves days and costs quarters.
• Dead code with compounding risk. Archived, zero dependents, PHP 8 incompatible, and pinned to Adyen's legacy recurring endpoints. Composer resolution will likely fail before any code runs; the fallbacks are vendor-and-patch or run it as a legacy sidecar — neither is a dependency.
• Payments-specific hazards it does not solve: duplicate recurring charges under naive retry, silent contract drift when Adyen changes a response shape, and Symfony2-era parameters.yml secret handling. All of these are ours to build regardless.
• Gate first. Take the endpoint inventory to Adyen and confirm legacy recurring API availability and sunset dates for our merchant account. If that fails, the initiative ends there.
• What it is good for: a 2–3 day spike to extract the domain model and endpoint list, then build natively on adyen/php-api-library with sandbox validation and a parallel run before cutover.

The ask: Approve the official Adyen SDK as the integration path. Fund a short spike to mine this repository for domain design. Add nothing to composer.json — this package is a reference, not a dependency. If an existing Symfony system already runs it in production, scope that as a strangler migration with dual-write, not a port.