Sylius Quickpay Plugin Laravel Package

Product Decisions This Supports

• Market entry into Denmark (and the Nordics). Quickpay is a Danish PSP with strong local method coverage — Dankort, MobilePay, and local card/3DS flows. Adding it is usually the difference between "we technically ship to DK" and "Danes will actually check out." That makes this a market-expansion decision, not an infrastructure decision.
• Checkout conversion / payment-method coverage roadmap. Payment method availability is one of the few checkout levers with a measurable, attributable effect on conversion. This plugin lets you test local-method coverage in a Sylius store without committing to a full custom gateway build.
• Build vs. buy vs. wrap. The realistic options are (a) build a Sylius payment gateway integration in-house, (b) wrap this plugin, or (c) consolidate onto a global PSP (Adyen, Stripe, Mollie) that already covers MobilePay/Dankort. This package materially changes the cost side of (a) — plausibly days of integration work instead of low weeks — which reframes the whole comparison.
• PSP consolidation strategy. If you're running multiple storefronts, decide explicitly whether Quickpay is a regional exception to a global PSP or the start of a multi-PSP architecture. This plugin is cheap enough that the "exception" path becomes defensible, but it also creates a second reconciliation/reporting stream for finance.
• Operational scope for finance and support. The gateway exposes authorize / capture / refund / cancel. That maps directly to decisions about partial captures, partial refunds, and whether back-office staff can resolve payment issues in the Sylius admin or need PSP-dashboard access.
• Sequencing against other roadmap work. Because it's an adapter rather than a platform change, it can ship behind a channel-level toggle and be enabled per storefront — low blast radius, good candidate for a time-boxed spike rather than a full epic.

When to Consider This Package

Consider it when all of these hold:

• You are on Sylius/Symfony, on a version this plugin's constraints actually support — verify composer.json against your Sylius minor, don't assume.
• Quickpay is already (or is about to be) your contracted PSP, or local-method coverage in DK is a validated requirement — not a hypothesis.
• You need standard flows: authorize/capture/refund, 3-D Secure/SCA, webhooks/callbacks. If you need subscriptions, split payments, marketplace payouts, or saved-card vaulting, validate those specifically; don't infer them from the feature list.
• You accept maintenance ownership. 3 stars and 0 dependents is a real signal: no community backstop, no crowd-sourced bug fixing, and a single-vendor bus factor. Setono is a credible Sylius agency, which reduces — but does not remove — the risk.
• You can absorb the code as a fork you control if upstream stalls (pin the version, review the diff, keep it vendored/patched rather than depending on the maintainer's release cadence).

Look elsewhere when:

• You're not on Sylius. Quickpay ships official/partner modules for the major SaaS platforms; use those rather than porting this.
• Your PSP strategy is consolidation. If Adyen/Stripe/Mollie already cover MobilePay and Dankort for your basket mix, a second PSP adds reconciliation, chargeback, and support overhead that a free plugin does not offset.
• You need deep custom payment logic — multi-seller splits, complex retry/dunning, custom SCA orchestration. At that point write your own gateway against Quickpay's REST API; the plugin is a starting reference, not a foundation.
• The plugin's supported Sylius versions lag your upgrade cadence, or the release history turns out to be dependency-bump-only with no substantive commits — that means you're adopting a fork on day one.
• You can't get a security review of third-party code that sits in the payment path. Non-negotiable: webhook signature verification, idempotent callback handling, no card data in logs.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, reversible enabler for selling in Denmark. It converts a "we can't take local payments" blocker into an integration task we can scope in days, and we can turn it on per storefront so the downside is contained. The honest caveat is vendor concentration: it's a small open-source adapter with minimal community adoption, so we should treat it as our code from day one — budget a named owner and a fallback to our global PSP if it stops being maintained. Frame the ask as a time-boxed pilot with a defined success metric (DK checkout completion rate and payment failure rate), not a permanent architectural commitment.

To engineering: Treat it as a reference implementation and a head start, not a black box. Diligence before adoption: confirm Sylius version compatibility, review the callback/webhook handling for signature verification and idempotency, confirm capture/refund/partial-refund semantics match finance's expectations, and confirm what's logged. Plan for a fork-and-own posture with pinned versions. Estimate the counterfactual — building this against Quickpay's REST API directly — so we know what the plugin is actually saving us.

To finance/ops: It introduces a second settlement and reconciliation stream alongside our existing PSP. We need a documented process for captures, refunds, and chargebacks in the Sylius admin vs. the Quickpay dashboard before go-live, not after the first dispute.