- How do I install rikudou/euqrpayment in a Laravel app?
- Install it with Composer using composer require rikudou/euqrpayment. It is a framework-agnostic PHP library, so there is no service provider, config file, facade, or published asset to register. Instantiate the payload builder directly or, better, wrap it behind your own Laravel service. Pin the exact version in composer.json because upstream has not released since 2021.
- Does rikudou/euqrpayment support Laravel 10, 11, or newer?
- The package has no Laravel-specific code, so Laravel version support mainly depends on running it on a compatible PHP version. The technical evaluation notes that PHP 8.2 and 8.3 compatibility is unverified because the last release was in September 2021. Test it in your target runtime during the spike before committing. Keep it behind your own boundary so a fork or replacement is easy.
- Can rikudou/euqrpayment generate the QR code image itself?
- No. It produces an EPC069-12 payload string, not an image. You still need a QR renderer such as endroid/qr-code or bacon/bacon-qr-code, plus GD or Imagick, to turn the payload into a scannable code. That renderer is a separate integration surface: set the error-correction level, quiet zone, and print DPI deliberately.
- Does this package tell me whether a customer has paid?
- No. It only builds a QR payment payload for SEPA credit transfers and does not initiate, transmit, confirm, or reconcile payments. If your product needs a paid or unpaid status, that must come from your PSP, bank feed, or reconciliation process. Treat this library as a complement to a payment provider, not a substitute.
- Does rikudou/euqrpayment validate the IBAN and prevent bad payloads?
- Do not assume full validation. The technical assessment specifically flags the IBAN mod-97 checksum, BIC omission rules, EPC character repertoire, and the 331-byte cap as items to verify in a spike. Out-of-spec payloads can still look like valid QR codes and then fail or mis-populate inside a banking app. Add your own validation and sanitization in a Laravel boundary before calling the library.
- What is the recommended way to integrate it into Laravel?
- Do not call the vendor class directly from controllers or Blade templates. Define your own interface, such as EpcQrPayloadGenerator, bind it in a service provider, and have it own validation, character sanitization, amount normalization, and a typed DTO with toPayload(). That keeps the vendor class behind one boundary so swapping to a fork or an in-house rewrite is a one-file change.
- What EPC payload details commonly go wrong?
- Check field order, the version header, and the trailing newline against EPC069-12 v2. Amounts should use a dot with exactly two decimals within 0.01 to 999999999.99, diacritics need the EPC character repertoire and transliteration, and BIC should be omitted rather than left blank for non-SEPA countries. Also enforce the 331-byte payload cap and test with real banking apps.
- How should I test EPC QR payment payloads in Laravel?
- Use golden-file tests that assert the exact payload string for a matrix of cases: CZ, DE, SK, and AT IBANs, diacritics in recipient and remittance text, minimum and maximum amounts, over-long remittance, and missing BIC. Then scan the rendered QR codes in at least three real banking apps as a conformance gate. Do not rely on visual inspection alone, because a malformed payload can still scan.
- Is rikudou/euqrpayment maintained and safe for production?
- It is dormant: the last release was 2021-09-27, with a single maintainer, around 18 stars, and no dependents. Treat it as adopt-and-fork rather than adopt-and-track, pin the exact version, commit the lockfile, and consider vendoring the source or using a private VCS fork. Add a visible note that upstream is unmaintained so nobody mistakes it for a supported dependency.
- Are there alternatives to rikudou/euqrpayment, or should I build the payload myself?
- The EPC QR format is roughly ten newline-separated fields with charset and length constraints, so an in-house builder is realistic and gives you full control over validation. Alternatives include implementing EPC069-12 yourself or forking this library and owning the tests. If you keep the text IBAN and BIC fallback alongside the QR, you reduce risk for users and apps that cannot scan.