Sermepa Omnipay Laravel Package

Technical Evaluation

• Architecture fit: nazka/sermepa-omnipay is an Omnipay gateway driver for Sermepa/Redsys, the Spanish card processor behind most bank TPVs. It fits Laravel/PHP applications that need redirect-based Redsys checkout and can adopt or already use Omnipay’s gateway interfaces. It is not Laravel-native, so fit depends on wrapping it in a service provider and application payment service. It is a poor fit for marketplace splits, subscriptions, stored cards, or advanced reconciliation without custom work.
• Integration feasibility: Composer installation is straightforward, but real feasibility is low-to-medium. The package is aged and low-adoption (21 stars, 0 dependents), so dependency constraints may conflict with modern Laravel/PHP versions. Expect a sandbox spike, merchant-account setup, and likely a fork or patch before production use.
• Technical risk: High. This is payment-critical code touching signatures, redirects, webhooks/IPN, refunds, and potentially 3DS/SCA. Risks include stale Redsys signature support, outdated Omnipay/PHP constraints, missing automated tests, unclear security maintenance, and low community validation. Treat the package as a reference implementation or fork candidate, not a default production dependency.
• Key questions: Which Omnipay major version does it target? Which PHP/Laravel versions are supported? Does it support Redsys SHA256 signatures, 3DS2/SCA, refunds, recurring payments, and IPN signature verification? Are there tests and a security policy? What is the license and maintenance status? Which Redsys merchant contract, terminal, and environment are required? What is the fallback if the package breaks?

Integration Approach

• Stack fit: Integrate through Omnipay rather than direct controller code. Bind a configured gateway as a Laravel singleton, store merchant code, terminal, secret, and environment in config/services.php, and wrap purchase/complete/refund flows in an application-level payment service. This isolates the package and makes replacement easier.
• Migration path: Start with a staging spike against Redsys sandbox. If the package is incompatible with the target Laravel/PHP stack, fork it and upgrade dependencies, or implement a minimal Redsys gateway on top of omnipay/common. Keep existing checkout behind a feature flag and dual-run with manual reconciliation before full cutover.
• Compatibility: Validate PHP 8.x, Laravel 10/11, Omnipay v3, Guzzle, and Symfony constraints early. Confirm Redsys endpoint versions, signature algorithm, currency/amount formatting, and IPN parameter handling. Assume dependency upgrades and typed-code fixes will be needed.
• Sequencing: 1) Audit license, maintenance, and security posture. 2) Prove sandbox payment, callback, and refund flows. 3) Fork/harden with tests and clear ownership. 4) Add idempotency, webhook verification, reconciliation, and observability. 5) Pilot with low-value transactions. 6) Roll out gradually with rollback and manual reconciliation runbooks.

Operational Impact

• Maintenance: High if adopted directly; medium if forked and owned. Budget for dependency upgrades, Redsys specification changes, security patches, and signature-algorithm updates. There is no meaningful vendor SLA.
• Support: Community-only and low-adoption, so internal support capability is required. Assign a payment owner, document merchant-support escalation, and maintain runbooks for failed payments, refunds, and callback disputes.
• Scaling: Redirect-based payment flows are mostly stateless and scale with the application. Webhooks/IPNs need queues, idempotency keys, retries, deduplication, and rate-limit handling. Persist transaction logs and run reconciliation jobs.
• Failure modes: Common failures include signature mismatch, amount/currency/order mismatch, timeout or duplicate charge, missing or duplicate IPN, 3DS abandonment, refund mismatch, secret rotation errors, and environment misconfiguration. Instrument alerts and provide replay/investigation tooling.
• Ramp-up: Medium-to-high for engineers unfamiliar with Redsys and Omnipay. Plan one to two sprints for discovery, sandbox certification, security review, and pilot preparation. The TPM should treat this as a conditional build-or-fork decision, not a drop-in Laravel package.