Redsys Bundle Laravel Package

Technical Evaluation

What we are actually evaluating. Not a Laravel package. paymentsuite/redsys-bundle is a Symfony bundle — and, more specifically, a [READ-ONLY] subtree split of a component inside the PaymentSuite monorepo. It is the Redsys (Sermepa / TPV Virtual) payment-method plugin for PaymentSuite Core, not a general-purpose Redsys SDK. That distinction drives every downstream decision: for a Laravel codebase this is raw material, not a dependency we can composer require into app/ and expect to work.

Architecture fit. The bundle only makes sense inside PaymentSuite's abstraction (paymentsuite/core, paymentsuite/payment-bundle), where it registers a payment method implementing PaymentMethodInterface and pushes order/payment records through PaymentSuite's managers. In a Laravel app we have none of that scaffolding. Leveraging it therefore means one of three things: (a) borrow the domain logic — parameter assembly, HMAC signing, callback verification — into a Laravel service; (b) run a Symfony kernel alongside Laravel purely for this integration (disproportionate); or (c) reject it and use a maintained Redsys SDK or Omnipay Redsys driver behind our own PaymentGateway interface. For a TPM the honest framing is: this repo is a reference implementation of the Redsys protocol in PHP, with a free MIT license, that we would port rather than install.

Business case. The strategic pull is real. Redsys is the dominant Spanish card-acquiring rail (Santander, BBVA, CaixaBank). If a "launch checkout in Spain" item exists on the roadmap, this package is a cheap way to price the build option in engineering days instead of weeks, and to run a low-volume pilot without a new PSP contract. That is why the opportunity score (9.65) is high even though the package quality score (0.25) is near zero. The opportunity score is about the market; the quality score is the one that governs execution.

Technical risk — high, and concentrated in a few verifiable facts.

• Community surface is effectively nil: 2 stars, 0 dependents, no downstream validation, issues and contributions routed to an upstream monorepo we do not control. We should assume we are the maintainers from day one.
• Signature algorithm is a go/no-go: Redsys mandated HMAC-SHA-256 in 2018 and deprecated SHA-1. If this bundle predates or never migrated, it is unusable in production without a fork. One file read answers this.
• Framework vintage is likely stale: expect Symfony 2.x/3.x-era constraints; compatibility with a modern Symfony LTS — and certainly with Laravel's ecosystem — is doubtful and must be tested, not read.
• Mirror lag: because the split is read-only and generated, security fixes may not land here promptly, and the published repo can trail upstream. Supply-chain review is ours.
• Protocol drift: Redsys has moved toward REST/InSite and newer TPV API versions; the bundle likely implements only classic redirect plus webservice notification.

Key questions to close before any commitment.

1. Does it sign and verify with HMAC-SHA-256, or SHA-1?
2. What are the composer.json constraints (PHP, Symfony, paymentsuite/core)? Run composer why-not against our targets.
3. Is upstream active (commits in the last 12 months), and is the split in sync?
4. Does it verify callback signatures server-side, and is it idempotent on duplicate notifications?
5. Does it keep card data off our servers (redirect-only, SAQ-A-ish scope), or does it touch PAN anywhere?
6. Is there any test suite, CI, or published test vectors?
7. Does it support the Sis-Test sandbox environment and separate test credentials?
8. What is the license hygiene across vendored files (MIT declared — verify per-file headers)?

Bottom line: technically viable as a starting point for a port or fork, not as a drop-in dependency, and definitely not as a Laravel dependency. The 0.25 quality score should drive the decision; the 9.65 opportunity score should drive whether we bother to run the spike at all.

Integration Approach

Stack fit. Assume a Laravel application, PHP 8.x, an existing checkout/order domain, and a desire to keep PCI scope at SAQ-A via redirect. The bundle's PaymentSuite assumptions (its own order interface, payment manager, event wiring) map onto nothing in Laravel. So the integration target is not the bundle — it is the protocol logic we extract from it, exposed behind a Laravel-native interface: a RedsysGateway service with createPaymentRequest(Order): RedirectPayload, verifyNotification(Request): VerifiedPayment, and a PaymentGateway contract we already use (or should introduce) so a future Stripe/Adyen path is a swap, not a rewrite.

Three routes, in order of preference for a Laravel stack.

• Port the logic (recommended default). Read the signing and verification classes, reimplement them in our own app/Payments/Redsys namespace, add PHPUnit tests against Redsys test vectors, and take no runtime dependency on PaymentSuite. Sizing: 2–4 engineering days for a mid-level developer. Removes dead-dependency and supply-chain risk entirely and gives us clean ownership.
• Fork and own. If the Logic is more entangled than expected, vendor a private fork: replace SHA-1 with HMAC-SHA-256, pin a version, document it, and accept a standing maintenance line item.
• Reject and buy. Use a maintained Redsys PHP SDK or Omnipay Redsys behind our own interface, or front Redsys with a PSP that abstracts it. Lowest long-term risk if the Spanish requirement is not hard.

Do not attempt to install the Symfony bundle into Laravel or stand up Symfony purely for it. That is an architecture tax with no product payoff.

Migration path and compatibility. Verify empirically, not from the README. Create a throwaway Symfony app on a target LTS and composer require the bundle to see what actually resolves; in parallel, do a static read of DependencyInjection/Configuration.php (the authoritative config surface — better than the README) and the signature classes. Expect pinning conflicts on symfony/http-kernel, symfony/event-dispatcher, and paymentsuite/core. Treat any successful install as evidence about the protocol code, not as a green light to depend on it.

Sequencing.

1. Day 1–2 — Static review and protocol answer. Read signing code, callback verification, composer.json, and configuration. Answer the SHA-256 question. Deliverable: one-page finding, go/no-go on continuing.
2. Day 2–3 — Sandbox spike. Sis-Test credentials, one successful and one declined payment, confirm callback signature validation and duplicate-notification behaviour. Deliverable: a working sandbox transaction, or a written reason we stopped.
3. Day 3 — Decision gate. Port vs fork vs buy. Nothing else in the checkout roadmap should be sequenced around this until the gate passes.
4. Week 2 — Harden. Idempotency on callback, integer-cents amount formatting, currency and locale handling, structured logging with no PAN or secret leakage, reconciliation job for abandoned redirects.
5. Week 2–3 — QA and production smoke. Full sandbox pass plus a small real-amount production transaction with the acquirer, with the terminal/key/environment matrix explicitly checked.

Success and failure criteria. Success = a validated sandbox transaction, a quantified maintenance estimate, and a named owner. Failure = the spike exceeds a few engineering days or the signature path cannot be brought to SHA-256 cheaply — in which case we buy the capability and move on.

Operational Impact

Maintenance dominates the total cost of ownership. A read-only mirror with zero dependents means nobody else is watching this code. Whatever we adopt or port, we own every future fix: Redsys protocol changes, PHP and framework upgrades, and security patches on the signature path. Budget roughly one day per quarter for dependency and protocol review, plus a named owner on the payments team. The single most important governance action is to prevent this sitting in composer.json as an unowned transitive dependency — either it is ported (and therefore ours, visibly) or it is bought (and therefore someone else's).

Support. No community, no meaningful issue history in this repo (issues live upstream), no StackOverflow footprint. Gateway-level support from Redsys and the acquiring bank for the TPV itself is actually strong, but it will not help with bundle internals. An internal runbook — credentials, environments, callback URLs, replay procedure, escalation — is mandatory, not optional.

Scaling. The authorization path is offloaded to Redsys via redirect, and the bundle is essentially stateless glue, so scaling is bounded by our callback endpoint and order persistence, not by this code. The real concerns are callback concurrency during Spanish retail peaks (rebajas, Black Friday), idempotent processing of retried notifications through a queue, and row contention on payment records under load. Design the callback as an idempotent, queue-backed handler from the start; retrofitting idempotency after a double-fulfilment incident is far more expensive.

Failure modes to design for explicitly.

• Signature mismatch on callback — wrong terminal, key, or environment. Silently drops valid payments if we only 500; must alert.
• Unverified or SHA-1 callbacks — exposure to forged confirmations. This is a release blocker, not a backlog item.
• Duplicate notifications — Redsys retries; without idempotency keys we double-fulfil or double-refund.
• Amount formatting — Redsys expects integer cents; decimal errors are common and customer-visible.
• Timeout or abandoned redirect — orders stuck pending; needs a scheduled reconciliation against Redsys.
• Environment bleed — Sis-Test keys in production or vice versa. Classic, expensive, and preventable with config assertions at boot.
• Secret leakage — key material in logs or exception traces; PCI and contractual exposure.

Ramp-up. The API surface is small, but there are two learning curves: PaymentSuite's abstractions (if we adopt rather than port) and Redsys' Ds_MerchantParameters and signature quirks. Estimate 3–5 days for a mid-level engineer to be productive, plus 2–3 days of sandbox QA; add a day if we port, for documentation. Given bus-factor risk on a payment integration, onboard a second engineer deliberately.

Stakeholder recommendation. Approve a time-boxed evaluation, not adoption. Fund 2–3 engineering days to answer the SHA-256 question and produce a sandbox transaction; treat the output as a fork-and-port commitment with a named maintainer and a recurring review line item. If the spike costs more than a few days, buy the capability from a supported provider that fronts Redsys. The decision to make now is not "do we use this package" — it is "do we want to own a Redsys integration," and this package only tells us how cheaply we could start owning one.