Iban Laravel Package

Technical Evaluation

What the package actually does. jschaedl/iban is a small, single-purpose PHP library with two capabilities: (1) validate that a string is a structurally valid IBAN (length per country, country code presence, ISO 7064 MOD-97-10 checksum), and (2) generate valid IBANs, which is only useful for test fixtures and seeding — not production functionality. There is no BIC lookup, no bank-name resolution, no account-number derivation, no SEPA/EMIR/PSD2 logic, and no persistence layer.

Architecture fit. The library is framework-agnostic and has no Laravel service provider, facade, config file, or validation-rule integration. Adopting it means we own the glue: a service provider binding, a Rule object, exception mapping, and configuration for which countries we accept. That glue is trivial, but it is glue we would write and then maintain forever against an upstream that will never change.

The blocking issue is lifecycle, not code quality. The package is explicitly marked [Deprecated] by its author, with the last release on 2017-04-07. Two consequences matter to a TPM:

1. No correctness maintenance. IBAN validity is data, not just an algorithm. Country format tables change: countries adopt IBAN, lengths are revised, new country codes appear. A frozen 2017 table will silently reject legitimately valid IBANs from jurisdictions that joined or amended after that date, and may accept formats that no longer exist. False negatives here are user-visible ("your account number is invalid") and directly cost conversion at the payment-method step.
2. No security or platform response. There is no maintainer to ship a CVE fix, a PHP 8.3/8.4 compatibility patch, or a Composer constraint update. A 2017 codebase has a high probability of emitting deprecation notices or failing on modern PHP; whether it runs today is something we must test, not assume.

Technical risk assessment. This is a low-severity, high-probability risk. Nothing here is a security boundary — a checksum check is not an authorization control — so a defect does not create a breach. But the failure modes are frequent and business-facing: rejected valid customers, accepted invalid ones that fail downstream at the clearing house (with per-item rejection fees), inconsistent validation between signup and payout, and quiet bit-rot that surfaces as a PHP upgrade blocker. The 60-star count and 1.06 health score corroborate that there is no community to absorb any of this.

Build-vs-buy conclusion. MOD-97 validation plus a country-length table is on the order of 100–150 lines of well-understood, testable code specified by ISO 13616. The package is not buying us meaningful complexity reduction; it is buying us a dependency with a known end-of-life date. A maintainable alternative — a maintained IBAN library, or the IBAN constraint already shipped by Symfony Validator (which Laravel projects can pull in without adopting the full framework) — is a strictly better trade.

Key questions for the team.

• Is this already in the codebase, or proposed? If already shipped, what is the blast radius and how many call sites?
• What is the actual cost of a false negative at each touchpoint (onboarding form, payout setup, batch import)?
• Do we need IBAN validation only, or also BIC resolution, bank-name display, or SEPA reachability? If the latter, this package is insufficient regardless of its status and the evaluation should be reframed around a proper payments-data provider.
• Which countries/currencies must be supported at launch and in 12 months? That determines whether a static table is survivable at all.
• What PHP versions must we support, and does the existing code emit deprecations under them?

Integration Approach

Stack fit. Poor as a direct dependency, fine as a swappable implementation detail. The package has no coupling to Laravel and no opinions about where validation lives, so the correct integration is a thin anti-corruption layer: a IbanValidator interface in our domain (methods such as isValid(string $iban, ?string $country = null) and normalize(string $iban): string), one adapter implementing it against whichever library we choose, and a Laravel service provider binding the interface. Controllers, form requests, Livewire components, and jobs depend only on the interface.

Migration path. Do not adopt jschaedl/iban as new work. For existing usage, treat it as scheduled technical debt with a defined exit:

1. Inventory. Grep for the namespace and any Composer dependents; identify every call site and whether it validates, generates, or both.
2. Characterize. Wrap the current behavior in characterization tests using a fixture corpus of valid/invalid IBANs per country, including edge cases (whitespace/formatting, lowercase, IBANs with spaces, non-IBAN account identifiers that must pass through untouched). This gives us a behavioral baseline and immediately exposes any 2017-table staleness.
3. Abstract. Introduce the interface and adapter, with the existing library as the first implementation. This is a no-behavior-change refactor.
4. Swap. Replace the adapter internals with a maintained library or a small in-house validator (MOD-97 plus a maintained country-length table sourced from SWIFT's IBAN registry). Run the same fixture corpus as an equivalence gate.
5. Remove. Drop the dependency, delete the adapter's legacy branch, and record the decision.

Compatibility considerations. Verify (a) Composer resolves the package under our PHP constraint without --ignore-platform-reqs, (b) no deprecation output under our target PHP and error reporting level, (c) no reliance on removed functions (each, create_function, loose preg_replace /e, PHP 4-style constructors) — all plausible for 2017 code, (d) PSR-4 autoload correctness, and (e) that its transitive dependency set is empty or trivially auditable. Any hard failure on (a) or (b) collapses the migration to "replace now" and should escalate the timeline.

Sequencing and effort. Roughly: 0.5 day inventory and characterization fixtures; 0.5 day interface plus adapter; 0.5–1 day swap and equivalence verification; 0.5 day for a custom Laravel validation rule and documentation. This is a single-sprint item for one engineer, not a project. Two ordering constraints matter: introduce the abstraction before the PHP upgrade that may break the legacy package, and land the country-table decision before any market expansion that adds new IBAN jurisdictions.

Operational Impact

Maintenance. Today the answer is "the vendor does not maintain this; we would." Abandoned dependencies are not free — someone on the team must own an internal fork or a vendored copy, track ISO 13616 / SWIFT registry changes, and re-verify on every PHP and Laravel upgrade. That is a recurring cost disproportionate to a library whose entire scope is a checksum and a lookup table. If the package stays, it should be forked into a private repository (or vendored) with our own version constraint and a named owner, not consumed from Packagist.

Support. No upstream support channel, no issue triage, no security disclosure path. Internal support burden is low in absolute terms — the domain is stable and the surface area is tiny — but any incident is 100% internal, including root-causing a customer's rejected IBAN back to an outdated format table.

Scaling. Computational scaling is a non-issue: MOD-97 on a ≤34-character string is negligible, and validation runs at request time or in batch import with no external calls, no rate limits, no latency budget concerns. The scaling concern is coverage, not throughput — the set of supported countries is frozen and does not grow with the business.

Failure modes to monitor.

• False negative on a valid IBAN — customer blocked at payout setup; most visible and most costly failure. Detect via drop-off analytics on the bank-details step and support-ticket tagging.
• False positive on an invalid IBAN — passes our form, fails at the payment rail; surfaces as rejected payouts, returned payments, and per-item fees. Detect via downstream rejection-rate monitoring.
• PHP upgrade breakage — deprecation notices or fatal errors appearing on framework/runtime upgrades. Detect in CI by running the suite at E_ALL against the target PHP version.
• Inconsistent validation surfaces — different rules in registration, account settings, and batch import; a common and quiet source of customer confusion.
• Silent dependency rot — composer audit finding an unpatched transitive issue with no upstream to fix it.

Ramp-up. Low. The API is a couple of methods and the IBAN specification is well documented and widely understood; a mid-level engineer can be productive in under an hour. The genuine knowledge requirement is not the library but the domain: knowing that country format data decays, that normalized vs. display formatting must be handled explicitly, and that validation and downstream clearance are different gates. That context belongs in a short ADR so the replacement decision isn't relitigated.

Bottom line. Do not adopt. If present, contain it behind an interface this sprint, verify it against a real fixture corpus, and replace it within a quarter with a maintained library or a small in-house validator backed by a current country table. The technical work is trivial; the decision that matters is refusing to inherit a dependency its own author has abandoned.