Saferpay Bundle Laravel Package

Product Decisions This Supports

• Payment provider strategy for the Swiss/DACH market. Saferpay (SIX Payment Services / Worldline) is a mainstream card gateway in Switzerland. This bundle is historical evidence of how a Saferpay integration was once built — useful context when you are evaluating Saferpay against Stripe, Adyen, or Worldline for a Swiss-facing checkout, and need to understand what an "own the integration" path looked like before committing to one.

• Build vs. buy vs. adopt on the integration layer. The decision is not "should we use this package" — it is "do we own a thin Saferpay adapter, use the provider's official tooling, or buy a supported connector." The archived status, 3 stars, and 0 dependents settle the adopt option; the remaining question is scope and sequencing for the build/buy path.

• Framework-fit triage for a Laravel roadmap. This is a Symfony bundle, not a Laravel package: no service provider, no facade, no config publishing, no queue/event hooks. That makes it a reference implementation of the Saferpay protocol rather than an installable dependency in a Laravel codebase. This distinction is itself a roadmap input — it tells you whether "reuse an existing integration" is a real option or a hidden cost.

• Legacy modernization and replatforming sequencing. If your codebase or an acquisition target already depends on this bundle, it is a concrete signal of a Symfony 2/3-era payment stack. That feeds the checkout modernization epic, the PHP/Symfony upgrade plan, and dependency-risk remediation.

• Technical due diligence and M&A. An archived, near-zero-adoption payment bundle is a quantified maintenance liability to price into integration cost, and a named action item in security review.

• PCI scope reduction scoping. Understanding how card data and payment flows are handled today informs the move to hosted payment pages and tokenization via Saferpay's current API — the levers that shrink PCI DSS scope.

• Sunset and deprecation policy. Justifies an internal "no new usage" rule, dependency pinning, and a funded replacement plan instead of incremental patching.

When to Consider This Package

Consider it only as a reference or a short-term bridge when:

• You maintain an existing Symfony application that already depends on it, and you need to understand or reproduce its behavior while planning migration.
• You are tracing the history of a payment integration during an audit, incident review, or acquisition diligence.
• You need a temporary pin or fork to keep a legacy checkout alive during a migration that already has an owner and a ship date — with the risk explicitly accepted.

Look elsewhere when:

• Any new build. Archived, ~3 stars, 0 dependents, no maintenance, no security patches. Payment code is the worst possible place for an unmaintained dependency.
• You are on Laravel. It is a Symfony bundle built on the older Payment/JMS payment abstractions. Adopting it means bridging two DI containers or, realistically, lifting the client and DTOs out and re-hosting them behind a Laravel-native wrapper. Use Saferpay's current JSON API directly or a maintained library.
• You need PCI DSS support, SLAs, or vendor accountability. None of that exists here. Use the provider's official SDK or a commercial connector with support terms.
• You need the current Saferpay feature set — modern JSON API, tokenization, 3-D Secure / SCA flows, hosted payment pages. This bundle reflects an older protocol surface. Whether it even targets live endpoints is an open question until a spike confirms it.
• You are in the EU/EEA. PSD2/SCA/3DS2 obligations are very likely unaddressed at this vintage. An integration that cannot complete a 3DS2 challenge fails live transactions, not test ones.

How to Pitch It (Stakeholders)

Executive summary: A legacy, archived Symfony integration library for the Saferpay gateway, with effectively no community behind it. It should not be adopted for new work and should be treated as a known technical liability wherever it already exists. The business case is risk-and-cost, not opportunity.

For executives — the risk and cost frame:

• Risk: payment code is business-critical and security-sensitive. An unmaintained dependency means no patches, no vendor support, and growing exposure as PHP and Symfony versions advance. It also likely predates PSD2/3DS2 requirements, which is a live-transaction failure mode, not a theoretical one.
• Cost: every future platform upgrade carries this component as a blocker or a manual patch burden. Steady state is roughly 10–15% of one engineer, plus a re-review on every Saferpay API deprecation — and there is no upstream to hand ownership back to.
• Opportunity: replacement is bounded and well-understood — a thin, well-tested adapter over Saferpay's current API — and rides naturally on an existing checkout or framework-upgrade initiative rather than becoming a standalone program. It is also the move that keeps you eligible for tokenization and hosted pages, which contain PCI scope.

For engineering — the ask:

• Freeze new usage and inventory every call site.
• Run a 1–2 week discovery spike against the Saferpay sandbox to confirm which API generation it targets, whether 3DS2/SCA is handled, whether callbacks are verified and idempotent, and whether it covers the full lifecycle (authorize, capture, void, refund, partial refund, tokenize).
• Treat the package as a protocol reference and a source of test fixtures, not a dependency. Define an internal PaymentGateway contract, adapt the current path behind it so behavior is frozen, then implement Saferpay behind the same interface and cut over per payment method behind a feature flag.
• Design for the failure modes that cost real money: silent state divergence when a callback is lost (reconcile against the transaction API, don't rely on callbacks alone), duplicate capture/refund on retry (idempotency keys on your own reference), forged success callbacks (verify signature or IP allowlist, confirm out-of-band before fulfillment), credential exposure in config and logs, and float/rounding defects in the amount path.

For leadership — the decision: No investment in this package. Fund a scoped migration to the provider's supported integration path and keep "archived payment dependency" on the risk register until it is retired.