- How do I install webtopay/libwebtopay in a Laravel application?
- Install it with Composer using composer require webtopay/libwebtopay. The library exposes a global WebToPay class, so you consume it with use WebToPay in your own code. Because it is not a Laravel package, there is no package discovery or service provider; create an App\Payments\Paysera adapter and bind it in your application service provider.
- Is webtopay/libwebtopay a Laravel package with a service provider or facade?
- No. It is a framework-agnostic PHP SDK with no Laravel service provider, facade, publishable config, or package discovery. The README shows static-style calls through the global WebToPay class. In Laravel, wrap it behind a first-party contract such as CheckoutGateway and avoid direct WebToPay calls in controllers, jobs, or domain services.
- How should I configure Paysera credentials in a Laravel app?
- Put Paysera settings in config/payments.php and feed them from .env or a secret manager. Store the project ID, sign password, Paysera public key, merchant private key, callback URL, and environment flag for test versus live. Keep these values out of source control and out of the merged WebToPay.php file.
- How do I validate Paysera callbacks securely in Laravel?
- Use the library to check transferred and received security parameters, but make SS2 RSA validation mandatory and explicitly disable or reject SS1 MD5. Re-validate every callback against your internal order record, including amount in minor units, currency, and order reference. Do not treat a valid signature alone as authoritative before fulfilment.
- How can I test Paysera payments in Laravel without calling the live gateway?
- Wrap WebToPay behind your own adapter interface and mock or fake that interface in tests. Build callback-validation fixtures for SS2 success and failure cases, amount mismatches, and replay attempts; the library includes a run_tests.sh script but your own fixtures are the real safety net. Avoid calling the static WebToPay API directly in controllers or jobs because it is hard to mock cleanly.
- Does webtopay/libwebtopay support PHP 8.2 and 8.3, and is it actively maintained?
- The ^3.0 release is documented as PHP 7.4-era code with strict types and type hints, and its interface is unchanged from ^2.0. PHP 8.2 and 8.3 compatibility is not verified by the README, so run a CI matrix before committing. The publisher is Paysera itself, which is a strong bus factor, but low star counts and no visible test suite mean you should rely on your own tests and fixtures.
- Does webtopay/libwebtopay support refunds, payouts, and transaction reports?
- The README covers collecting online payments through Paysera Checkout and validating transferred or received security parameters. Refunds, payouts, transaction reporting, and reconciliation may live outside this library in other Paysera APIs. Confirm the available endpoints in Paysera's documentation and add explicit adapter methods for any operations your application needs.
- What is the difference between SS1 and SS2 callback validation in Paysera?
- SS1 uses MD5-based parameter signing, while SS2 uses RSA signatures. For production, require SS2 and explicitly disable or reject SS1 so a downgrade cannot bypass stronger validation. The library can check security parameters, but you must still compare the validated callback data with your own order record before marking a payment as paid.
- Is LGPL-3.0 licensing a problem for a commercial Laravel SaaS using webtopay/libwebtopay?
- LGPL-3.0 generally permits dynamic linking from proprietary code, and normal Composer consumption satisfies that model. Copying the merged WebToPay.php file into your application source, or patching it in-tree, changes the analysis and should be avoided without legal review. Route the licensing question to legal before build, especially if you ship a binary or appliance.
- How do I prevent duplicate Paysera callbacks from double-crediting orders in Laravel?
- Gateways retry callbacks, so enforce a unique constraint on the payment reference and use a monotonic state machine such as pending to paid to refunded with no regressions. Re-validate amount, currency, and order reference against the internal order record before fulfilment. Queue callback processing and make each transition idempotent so duplicate deliveries cannot double-credit or double-fulfil an order.