- How do I install creagia/laravel-redsys in a Laravel application?
- Install it with Composer using composer require creagia/laravel-redsys, then publish the package configuration and add your Redsys merchant credentials through your secret management workflow. On version 4.x, plan for Laravel 11 or newer; older Laravel versions are blocked by the package's support matrix.
- Which Laravel and PHP versions does creagia/laravel-redsys support?
- Version 4.0.0 adds Laravel 13 and PHP 8.5 compatibility and drops Laravel 8, 9, and 10, so Laravel 11, 12, and 13 are the straightforward targets. The release notes say PHP 8.5 compatibility but do not clearly state the minimum PHP version, so verify the Composer constraint before planning a runtime upgrade. For Laravel 8–10 applications, pin to the 3.x line.
- Can creagia/laravel-redsys handle Redsys server notifications and callbacks securely?
- Yes, the package is intended to help you handle Redsys server notifications and callbacks, including verification of the gateway's signed messages. Treat the notification endpoint as security-sensitive and verify signatures before marking orders as paid. The package is a thin wrapper around Redsys signing and verification, so your application still needs clear incident-response ownership.
- Does creagia/laravel-redsys support Bizum, cards, and SEPA transfers?
- Redsys supports cards, Bizum, and SEPA transfers, and this package integrates your Laravel app with that gateway. Whether a specific method is available depends on your Redsys merchant contract and the parameters you send, not just on the package. The package does not provide a separate payment-method abstraction across providers.
- Is creagia/laravel-redsys a multi-PSP payment abstraction?
- No. creagia/laravel-redsys is a Laravel-native Redsys integration layer, not a multi-PSP abstraction or unified payment domain model. If you need routing across providers, keep payment logic behind your own interface or a dedicated payment service and use this package only inside the Redsys adapter.
- How do I upgrade from creagia/laravel-redsys 3.x to 4.x?
- The move from 3.x to 4.x is a support-matrix break rather than a normal in-place package upgrade. Upgrade the host application's PHP runtime and Laravel version to 11 or newer first, resolve other dependencies pinned below that floor, then require ^4.0. The release notes mention no behavioural or API changes, but you should still review the diff and any upgrade notes before deploying a payment path.
- Can I use creagia/laravel-redsys with Laravel 10 or Laravel 9?
- Version 4.x drops Laravel 8, 9, and 10, so those applications should pin to ^3.0 until they can upgrade the framework. The provided context does not state how long 3.0.3 will remain supported or whether security fixes will be backported. Confirm that support commitment with the maintainer before relying on the older line.
- What are the production risks of using creagia/laravel-redsys?
- The main risks are that this is a revenue-critical payment path, the package is effectively single-maintainer with a bus factor of one, and the 3.x to 4.x transition is a hard framework support break. Release notes are terse, so verify signature-verification behaviour and config keys against the source rather than assuming compatibility. Assign someone who understands Redsys HMAC-SHA256 and 3DES notification verification to review and own payment incidents.
- How should I test Redsys payments in a Laravel app using this package?
- Test the package at the boundaries: signed request generation, redirect parameters, and notification signature verification. Because it is a thin Redsys wrapper, put it behind your own payment service or adapter so you can unit-test business logic without calling the gateway. Use Redsys test credentials or sandbox facilities if your contract provides them and never rely on production notifications for test coverage.
- Can I use creagia/laravel-redsys in a non-Laravel service or polyglot architecture?
- It is not a good fit for non-Laravel consumers such as Go or Node services, mobile backends, or queue workers outside Laravel, because it is built as a Laravel service provider and facade wrapper. In a polyglot estate, place it inside a dedicated Laravel payment service and expose an internal API rather than coupling other services to Redsys signing details. It also is not the right seam if you need multi-PSP routing or a unified payment model.