Iban Bundle Laravel Package

Product Decisions This Supports

• Scope decision for any payment, payout, or reimbursement feature. IBAN capture sits upstream of vendor onboarding, marketplace seller payouts, SEPA direct debits, expense reimbursement, and invoicing. The PM decision is whether validated IBAN capture is in-scope for this milestone and how strict it should be — checksum-verified at the point of entry, or format-only with downstream correction. This package exists because that decision has already been made by someone else in the ecosystem; it is evidence the requirement is standard, not evidence that this implementation is the right one.
• Build vs buy on validation logic. The honest framing is that IBAN validation is a "buy the data, build the glue" problem. A maintained PHP IBAN library supplies the country format tables and mod-97 checksum; the Laravel integration is a validation rule, a value object, and a form request — roughly one engineer-day. This bundle is neither half of that equation for us: it is the glue for a framework we do not use. The PM decision it supports is to fund a small, owned build rather than adopt an unmaintained adapter.
• Supply-chain risk triage on payment-critical paths. Four stars, zero dependents, no meaningful issue history. The PM decision this supports is a policy one: payment-adjacent validation surfaces should not sit on dependencies we cannot escalate to and did not choose. The cost of owning ~150 lines is lower than the cost of being the de facto maintainer of a fork nobody else uses.
• Reframing inbound requests from Symfony-idiom teams. When a feature request arrives phrased as "add an IBAN form type," the PM's job is to translate it into our vocabulary — Laravel validation rule, form request, Blade/Inertia component — and reject the implied package. Accepting the proposal as written silently imports a framework-mismatched dependency into a payment path.
• Architecture-fit check as a first-class gate. This package is a useful forcing function for a lightweight intake question: does the proposed dependency target our stack? A Symfony bundle in a Laravel app fails that gate before any code is read, which is exactly the kind of fast, cheap rejection a PM wants to institutionalize.

When to Consider This Package

• Only on Symfony, ideally older Symfony, with Symfony Forms in use. The -bundle naming convention and the low maintenance signal point to the Symfony 2/3/4 era. If the team is on that stack and wants a drop-in IBAN field with minimal effort, the calculus changes — but the abandonment risk does not disappear, so it should still be evaluated against a maintained library plus a short custom type.
• Never as a Laravel dependency. Laravel has no bundle kernel, no Symfony Form abstraction, and no bundle registration path. composer require here is a dead end; any spike that starts there should be killed before it consumes time. The value is extractable, but only as a read-and-reimplement exercise.
• Look elsewhere if the requirement is broader than string validation. IBAN-to-BIC derivation, country-specific display formatting, SEPA mandate lifecycle, account verification or micro-deposits, and storing financial instruments are all out of scope. If the roadmap points at any of those, adopt a payments-domain library rather than a validator.
• Look elsewhere for new builds. A maintained standalone IBAN library plus a hand-rolled Laravel rule gives the same user-facing behavior with a live data table, an active maintainer, and no framework coupling. The only thing lost is the Symfony form type, which we do not need.
• Hard stop signals: four stars, zero dependents, no release cadence, no community. For a soft UX nicety on a profile page that might be tolerable; for anything that routes money, it is not.

How to Pitch It (Stakeholders)

Summary. The requirement behind this package is real and already on our roadmap: users need to enter bank account details for EU/SEPA payouts and reimbursements, and those details need to be validated before they reach a payment file. The package itself is the wrong vehicle. It is an effectively unmaintained Symfony bundle, we run Laravel, and there is no integration path — not a difficult one, not a costly one, none. Its only durable asset is a small amount of well-specified, publicly documented domain logic: IBAN structure, country length tables, and a mod-97 checksum.

Recommendation. Do not adopt. Budget roughly one engineering day to implement a Laravel validation rule and a small Iban value object, backed by a maintained IBAN validation library for the country tables and checksum. Wire it into the relevant form requests and expose a client-side hint. If the team wants a head start, treat the bundle's validator as a reference implementation to read with attribution — not a dependency to install.

Value and risk. The upside is identical to what the package promises: validated IBAN capture that unblocks seller onboarding and payout flows. The difference is ownership. Adopting the bundle makes us the de facto maintainers of a fork with no upstream, and — more dangerously — leaves us on a country-format table that will silently drift as SEPA formats change. A stale table does not throw an exception; it routes a payout to a malformed account and surfaces later as a support incident. Owning one file plus one data table removes that failure mode permanently and keeps a payment-critical surface inside our own review and test process.

Engineering note. Extract the spec, do not fork the code. Country length and character-set rules, mod-97 checksum, space stripping, and uppercasing into a single normalizing validation rule, covered by a table-driven test of known-valid and known-invalid IBANs per market. This also establishes the pattern for the next bank-data requirement — BIC, country-specific formatting, mandate references — which we will control rather than inherit.