Bank Account Bundle Laravel Package

Product Decisions This Supports

• Sweden market entry scoping. If Sweden is on the roadmap, this package makes concrete the data-quality requirement behind payouts, invoicing, refunds, and Autogiro (Swedish direct debit): validating and formatting Bankgiro, Plusgiro, and clearing+account numbers before money moves. Use it as a scoping input to size the work — not as a shipping dependency.
• Build vs. buy vs. borrow for payment-detail validation. The domain logic — clearing-number ranges per bank, mod-10/mod-11 checksums, formatting — is small but bank-specific and easy to get subtly wrong. This repo is a useful reference implementation when deciding whether to hand-roll a validator, fork the logic, or lean on a PSP SDK.
• Feature enablement for payout and onboarding flows. Marketplace seller onboarding, vendor AP, refunds, and subscription billing via Autogiro all depend on correct Swedish account details. Validating at capture reduces failed payouts, returned direct debits, and manual CS remediation.
• Data-model decisions. Informs whether to persist normalized and formatted forms, store clearing numbers separately from account numbers, and how to represent Bankgiro vs. Plusgiro vs. regular accounts.
• Risk scoping for payment-path code. A zero-star, zero-dependent, single-maintainer package sitting on the payment path is itself a decision input: it tells you to budget for owning the logic (fork or reimplement) rather than depending on it.

When to Consider This Package

Consider it when:

• You operate in or are entering the Swedish market and need to validate and format Bankgiro, Plusgiro, or clearing+account numbers.
• You only need validation and formatting — not IBAN/BIC conversion, account ownership verification, or payment initiation.
• You are willing to vendor the core validator/formatter logic rather than install the bundle as-is. This is a Symfony bundle, not a Laravel package: its DI extension, service definitions, and Symfony Validator constraints will not drop into a Laravel app. In Laravel you would depend on the underlying jongotlin/bank-account library and wrap it in a custom validation rule.
• You want a cheap starting point and will back it with your own test suite against published test vectors.

Look elsewhere when:

• Maturity matters. Zero stars, zero dependents, single maintainer, no security disclosure process, no visible CI signal — a bus factor of one. For anything touching money movement, treat it as untrusted code by default.
• You need Laravel-native integration. Expect to reimplement the wiring; do not budget for "just composer require."
• You need IBAN/BIC handling, account verification, or payment rails. Use a maintained IBAN library or your PSP's SDK (Stripe, Adyen, Klarna, Tink) instead.
• You are not in the Swedish market.
• You need audited, supported code. The low opportunity score and absence of downstream usage are red flags for production payment flows.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free (MIT) helper for validating Swedish bank account numbers, relevant only if we pursue Sweden. Its value is as a reference for the domain logic, not as an approved dependency: it has no community, no downstream users, and a single maintainer. Recommendation: fund a short 1–2 day engineering spike to review and reimplement the validation rules in-house with tests, rather than depending on an unmaintained third-party package on the payment path.

For engineering: The reusable assets are the clearing-number ranges, the checksum logic (mod-10/mod-11/none), and the formatting rules. The Symfony bundle plumbing is unusable in our Laravel stack — depend on the underlying jongotlin/bank-account library and wrap it behind our own BankAccountValidator interface, exposed as a Laravel ValidationRule for input and a value object with normalised()/formatted() accessors so display formatting never leaks into persistence. Add a golden-file test corpus per bank clearing range and checksum edge case, run the validator in shadow mode against live account data before enforcing, and assign a named owner for the annual clearing-number table review. Mask account numbers in logs and error trackers from day one — they are financial PII — and keep an ops override path for legitimate accounts the validator rejects.