Weave Code
Sepa Xml Laravel Package
digitick/sepa-xml
PHP library for generating SEPA XML payment files. Build pain.001 credit transfers and pain.008 direct debits with a fluent API, supporting batches, groups, and multiple payment methods for European bank payments.
SEPA file generator in PHP
Frequently asked questions about Sepa Xml
- How do I install and use digitick/sepa-xml in a Laravel application?
- Install it with composer require digitick/sepa-xml, but first confirm the canonical package name, since the repository now lives under the php-sepa-xml GitHub organization. There is no service provider or publishable config, so you call the library directly from your own service or action class. Wrap it behind an application-owned interface such as SepaFileGenerator so controllers, models, and queued jobs never touch package classes.
- Does digitick/sepa-xml support Laravel 10, 11, or 12?
- The library is framework-agnostic plain PHP, so compatibility is driven by your PHP version rather than a Laravel major version. It ships no service provider, no config file, and no framework-native validation. Any recent Laravel app on a supported PHP runtime can use it, but you own the dependency injection bindings, configuration, and wiring.
- How do I generate a pain.001 credit transfer file with multiple transactions?
- Create the credit transfer file through the library facade or the CustomerCreditTransfer objects, add each payment with its amount, IBAN, BIC, and remittance information, then call asXml to get the pain.001 document. Set debtor name, IBAN, BIC, and batch booking on the originating party so the group header is bank-ready. Map internal DTOs into package objects in a thin anti-corruption layer instead of passing Eloquent models straight in.
- How do I build a pain.008 direct debit with mandate details and a creditor identifier?
- Create a CustomerDirectDebitTransferFile, set the creditor identifier, creditor name, and IBAN, then add DirectDebitTransaction objects carrying mandate ID, signature date, sequence type, and amount. Creditor postal address support for pain.008 landed in 3.2.0, and some banks and scheme rulebooks expect that block. Mandate lifecycle, FRST/RCUR/OOFF/FNAL transitions, and amendment history should stay in your application's domain model, not in the XML layer.
- Can I validate the generated SEPA XML against the XSD before sending it to the bank?
- Yes, release 3.2.0 adds optional XSD validation, so you can reject schema-invalid files before bank submission instead of relying on well-formedness alone. Run it as a pre-delivery gate inside the action that produces the file, and fail loudly with a logged error. Keep a known-good sample per bank profile too, because XSD conformance does not guarantee a specific bank's implementation guide is satisfied.
- What is the difference between pain.001 and pain.008, and which one do I need?
- pain.001 is the customer credit transfer message you send to pay money out, while pain.008 is the customer direct debit message you use to collect money under a mandate. Choose pain.001 for supplier or payroll payments and pain.008 for SEPA direct debit collections. Many applications need both, and the package generates each file type independently.
- Is digitick/sepa-xml still maintained, and what happened to the digitick namespace?
- The repository now appears under the php-sepa-xml GitHub organization rather than the original digitick namespace, so confirm the canonical Composer package name and whether the old name is abandoned or aliased before pinning. Release 3.2.0 shows sustained maintainer activity, Dependabot dependency hygiene, and contributions from new maintainers. Adoption signals remain modest, so treat it as a tactical component with a limited bus factor.
- Why did ramsey/uuid move to require-dev in version 3.2.0, and does that break my app?
- ramsey/uuid moved to require-dev in 3.2.0, which reduces the production dependency footprint of the package. If any of your own code implicitly counted on ramsey/uuid being installed transitively through this library, declare it explicitly in your composer.json now. Otherwise the runtime dependency graph is unchanged and existing generation code keeps working.
- How should I test SEPA XML generation in a Laravel test suite?
- Generate golden files for each bank profile and assert byte-for-byte or normalized-XML equality in Pest or PHPUnit. This matters because the PmtTpInf element was dropped in v3.0 and only restored in 3.2.0, so schema-level regressions have reached consumers before. Pair those fixtures with an XSD validation assertion and a check that the payment type information block is present.
- What are the alternatives to digitick/sepa-xml for Laravel projects, and what are the production risks?
- There is no official Laravel wrapper, so the alternatives are third-party Laravel SEPA packages, a hosted payments API, or hand-rolled XML generation. For most teams this adapter approach is sufficient, but pin an exact version, review the LGPL-3.0 terms for distribution or modification, and keep the interface swappable. Before bank certification, verify that the restored PmtTpInf block matches each bank's implementation guide.
Weaver
How can I help you explore Laravel packages today?