- Can I install lolautruche/payline-bundle in a Laravel application?
- Not as a Laravel package. It is a Symfony bundle built around a Bundle class, a DependencyInjection Extension and a Configuration tree, and Laravel has no registerBundles() step or compiler-pass pipeline to execute any of that. The genuinely portable asset is its transitive dependency on Monext's payline/payline-sdk, which is plain PHP. Treat this repository as a reference implementation and rebuild the glue as a service provider.
- Does lolautruche/payline-bundle support PHP 8.3/8.4 and modern Symfony versions?
- The v3.0.4 release notes say only "Update PHP version support", which is not enough to conclude anything. Read the composer.json PHP constraint to see whether the floor was raised, the ceiling widened, or both, and check whether the symfony/* constraints moved across v3.0.0 to v3.0.4. If they still cap around ^4.4 or ^5.x, the bundle will conflict with Laravel 11/12's Symfony requirements regardless of PHP support.
- How do I configure the Payline merchant ID, access key and contract numbers?
- In Symfony you set them in the bundle's configuration section, and the extension maps them into the Payline SDK client. If you rebuild this in Laravel, mirror the same keys in a config/payline.php file and read them through config() so credentials stay in .env. Keep live credentials out of version control and out of staging deploys.
- How does the bundle handle Payline sandbox versus production environments?
- The bundle lets you point the client at Payline's sandbox or the production endpoint through configuration. Drive that setting from an environment variable so a staging deploy can never accidentally hit live payments. Verify which endpoint values the installed version actually accepts before you go live.
- Which Payline API generation does this bundle use, SOAP doWebPayment or REST?
- The bundle wraps the official payline/payline-sdk, so the API generation is whatever that SDK exposes, and the v3.0.4 notes say nothing about a change here. This matters because the older SOAP doWebPayment generation predates the current REST APIs. Confirm the generation before building compliance or reconciliation work on top of it.
- Is lolautruche/payline-bundle PSD2 and 3DS v2 (SCA) compliant?
- A PHP version bump does not make a 3DSv1-era wrapper compliant with PSD2 strong customer authentication. The v3.0.4 release notes say nothing about EMV 3DS v2 fields, SCA flows or updated authentication requests. If your merchant traffic falls under PSD2, verify 3DS v2 support in the underlying SDK before shipping anything to production.
- How do I handle the Payline return URL or webhook?
- In Symfony the bundle provides the controller or listener for the payment return URL, and you point Payline at that route. In Laravel you would write a CSRF-exempt route that accepts the out-of-band callback. Treat the incoming response as untrusted input and re-query the payment status from the Payline API before fulfilling an order.
- How do I inject the Payline client into my own service or controller?
- In Symfony the bundle registers the Payline services in the DI container, so you type-hint the client and let autowiring resolve it. In Laravel the equivalent is a singleton binding in a service provider that constructs the SDK client from config. The full glue surface is small, roughly 150 to 300 lines for config, service wiring and a return route.
- What should a Laravel team use instead of this bundle?
- There is no Laravel-native Payline package worth defaulting to, so most teams require Monext's payline/payline-sdk directly and wrap it in their own service provider. You then own the config file, the return route and the error handling, which is a modest amount of code. Using this bundle's structure as a blueprint is reasonable; installing the bundle itself is not.
- Is lolautruche/payline-bundle actively maintained and safe for production?
- One patch release is not a maintenance commitment. The repository has a small star count, no dependents and a single maintainer, so there is little issue history to mine for edge cases. The PHP support bump slightly reduces the abandoned-package risk but does not create a support relationship, so plan to own the integration and its failure modes yourself.