Symfony Revolta Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental ecosystem mismatch. Despite the request framing, this is not a Laravel/PHP package; it is a Symfony bundle (RvltDigital\SymfonyRevoltaBundle). Bundles are coupled to Symfony's HttpKernel, the DependencyInjection component (Extension classes, Configuration trees, compiler passes), and auto-registration via config/bundles.php. Laravel has no bundle concept — it uses service providers, its own container contract, and PHP-array config. None of the bundle's wiring layer transfers. What may transfer is the underlying payload: an HTTP client wrapper, DTOs, and request-signing/auth logic. That is the only part worth evaluating.

Integration feasibility — low as-is, moderate as a source to mine. Using it directly would require an adapter package that reimplements the bundle's YAML configuration semantics in PHP, rebinds services into Laravel's container, and replaces any Symfony event-subscriber or security-layer hooks. If the reusable core is a few hundred lines of API glue (likely for a payment-initiation wrapper), the adapter costs more than extracting the client and discarding the bundle plumbing.

Technical risk — high, concentrated in two places.

• Version ceiling. Last release 2020-10-27 implies Symfony 4.x/5.x and PHP 7.2–7.4-era constraints. Laravel 10/11 requires PHP 8.1+, so Composer will either refuse to resolve or will pull abandoned transitive dependencies. Forcing installation with --ignore-platform-reqs invites runtime deprecations and type errors on PHP 8.2+.
• Unmaintained code on a money path. 0 stars, 0 dependents, no releases in ~5 years means no community validation, no security review, and no issue triage. Payments code amplifies every defect: a missing idempotency key or unverified webhook signature becomes a reconciliation incident, not a bug ticket.

Key questions to resolve before any commitment:

1. Is the target PSP Revolut Business, or an internal "Revolta" gateway? This determines whether an official SDK already exists (in which case the bundle is redundant).
2. Which API version is pinned, and is it still served by the provider?
3. Does it implement idempotency keys, webhook signature verification, and refund/partial-refund flows — or only payment initiation?
4. What are the actual composer.json constraints for php, symfony/framework-bundle, and Guzzle? Guzzle 6 vs 7 is a common hard conflict with modern Laravel dependency graphs.
5. Who owns maintenance upstream, and is there a private fork with fixes not published?

Integration Approach

Stack fit. Three viable paths, in order of preference:

1. Use the PSP's official PHP SDK, if one exists. The bundle's only value-add is Symfony DI wiring; if the provider ships an SDK or a documented REST API, this package contributes nothing but a stale dependency.
2. Extract and repackage. Pull the client, DTOs, and signing logic into a Laravel-native package with a ServiceProvider, a config/revolta.php file, and a facade. This is the realistic path if no official SDK exists.
3. Symfony sidecar. Run the bundle in a minimal Symfony service exposing an internal HTTP endpoint. Only justified if the organization already operates Symfony services and wants to avoid reimplementing auth/signing. Otherwise it adds a network hop and a second runtime for one integration.

Migration path. There is no migration — nothing depends on this package, so there is no incumbent to move off. If a team has already vendored it, extract the client first, ahead of any PHP 8 upgrade deadline.

Compatibility checklist. Verify PHP constraint, Symfony constraint, PSR-7/PSR-18 adoption, Guzzle major version, and whether the bundle registers global middleware or event listeners that would leak into a host application. Any of these can turn a "simple" install into a dependency-resolution fight.

Sequencing.

1. Confirm PSP choice and official SDK availability (blocks everything else).
2. Read the bundle source end-to-end — inventory reusable classes vs. Symfony-specific glue.
3. Build or borrow a thin Laravel wrapper; keep the config surface minimal (credentials, sandbox flag, timeout, retry policy).
4. Write contract tests against the PSP sandbox covering success, decline, timeout, duplicate-submit, and webhook replay.
5. Roll out behind a feature flag with a single low-value payment path first.

Operational Impact

Maintenance — you will own this permanently. Zero stars, zero dependents, and no release since October 2020 is a clear signal: treat it as vendored source code, not a dependency. Fork it into your own org, pin the commit SHA, and budget engineering time for PHP, Laravel, and Guzzle upgrades. There will be no upstream fixes to pull.

Support. No community, no issue triage velocity, no Stack Overflow corpus, no published changelog. Escalation path during an incident is "read the source at 2 a.m." For a payments integration, that is a measurable on-call cost and a strong argument for owning a wrapper your team actually wrote.

Scaling. The package itself will not be the throughput bottleneck — it is HTTP glue in front of the PSP, and the provider's rate limits plus your retry/idempotency design dominate. The failure modes that matter are semantic, not volumetric:

• Duplicate charges from retries without idempotency keys.
• Unverified or replayable webhooks.
• Timeouts with no circuit breaker, cascading into request-queue backpressure.
• Currency and rounding bugs (minor-unit handling) that silently corrupt ledgers.

Audit each of these explicitly before go-live; do not assume a 2020-era wrapper handles them.

Ramp-up. Low for a Symfony developer — the bundle conventions are familiar and the source is small. Moderate for a Laravel team, which must map YAML config to PHP config and rebind services into a different container. Allocate roughly half a day of source reading plus a day of sandbox testing before any production estimate.

Recommendation: do not adopt as a dependency. Treat it as a reference implementation — mine the API client and signing logic, discard the bundle layer, and either wrap it in a Laravel-native package you own or use the PSP's official SDK. The opportunity score of 15.39 reads correctly: wrong ecosystem, past end-of-life, and in a domain where unmaintained code carries financial rather than merely cosmetic risk.