Sermepa Omnipay Laravel Package

Product Decisions This Supports

• Market expansion into Spain (EUR, cards): Redsys (formerly Sermepa) is the payment processor behind most Spanish banks' TPV Virtual — BBVA, Santander, CaixaBank, Sabadell, Bankinter. If a roadmap item is "sell to Spanish customers with local card acceptance," this package is a candidate building block for that integration rather than a reason to default to Stripe/Adyen for the Spanish market.
• Build vs. buy for gateway plumbing: Redsys is not a "just call an endpoint" integration. It involves merchant-key derivation per order, HMAC signature computation, base64/DCC payloads, TLS client certificates, and redirect/insite flows. Using an existing Omnipay driver is the cheap path versus a bespoke in-house client — if the driver is current.
• Payment method coverage decisions: Redsys supports card, Bizum, and recurring/reference payments ("pago por referencia") in one contract. A working driver lets you decide whether to ship Bizum or subscriptions as differentiators for the Spanish segment without adding a second PSP.
• PSP consolidation vs. fragmentation: Adopting Redsys often means one PSP per country (Redsys for ES, Stripe for the rest). This package informs whether that fragmentation is tolerable at the code layer — a common Omnipay interface keeps the rest of the app provider-agnostic.
• Recurring billing / subscription roadmap: Redsys supports merchant-initiated and card-on-file transactions. Whether this driver exposes tokenization and reference payments determines if subscriptions are "config" or "new integration work."
• Refund, partial refund, and pre-authorization flows: Worth auditing against your support/ops requirements (partial captures, void windows) before committing — these are the flows that generate support tickets later.
• Vendor/supply-chain risk register: 0 stars and 0 dependents means this is effectively unproven. That is itself a product decision input: treat it as a reference implementation or fork candidate, not a dependency you can lean on for PCI-adjacent code.

When to Consider This Package

Consider it when:

• You have (or can get) a Spanish acquiring relationship — Redsys access comes through a Spanish bank's TPV contract, not self-serve signup. Without that, the package is moot.
• You're already standardized on Omnipay and want a uniform gateway abstraction rather than a Redsys-specific SDK.
• You need card + Bizum + reference/recurring payments under one merchant contract, in EUR, for Spanish customers.
• You're evaluating a fork-and-own strategy: the package is small enough to vendor into your codebase, harden, and maintain internally with a named owner.

Look elsewhere — or budget for a rewrite — when any of these fail during diligence:

• 3DS2 / PSD2 SCA support. EU card payments require Strong Customer Authentication with EMV 3-D Secure. If the driver predates 3DS2 (or only implements the legacy SHA-1 signature path rather than HMAC-SHA256), it is not merely outdated — it is a compliance blocker, not a code-quality nit.
• Maintenance signals. 0 stars, 0 dependents, and no recent releases mean no community backstop. Check last commit date, open issues, PHP version support (PHP 8.x, Omnipay v3 API vs. v2), and whether the author responds at all.
• Test coverage and fixtures. Signature generation is the highest-risk code in the integration. No tests = you inherit the debugging.
• Laravel ergonomics. Omnipay is framework-agnostic; this package gives you a gateway class, not a Cashier-style Laravel integration. You'll wrap it yourself (service provider, config, webhook/notification controller, idempotency, logging). Budget that work explicitly.
• Marketplace / split payments. Redsys is not a Stripe Connect analogue. If your model needs fund splitting or multi-party payouts, this is the wrong rail entirely.
• Better-maintained alternatives exist — a current Redsys PHP library, a maintained Omnipay Redsys driver, or a PSP aggregator that already abstracts Redsys. Compare total cost of ownership, not license cost (which is zero either way).

Minimum diligence checklist before adoption: license compatibility · last release date · PHP/Laravel/Omnipay version matrix · 3DS2 and HMAC-SHA256 implementation · tokenization/recurring support · refund and pre-auth coverage · notification (webhook) signature verification · presence of automated tests · security disclosure process · named internal owner.

How to Pitch It (Stakeholders)

For executives: This is a zero-cost, low-ceremony enabler for selling into Spain — the market where Redsys is the default card rail for nearly every local bank. The strategic value is market access, not the library itself. The risk is equally clear: the package is unmaintained and unproven (no stars, no dependents), and a stale Redsys integration can fail EU Strong Customer Authentication requirements, which is a hard regulatory gate rather than a bug. Recommendation: treat it as a free head start, not a foundation — validate 3DS2/SCA and signature handling first, then either fork it under internal ownership or buy a maintained alternative. The comparison to make is a few days of engineering diligence against weeks of building a Redsys client from scratch; the bank contract, not the code, is the real long pole.

For engineering: A small Omnipay driver for the Redsys/Sermepa redirect and insite flows. It buys you the fiddly parts — merchant-key derivation, order signing, response validation — behind a standard Omnipay interface, which keeps the rest of the payment layer PSP-agnostic. It does not buy you a Laravel integration, so plan for a service provider, notification controller with signature verification, idempotency, and reconciliation logging. Before anything else: confirm HMAC-SHA256 and EMV 3-D Secure (3DS2) support, PHP 8 / Omnipay v3 compatibility, and test coverage. If 3DS2 is missing, scope it as a fork-and-extend project with an owner, or pick a maintained library. Either way, pin the version and vendor the code — do not let an unmaintained dependency sit in the payment path unowned.