Payline Bundle Laravel Package

Product Decisions This Supports

• Payment provider selection for French/EU markets. Payline (Monext) is a viable PSP alongside Stripe/Adyen for French e-commerce, with card, wallet, 3DS2/SCA, and recurring-payment support. This bundle's value in that decision is narrow: it proves a Symfony-native path exists, not that it is the best path.
• Build vs. buy on the integration layer. The bundle is a thin wrapper — config tree, DI service definitions, and calls into Payline's official SDK. That framing supports the real decision: adopt the official payline-sdk-php directly and own ~200–400 lines of glue code, rather than take a dependency on a wrapper.
• Scope clarification for a Laravel roadmap item. Despite the repo description ("Symfony integration"), this is not a Laravel package. If a ticket says "integrate Payline in our Laravel app," this package contributes nothing reusable beyond reading its source as a reference implementation for request/response mapping.
• Checkout/recurring feature planning. The bundle's coverage of Payline wallet and recurring flows is useful as a feature-scope reference (what fields, what contract numbers, what webhook/return-URL handling is required) even if the code is never installed.
• Maintenance-burden budgeting. Stars (15) and dependents (0) are unchanged, and v3.0.4 is a single-line dependency-constraint patch ("Update PHP version support") — activity, not stewardship. No roadmap, no issue triage, no security response. That still belongs on the cost side of the build-vs-buy ledger; the patch nudges the "is it dead?" answer from yes to barely alive.

When to Consider This Package

Consider it when:

• You are on Symfony 3.4–5.x with PHP 7.x — or, per v3.0.4's PHP version-support update, a newer PHP if composer.json confirms it — and need Payline quickly with minimal glue code.
• You want a config-driven, container-wired integration (payline: config keys, injected Payline service) rather than hand-rolling a client — and you accept that you will fork it.
• You need a reference implementation to read for Payline API semantics: payment vs. authorization, wallet creation, 3DS return handling.
• The payment surface is small and stable — one-off card payments, no complex marketplace/split-payment logic.

Look elsewhere when:

• Your stack is Laravel. The bundle has zero portable value: it depends on Symfony's DI container, config component, and bundle bootstrapping. Use Payline's official SDK inside a Laravel service provider instead.
• You need maintained compliance. v3.0.4 widens PHP support only; it does not indicate any tracking of SCA/3DS2 or Payline API evolution. Payment code that isn't tracking PSP changes is a liability, not an asset.
• You are on Symfony 6/7. The PHP constraint may now permit installation, but Symfony-version compatibility is a separate, unaddressed question; expect to patch.
• You need community or vendor support. 15 stars and 0 dependents means no ecosystem, no issue triage, no security response — a patch release does not change that.
• You want an abstraction over multiple PSPs. This is Payline-specific by design; a gateway abstraction (e.g., Omnipay-style) is a different purchase.
• Payline's own SDK already covers it. Check the official SDK's surface first — if it does, the bundle is redundant.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small Symfony plugin for the Payline payment provider — 15 stars, no downstream users. A v3.0.4 patch recently landed, but its entire content is a PHP version-constraint update: it signals the repo isn't abandoned, not that it is supported. It is not a strategic asset and carries real maintenance and compliance risk if adopted as a dependency. The recommendation is to treat it as a reference document, not a vendor: if we integrate Payline, we do so on Payline's officially supported SDK and own the integration code ourselves. Cost is modest and bounded; the alternative — inheriting an effectively unmaintained wrapper in our payment path — is not.

To engineering (bullets):

• Not applicable to our Laravel services. It's a Symfony bundle; nothing here transfers except API call shapes.
• If Symfony: read the bundle for request/response mapping and wallet/recurring flows, then implement against payline-sdk-php directly. Budget 1–2 days of glue plus test coverage.
• Read v3.0.4 before assuming compatibility. It's a patch-level dependency constraint change with no stated feature, API, or compatibility detail — check composer.json for the actual php/symfony/* ranges rather than trusting the release note. No breaking changes are implied.
• Do not vendor it. One PHP-constraint patch after a long gap is not a maintenance cadence; there are no dependents and no security response process. Forking is the only sane posture, and if we're forking we should just write the thin layer.
• Non-negotiable: integration tests against Payline's sandbox, plus explicit handling of 3DS/SCA return URLs and idempotency on payment creation.
• Owner and review cadence: assign a named owner and a quarterly check against Payline API changes; payments code without an owner is a latent incident.