- Can I use rikudou/qr-payment-bundle in a Laravel application?
- Not directly. It is a Symfony bundle, and Laravel does not auto-discover Symfony bundles, so you would have to manually register its services in a service provider for very little benefit. The practical route is to require rikudou/qr-payment directly and wrap its factory behind your own Laravel service or interface.
- What does the bundle actually add on top of the rikudou/qr-payment library?
- It registers the QR payment generator and related services in the Symfony dependency injection container and exposes bundle configuration, typically YAML, for default payment settings. The actual payload generation and rendering come from the framework-agnostic core library. In Laravel you only need that core library plus a small adapter bound in a service provider.
- How do I install and configure default payment details?
- On Symfony you run composer require rikudou/qr-payment-bundle, enable the bundle in config/bundles.php, and set defaults such as IBAN, amount, currency, and message in the bundle configuration. On Laravel, skip the bundle entirely and put those defaults in a config file or service provider that your generator reads, so controllers, jobs, and PDF generation share identical behavior.
- Which Laravel and PHP versions are supported?
- The bundle targets Symfony, so Laravel version support is not really meaningful. PHP support is defined by the core library's composer.json plus its Symfony component and QR renderer constraints, so run composer why-not or a short install spike against your PHP version. Pin a version and confirm transitive dependencies resolve within your Laravel footprint before committing.
- Does it generate only Czech QR Platba codes or other formats too?
- The bundle is documented around Czech QR Platba with SPAYD-compatible output. The underlying library also exposes Slovak and European factory methods, but you should confirm exactly which standards your pinned version covers and to which spec revision. Do not assume standard coverage without checking the source and its tests.
- Does the library validate IBAN, BIC, or parse existing QR codes?
- It is generation-focused: you supply payment data and get a QR payload and image back. It is not a payment gateway, so there is no settlement, webhook, or reconciliation signal. Validate IBAN, BIC, amount precision, currency, variable symbol, and message length in your own domain layer first, because malformed input produces a code that fails silently when a customer scans it.
- Can I get the raw payment string without rendering an image?
- Yes, in practice the core library exposes a payload string accessor alongside the image renderer, which is exactly what you want. Persist that string against the invoice, assert it byte-for-byte in tests, and render the QR image separately. That keeps the payload testable independently of any renderer or Symfony service wiring.
- How should I test generated QR payment codes?
- Use golden fixtures: build a payment from known invoice data and compare the exact payload string against a value verified against the published spec example, asserting amount formatting, currency code, and diacritics. Then scan the rendered image with a real Czech banking app in staging before shipping. Do not rely on image diffing alone, since a visually similar code can still be unscannable.
- Is this bundle safe to use in a production payment flow?
- Treat it cautiously. Adoption signals are weak, with few stars, no dependents, and a single maintainer, and the WTFPL license carries no warranty or support, so assume you own the integration and possibly a fork. Correctness risk is asymmetric because a byte-level defect fails silently until a real customer tries to pay. Get legal sign-off on the license and keep the integration behind an interface you can swap.
- What are the alternatives if I would rather not depend on this bundle?
- You can build the SPD or SPAYD string yourself, since the spec is short and stable, and render it with a maintained QR library such as endroid/qr-code or chillerlan/php-qrcode. Alternatively, use the rikudou core library behind your own interface and fork later if upstream stalls. Either way, drive format selection from a currency or payment-rail field on the model rather than the application locale.