Saferpay Bundle Laravel Package

Product Decisions This Supports

• Payment method expansion (DACH/Swiss market): Saferpay is a SIX-owned Swiss PSP, so this package is relevant if the roadmap includes CHF checkout, Swiss merchant requirements, or European card/3DS coverage alongside an existing gateway.
• Build vs. buy for a payment integration: The bundle is a thin extension of CorePaymentBundle, meaning it buys you request/response plumbing and configuration, not gateway behavior. The real decision is "direct PSP API vs. an abstraction layer," and this package is one data point in favor of the abstraction route — with a caveat on its own maintenance risk.
• Architecture direction — gateway abstraction vs. direct integration: Because it sits on top of CorePaymentBundle, adopting it signals a commitment to a payment-abstraction layer (multiple PSPs behind one interface). That's a strategic decision worth making explicitly rather than accidentally.
• Stack-fit decision (important): Despite being catalogued as a "Laravel/PHP package," this is a Symfony bundle. For a Laravel product it implies adapter/porting work. This directly informs whether the saving is real.
• Spike/feasibility scoping: At 1 star, 0 dependents, and a low quality score, this is best evaluated as a reference implementation for Saferpay's flow (init, authorize, capture, 3DS, notifications) — useful for estimating effort and shaping a ticket, not for defining the architecture.
• Vendor and lock-in analysis: Reviewing it clarifies what parts of a Saferpay integration are commoditized (HTTP calls, DTOs) versus sticky (tokenization, reconciliation, chargebacks, PCI scope) — which is what should actually drive the buy/partner decision.

When to Consider This Package

Consider it when:

• The team is already on Symfony and already using CorePaymentBundle (or an equivalent abstraction) — the marginal gain is highest and the porting cost is lowest.
• Saferpay is a confirmed business requirement (existing SIX contract, Swiss entity, mandated acquirer), not a speculative "maybe someday."
• You need a fast proof-of-concept of Saferpay's payment flow and have an engineer who can read and fork the code.
• You have in-house capacity to own and maintain the integration — vendor support, security patches, and API version updates are on you.
• The integration is low-blast-radius (single market, single payment method, no recurring billing complexity).

Look elsewhere when:

• The stack is Laravel-first. The Symfony coupling (CorePaymentBundle, service container, bundle config) means you'd be re-implementing most of it; a direct integration or a maintained multi-gateway library (e.g., Omnipay-style abstraction or Saferpay's own SDK/JSON API) is a better fit.
• You need maintained, supported code with an active community, security responsiveness, or an SLA. One star and zero dependents is a strong signal that no one is watching this repo.
• Compliance requirements are strict: PCI DSS scope, 3DS2, SCA, webhook signature verification, idempotency, and reconciliation all need validated implementations, and a thin bundle won't provide them.
• You expect to add multiple PSPs — pick a maintained orchestration/abstraction layer rather than reviving one.
• You're pricing the total cost: a free package with no maintainer is often more expensive than a small, well-tested in-house module.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-adoption open-source connector to Saferpay, a Swiss payment provider we'd need for CHF/European checkout. It could shorten a prototype by a few days but it is essentially unmaintained and built for a different framework (Symfony) than ours. Treat it as a reference for scoping, not as the foundation of our payments roadmap — the real cost is not the HTTP plumbing, it's the merchant setup, 3DS/SCA, reconciliation, and ongoing maintenance, none of which this package solves. Recommendation: use it for a timeboxed feasibility spike only if Saferpay is a committed requirement; otherwise budget a small direct integration and keep the gateway behind our own interface.

For engineering (framing): The bundle wraps Saferpay calls behind CorePaymentBundle's abstractions. Evaluate it as a worked example of the payment flow — init, authorize, capture, refund, notifications — and as a comparison point for our own abstraction. Judge it on: does it cover tokenization, 3DS2/SCA, webhook verification, and idempotency? Does its API version still match Saferpay's current one? If we lift any code, plan to own it: fork, pin, and add tests. The estimate we should bring back is "days saved on plumbing" versus "days of adaptation and hardening," so leadership sees a net number, not a library name.

Decision ask: A one-week spike to confirm stack fit and API version currency, with a pre-agreed default of direct integration if the package fails any of the maintained-connector criteria.