Product Decisions This Supports
- Brazil market entry / monetization roadmap. Iugu is a Brazilian payments and billing provider (credit card, boleto, Pix, subscription invoices, payment links, marketplace split). Any decision to sell in BRL, charge recurring subscriptions, or pay out sellers in Brazil runs through a provider like Iugu. This package is a thin Symfony wrapper over the Iugu PHP API client — its only product value is shortening the time to first API call, not adding capabilities.
- Build vs. buy vs. wrap. Use this package's existence as a data point in the "adapter layer" decision: do we write our own billing abstraction (provider-agnostic interface + Iugu driver), or adopt a pre-built wrapper? The wrapper here is ~2016-era and unmaintained, so the honest answer is "neither — integrate the official Iugu SDK behind our own interface." The package is useful mainly as a reference implementation of which Iugu objects (customers, invoices, subscriptions, payment tokens, transfers) a billing domain model needs to cover.
- Scope of the first billing release. Reading the bundle's exposed services maps cleanly to a v1 feature set: customer creation, one-off invoice/charge, subscription creation and cancellation, payment tokenization (so card data never touches our servers), and webhook handling for status changes. That's a credible MVP; everything else (dunning, proration, tax, multi-currency) is v2.
- Compliance and risk posture. Because it delegates to Iugu's tokenization, the decision it supports is "stay out of PCI scope by never storing PANs" — a product constraint that shapes checkout UX (hosted/tokenized fields vs. custom form).
- Explicitly not supported: Laravel. This is a Symfony bundle — it registers services via a DI extension and expects Symfony's kernel. For a Laravel product it is not a drop-in dependency; the underlying
iugu-php client is the reusable part, and even that should be evaluated for currency.
When to Consider This Package
Consider it only if all of the following hold:
- The application is Symfony (not Laravel), and on a PHP/Symfony version contemporaneous with 2016 — the bundle predates Symfony 4/5/6 autowiring conventions and will likely need a shim or fork to boot.
- You are doing a time-boxed spike or proof-of-concept to validate Iugu as a provider, and you want DI wiring for free rather than writing a service provider.
- You are maintaining a legacy Symfony codebase that already depends on it and the cost of migration exceeds the cost of carrying it.
- You accept that you are vendoring/forking it: no releases since 2016-09-27, zero stars, zero dependents means no upstream support, no security patches, and no community answers when it breaks.
Look elsewhere — and you almost certainly should — when:
- You are on Laravel. Use the official
iugu/iugu-php client wrapped in a Laravel service provider and facade, or call the REST API directly via Http:: with your own typed DTOs. This is 100–200 lines and gives you testability, retries, and logging the bundle never had.
- You need modern PHP (8.x), typed properties, PSR-18 HTTP clients, or static analysis. The 2016 dependency tree will fight you.
- You need current Iugu capabilities — Pix, split payments for marketplaces, newer webhook signature verification, updated API versions. A 2016 wrapper cannot reflect API surface added after it was abandoned.
- Reliability and auditability matter. Payments code needs an owner, a changelog, and a CVE response path. Zero dependents means no one else is exercising these code paths in production.
- You want provider portability. Even the official SDK should sit behind your
PaymentGateway interface, so switching to Stripe/Pagar.me/Asaas is a driver swap, not a rewrite.
How to Pitch It (Stakeholders)
To executives: We need a Brazilian payments/billing provider to sell in BRL and handle boleto, Pix, and recurring charges. Iugu is a credible option. This specific package — a 2016 Symfony wrapper with no stars, no dependents, and no release in roughly a decade — is not something we should put in production; it's an unmaintained third-party dependency in the most sensitive part of our stack (money movement). The recommendation is to integrate Iugu's official SDK directly, behind our own thin billing interface, which costs roughly the same effort, carries far less risk, and lets us switch providers later without touching product code. I'm using this package only as evidence of what a v1 billing integration needs to cover, not as a dependency.
To engineering: Don't add hugomn/iugu-bundle. It's Symfony-only, so it doesn't fit our Laravel app; it hasn't shipped since 2016; and it has zero downstream users, so we'd be the only ones finding its bugs. Proposed instead: a Billing domain module with a PaymentGateway contract, an IuguGateway implementation over iugu/iugu-php (or raw HTTP calls through Laravel's client), typed request/response DTOs, idempotency keys on charge creation, queued webhook processing with signature verification, and contract tests against Iugu's sandbox. Estimated 1–2 sprints for MVP scope (customers, one-off charges, subscriptions, webhooks). The bundle's service list is a decent checklist for what to model.