Weave Code
Payment Bundle Laravel Package
kitano/payment-bundle
Symfony bundle that brings payment processing into your app, wrapping multiple payment gateways behind a shared service interface so you can configure providers, create payments, and handle callbacks and status updates with minimal boilerplate.
This bundle is a generic paymentBundle. It manages the payment flow of a payment system. You can use this PaymentBundle with another bundle for one specific payment system (Ex: KitanoPaymentSipsBundle, KitanoPaymentFakeBundle,...)
Frequently asked questions about Payment Bundle
- Can I use kitano/payment-bundle in a Laravel application?
- Not directly. This is a Symfony bundle whose extension model is kernel/bundle registration and the Symfony DI container, with persistence handled by a Doctrine PaymentInstruction entity. Nothing in the repository targets illuminate/*, so there is no service provider, publishable config, facade, or Eloquent binding. Reaching parity in Laravel would mean re-registering the orchestration services, bridging events to Laravel's dispatcher, and rewriting the manager and persistence layer against Eloquent, which is re-platforming rather than integration.
- What does Kitano Payment Bundle actually do?
- It adds a payment abstraction layer that wraps multiple payment gateways behind a shared service interface. You configure supported payment methods and gateways, initiate a payment through a unified service, redirect the customer to the provider, and handle the callback to update order or payment status. The core asset is the generic payment-instruction state machine (new, pending, completed, canceled, failed) with provider-specific adapters behind a PaymentSystemInterface.
- How do I install and configure Kitano Payment Bundle in a Symfony app?
- You would add kitano/payment-bundle through Composer, register the bundle in your kernel, and define your payment methods and gateways in the bundle configuration. The orchestration services, adapters, and the Doctrine-backed payment instruction persistence are then wired through the Symfony container. Expect PHP 5.x and Symfony 2.x era conventions such as PSR-0 autoloading, so modern projects will likely need patching before anything runs.
- Which payment gateways does Kitano Payment Bundle support?
- The repository provides adapters for SIPS/Atos and a Fake gateway intended for development and testing flows. The architecture is pluggable, so additional providers are added by implementing the PaymentSystemInterface and registering the adapter with the container. Any other gateway, Stripe included, is your own implementation rather than something shipped by the package.
- Is Kitano Payment Bundle compatible with PHP 8 and current Symfony versions?
- Compatibility is unproven. The bundle was authored in the PHP 5.x and Symfony 2.x era, so you should expect PSR-0 autoloading and deprecated constructs that require patching before it will run on PHP 8. It is a poor fit even for Symfony 3 or 4 and later, since the scaffolding predates the modern bundle structure. Realistically it fits only a legacy Symfony 2 application that already runs it.
- Is it safe to use Kitano Payment Bundle in production for real payments?
- Treat that as high risk. The project has around 7 stars and zero dependents, meaning no downstream consumers exist to surface defects through real usage, and there is no CVE monitoring or escalation path if something breaks. Payment orchestration sits inside PCI-DSS scope and moves money, so adopting it means owning a security-critical component with no upstream accountability. The practical problem is not that the code is bad, it is that nobody is accountable for code in the money path.
- Does Kitano Payment Bundle handle payment callbacks and order status updates?
- Yes, that is the core flow it was built around: initiate a payment, redirect to the provider, then process the callback and update the payment or order status. Status transitions follow a generic lifecycle of new to pending to completed, canceled, or failed, driven by gateway responses. What is not demonstrated is explicit idempotency for capture, refund, and callback replay, so verify that before relying on the flow.
- What should I use instead of Kitano Payment Bundle in a Laravel project?
- For Laravel, laravel/cashier with Stripe or Paddle covers the common subscription and one-off payment cases with maintained tooling. If you need many providers behind one API, league/omnipay offers the same generic-flow-plus-adapter design with maintained drivers and PSR-3 and PSR-18 alignment. If a specific acquirer such as SIPS is a hard requirement, wrap that provider's official SDK behind a thin first-party PaymentGateway contract instead of resurrecting a stale orchestrator.
- Can I reuse the payment abstraction design without adopting the bundle?
- Yes, and that is the realistic option: port the pattern, not the package. Implement a PaymentGateway contract with provider-specific adapters, an explicit payment state machine, an append-only audit log, and idempotency keys on every mutating gateway call. Bind it through a Laravel service provider and persist with Eloquent models that preserve the state-transition guarantees. This keeps you outside the legacy bundle while retaining the architectural value.
- Is Kitano Payment Bundle actively maintained and does it have a test suite?
- Maintenance is the main open question: last commit date, license, and whether any maintainer responds to issues should be checked before anything else. The absence of dependents is itself a finding, since no downstream consumers means defects surface only in your application. A reusable fake-gateway harness in the test suite would be the one part genuinely worth porting, so confirm whether it exists and is usable.
Weaver
How can I help you explore Laravel packages today?