Redsys Bundle Laravel Package

Product Decisions This Supports

• Go/no-go on Spain market entry. Redsys is the dominant card-acquiring rail in Spain (owned by Santander, BBVA, CaixaBank). Any "launch checkout for Spanish customers" roadmap item is gated on being able to talk to Redsys. This package is the cheapest possible way to scope that gate: it prices the "build it ourselves" option in engineering days rather than weeks, which is exactly the input a PM needs to decide between a local-rails launch and a pan-European PSP.
• Build vs. buy on payment plumbing. The code is MIT and small. That means the PM can put a real number on the "build" column (a fork-and-own spike) and compare it honestly against the "buy" column (Stripe/Adyen/a Redsys-certified PSP with a contract, SLA, and PCI-scope reduction). Without a concrete baseline like this, "buy" always wins by default on fear rather than arithmetic.
• Gateway abstraction strategy. It sits on PaymentSuite Core, which models payment methods as pluggable services. That supports an architectural bet — "one payment abstraction, many acquirers" — rather than hard-coding one provider into checkout. That bet determines how fast we can add Bizum, SEPA, or local wallets later.
• MVP / pilot scoping. Because it is thin and permissively licensed, it underwrites a decision to ship a low-volume Spanish pilot without a commercial contract or vendor onboarding cycle, deferring the "real" PSP decision until volume justifies it.
• Resourcing decision, not just a technical one. The health signals (2 stars, 0 dependents, read-only subtree split of an upstream monorepo) tell the PM whether maintenance is budgeted as "consume a dependency" or "own a fork with a named maintainer." That is a headcount line, not a code review comment.
• Killing a bad idea cheaply. The two scores point in opposite directions: market opportunity 9.65, package quality 0.25. A PM should read that as "real demand, unusable artifact" — the decision is about the market, not about adopting this repo.

When to Consider This Package

Adopt it only as a reference implementation and a scoping tool, not as a drop-in dependency — especially if the target application is Laravel.

Consider it when:

• You are on Symfony and already using PaymentSuite Core. This is the only clean-fit scenario. It is a Symfony bundle and a read-only subtree split; it does not slot into Laravel without a bridge/adapter layer, which changes the build-vs-buy math materially.
• Redsys is a hard requirement — a Spanish entity, an existing merchant contract with a Spanish acquirer, or a customer segment that expects TPV Virtual. If Stripe/Adyen with local methods is acceptable, the strategic reason to carry this dependency disappears.
• You are using it to estimate, not to ship. The PM value is highest before commitment: read the signing and callback-verification code, answer "does it do HMAC-SHA-256 or legacy SHA-1?", and turn that into an engineering-day estimate for our own implementation.
• You are willing to fork and own it. With 0 dependents, budget a named owner, a pinned version, a security review of the signature path, and a plan to absorb upstream changes yourself.
• Volume is modest and the flow is simple: one-off card payments via redirect. Treat subscriptions, tokenization, refunds, partial captures, and 3-D Secure exemptions as unverified.

Look elsewhere when:

• You need vendor support, an SLA, or PCI-scope reduction — a maintained PSP (Stripe, Adyen, Mollie, or a Redsys-certified regional PSP) is the lower-risk path.
• You need Laravel-native ergonomics: prefer a dedicated Redsys PHP SDK or the actively maintained Omnipay Redsys driver, wrapped behind our own interface.
• Maintenance risk is unacceptable — near-zero community surface means every bug and protocol change lands on our team.
• You are not selling into Spain — the business case collapses to "we could," which is not a decision.

How to Pitch It (Stakeholders)

For executives. Redsys is how Spanish customers expect to pay by card. This package is a near-zero-cost, MIT-licensed artifact that lets us answer the Spanish-market question without signing a new PSP contract — but it is not a dependency we can simply adopt. The published repo is a read-only mirror of an upstream project with effectively no community (2 stars, 0 dependents), so the moment we ship it we become its maintainers. Recommendation: fund a time-boxed spike, not adoption. Success is a validated sandbox transaction plus a quantified maintenance burden; failure means we buy the capability from a supported provider and move on with a better-informed decision either way.

For engineering. This is a Symfony bundle from the PaymentSuite family, split read-only from a monorepo, so it will not slot into a Laravel app without an adapter. It provides a payment-method abstraction plus a Redsys redirect integration. Ask for: confirmation that it signs and verifies with HMAC-SHA-256 rather than deprecated SHA-1, a check against current Redsys endpoints and API versions, an audit of the notification/callback verification path including idempotency on duplicate notifications, a pinned version and lockfile, and an estimate for the Laravel adapter work if that is the target.

Decision framing. Approve a two-to-four day evaluation with a hard gate, not a dependency addition. The deliverable is a working sandbox payment, a written statement of exactly what we would now own, and a recommendation of adopt / fork / reject. Treat the package quality score of 0.25 — not the 9.65 opportunity score — as the number that drives the call.