Redsys Php Laravel Package

Product Decisions This Supports

• Wallet-based checkout (Apple Pay / Google Pay): The 3.0.3 release adds a payment-method case for wallet payments in the Redsys integration. This lets product teams offer one-tap wallet checkout in iOS Safari and Chrome/Android without building a separate gateway integration — directly relevant to mobile conversion-rate bets and cart-abandonment reduction roadmaps.
• Market/expansion scoping: Redsys is the dominant card-processing gateway for Spanish banks (Santander, BBVA, CaixaBank, etc.). Adopting this package is a decisive enabler for any Spanish-market launch or localization roadmap item; the Apple Pay/Google Pay case makes it competitive with Stripe/Adyen wallet support for that market.
• Build vs. buy for payments: Because this is an open-source package wrapping the Redsys API (signature/HMAC handling, notification parsing, refunds), the decision reduces to "integrate this OSS wrapper" vs. "build and maintain Redsys signing + reconciliation in-house" vs. "use a PSP aggregator." Wallet support arriving as a low-friction patch tips the build-vs-buy call toward adopting the package for Redsys-native flows.
• Checkout feature sequencing: Wallet support is a discrete, low-risk feature you can schedule independently of core card flow. It belongs in a "mobile checkout improvements" epic rather than a re-platforming effort, which helps sequence roadmap work.
• Compliance & ops: The package handles server-to-server signature generation and Redsys notification callbacks — relevant to PCI-scope reduction and reconciliation decisions (what stays server-side vs. what the client SDK handles).

When to Consider This Package

Adopt it when:

• You are selling in Spain (or to Spanish cardholders) and your acquirer/bank requires Redsys rather than an international PSP.
• Your stack is PHP/Laravel and you want an idiomatic wrapper instead of hand-rolling the Redsys HMAC signature, merchant parameters, and notification verification.
• You want Apple Pay / Google Pay on Redsys without a separate wallet gateway — 3.0.3 gives you the payment-method case, though note this is a Redsys payment-method identifier, not a full Apple Pay merchant-validation integration; you still own domain verification, merchant certificates, and the client-side wallet sheet.
• You need refunds, pre-authorizations, or notification handling as part of a standard card flow.

Look elsewhere when:

• You are not on a PHP/Laravel stack, or your payments are outside the Redsys ecosystem (Stripe/Adyen/Checkout.com have broader wallet and multi-currency coverage out of the box).
• You need a fully managed wallet solution with merchant-cert provisioning and PCI attestations handled for you — a gateway/PSP aggregator is a better fit than an OSS wrapper.
• You require enterprise SLAs, vendor support contracts, or guaranteed security patching cadence; this is a community-maintained package.
• Your compliance posture forbids community OSS in the payment path without an internal fork/security review.

Version note: 3.0.3 is a patch-level increment adding a wallet payment-method case — low migration risk, but verify it against your Redsys merchant terminal configuration and confirm the wallet flow end-to-end in sandbox before committing to a launch date.

How to Pitch It (Stakeholders)

To executives: We can enable Apple Pay and Google Pay at checkout for the Spanish market with a small, low-risk change to an existing open-source Redsys integration — no new vendor contract, no re-platforming. This is a direct lever on mobile conversion and cart abandonment, and it keeps us on the bank-preferred gateway for Spain.

To engineering: The 3.0.3 release adds a wallet payment-method case to the Redsys integration. Integration effort is a patch-level bump plus wiring the client-side wallet flow (Apple Pay merchant validation / Google Pay tokenization) and confirming the merchant terminal is provisioned for wallet payments. Scope the wallet sheet and certificate setup as separate work from the package upgrade — the package covers the Redsys-side method, not the full wallet onboarding.

Risks to flag: Community-maintained OSS in the payment path needs a security-review and an internal ownership plan (pinning the version, tracking upstream releases). Wallet enablement depends on merchant-terminal configuration and Apple/Google merchant onboarding, which sit outside the package and should be tracked as their own workstream.