Symfony Revolta Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a payment/banking integration layer. The bundle is best understood as a thin Symfony integration wrapper for the Revolta (Rvlt Digital) API — HTTP client wiring, service container configuration, request/response mapping, possibly webhook controllers. A PM weighing it is really deciding whether to adopt a pre-built adapter or have engineering write and own a small client directly. At this maturity level (0 stars, 0 dependents, last release October 2020), the "buy" option is effectively a code donation, not a vendor relationship — you inherit the code and the maintenance.

• Roadmap input for adding a payment rail. Useful as a spike/scoping artifact: reading the bundle's service definitions and DTOs is a fast way to size the surface area of a Revolta integration (auth, payouts, FX, webhooks) before committing roadmap capacity. Treat it as a reference implementation for estimation, not a dependency.

• Feature scoping for marketplace payouts, multi-currency collection, or card/expense workflows. If the product direction involves Revolta as merchant-of-record or payout rail, the bundle sketches the object model (accounts, transactions, counterparties) that product specs will need to speak in.

• Framework standardization decision. Despite being catalogued in Laravel/PHP tooling, this is a Symfony bundle, not a Laravel package. That surfaces a real product question: do we standardize on framework-agnostic integration code (a standalone client consumed by both Laravel and Symfony services), or accept framework-coupled adapters? The package's existence argues for keeping the core client framework-agnostic and treating bundles as optional sugar.

• Dependency-risk triage / tech-debt register. It is a concrete example to point at when setting policy on abandoned dependencies (no release in ~5 years, no community, no security response path). Useful for a "third-party risk" line item on a platform roadmap.

When to Consider This Package

Consider it only under a narrow set of conditions:

• The team is on Symfony 4/5 with PHP 7.x, and Revolta is already a committed vendor decision — the bundle is not a reason to pick the vendor.
• You need a one-to-two day spike or internal prototype, and reading an existing adapter is cheaper than reading the vendor's API docs from scratch.
• You are prepared to vendor/fork it into your own repo, pin it, and assign an owner, with a written plan to replace it with a direct API client or a maintained SDK.
• You want a reference for interface design (service names, DTO shapes) rather than a runtime dependency.

Look elsewhere when:

• Production payment paths are involved. No releases since 2020 means no fixes for API changes, no PSD2/SCA/3DS updates, no webhook idempotency hardening, and no one to page. Payment code with an unmaintained dependency is an audit and incident-response liability.
• You are on Laravel. A Symfony bundle does not drop in; you would be pulling Symfony components into a Laravel app or bypassing the bundle entirely. Use the vendor REST API through an HTTP client (e.g., Saloon) or an official/postman-derived SDK instead.
• You need SLAs, support, or security disclosure handling. Zero dependents and zero stars means no community backpressure and no realistic expectation of maintenance.
• A maintained alternative exists — an official vendor SDK, an Omnipay/generic gateway driver, or a plain typed client your team owns — for roughly the same integration effort.
• You require modern PHP/Symfony versions, typed properties, or PHP 8 attributes; expect to do the upgrade work yourself.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-style Symfony adapter for the Revolta API that could shave a few days off a payment integration — but it has had no release since October 2020, no stars, and no downstream users, which means no one is maintaining it. Recommendation: fund a short spike (1–2 engineer-days) to mine it for design and effort estimates, and explicitly keep it off any critical payment path. It is an accelerator, not a foundation. If Revolta becomes strategic, we budget for either an owned internal client or the vendor's official SDK.

To engineering: Treat it as reference source. Pull it, read the service wiring and DTOs, and use it to size the real integration. If we adopt any of it, fork it into our monorepo, pin the version, add tests around auth/webhook handling, and log an owner and a replacement trigger. Note it is Symfony-specific — in a Laravel codebase the correct move is a standalone HTTP client against the vendor API, with the bundle used only as a spec.

To the vendor/partnership conversation: Ask Revolta for their current official SDKs, versioning policy, and deprecation notices — the existence of only one stale community bundle from 2020 is a signal to confirm their integration story before we commit.