- Can I use e2k/payment-bundle in a Laravel application?
- No, this is a Symfony bundle, not a Laravel package. It registers through Symfony's bundle system and Symfony Flex, and its gateway services are wired into the Symfony container, so there is no Laravel service provider or config publishing to hook into. Laravel teams would have to wrap the underlying gateway classes themselves rather than installing it as-is. If you need a first-class Laravel integration, treat this repository as reference code for the CentralBill API instead of a drop-in dependency.
- How do I install e2k/payment-bundle with Symfony Flex?
- Run composer require e2k/payment-bundle. With Symfony Flex installed, the bundle is registered automatically and you can go straight to creating config/packages/e2k_payment.yaml. No entry in config/bundles.php is required in that case.
- How do I register the bundle manually without Symfony Flex?
- Install it with Composer, then add E2K\PaymentBundle\E2KPaymentBundle::class => ['all' => true] to the array returned by config/bundles.php. After that, create the e2k_payment.yaml configuration file and set the matching environment variables.
- Which Symfony and PHP versions does this bundle support?
- The bundle targets Symfony 6.4 and 7.x and requires PHP 8.2 or newer. Check your composer.json constraints before upgrading, since running it on Symfony 5.x or PHP 8.1 is not supported.
- How do I configure the CentralBill gateway?
- Create config/packages/e2k_payment.yaml and define the centralbill entry under gateways with application_id, application_secret, web_pay_base_url, callback_url and redirect_url, and set enabled to true. Point each value at an environment variable using Symfony's %env()% syntax rather than hardcoding credentials. The application_id and application_secret come from your CentralBill account, and the web_pay_base_url is the CentralBill web payment endpoint for your integration.
- How do I keep payment credentials out of my codebase?
- Every configuration value in e2k_payment.yaml is a reference to an environment variable, so secrets live in your .env file, server environment, or secret manager rather than in version control. Set PAYMENT_DEFAULT_GATEWAY, PAYMENT_ROUTE_PREFIX, and the CENTRALBILL_* variables in each environment. Only the YAML skeleton, which contains no secrets, is committed.
- How do I change the default gateway or the payment route prefix?
- Set the default_gateway and payment_route_prefix options in e2k_payment.yaml, typically sourced from PAYMENT_DEFAULT_GATEWAY and PAYMENT_ROUTE_PREFIX environment variables. The default gateway decides which provider handles a payment when none is specified explicitly, and the route prefix controls where the bundle's payment endpoints are mounted. Keep the prefix consistent with your firewall and routing rules so callbacks and redirects are not blocked.
- Can I add a payment gateway other than CentralBill?
- Yes. The bundle is built around a shared gateway interface with CentralBill as the bundled implementation, so additional providers are added by implementing that interface and registering the service. Because consuming code depends on the abstraction rather than the concrete gateway, your controllers and services should not need to change. Start by mirroring the CentralBill implementation to see the expected method signatures and configuration keys.
- How do I test payments safely before going live?
- Use CentralBill sandbox credentials and a non-production web_pay_base_url in your staging environment, and point callback_url and redirect_url at staging routes that are reachable from the internet. Exercise a full payment, then verify the callback handling and the redirect back to your application. Also test refunds and any partial capture flows, because those often surface amount unit issues that a single successful charge hides.
- What changed in version 1.1.5 regarding amount handling, and should I re-verify my integration?
- Version 1.1.5 is a patch release whose single pull request aligns amount handling between the gateways, so the change sits in the adapter layer rather than your application code. A patch version number does not prove behavioral compatibility here: subunit mismatches such as kobo versus major units produce silent 100x errors instead of exceptions. Pin explicitly to 1.1.5 during verification, run sandbox transactions through each gateway and currency you use, and confirm refunds, partial captures and stored amounts still match intent. Add a regression test asserting the expected unit per gateway before rolling out.