laravel-boleto: boletos, remessas and retorno files for Brazilian banks

Three file formats: slip, remittance and return

The scope of the package is narrow and specific to the Brazilian banking system. The README describes it as a package for generating boletos, remessas and reading retorno files. A boleto is the payment slip a customer pays at a bank branch, by ATM or through online banking, and the remessa is the file an account holder sends to the bank listing the slips to be issued. The retorno file travels the other way, carrying the payment status of slips the bank has processed. That closed loop of slip, remittance and return is the entire domain of this package. It is not a payment gateway integration and it does not talk to bank APIs, it produces and consumes files in the formats banks expect, which means the hard part of any such integration is usually the file specification rather than the transport.

Bank coverage is visible in the repository topics

The repository topics give a clearer picture of the supported banks than the short README does. The tag list names bancoob, banrisul, bradesco, cef, hsbc, itau, santander, sicoob and sicredi, and it includes cnab as a separate tag, which points at the CNAB layout used by some Brazilian banks rather than a single unified format. Each of those banks has its own file layout, its own field positions and its own validation rules, so the number of tags is a reasonable proxy for how much of the code is per bank format. The repository also carries logos/, which points at per bank assets, and manuais/, which is where the bank manuals for the file layouts would live. The README itself does not enumerate the supported banks or document the field layouts, so the manuals directory and the documentation site at laravel-boleto.readthedocs.io are where the real specification lives.

PHP 7.2 and Laravel 6 are the stated baselines

Two compatibility statements in the README frame how the package is meant to be used. The first says the project has been updated for PHP 7.2 and tells you to always use the latest PHP version, which reads like a nudge to run a current runtime rather than a floor. The second says support covers Laravel 6 onward, so the package sits on the modern side of the framework boundary, which is unusual for a package whose own scaffolding still targets an old runtime. The development container makes that split visible: the Dockerfile is built FROM php:7.3.25-fpm-alpine3.11, and the docker-compose file mounts the project into a service named laravel.boleto with a bridge network and a tty enabled. A php:7.3 base image is long out of support, so if you adopt this you should rebuild the image on a supported PHP version rather than shipping the one in the repository.

The container needs the extensions the file formats rely on

The Dockerfile is short but it documents the runtime requirements precisely. It starts from the PHP FPM Alpine image and installs openssl, bash, unzip, vim, libzip-dev, zlib-dev, libsodium-dev, icu-dev and libpng-dev, then configures and installs the zip, sodium, intl and gd extensions and enables zip and sodium explicitly:

RUN docker-php-ext-configure intl
RUN docker-php-ext-install zip sodium intl gd
RUN docker-php-ext-enable zip sodium

Sodium is the interesting one, since the crypto library is what makes libsodium functions available, and zip plus intl cover archive handling and locale aware formatting, which is what a bank file layout with accented names and date formats tends to need. The image also pulls in the Composer installer and ends with EXPOSE 9000 and an entrypoint of php-fpm, so the container is a PHP process rather than a CLI. Composer itself runs inside the mounted project directory, which is how the compose file is meant to be used: as a PHP environment with your package checked out, not as a running application.

Two PHPUnit configurations and a style fixer

The repository has a tests/ directory and, unusually, two PHPUnit configuration files: phpunit.xml and phpunit_gt_81.xml. The naming convention of the second one implies it targets PHP versions greater than 8.1, so the project runs its suite in two shapes, presumably because assertions and error behaviour differ across those versions. There is also a .php-cs-fixer.php at the root, which means the code style is enforced by a tool rather than by convention, and a .phpunit configuration is accompanied by a build workflow badge in the README pointing at a GitHub Actions build workflow. For a package handling money, the presence of two test configurations and a fixer is a reasonable signal about the project's habits. It is not a signal about coverage, since the README says nothing about how much of the package the tests cover.

Manuals, examples and a documentation site

The repository carries three documentation directories that split the audience. docs/ is the developer documentation, manuais/ holds the bank manuals, and exemplos/ holds usage examples, with the Portuguese name for examples confirming the project is maintained for Brazilian developers. The README links to a separate documentation site hosted at laravel-boleto.readthedocs.io, so the readthedocs project is the primary place to read how the package is configured and used. The division matters in practice, because the two hard problems are different. Understanding the API is a documentation problem, and the docs directory handles that. Producing a file a specific bank will accept is a specification problem, and the manuals directory handles that, since each bank publishes its own layout document and the package has to follow it exactly.

Version 0.11.2 shipped in 2026 after a quiet 2024

The release history is uneven. Version 0.11 was tagged on 2024-03-20, version 0.11.1 on 2024-04-29, and then there is a long gap before 0.11.2 on 2026-04-29, with the last push on 2026-07-10. The package sits below version 1.0, which is the usual signal that the public API may still move. The README also asks for donations and sponsors to help fund part of the development, listing individual supporters and offering PayPal and PagSeguro, which is worth knowing if you plan to depend on the package: continued maintenance partly depends on funding rather than on a company behind it. The licence is MIT, which is permissive and fine for commercial use, so the licensing position is not the risk here. The risk is cadence, and the fact that the maintainer is one person.

Editorial conclusion

Adopt laravel-boleto if you run a Laravel application that has to issue Brazilian bank payment slips or exchange remessa and retorno files with a bank, and you accept depending on a package whose stated baseline is PHP 7.2 with Laravel 6 support. Do not adopt it for a greenfield PHP 8 project without checking the dependency and test setup, and do not treat it as a general banking integration layer, since it is scoped to the boleto file formats. Verify first which bank formats your package version actually supports against the manuais/ directory, run the phpunit.xml suite and the phpunit_gt_81.xml suite that exists for newer PHP, and confirm that the generated files satisfy your bank's specification before you rely on them for settlement.

Frequently asked questions

Official sources

1. eduardokum/laravel-boleto on GitHub
2. Issues
3. License: MIT
4. README
5. Releases