Laravel Redsys Laravel Package

Technical Evaluation

Architecture fit. creagia/laravel-redsys is a thin, Laravel-native integration layer for the Redsys payment gateway (cards, Bizum, SEPA transfers — the dominant PSP for the Spanish market). Architecturally it is a service-provider + facade wrapper around Redsys' request signing and notification verification, not a payment abstraction layer. That is a good fit if Redsys is a hard requirement and the application is a standard Laravel HTTP app; it is a poor fit if we need multi-PSP routing, a unified payment domain model, or non-Laravel consumers (queues, Go/Node services, mobile backends). Treating this package as the only payment seam in the codebase would couple business logic directly to one processor's HMAC/3DES signing scheme and its particular response codes.

Integration feasibility. 4.0.0 is a support-matrix release: it adds Laravel 13 and PHP 8.5 compatibility and drops Laravel 8, 9, and 10. Integration on Laravel 11/12/13 is straightforward — Composer install, publish config, wire merchant credentials into secrets management. Integration on anything older is blocked at the dependency solver, which is the decisive constraint for this evaluation. The accompanying Larastan fixes and dev-dependency cleanup suggest improved static-analysis hygiene but also mean transitive dev constraints shifted; they should not affect runtime, but this is worth confirming rather than assuming.

Technical risk. Three concerns dominate. First, this is a payment path: any defect is a revenue and customer-trust incident, not a bug ticket. Second, the package is effectively single-maintainer (@dtorras is the sole author on both changes), so the bus factor is 1 and long-term support is contingent on one person's continued interest. Third, the 3.x → 4.x jump is a hard support-matrix break with no in-place upgrade — teams cannot adopt the patch stream of 4.x without first moving the host application to Laravel 11+. The release notes contain no behavioural or API changes, which is reassuring for 3.x users who have already moved frameworks, but the notes are terse and do not constitute a compatibility guarantee.

Key questions.

• What is the actual minimum PHP version for 4.0.0, and does "PHP 8.5 compatibility" mean tested on 8.5 or requires 8.5? This determines whether the runtime upgrade is a minor or major infrastructure project.
• Are there any API, config-key, or signature-verification changes not captured in these two PR lines? Please supply the UPGRADING.md / diff for src/.
• Does 3.0.3 remain the supported line for Laravel 8–10, and for how long? Is there a security-fix backport commitment?
• Who owns payment incident response today, and does that person understand Redsys' HMAC-SHA256/3DES notification verification well enough to review the package rather than trust it?
• Is Redsys contractually fixed for the next 24 months, or is PSP flexibility a live requirement?

Integration Approach

Stack fit. Clean fit for a Laravel 11–13 monolith or modular monolith on PHP 8.3+ serving the Spanish market, including Bizum and 3DS/SCA flows. Not a fit for polyglot estates where payments are centralised in a separate service — in that case the package belongs to a dedicated Laravel payment service, with an internal API in front of it.

Migration path. Sequence is forced, not optional: upgrade the host application's PHP runtime → upgrade Laravel to 11+ → resolve other packages pinned below the new framework floor → then adopt laravel-redsys 4.x. Attempting the package bump first will simply fail dependency resolution. For applications that cannot leave Laravel 8–10 in this planning cycle, pin to ^3.0 and record the package as a tracked upgrade blocker rather than an open task.

Compatibility. Two axes to verify before committing: (1) the package's own PHP floor against our runtime images, and (2) whether any other dependency in the payment module (HTTP clients, encryption extensions, queue drivers) conflicts with the new floor. Because 4.0.0 changes only dev dependencies at runtime level, functional behaviour should be identical to 3.0.3 — which makes a parallel-run comparison cheap and worthwhile.

Sequencing.

1. Pin ^3.0.3 in the current release branch; confirm production stability baseline.
2. Land the PHP and Laravel upgrades behind the existing test suite, with laravel-redsys still on 3.x if resolvable, otherwise in the same change.
3. Bump to ^4.0 in a dedicated PR; diff src/ and config between tags and confirm zero behavioural delta.
4. Validate against the Redsys sandbox: successful card, declined card, 3DS challenge, Bizum, and a replayed/tampered notification.
5. Canary to a low-volume merchant terminal before full traffic.

Operational Impact

Maintenance. Low ongoing effort in steady state — the surface area is small and the vendor does not churn. The real cost is the recurring framework-floor tax: each major Laravel release will likely force another package major, and each is a payment-path change requiring full regression. Budget one upgrade cycle per year. Single-maintainer risk means we should vendor the dependency or maintain a fork-ready posture (documented patch process, src/ reviewed at least once by our own engineers).

Support. Vendor support is community/GitHub-issue only; there is no SLA, no commercial backing evident, and no security disclosure policy referenced in the release. For a payment integration this is the weakest dimension. Mitigation: internal ownership assigned by name, an alert on the repo's release feed, and a documented fallback to direct Redsys HTTP integration (the protocol is simple enough that escape is realistic).

Scaling. The package is stateless request/response signing and verification — it scales with the application and adds no meaningful overhead. Watch instead the surrounding concerns: outbound HTTP timeouts and retries to Redsys, idempotency on order references to prevent double capture, queue isolation so a Redsys slowdown does not starve other workers, and structured logging of Redsys response codes without logging card data.

Failure modes.

• Framework lock-out: an unplanned Laravel upgrade becomes a payment-module blocker.
• Silent verification drift: if Redsys changes notification signing, the package may fail closed (good) or mis-handle edge cases (bad) — only tampered-notification tests catch this.
• Abandonment: no release for a PHP/Laravel generation leaves us pinned and eventually unsupported.
• Improper use: developers bypassing the package's verification helper and hand-rolling checks, silently widening PCI scope or accepting unverified callbacks.

Ramp-up. Half a day for a Laravel-fluent engineer to integrate and run sandbox transactions; one to two days to become genuinely trustworthy on Redsys notification verification, response-code semantics, and refund/partial-refund behaviour. Add explicit onboarding material covering the sandbox terminal, the tampered-notification test, and the rule that all Redsys traffic goes through the package's verification path. Total adoption estimate for a Laravel 12 application: 3–5 engineering days including sandbox validation; 2–4 weeks if the host application's framework upgrade is on the critical path.