Php Iban Laravel Package

Product Decisions This Supports

• Bank account capture at onboarding (payouts, refunds, payroll, expense reimbursement). Validate IBAN structure, country, length and checksum at the point of entry rather than at first payout. This shifts a class of failures from "payment bounced three days later" to "inline form error" — a measurable reduction in failed disbursements and support tickets.
• Payout corridor expansion without per-country engineering. 116 supported countries (including non-SEPA: MENA, West Africa, Latin America, plus dependent territories like Faroe Islands, Réunion, French Guiana) means adding a new market is a configuration and compliance conversation, not a parser build. This directly informs roadmap sequencing for international seller/creator payouts.
• SEPA and IIBAN use cases. SEPA credit transfer and direct-debit mandate collection need IBAN validation plus BBAN/bank/branch extraction for mandate storage and XML generation. IIBAN (the AA "Internet" scheme) is relevant if we ever accept PSP-issued identifiers.
• Data enrichment for operations and compliance. Extracting country code, bank code, branch/sort code, national currency (ISO 4217), and central bank name/URL feeds KYC review queues, routing logic, sanctions-screening scoping, and finance reconciliation — without calling a third-party API.
• Input error correction as a UX feature. Mistranscription suggestions ("did you mean…") and human/machine format conversion are cheap wins on a form where users copy long alphanumeric strings off paper statements. Also reduces the classic 0/O and 1/I failure mode.
• Safe display and support tooling. Obfuscation supports PII minimization in support screens, screenshots and logs — a small but real data-protection decision that costs nothing to adopt.
• QA and test fixtures. The bundled example-IBAN database lets us write deterministic tests for every supported country instead of hand-crafting fake account numbers.
• Build vs buy decision: this is a "don't build" call. Mod-97 checking, per-country length/format rules, national checksum algorithms, and registry drift are tedious, low-differentiation work. Adopting a library here is the default; the genuine build-vs-buy question is whether we need account verification (name/ownership match) on top, which this package explicitly does not do.
• It is a library, not a vendor. No network calls, no per-verification fee, no PII leaving our infrastructure, no contractual dependency. That keeps unit economics flat and simplifies procurement/DPA review.

When to Consider This Package

Adopt when most of these hold:

• The product is PHP/Laravel, and IBAN validation is needed in-app (validation rule, form request, cast, or domain service).
• We need breadth of countries more than depth of bank metadata: multi-country IBAN parse/validate/format plus checksum error-correction.
• We need offline, deterministic validation with no per-call cost or third-party data-sharing — attractive for finance, health, or regulated environments.
• We accept LGPL-3.0: fine for commercial use as an unmodified Composer dependency, but it must clear our OSS policy — and any fork/patched copy we distribute carries copyleft obligations. Confirm with legal before vendoring or modifying.
• We are willing to pin the version, wrap it behind our own interface (a IbanValidator/BankAccount value object), and own the upgrade and regression-test cadence for the countries we actually operate in.

Look elsewhere when:

• We need account ownership verification or bank-name/BIC resolution — this is structural validation only. Pair it with a verification vendor, or choose a vendor that bundles both.
• Registry freshness is a hard requirement. The README states it is aligned to the SWIFT registry as of the January 2020 release (PDF #86). Markets that joined or changed formats since then may be missing or wrong, and the "unofficial" country entries are best-effort. For a payments-critical surface, verify the specific countries on our corridor list.
• Supply-chain policy demands multi-maintainer, security-policy-backed dependencies. This is a long-running single-maintainer project. The metadata also shows dependents: 0, which contradicts the README's ~7M install claim — resolve that discrepancy (Packagist stats, actual transitive usage) before treating it as well-exercised inside our stack.
• We need SEPA scheme-specific validation beyond IBAN (creditor identifier, mandate rules, scheme rulebook conformance) or full ISO 20022 message validation — use a SEPA/ISO 20022 library instead.
• We want a framework-native implementation with no wrapper work. Framework validator integrations exist elsewhere; this is a procedural + OO library that we would wrap ourselves (which is also its main advantage: minimal surface area, zero dependencies).
• The consuming service is not PHP — the logic is not portable as code, so standardize elsewhere.

How to Pitch It (Stakeholders)

To executives (one paragraph): For a single Composer dependency under a license that is free for commercial use, we can validate and error-correct international bank account numbers for 116 countries entirely inside our own systems — no vendor contract, no per-check fee, no customer bank data leaving our infrastructure. Expected impact: fewer failed payouts and refunds, faster onboarding in new payout markets, and cleaner data in finance and compliance queues. The risk is not cost or privacy; it is maintenance (a single maintainer and a registry baseline from 2020), which we contain by pinning the version, wrapping the library, and validating our specific corridors before launch.

To engineering: Zero runtime dependencies, small API surface, both procedural and OO entry points, and a bundled fixture database of per-country example IBANs for tests. Recommended integration: one composer require, one thin adapter (a Laravel validation rule plus a BankAccount value object exposing country, bank code, branch, account number, currency), then all call sites depend on our interface, not the library. Add regression tests for our supported country list and a CI check that fails if a fixture stops validating. Note the README's own "comedy of errors" documentation of SWIFT registry defects — treat the library as the source of truth for parsing but not for regulatory compliance.

Ask / decision needed: (1) Legal sign-off on LGPL-3.0 use as an unmodified dependency, with a written note on no-vendoring/no-patching. (2) Agreement that IBAN validation is not a substitute for account verification, so the payments roadmap must fund both. (3) Owner named for dependency and registry-freshness review each quarter.