Sylius Quickpay Refund Bridge Plugin Laravel Package

Technical Evaluation

Architecture fit. The first thing to flag is a stack mismatch: despite being described as a Laravel/PHP package, this is a Sylius plugin — Sylius being the Symfony-based e-commerce platform, not Laravel. It integrates at the Symfony level (bundle registration, service container, likely an event subscriber or service decorator around Sylius's RefundPayment / payment-state-machine refund handling) and calls Quickpay's API through Setono's Quickpay PHP client. If the actual target stack is Laravel, nothing here is directly reusable — no service provider, no Eloquent, no Laravel HTTP client. Its only value in that scenario is as a reference implementation for how to map a Quickpay refund call onto an order/payment state machine.

Integration feasibility. For a Sylius 1.x store already running Setono's main Quickpay payment plugin, feasibility is moderate-to-good: the bridge is deliberately thin, and the surface area to audit is small (likely a handful of classes plus DI config). For anyone else — a different Sylius major version, a different PSP, or a non-Symfony stack — feasibility drops to "rewrite or skip." Note the hard dependency chain: this plugin is a bridge, so it is only meaningful alongside a working Quickpay payment integration and a compatible Quickpay SDK version.

Technical risk. High, concentrated in abandonment rather than complexity. Last release April 2022, 2 stars, 0 dependents, a composite score of 0.01 — that is the profile of an internal utility published to Packagist and never maintained in public. Concretely: no security-advisory coverage, no issue-tracker signal to read, no community to catch breakage, and almost certainly stale Composer constraints that will conflict with Sylius 1.12+/2.x, Symfony 6/7, and PHP 8.2+. The Quickpay API and Setono's SDK have both had years to move; whether this still performs a correct, idempotent refund against the current provider API is unverified. Refund logic is also money-moving logic, which raises the cost of silent incorrectness well above what a 2-star dependency normally justifies.

Key questions.

• What Sylius version, Symfony version, and PHP version is the target, and does the plugin's composer.json actually permit them?
• Is Quickpay still the payment provider of record, and is the companion Setono Quickpay payment plugin itself still maintained?
• Does the business need partial refunds, multiple refunds per payment, or refunds after capture-window expiry? Does this bridge handle them, or only full refunds?
• Is the current process manual (back-office refunds executed directly in the Quickpay dashboard)? If so, the automation value may not justify owning a fork.
• Who on the team can own Symfony bundle maintenance, and is that person available at refund-incident time?

Integration Approach

Stack fit. Green light only for: Sylius 1.x + Symfony 5.4 + the Setono Quickpay payment plugin + PHP 8.0/8.1, with a team that already knows Sylius state machines. Amber for: a Sylius store on a newer major version — treat it as a code sample to port, not a dependency. Red / do not integrate for: Laravel or any non-Symfony application.

Migration path. Do not consume this from Packagist as a live dependency. Clone it, inspect it, and vendor it into your own namespace (private Composer VCS repo, or a src/ copy merged into your application). The code volume is small enough that forking is cheaper than fighting version constraints, and the MIT license makes that clean. If the target is Laravel, extract only the refund request/response shape and error semantics and reimplement against Quickpay's current API.

Compatibility. Expect to relax composer.json constraints by hand — Sylius plugins of this vintage typically pin sylius/sylius and setono/quickpay-* to ^1.x ranges that will not resolve on modern PHP. Verify the Quickpay SDK version it assumes still matches the provider's current API version, and check whether refunds are synchronous or asynchronous (webhook-confirmed) — that determines how much of the state-machine wiring you must build yourself.

Sequencing.

1. Confirm the PSP decision (Quickpay vs. alternatives) before investing further; this package is worthless if the PSP is changing.
2. Audit the source — read every class, map each call to a Sylius state transition, and check error/idempotency handling.
3. Fork, re-namespace, loosen constraints, pin to a commit SHA in your private repo.
4. Sandbox integration test against Quickpay's test environment: full refund, partial refund, duplicate-submit/idempotency, refund on an already-refunded payment, network failure mid-call.
5. Build reconciliation — a scheduled job comparing Sylius refund state against Quickpay refund records — before go-live, not after.
6. Roll out behind a feature flag with a manual-refund fallback documented for support.

Operational Impact

Maintenance. Treat this as an owned fork from day one, not a dependency. Absolute effort is low (small codebase), but it is permanent and non-deferrable: every Sylius, Symfony, PHP, or Quickpay SDK upgrade is your patch to make. Budget a few days per major platform upgrade and a named owner.

Support. None available. No vendor, no active maintainer, no issue throughput, no Stack Overflow footprint at 2 stars. Escalation is internal. That is acceptable for a low-volume refund path with a manual fallback; it is not acceptable if refunds become the only path to customer money.

Scaling. Not a concern in the usual sense — refunds are a small fraction of transaction volume and this is an API-call bridge with no compute or storage footprint. The real scaling question is operational: does it hold up when finance runs a bulk refund batch, and does Quickpay rate-limit you? Add queuing and retry with backoff rather than assuming synchronous success.

Failure modes.

• Divergence: refund recorded in Sylius but rejected/timed out at Quickpay (or vice versa) — the highest-severity risk, producing customer-facing accounting errors. Mitigate with the reconciliation job and an alert on unmatched refunds older than N hours.
• Stale contract: the SDK or provider API shifts and refunds begin failing or, worse, succeeding incorrectly. Add explicit response validation and fail loudly rather than optimistically marking refunded.
• Silent webhook loss: async refund confirmation never arrives, leaving orders stuck in a pending-refund state that blocks fulfillment or customer communication.
• Upgrade deadlock: a routine Sylius upgrade is blocked because this package's constraints break, forcing an unplanned fork sprint at the worst moment.
• Partial-refund gaps: if the bridge only handles full refunds, support staff will discover it during a customer escalation.

Ramp-up. Low for a developer already fluent in Sylius and Symfony DI — a day to read the source and stand up a sandbox. Near-total for a Laravel-only team, where the effort is really "learn the Sylius refund state machine and integrate Quickpay from scratch," in which case this package contributes design hints and little else. Net recommendation: conditionally adopt for an existing Sylius 1.x + Quickpay store with a named maintainer and a manual fallback; otherwise treat as reference material only.