Symfony Revolta Bundle Laravel Package

Getting Started

Before you write a line of code, check compatibility. This bundle's last release was October 2020, has zero dependents, and no stars. That means the fastest path is:

composer require rvlt-digital/symfony-revolta-bundle

Watch for a conflict on symfony/framework-bundle, symfony/http-client, or guzzlehttp/guzzle — a 2020 bundle will pin old constraints and may refuse to install on Symfony 5.4/6.x/7.x. If composer require fails, try composer require rvlt-digital/symfony-revolta-bundle --with-all-dependencies and be ready to fork and bump the constraints yourself.

Enable the bundle. On Symfony Flex it registers automatically in config/bundles.php. On older versions add it manually:

// config/bundles.php
RvltDigital\RevoltaBundle\RevoltaBundle::class => ['all' => true],

Find the configuration key. Don't guess the YAML tree — inspect the bundle's DependencyInjection/Configuration.php in vendor/rvlt-digital/ first. A typical payment bundle exposes something like:

# config/packages/revolta.yaml
revolta:
    api_key: '%env(REVOLTA_API_KEY)%'
    environment: 'sandbox' # usually 'test'|'sandbox'|'production'
    # optional: timeout, base_uri, webhook_secret

Find the services it actually registers — this is the single most important first step, because the README may be stale:

bin/console debug:container Revolta
bin/console debug:container --tag=revolta
bin/console debug:config revolta

First use case: create a payment and redirect the customer. Inject the client/service into a controller, create a payment/transaction, and redirect to the hosted checkout URL the provider returns. That "create → redirect → handle return" loop is the 90% use case; everything else (refunds, status checks) is secondary.

Implementation Patterns

Constructor injection of the client. The bundle almost certainly registers a client or manager service. Autowire it:

public function __construct(private RevoltaClientInterface $revolta) {}

If autowiring fails because the service isn't aliased to an interface, either alias it in your own services.yaml or inject the concrete class (debug:container tells you the service id).

Payment creation + redirect pattern. Keep the controller thin: build a request DTO, call the client, persist your own Order/Payment record with the provider reference before redirecting, then redirect to the returned checkout URL. Persisting first means you can reconcile even if the customer abandons before returning.

Return/callback handling. Follow the standard hosted-checkout pattern:

• A return_url controller that handles the browser redirect and shows the result.
• A separate webhook/callback controller that processes status notifications.
• Mark your order as paid only from the server-side notification, never from the browser return alone.

Environment switching. Wire sandbox vs production from %kernel.environment% or an env var so the same code path works in dev/CI/prod. Test credentials usually come from the provider's dashboard, not the bundle.

Integration into an existing payment flow. Wrap the bundle behind your own PaymentGatewayInterface, so CreatePaymentAction depends on your abstraction, and the bundle is one adapter. This is essential for an unmaintained dependency — it lets you swap to a direct HTTP client later without touching controllers.

Gotchas and Tips

• This is a Symfony bundle, not a Laravel package. If you're working in Laravel, you cannot use it as-is. There is no service provider bridge, no config/revolta.php auto-publishing, and no container auto-registration. You'd either (a) pull the bundle's underlying HTTP/SDK logic out manually, or (b) skip the bundle and call the Revolta REST API with Laravel's Http facade. The second is usually faster and safer.
• Abandonment risk is the headline issue. No releases since Oct 2020, zero stars/dependents. Expect unmaintained transitive dependencies (old Guzzle, old symfony/http-client) with known CVEs. Run composer audit after install and be prepared to fork (vcs repository in composer.json) to patch.
• Don't trust the README's config keys. For a 2020 zero-download bundle, docs drift from the Configuration.php node names. Use debug:config revolta to confirm the real tree before debugging a "config not found" error.
• Debugging webhooks: log the raw request body and headers before any parsing/signature check. If signature validation fails, compare the raw body bytes against what you signed in the sandbox — reordered JSON keys break HMACs.
• Idempotency: payment providers retry webhooks. Persist the provider's transaction/event id and short-circuit on duplicates, or you'll double-credit orders.
• Timeouts and retries: a 2020 HTTP client default may be 0 (infinite) or very short. Set explicit timeouts in config; wrap the client call in a try/catch for connection exceptions and show a "payment unavailable" path rather than a 500.
• Extension points: the bundle likely only registers a client + config. Business logic (order state, refunds, reconciliation) is yours to build. Treat the bundle as a thin transport layer and keep your domain code provider-agnostic.
• Escape hatch: the package is small. If constraints block install or a CVE lands, replacing it with a 50-line HttpClient wrapper around the documented Revolta REST endpoints is a low-risk, often faster move — plan your abstraction so this swap is a one-file change.