- How do I install jschaedl/iban in a Laravel application?
- Install it with Composer by running composer require jschaedl/iban. The package is framework-agnostic and does not ship a Laravel service provider, facade, config file, or validation rule. You can call its classes directly from a controller, form request, or a small custom service class. Because the package is deprecated, treat the install as a temporary or legacy dependency and wrap it behind your own interface.
- Is jschaedl/iban deprecated and still safe to use?
- Yes, the package is explicitly marked Deprecated by its author, with its last release on 2017-04-07. It has no maintainer to ship security fixes, PHP compatibility patches, or updated Composer constraints. The validation logic itself is not a security boundary, but using it in production carries business risk from stale country data and bit-rot on modern PHP. Prefer a maintained alternative for new work.
- How do I validate an IBAN with jschaedl/iban in PHP?
- The library checks that a string is a structurally valid IBAN by verifying the country code and country-specific length and by running the ISO 7064 MOD-97-10 checksum. In Laravel you would call it from a form request, a custom validation rule, or a domain service rather than relying on a built-in rule. Keep the call behind an IbanValidator interface so you can swap the deprecated package later.
- Does jschaedl/iban provide a Laravel validation rule?
- No. The package has no Laravel service provider, facade, config file, or validation-rule integration, so you must write the glue yourself if you want a rule object. That glue is small, typically a custom Rule class that delegates to the library and maps failures to user-facing messages. The lack of a rule is one reason many teams choose a maintained IBAN validator instead.
- How do I generate an IBAN for testing with jschaedl/iban?
- The library can generate valid IBANs from a country and account details, which is useful for test fixtures, seeders, and demo data. It is not intended to create real account numbers or production payout data. Use generated values only in tests and staging, and assert against your own validation layer.
- Which countries and IBAN lengths does jschaedl/iban support?
- It uses a country format table frozen at the package's 2017 release, so it supports the IBAN countries and lengths known at that time. Countries that adopted IBAN later, or whose formats were revised after 2017, may be rejected or mishandled. Because IBAN validity is data as well as an algorithm, you should verify the supported country list against your launch and 12-month market requirements.
- What are good alternatives to jschaedl/iban for Laravel?
- A maintained IBAN library is the better choice for new projects, and Symfony Validator's IBAN constraint can be pulled into a Laravel project without adopting the full framework. For broader payment needs, consider a payments-data provider that also covers BIC lookup, bank-name resolution, and SEPA reachability. If you only need MOD-97 validation plus a country-length table, about 100 to 150 lines of tested code is a reasonable build-vs-buy alternative.
- Does jschaedl/iban work with PHP 8 and Laravel 10 or 11?
- The package was last released in 2017, so PHP 8.3 and 8.4 compatibility is not guaranteed and must be tested rather than assumed. It may emit deprecation notices or fail under modern PHP versions, and there is no maintainer to publish a patch. If you keep it, pin your PHP version in CI and wrap it so you can replace it quickly.
- Can jschaedl/iban look up BIC, bank names, or SEPA reachability?
- No. The package only validates IBAN structure and generates test IBANs; it has no BIC lookup, no bank-name resolution, no account-number derivation, and no SEPA, EMIR, or PSD2 logic. If your product needs those capabilities, this package is insufficient regardless of its deprecated status. Reframe the evaluation around a proper payments-data provider.
- How should I test IBAN validation in a Laravel app using jschaedl/iban?
- Test at your own boundary: a custom rule or IbanValidator service should accept known-valid IBANs, reject bad checksums and wrong lengths, and return clear error messages for forms and API responses. Include cases for every country you support, plus countries added after 2017 to expose the stale table. Add a PHP version matrix in CI so an upgrade failure from the 2017 codebase is caught before production.