Swiss Qr Bill Laravel Package

Product Decisions This Supports

• Market entry into Switzerland. Any product that bills Swiss customers in CHF eventually needs a scannable payment part on the invoice. This package is the "render a compliant Swiss QR bill" primitive that unblocks a CH launch without a payments vendor contract.
• Build vs. buy for invoice output. The Swiss QR-bill spec is deceptively detailed: the QR payload structure, QR-IBAN vs. IBAN rules, QR reference with mod-10 recursive check digit, creditor/debtor address modes, amount formatting, print margins, font sizes, and multilingual labels. A PM should treat in-house implementation as a multi-week engineering item plus an ongoing spec-maintenance line, not a sprint task. This package collapses that into a Composer dependency, which is the strongest form of the build-vs-buy argument.
• Feature scoping for the invoicing/billing module. Forces early decisions on data model: do we support QR-IBAN and QR references, or only standard IBAN with no reference? Do we store structured addresses (required for the newer address mode) or legacy combined fields? Those choices are expensive to retrofit and should be made explicitly at roadmap time, not discovered during implementation.
• Scope boundary: render vs. submit. This library produces the document, not the payment. It is not EBICS, not pain.001, not eBill. That distinction lets you ship "printable invoice with payable QR" as Phase 1 and defer bank connectivity/e-invoicing to a later phase with a different vendor.
• Where it shows up in the product: SaaS subscription invoices, ERP/accounting receivables, e-commerce order and refund documents, membership dues, tuition and insurance billing, expense reimbursement, any B2B invoice PDF destined for a Swiss AP department.
• Support and compliance risk budgeting. Because rejection happens at the bank or in the customer's banking app, quality is binary and visible. Allocate acceptance criteria accordingly: golden-file regression tests on generated PDFs, scan tests across the major Swiss banking apps, and a pre-launch pass through a bank's QR-bill validation tool.
• Exit-cost planning. Adopting a small, single-maintainer MIT library is a decision to accept a fork-and-own fallback. That is a legitimate, cheap hedge for a component this narrow — but it should be recorded as a decision, not left implicit.

When to Consider This Package

Adopt when:

• You are on PHP (Laravel or otherwise) and already generate invoice PDFs server-side; this is framework-agnostic and drops in via Composer.
• You need Swiss QR bills at on-demand or batch volume, generated inside your own infrastructure — no external API call, so no data-residency or third-party DPA conversation about customer IBANs.
• You want the payment part only, and are content to compose it into your existing invoice template/PDF pipeline rather than replace it.
• You value MIT licensing and a narrow, single-purpose surface area over a broad document suite.
• You have engineering capacity to pin a version, wrap it behind an internal interface, and write regression tests against known-good output.

Look elsewhere when:

• You are not a PHP shop — the value is entirely in the implementation, not the format.
• You need a full document/templating engine (invoice layout, branding, multi-page, localization) rather than the payment slip. Pair it with your PDF stack or buy a billing platform.
• You need the money to actually move or reconcile: EBICS, ISO 20022 / pain.001, camt.053 statement parsing, or direct bank integration. Different problem, different vendor.
• You need eBill (the Swiss e-invoicing network) or cross-border e-invoicing compliance — adjacent standards this does not address.
• You require vendor SLAs, indemnification, security review paperwork, or a named support contact. A 330-star community library with a small maintainer base will not satisfy procurement in a regulated enterprise; you would instead lean on a certified payments provider or accept the fork-and-own cost internally.
• Your finance team insists on a SIX-certified/validated generator with a certification paper trail — in that case use a certified print/service provider and treat this only as a prototype accelerator.

Adoption checklist: pin the version; wrap in a SwissQrBillGenerator-style internal service; assert on the QR payload string, not just the PDF; test at least one QR-IBAN + QR-reference path and one plain-IBAN path; validate output in a bank's QR-bill checker before the first customer invoice.

How to Pitch It (Stakeholders)

For executives (30 seconds). Swiss invoices need a scannable QR payment part — it is a legal/market expectation, not a nice-to-have, and getting the encoding wrong means customers cannot pay and finance teams notice immediately. Buying that capability as a small MIT-licensed library removes an estimated multi-week build plus an ongoing spec-maintenance line, at zero license cost and with no vendor lock-in: it is a self-contained PHP component we can replace or fork in days if needed. It is the cheapest credible path to invoicing Swiss customers, and it de-risks the CH launch timeline.

For engineering. Composer-installable, framework-agnostic PHP with an MIT license and recent, continuing releases. It does one thing — assemble the Swiss QR payload and render the payment part — with no runtime service dependency and no outbound network calls, so it is deterministic and easy to test. We wire it behind a thin internal interface so the rest of the codebase never imports it directly; that keeps the swap cost near zero. Two asks: pin the version and add golden-file regression tests on the generated output, because PDF/layout regressions from a minor bump are the realistic failure mode.

Risks we are accepting, stated plainly. Small community (~330 stars) and a concentrated maintainer base — mitigated by the permissive license, narrow scope, and our interface wrapper. Correctness is validated externally by banks, not by us — mitigated by pre-launch validation through a bank's QR-bill checker and scan tests on real devices. The library renders documents; it does not move money or handle eBill — those remain separate roadmap decisions and should not be implied to customers as covered.