Saferpay Laravel Package

Product Decisions This Supports

• Provider expansion / market entry: Evaluating whether to add Saferpay (SIX/Worldline, strong in DACH/Switzerland) as a checkout option for a Laravel-based product, and what the integration lift actually looks like.
• Build vs. buy vs. adopt: A concrete data point for the recurring "integrate the PSP ourselves, use an existing driver, or route through an orchestrator (Stripe/Adyen/Mollie/CommerceTools)" decision — this package represents the cheapest possible answer to that question, and its state tells you why cheap is often expensive.
• Payment flow scoping: Helps a team size the surface area of a real integration — payment initiation, hosted payment page redirect, authorization, capture, refund, and stored-card/tokenization flows — before committing to a roadmap item.
• Reference architecture: Useful as a reading artifact when designing an in-house gateway adapter (how to wrap HTTP calls, handle statuses, model transactions) rather than as a dependency.
• Legacy triage: Informing a keep/replace decision on an existing product already on Saferpay, particularly if the current integration was built in the same era.
• Risk/compliance budgeting: Makes visible the work that a 2016-era wrapper does not cover — SCA/PSD2, 3-D Secure 2, API versioning — so those become roadmap line items instead of launch surprise.

When to Consider This Package

Consider it only when:

• You have an existing Laravel application already speaking Saferpay and need a short-term read on how the flow was modelled.
• The scope is internal, low-value, or non-production (back-office reconciliation, sandbox prototypes, migration mapping).
• You are willing to vendor/fork it, own the code, and pin PHP/Laravel versions yourself — the MIT license makes this legally trivial; it does not make it operationally trivial.
• You accept a reference-only role: use it to understand the API shape, then write your own adapter.

Look elsewhere when any of the following is true:

• Production payments. The package is archived, with no release since 2016 and a low adoption signal (~18 stars). No security patching, no bug fixes, no maintainer.
• Compliance is in scope. SCA/PSD2, 3-D Secure 2, and current Saferpay JSON API versions postdate this code. Building compliance on an unmaintained wrapper is a materially worse risk than building on the provider's own SDK.
• You need support or an SLA. There is none — not from the package, and the provider will not support a third-party wrapper.
• Modern PHP/Laravel. Framework and PHP compatibility, dependency constraints, and autoloading conventions have moved on substantially since 2016; expect upgrade work before first use.
• Payment method breadth. Card-only-era abstractions will not cover wallets, local methods, or newer Saferpay endpoints.
• The decision is still open on the PSP itself. If you have not committed to Saferpay, prefer a provider with a first-party SDK and a maintained framework integration.

Recommended posture: treat this as documentation, not as a dependency. Adopt the provider's official library or budget one to two engineering weeks for a thin, owned adapter.

How to Pitch It (Stakeholders)

Summary for executives: This is an unofficial, community-built connector between Laravel applications and Saferpay, a European card payment provider. It is usable in principle and permissively licensed (MIT), but it has been archived, has not shipped a release since September 2016, and has minimal adoption. It is not something we should put in front of customers or auditors.

What it tells us: Saferpay integration in our stack is a small-to-medium engineering task — the flow is well understood (initiate, redirect to hosted page, authorize, capture, refund). The package is useful mainly as evidence that the integration is tractable, not as the implementation itself.

The recommendation: do not adopt as a dependency. Either use Saferpay's official SDK, or have engineering build and own a thin integration layer. Budget roughly 1–2 engineer-weeks for the adapter plus compliance review for SCA/3-D Secure 2 and current API versions — costs this package would not remove and could obscure.

The risk in one line: payment code is code that moves money; unmaintained payment code is a liability we would inherit permanently for a few days of saved effort.

Ask: approve the in-house/official-SDK route and treat this package as a reference during design, not a line in the dependency manifest.