- Does jongotlin/bank-account-bundle work in a Laravel application?
- Not natively. Despite the Composer name, this is a Symfony bundle: it ships a bundle class, a dependency injection extension, a config tree and Symfony Validator constraints, none of which Laravel's container discovers or executes. Composer will install it without errors, but the package will sit inert in your vendor directory. For Laravel you should skip the bundle entirely and integrate the framework-agnostic jongotlin/bank-account library behind your own service provider and validation rule.
- How do I install jongotlin/bank-account-bundle?
- You would run composer require jongotlin/bank-account-bundle, and in a Symfony app you would then register the bundle in bundles.php or config/bundles.php. In Laravel there is no equivalent registration step that would activate its services, so installation alone accomplishes nothing. If you only want the validation logic, require the underlying jongotlin/bank-account library instead and wire it yourself.
- Which PHP and Laravel versions are supported?
- The package targets Symfony, so its compatibility matrix is expressed against Symfony and PHP versions rather than Laravel releases. There is no published Laravel support statement, and no Laravel service provider is included to bind it. Verify the library's PHP floor and ceiling against your runtime before considering it, because the bundle inherits that constraint transitively.
- Can I use it as a Laravel validation rule for IBAN and BIC fields?
- Not directly. The bundle exposes Symfony Validator constraints, which are a different contract from Laravel's ValidationRule interface, so you cannot drop them into a FormRequest rules array. The practical path is to depend on the underlying library and write a small custom rule class that calls it and returns a boolean or throws. That wrapper is roughly fifty lines of code and keeps vendor classes out of your application layer.
- Does the bundle validate IBAN and BIC, or only Swedish domestic account numbers?
- Treat the marketing description as unverified. The overview claims IBAN checksum validation and BIC/SWIFT verification, while the supporting technical assessment describes Swedish domestic account numbers — clearing number plus account number, Bankgiro and Plusgiro — with no IBAN or BIC generation. Those are materially different capabilities with different implications for SEPA relevance. Read the source and confirm before you commit to any roadmap item that depends on it.
- How do I configure supported countries and account number formats?
- Configuration is done through the Symfony config tree exposed by the bundle's DI extension, typically in config/packages with a bundle-specific key. That mechanism is Symfony-only and has no meaning inside a Laravel application, where configuration lives in config files read through the config repository. If you write your own Laravel wrapper, expose the country and format options as your own config keys so the vendor API stays swappable.
- Is jongotlin/bank-account-bundle safe and actively maintained for production use?
- The signals are weak: zero stars, zero dependents, a single maintainer, and no visible CI or security disclosure process. Correctness risk is medium-to-high because Swedish account validity is clearing-number dependent, and a stale range table produces false negatives that block legitimate payouts. The MIT licence is your mitigation, since it lets you fork and pin a reviewed copy. Treat the code as untrusted until someone on your team has read it.
- What should I use instead for IBAN validation in Laravel?
- Use the framework-agnostic jongotlin/bank-account library, or a dedicated IBAN package, bound behind your own BankAccountValidator interface rather than referencing vendor classes directly. That way an in-house replacement is a container binding rather than a refactor. Expose it to two consumers: a validation rule for form and API input, and a value object for storage. Before choosing, confirm whether your payout rail is domestic Bankgirot/Autogiro or SEPA, because that decides whether the package is load-bearing or a form-validation nicety.
- How do I test bank account validation in my Laravel test suite?
- The logic here is pure string arithmetic with no I/O, no deserialisation and no external calls, so tests are fast and deterministic. Use published test vectors with known-valid and known-invalid accounts rather than generating numbers yourself, and assert both the pass and fail paths. Also pin down the library's error contract, boolean versus exception, since that determines how your rule reports failures. Cover the clearing-number ranges explicitly, because that is where false negatives hide.
- What happens if the maintainer abandons the package — can I fork it?
- Yes. The MIT licence permits forking, patching and redistribution, so the supply chain risk is recoverable rather than fatal. The real cost is domain ownership: someone internally must own Swedish payments knowledge and be able to verify clearing ranges and checksum rules against a citable source such as Bankgirot or Bisnode test vectors. Decide now whether the standing response to abandonment is to fork or replace in-house, not during an incident.