Banking Laravel Package

Product Decisions This Supports

• Swedish market entry (build vs. buy): Adopting this package lets us ship Swedish account entry, payout, and invoice-payment flows without building and maintaining our own clearing-number ranges, Bankgiro/Plusgiro checksum rules, OCR reference validation, and BIC mappings. The entire domain is a thin, immutable value-object layer we'd otherwise own forever.
• Payment flow hardening: Validating clearing + account number, Bankgiro, Plusgiro, OCR references, and BIC before submission cuts failed transfers, returned payments, and manual reconciliation — the most expensive failure mode in a payments product.
• Data migration and onboarding: Normalizes messy legacy inputs (CSV/ERP exports, free-text form fields) into consistent formats and surfaces descriptive exceptions we can turn into actionable user errors.
• Metadata for UX and routing: Bank-name/BIC extraction from clearing numbers supports account-confirmation screens, payout routing, and fraud-signal enrichment.
• Roadmap enablement: Unblocks a Swedish payouts/invoicing milestone without diverting engineering into domain-primitive work; the adapter we'd wrap it in becomes the seam for a future in-house or vendor implementation.
• Platform compatibility (updated): Release 2.2.3 adds PHP 8.0 support and raises the floor to PHP 7.3. That removes the "can't run on our runtime" objection for PHP 8.0-era Laravel, but does not yet cover PHP 8.1/8.2/8.3 — relevant if our target Laravel version (10+) mandates 8.1+.
• Use cases: invoice payment links (OCR/Plusgiro), direct debit and payout APIs, accounting exports, KYC/onboarding forms, reconciliation pipelines, and back-office tooling.

When to Consider This Package

Consider adopting when:

• We operate in or transact with Sweden and handle SEK payouts, Bankgiro/Plusgiro payments, or OCR-referenced invoices.
• The stack is PHP / Laravel on PHP 7.3–8.0, where a Composer value-object library drops in cleanly. Release 2.2.3 explicitly targets this range and modernizes the test harness (PHPUnit 9).
• We need local validation and canonical formatting — not live account verification — and want descriptive exceptions we can map to user-facing errors.
• Correctness of the domain rules matters more than breadth of features.

Look elsewhere or plan to fork when:

• We need non-Swedish coverage, generic IBAN/SEPA validation, or live account-ownership checks (PSD2/open-banking APIs) — this library is offline validation only.
• We run PHP 8.1+ (Laravel 10/11). 2.2.3 is a compatibility patch, not a forward-compatibility commitment; we should verify it installs and behaves on our runtime, or budget a small patch of our own.
• We require an SLA, guaranteed security patching, or an actively maintained roadmap. 2.2.3 shows a maintainer is still alive and shipping, which softens the earlier "abandoned since 2020" read — but one patch does not equal a support commitment. Bank mergers and clearing-range changes may still post-date the domain data.
• We're not on PHP, or we want a managed service rather than vendored code.
• Licensing (Unlicense): essentially public domain, so legal friction is minimal — but so are warranties. Treat it as code to vendor and own, not a supported dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, free, public-domain PHP library that encodes the validation rules for Swedish bank account, clearing, Bankgiro, Plusgiro, OCR, and BIC data. Using it de-risks our Swedish payment flows and speeds time-to-market by removing weeks of domain-rule development, at zero licensing cost. A recent release (2.2.3) adds PHP 8 support, so it fits our current runtime and the project is not wholly dormant. It remains a low-activity, single-maintainer library without an SLA, so we plan to vendor and own it, backed by our own tests and a compatibility check against our PHP version — a modest, bounded engineering commitment rather than an open-ended dependency.

To engineering: Immutable value objects, descriptive exceptions, and a comprehensive test suite — a clean fit to wrap behind a single internal SwedishBankingValidator/adapter interface so the dependency stays swappable. Release 2.2.3 is a maintenance drop, not a feature release: PHP 8.0 support, minimum bumped to 7.3, PHPUnit 9 for the build. No API or behavior changes, so our integration surface is unaffected. Recommend pinning to 2.2.3 or later, vendoring the source, confirming our PHP/Laravel combination (notably 8.1+) is actually covered rather than merely installable, adding coverage for clearing ranges and banks that changed since the last domain update, and isolating exceptions at the adapter boundary so error messages remain ours to control. No runtime services, no API keys, no network calls — low operational footprint. License is Unlicense, so there is no legal obstacle to forking if upstream goes quiet again.