Sermepa Omnipay Laravel Package

Product Decisions This Supports

• Spain market entry and payment rail selection. Redsys (formerly Sermepa) is the card-processing backbone behind most Spanish banks' TPV virtual terminals — BBVA, Santander, CaixaBank, Sabadell. If the roadmap includes selling to Spanish customers, "which gateway?" is rarely a real choice: it is Redsys, or a PSP layered on top of it. This package answers "can we take cards in Spain?" cheaply, before budget is committed.
• Build vs. buy on the signature layer. The Redsys integration is deceptively painful: a single base64-encoded Ds_MerchantParameters blob, HMAC-SHA256 signing, and a 3DES-derived merchant key from the order number. Hand-rolling this costs days and produces silent, opaque failures (a bad signature returns an error page with no diagnostics). Adopting a driver converts a cryptography project into a configuration task — a real schedule and risk decision, not just a technical one.
• Payment architecture choice: Omnipay vs. Laravel Cashier vs. raw HTTP. Cashier has no Redsys support, so teams default to bespoke HTTP clients. Omnipay provides a consistent purchase / completePurchase / refund contract, which matters if Spain is one of several markets and product wants one payment interface in the domain layer.
• Checkout UX and scope-of-flow decisions. The driver supports a redirect-based flow (signed form POST to Redsys, then return + server-to-server notify). PMs can evaluate whether a full-page redirect is acceptable for the funnel, versus the cost of building hosted fields, and whether 3-D Secure challenge handling meets the market's PSD2/SCA expectations.
• Feature-gap discovery against the roadmap. Tokenization/recurring billing, partial refunds, and pre-authorization should be verified against the subscription roadmap before this becomes load-bearing. If the next two quarters include "monthly plans in Spain," this package is a starting point, not the answer.
• Vendor and dependency risk budgeting. 21 stars, 0 dependents, effectively a solo maintainer. That is a legitimate input to a "fork, pin, and own it internally" decision — it should be priced in, not treated as a blocker.

When to Consider This Package

Adopt when:

• The application is PHP and already standardized on league/omnipay, or the team is willing to adopt Omnipay as its payment abstraction.
• Redsys is required or strongly preferred — a Spanish legal entity, an existing merchant contract with a Spanish bank, or a client mandating it.
• Payments are one-off, redirect-based card transactions with 3DS: the mainstream Spanish e-commerce flow this driver was written for.
• You can tolerate a small, low-traffic dependency by pinning the version, vendoring the source, and assigning an internal owner to review it.
• The realistic alternative is a bespoke Redsys implementation by engineers with no prior Redsys experience.

Look elsewhere when:

• You need subscription billing, stored cards, or merchant-initiated recurring at scale — evaluate Redsys' own tokenization APIs or a PSP (Stripe, Adyen, Mollie) that fronts the Spanish market with a maintained SDK.
• You need a broadly supported multi-gateway abstraction with active Laravel-first maintenance and current PHP/Laravel version guarantees — consider a commercially supported Omnipay fork or a maintained PSP SDK.
• You need embedded/hosted-fields checkout rather than a full-page redirect.
• You require vendor SLAs, a security disclosure process, or a documented maintenance cadence — a single maintainer and zero dependents do not provide these. Check commit recency and the open-issue backlog first; if it has gone quiet, treat it as "reference implementation to fork," not a dependency.
• You are not on PHP/Omnipay — the value proposition collapses.

How to Pitch It (Stakeholders)

For executives: To sell in Spain we need Redsys, the gateway behind nearly every Spanish bank's card terminal. Its integration is unusually error-prone, so instead of having engineers reverse-engineer it, we can adopt a small open-source driver that already speaks it. Cost is near zero and time-to-first-transaction is days, not weeks. The trade-off is that it is a niche package with essentially no community — so we would fork it, pin it, and own it internally. This is a tactical enabler for a market test, not a strategic platform bet; if Spain converts, we revisit and either invest in a supported PSP or formalize our fork.

For engineering: nazka/sermepa-omnipay is a Redsys gateway driver for league/omnipay, wrapping the Ds_MerchantParameters encoding, HMAC-SHA256 signing with 3DES-derived keys, and the redirect/callback round-trip. Proposed handling: vendor the source, pin the version, add contract tests around signature generation and callback validation, and document the merchant-code/terminal/key configuration. Before it becomes critical, verify tokenization, partial-refund, and pre-auth coverage against the roadmap — those are the likely gaps. Budget roughly half a sprint for hardening and integration tests, and confirm the Omnipay major version it targets before committing.