Sepa Payment Bundle Laravel Package

Product Decisions This Supports

• EU payments expansion / roadmap sequencing. This package supplies the commodity half of SEPA collections: IBAN validation, creditor mandate records, SEPA Credit Transfer (pain.001) and SEPA Direct Debit (pain.008) file generation. It lets you put "collect in EUR via direct debit" on the roadmap with a credible, low-cost path instead of a bespoke payments build.
• Build vs. buy, split three ways. Decide explicitly which layer is ours:
  • Adopt/borrow: IBAN validation (checksum + per-country BBAN structure) and XML serialization — zero differentiation, high spec-churn.
  • Own, behind a wrapper: mandate lifecycle (creditor identifier, mandate reference, signature date, sequence types FRST/RCUR/OOFF/FNAL), retry/dunning, reconciliation. This is where your support tickets, chargebacks and audit exposure live.
  • Not covered here — plan for it: inbound reconciliation (camt.053), R-transactions (rejects/returns/refunds), mandate amendments (bank change), multi-scheme (BACS/ACH).
• Use cases to evaluate it against: subscription billing, invoice/receivables collection, B2B payment terms, refunds via credit transfer.
• Falsifies "we need a payments engine." A 1–2 sprint spike against this codebase is enough to answer whether the XML layer is a build item at all. That's a cheap decision input, not a commitment.
• Framework-strategy signal (important). Despite the brief's "Laravel/PHP" framing, this is a Symfony bundle (PHP ≥8.1, Symfony 6/7/8, DI extension, form types, Twig). If the product is Laravel-first, this package is not a decision lever — the decision becomes "pick a Laravel-native or framework-agnostic SEPA library," and the evaluation criteria below still apply.

When to Consider This Package

Adopt-consider when:

• The stack is Symfony 6/7/8 on PHP ≥8.1 and you want SEPA file generation wired through native DI/forms rather than glued in ad hoc.
• You are EU-only, direct-debit-led, and small enough that no one owns payments full-time.
• You can treat the code as acquired source, not a vendor dependency — i.e. you're willing to pin a version, vendor/fork it, and add contract tests against your bank's test environment.
• You need a fast, readable reference implementation of pain.001/pain.008 and mandate fields to validate your own data model.

Look elsewhere when:

• You're on Laravel or framework-agnostic PHP. Wrong abstraction; use a standalone library instead.
• You need initiation, not just file generation (PSD2/open banking, instant payments), reconciliation, or multi-scheme support.
• Procurement requires a vendor, SLA, or named support — this has none.
• You need maturity signals: 1 star, 0 dependents, single maintainer, low composite score (~20/100). Code quality may be fine; ecosystem risk is real, and money-moving code has a bad failure mode. Only proceed if you can absorb ownership.
• You cannot own a fork. Without that, you're exposed to abandonment mid-mandate-lifecycle.

How to Pitch It (Stakeholders)

Executives: "This isn't a vendor contract — it's a shortcut through the boring 60% of EU direct debit: IBAN checks and bank-file formatting. It could save us a couple of engineer-weeks and de-risk the roadmap date. The catch is maturity: one maintainer, near-zero adoption, no support. We mitigate by forking it, pinning it, and testing against our bank — so the real ask is a one-week spike, not a production bet. Low lock-in, reversible."

Engineering: "MIT, thin, Symfony-native (auto-wired services, compiler passes, form types). Use it behind our own interfaces — MandateRepository, PaymentFileGenerator — so it never leaks into the domain model and a swap is a day's work. It's the starting point, not the architecture: we still own mandate state transitions, sequence-type correctness (a wrong FRST/RCUR is a rejected collection), audit trail, and reconciliation intake. Add golden-file tests and validate output in the bank sandbox before anything ships."

Finance / Compliance: "The library formats files; it does not certify them. Creditor Identifier validity, mandate evidence retention, signature capture, and scheme-rule conformance remain our obligations. Budget time for a compliance review of generated output, not just a code review."

The decision to ask for: approve a 1-week technical spike (sandbox validation + a thin wrapper + golden-file tests). Outcomes: adopt behind a wrapper, fork, or build the ~400 lines ourselves. Do not approve production use on the strength of the package alone — the opportunity score (~38/100) says the market gap is real, the low overall score says this implementation is unproven.