Product Decisions This Supports
- Local payment method for the Czech market. This library generates the Czech "QR Platba" / SPD (Short Payment Descriptor) string that Czech banking apps scan to pre-fill a domestic payment. That makes it a candidate building block for any feature aimed at CZK-paying users: checkout "pay by QR," invoice PDFs with a scannable payment code, donation pages, and B2B supplier settlement.
- Build vs. buy on a commodity formatter. The scope is narrow — encode IBAN, amount, currency, variable/specific/constant symbols, and a message into a spec-defined string. This is a "buy" (adopt) at zero license cost, but also a realistic "build" candidate: roughly a hundred lines covers it. The decision hinges less on capability than on appetite for a low-adoption dependency.
- Fee-sensitive payment flows. QR Platba is a bank-to-bank transfer initiated by the payer, so there is no acquiring fee and no gateway markup. That supports a product decision to offer a free or near-free payment path for low-ticket invoices, membership dues, and donations where card processing economics don't work.
- Invoice and back-office features. Any billing, accounting export, or PDF-generation feature for Czech customers can embed a payment QR with minimal effort. This is the highest-leverage, lowest-risk use case because the QR only needs to be correct, not real-time.
- Roadmap sequencing for CEE expansion. Adopting it signals a Czech-first localization strategy. It is not a template for the rest of the region — Slovakia, Poland, and the eurozone use different standards (SEPA EPC QR being the relevant one for EUR).
- An explicit non-decision: reconciliation. The library produces payment instructions only. It does not confirm, settle, or reconcile anything. Choosing it commits you to a separate answer for "did the money arrive?" — bank statement import, a bank API integration, or manual matching. Surface that dependency in the same planning cycle, not the next one.
When to Consider This Package
Consider it when:
- You are collecting CZK into a Czech bank account and want a scannable payment code rather than a card or gateway flow.
- You need the SPD/QR Platba string specifically — you'll pair it with an image library (e.g.
endroid/qr-code, chillerlan/php-qrcode) to rasterize the code, so factor that second dependency in.
- Usage is asynchronous and tolerant of manual payer action — invoices, statements, donation prompts, printed materials — rather than a checkout where the user expects instant confirmation.
- Your dependency policy is permissive and you're comfortable with a small, single-maintainer MIT package.
Look elsewhere when:
- You need payment processing, capture, refunds, or webhooks. This is a formatter, not a PSP. Card acquiring, wallets, and pay-by-link all require a real provider.
- The market is eurozone/SEPA, not Czech domestic — that's the EPC069-12 QR standard, a different spec and a different package.
- You need multi-currency beyond CZK/EUR or cross-border transfers; bank support for exotic currency codes in QR Platba is inconsistent in practice.
- Your supply-chain rules reject low-adoption dependencies (0 dependents, ~29 stars, single maintainer). That's a defensible position — in which case vendor the logic into your codebase behind an interface, keep the spec reference in a comment, and move on. The format is stable and well documented by the Czech Banking Association, so a reimplementation is low-risk.
- You need guaranteed payer-side compatibility testing across banking apps; the library can't provide that, and neither can you without manual device testing.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed PHP component that lets us accept domestic Czech payments by QR code at essentially zero marginal cost, with no acquiring fees and no contract. It's the cheapest possible way to test demand in the Czech market and to make our invoices payable in one scan. The cost of adoption is a few hours of engineering; the cost of being wrong is near zero because the logic is small enough to replace in-house if the package stalls.
To engineering: Single-purpose SPD string generator, MIT, last released December 2024, no meaningful dependency weight. Wire it behind our own PaymentCode interface so we aren't coupled to the package name, pin the version, and add a test asserting output against the published spec examples. Pair it with an existing QR image library; it does not render images. Flag: single maintainer, negligible downstream usage — treat it as vendorable, not load-bearing.
To finance/ops: The QR instructs the payer's banking app; it does not tell us when payment lands. Whatever we launch with this must ship alongside a reconciliation path — statement import, bank API, or a manual matching queue — or the operations team absorbs the work manually. Budget for that half of the feature, which is the larger half.
Headline risk: low technical risk, low license risk, moderate operational risk concentrated in the unaddressed reconciliation gap and the single-maintainer dependency. Both are mitigable and neither is a reason to defer.