Product Decisions This Supports
- Checkout and invoice “scan to pay” option — enables bank-transfer payment via QR code for high-ticket, B2B, invoice-driven, and margin-sensitive flows where card fees are painful. The customer scans in their banking app; the business avoids PSP revenue share.
- Market-entry and localization roadmap — supports go/no-go decisions for Czechia (QR Platba), Slovakia (PAY by square), and SEPA/EUR markets (EPC QR), where local payment expectations are table stakes.
- Build vs. buy for QR payment standards — replaces weeks of spec work across multiple bank-consortium formats with a small library call. Licensing is effectively free (WTFPL), so the real decision is maintenance ownership, not procurement.
- Adjacent feature surface — the same primitive can power invoice PDFs, dunning emails, refund instructions, expense flows, and marketplace seller payout instructions.
- Unit economics and payment-method mix — gives product a zero-fee or low-fee payment option to offer alongside cards, useful for subscriptions reminders and large invoices.
- Explicitly not a driver for card acceptance, wallets, subscription orchestration, payment-status reconciliation, refunds, or webhooks. A QR code is a static payment instruction with no settlement signal.
When to Consider This Package
Adopt when:
- You need QR Platba (CZ), PAY by square (SK), or EPC/SEPA QR (EUR) and want to avoid hand-rolling three separate specifications.
- A static, one-way payment instruction is enough: display the QR, customer scans it, reconciliation happens against the bank statement or back-office process.
- You are on Symfony, or you are willing to use the underlying
rikudou/qr-payment library directly in Laravel behind a service provider.
- You treat it as a small, replaceable utility wrapped behind an internal interface, with golden-file tests and a manual payment-details fallback.
Look elsewhere when:
- You need payment confirmation, webhooks, refunds, settlement state, or orchestration — use a PSP or open-banking provider.
- You need card acceptance, wallets, or subscription billing — out of scope.
- You require SLA-backed support, security patch guarantees, or vendor accountability — this is a tiny, single-maintainer project with weak adoption signals.
- Legal is strict about license wording — WTFPL is functionally public domain but often triggers review in payment-adjacent flows.
- You are Laravel-native and want zero Symfony coupling — skip the bundle and use the core library; the bundle is Symfony-specific scaffolding, not a Laravel package.
How to Pitch It (Stakeholders)
To executives: This is a small, free capability that unlocks “scan to pay by bank transfer” across Czechia, Slovakia, and the SEPA eurozone. It lets us offer a payment method with no card fees, valuable for B2B invoices and high-ticket orders, and it ships in days rather than weeks. The license is public-domain-equivalent, so there is no procurement cost. The real risk is maintenance, not functionality: the project is tiny and single-maintainer. We mitigate that by isolating it behind an internal interface, scoping it to display-only QR generation, and keeping a manual bank-details fallback. It does not touch money movement, credentials, or customer data.
To engineering: Treat this as a thin QR-payload generator, not a payment integration. In Laravel, do not adopt the Symfony bundle directly; use the underlying rikudou/qr-payment library behind a PaymentQrGenerator interface bound in a service provider. Expose domain-friendly methods such as generateForInvoice(Invoice $invoice): QrPayment, persist the payload string rather than the image, and render images on demand. Pin the version, add golden-file tests against published CZ/SK/EPC examples, validate generated codes in real banking apps, and feature-flag a low-risk invoice pilot. Keep the core library as the documented fallback if the bundle or wrapper goes stale.