Laravel Redsys Laravel Package

Product Decisions This Supports

• Payment integration scoping for Spain/LATAM expansion: Redsys is the dominant card processor for Spanish merchants (Santander/BBVA/CaixaBank-backed). This package tells you whether "accept payments in Spain" is a sprint-sized task or a multi-month gateway integration project.
• Build vs. buy on payment plumbing: The existence of a maintained, framework-native wrapper shifts the calculus toward "rent" — you keep your own order, refund, and reconciliation logic in-house while outsourcing the Redsys protocol handshake (signature generation, HMAC-SHA256 signing, 3DS/EMV3DS redirect flows, notification verification).
• Framework upgrade roadmap: The 4.0.0 release is itself a roadmap input. Dropping Laravel 8–10 means this package now tracks the two most recent majors only, so it constrains when your platform can upgrade and, conversely, when you must upgrade to stay on a supported payment dependency.
• PCI/security posture decisions: Whether Redsys's redirect-based (non-iframe, non-hosted-fields) model satisfies your compliance and UX requirements is a product call this assessment should trigger — it affects checkout conversion design and whether you need a separate tokenization provider.
• Use cases that fit: subscription/marketplace flows via Redsys tokenization, one-off e-commerce checkout, and Spanish public-sector or enterprise customers who mandate Redsys as an acquiring contract.

When to Consider This Package

Adopt when all of the following hold:

• You are on Laravel 11, 12, or 13 and PHP 8.2+ (8.5 supported) — 4.0.0 explicitly drops Laravel 8–10, so older apps must stay on 3.0.x or upgrade the framework first.
• Your acquirer or merchant contract routes through Redsys (or you are targeting the Spanish market where it is effectively mandatory).
• Your checkout can accept a redirect-based payment flow with server-to-server notification handling, rather than an embedded/hosted-fields experience.
• You want a thin, framework-idiomatic adapter — service provider, config publishing, facades — rather than a full payment orchestration platform.

Look elsewhere when:

• You need multi-gateway abstraction (Stripe + Redsys + Adyen behind one interface) — this is single-gateway; you would wrap it yourself.
• You need subscription billing, dunning, proration, or a billing portal out of the box. This package handles the Redsys wire protocol, not the recurring-billing domain model.
• You require a vendor with an SLA or commercial support contract — this is a community package (Creagia), maintained by a small contributor base; the 4.0.0 diff is two PRs, one of which is a CI/static-analysis cleanup. Bus-factor risk is real and should be priced in.
• You are on Laravel 8–10 with no near-term upgrade path.
• You need features outside the core authorize/charge/refund surface — verify against the README before committing, as coverage of newer Redsys capabilities (e.g. certain 3DS2 exemption flows) is not evidenced by these release notes.

How to Pitch It (Stakeholders)

For executives: Redsys is the payment rail most Spanish banks require. Rather than build and maintain that integration ourselves, we can adopt a small open-source Laravel wrapper that handles the cryptographic signing and redirect protocol. It is free, actively kept current with the framework — version 4.0.0 shipped this cycle with support for Laravel 13 and PHP 8.5 — and lets our engineers focus on checkout and reconciliation logic instead of bank protocol details. The trade-off is vendor-support risk: it is community-maintained with a small contributor base and no SLA, so we should treat it as a dependency we can fork or replace, not a strategic platform.

For engineering: 4.0.0 is a breaking release — it drops Laravel 8, 9, and 10 and requires a modern PHP runtime. If we adopt, pin to ^4.0 only after confirming our framework version; teams on older majors must either stay on 3.0.x or complete their Laravel upgrade first. The release is narrow (framework-compatibility bumps plus a larastan/dev-dependency cleanup), which is a good sign for stability but means no new payment features — evaluate the actual API surface against our requirements before committing. Mitigations: wrap the package behind our own PaymentGateway interface so a swap is a one-file change, pin the version explicitly, and confirm the signing and notification-verification paths are covered by our integration tests rather than assumed.