Bacon Qr Code Laravel Package

Product Decisions This Supports

• Build vs. buy on QR generation: Encoding QR codes is a spec-heavy, commodity capability (Reed–Solomon, masking, version selection, ECI). Building it is not a differentiator. bacon/bacon-qr-code is a PHP port of the ZXing encoder, MIT-licensed and actively maintained — a credible "buy" as a dependency rather than a service.
• Vendor/API decision: Because it runs in-process, QR payloads (order IDs, pickup codes, otpauth:// URIs, signed deep links) never leave our infrastructure. This is a decision-grade argument for any flow touching PII or auth.
• Output-format roadmap: The pluggable renderer architecture lets us standardize per surface — SvgImageBackEnd for PDF invoices, labels, and print collateral; GDLibRenderer for fast web/email thumbnails; ImagickImageBackEnd only where raster control matters. That's a product decision about where QR codes appear, made cheaply.
• Feature bets enabled: Checkout/order confirmation codes, event ticketing and vouchers, WiFi/vCard/deep-link sharing, 2FA enrollment, multi-tenant white-label codes (gradients, transparency, custom eye shapes, compact text output are all supported).
• Internationalization: Configurable UTF-8 ECI prefix and Kanji-mode fixes mean non-Latin payloads are viable; this de-risks localization of any QR-bearing flow.
• Theming/white-label: Per-tenant color, gradient, and eye-shape styling is a supported configuration surface, not a fork.

When to Consider This Package

Adopt the underlying package when:

• You are on PHP 8.1+ and need encoding only (no decoding/scanning).
• You want SVG or EPS output for print or infinite-scale assets.
• You want no external HTTP dependency and no per-scan cost.
• You are comfortable owning a thin internal wrapper (a QrCodeGenerator service behind an interface) rather than a framework-native API.

Look elsewhere when:

• You want a Laravel-native experience — facade, config publishing, fluent builder. In practice, endroid/qr-code and simplesoftwareio/simple-qrcode both sit on top of Bacon and give you that DX. For a Laravel app, the realistic recommendation is to depend on one of those and treat Bacon as the transitive engine, unless you have a specific reason to go one level down.
• You need decoding/scanning — the encoder-only scope is explicit.
• You cannot guarantee ext-gd, ext-imagick, or ext-xmlwriter across target environments.
• You need a managed SLA, hosted rendering, or dynamic short-link redirect analytics — that's a vendor product, not a library.

Flag as a real risk: the documented Imagick rasterizer bug causing stray white pixels inside filled modules. The maintainers state it cannot be reliably worked around. Do not standardize on ImagickImageBackEnd for anything scanned at margin 0, printed, or rendered small. Standardize on SVG (with GD as the raster fallback) and write that into the technical decision record.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, actively maintained PHP library that generates QR codes on our own servers with zero per-scan cost and zero data leaving our infrastructure. It removes a third-party dependency from any flow carrying customer data, and it covers every output we're likely to need — web images, email, SVG for print, branded multi-tenant styling — without new headcount. Maintenance load is low: the project ships semantic releases, changelogs, and CI with coverage.

For engineering: Encoder-only port of ZXing with a clean renderer abstraction (Imagick / SVG / EPS / GD). PHP 8.1+, no Laravel coupling — we wrap it behind a single internal service so it's swappable. Two known caveats: no decoder, and an ImageMagick rasterizer bug that produces stray white pixels, so we standardize on the SVG backend and use GD where we need raster. Requires ext-xmlwriter or ext-gd.

Recommendation: Adopt, but consume it through a wrapper — realistically via endroid/qr-code for Laravel ergonomics — and make SVG the default renderer. Low cost, low lock-in, and it converts a vendor dependency into an owned, auditable capability.