Saferpay Bundle Laravel Package

Technical Evaluation

Architecture fit — the label is wrong and it matters. The catalog calls this a Laravel/PHP package; it is a Symfony bundle from the payment-legacy namespace, built on the older Payment/JMS payment abstractions. There is no service provider, no facade, no publishable config, no queue or event hooks a Laravel app would recognize. For a TPM this is the single most important framing: this is not a dependency you install, it is a specimen of a Saferpay integration you read. Any plan that assumes composer require followed by a config file is wrong by an order of magnitude, and that error propagates straight into your estimate and your stakeholder comms.

Integration feasibility. The realistic work is "extract the protocol knowledge, discard the framework." That means lifting request builders, response models, and field-level detail (amount formats, currency handling, transaction/order ID conventions, status enumerations) into DTOs and a thin client. It is well-bounded work, but it is build, not integrate — a distinction worth being blunt about with sponsors, because "use this package" and "write a Saferpay client, using this as a reference" carry very different costs and ownership tails.

Technical risk — high, and concentrated in compliance rather than code quality. Four categories worth tracking as named risks:

• Vintage/compliance: a package of this age almost certainly predates SCA/3DS2 and PSD2 obligations. If it only implements the legacy Saferpay HTML/Interface flow, it cannot complete a modern challenge — that fails in production, not in test.
• Endpoint mortality: hard-coded legacy URLs and no version negotiation are the pattern here. The failure mode is a total payment outage on a provider-side sunset with no code change on your side.
• Security posture: committed credentials, unverified callbacks, and non-constant-time comparisons are typical for this era. Treat callback verification as work you must add, not work you inherit.
• Ownership: archived, 3 stars, 0 dependents means zero CVE response and no upstream to escalate to. Any defect is permanently yours.

Key questions a TPM should force answers to before funding anything (these are the spike's deliverables, not open-ended research):

1. Which Saferpay API generation does it target, and are those endpoints still live in production today?
2. Does it do 3DS2/SCA, and does it model the authentication result states?
3. Are authorize, capture, void, refund, partial refund, and tokenization all covered — or just the initial payment?
4. Are callbacks verified and is processing idempotent, or is idempotency on us?
5. Does it run on PHP 8.2/8.3 without patching, and are its transitive dependencies themselves abandoned?
6. Is there a test suite, and can we stand it up against the Saferpay sandbox to produce a request/response catalogue?
7. What is the license, and is code reuse actually permitted?

TPM verdict: not adoptable. Its value is (a) a protocol reference that shortens the discovery spike and (b) evidence for a risk-register entry. The narrow opportunity is real — there is no credible maintained Laravel-native Saferpay integration — but the correct output of that insight is a thin in-house client, not a fork.

Integration Approach

Stack fit. Plan for a wrapper, not a bridge. Laravel already carries Symfony components, so reusing a PSR-18/Guzzle transport layer is plausible; bootstrapping Symfony's DI container next to Laravel's is not worth the complexity and will be the thing that breaks under Octane. The clean target is a single SaferpayGateway class behind an application-owned PaymentGateway contract, using Laravel's HTTP client, config, logging, and queue — with the package's request/response shapes re-hosted as DTOs.

Migration path — strangler, not swap.

1. Define the internal PaymentGateway interface (authorize, capture, refund, status, tokenize) and repoint call sites at it. This is the step that makes every later step reversible.
2. Put an adapter in front of whatever is live today so current behavior is frozen and testable — this is your safety net and your regression oracle.
3. Build the Saferpay implementation behind the same interface, driven by the sandbox catalogue from the spike.
4. Cut over per payment method — card first, tokenized/subscription flows last — behind a feature flag with per-merchant or per-cohort routing.
5. Keep the old path warm for one full billing cycle before deletion, gated on finance reconciliation sign-off.

Compatibility checks that belong in the definition of done, not in a later cleanup: PHP 8.2/8.3, Guzzle 7, PSR-18 client discovery, no mcrypt/each()-era artifacts, no superglobal or static credential state (Octane and long-running workers will expose it), integer minor units everywhere in the amount path (a float is a defect, not a nit), and explicit timezone and currency handling.

Sequencing and rough sizing.

• Discovery spike, 1–2 weeks, one engineer: sandbox harness plus a documented request/response catalogue. This is your decision gate.
• Gate: if the legacy API is confirmed sunset, stop here and go to Saferpay's official library or a direct HTTP client. Expect this outcome; design the spike so a "no-go" is a cheap, fast, respectable result rather than a failed project.
• Interface and adapter scaffold: 1–2 weeks.
• Saferpay client plus sandbox-driven contract tests covering every lifecycle state: 2–4 weeks.
• Security/compliance review (callback verification, idempotency keys, log redaction, 3DS2 evidence): 1–2 weeks, parallel.
• Canary rollout and reconciliation soak: 2–4 weeks, blocked on finance sign-off.

Leverage point for the TPM: the spike is the whole product decision in miniature. Fund it as a timeboxed discovery with a written deliverable, and you get an API-generation answer, a protocol catalogue, and a defensible go/no-go — regardless of whether this repository turns out to be useful.

Operational Impact

Maintenance. Forking or vendoring converts a dependency into a permanent ownership commitment. Every Saferpay API change, PHP minor release, and TLS rotation lands on your team, with no upstream and no path to hand ownership back. Budget roughly 10–15% of one engineer steady-state, plus a mandatory re-review whenever Saferpay announces a deprecation. Record this in the ADR so the cost stays visible to whoever inherits it — the failure mode is that this quietly becomes nobody's line item.

Support. There is no support for the package, and Saferpay/Worldline support covers their API and your account, not this code. Every incident call splits across two vendors with you in the middle as integrator. Define the internal model up front: on-call can read structured logs of every redacted Saferpay request/response, and finance has a reconciliation report keyed by transactionId/orderId. Without both, every dispute becomes archaeology.

Scaling. The package is thin; the provider is the bottleneck. The risks are architectural and mostly inherited: synchronous HTTP inside the request cycle inflates tail latency and pins PHP-FPM workers when Saferpay is slow; no retry/backoff or circuit breaker; and no idempotency means a retried authorize can double-charge. Move status polling and notification processing onto queued jobs, wrap the provider in a circuit breaker, and make every state-changing call idempotent on a reference you generate.

Failure modes to instrument for explicitly.

• Silent state divergence — payment succeeded at Saferpay, order stuck pending, because a redirect or callback was lost. Mitigate with scheduled reconciliation against Saferpay's transaction API; never let callback-only state machines be the source of truth.
• Duplicate capture or refund on retry or double-submitted forms.
• Deprecated endpoint returning 4xx/410 after a provider sunset, presenting as a sudden total payment outage.
• Forged "success" callbacks — verify signature or IP allowlist and always confirm status out-of-band before fulfillment.
• Credential exposure in committed config or verbose exception logs; enforce secret storage and redaction in review.
• Currency/rounding drift producing small systematic mismatches that only surface at month-end reconciliation.

Ramp-up. One to two weeks to productivity, four to six to real confidence in the payment flow. The scarce skills are legacy Symfony DI idioms and older Saferpay API semantics — neither is common and neither is documented by the package. Mitigations: keep the wrapper thin, push protocol knowledge into tests rather than people, treat the spike's request/response catalogue as first-class documentation, and pair implementation with a payments-literate reviewer from finance or ops. Assume the engineer joining in six months will need that documentation, because the original author will have moved on.