- Is rispo/yandexkassa-bundle a Laravel package?
- No. It is a Symfony 2/3 bundle that wraps the official yandex-kassa PHP SDK so the payment client can be registered in the Symfony dependency injection container. Laravel has no bundle system, no bundle configuration loader, and no equivalent container extension mechanism, so this package does not integrate with Laravel the way a Laravel package would. Treat it as a Symfony integration, not a Laravel one.
- Can I install rispo/yandexkassa-bundle in a Laravel application with Composer?
- Composer may resolve the package, but it targets Symfony 2/3-era components and PHP 5/7 assumptions, so you should expect dependency conflicts with PHP 8.1+ and current Laravel or Symfony releases. Any attempt should be a strictly time-boxed spike in a throwaway sandbox, never a supported production path. For most modern Laravel applications the install will fail or pull in unmaintained transitive dependencies.
- Which Laravel and PHP versions does rispo/yandexkassa-bundle support?
- None officially. The bundle targets Symfony 2/3 and the PHP versions of that era, and its last release was 2016-07-09. Modern Laravel applications running PHP 8.1 or newer should assume incompatibility until proven otherwise. Even if it installs, you inherit old assumptions about HTTP handling, container wiring, and error reporting.
- How do I configure the Yandex Kassa shop ID and secret key with this bundle?
- In Symfony you set the shop ID and secret key in the bundle configuration file, which the bundle loads into container parameters used by the client service. Laravel has no equivalent bundle configuration layer, so a port would mean moving those credentials into config/services.php and environment variables. Either way, keep secrets out of version control and rotate them if they were ever committed.
- How do I create a payment and check its status with this bundle?
- You inject the configured client service from the container and call the underlying SDK methods to create a payment and query its status. The bundle's job is mostly wiring the SDK client and API as services, not modelling payments for your application. You still need to persist payment IDs, idempotency keys, amounts, and status transitions in your own database, and in Laravel you would do that through Eloquent and a service provider binding.
- Does the bundle handle YooKassa webhooks and payment callbacks for me?
- No. It provides Symfony service wiring for the SDK client; it does not ship Laravel routes, controllers, middleware, or queue jobs for HTTP notifications. You must build the webhook endpoint yourself, including verification of the notification source, idempotent event handling, retries, and dead-letter handling for failed jobs. That logic is exactly where most production payment bugs appear, so it deserves dedicated tests.
- Is rispo/yandexkassa-bundle maintained and safe for production use?
- The package is effectively abandoned: last release 2016-07-09, roughly 14 stars, zero dependents, and no vendor SLA or security process. Payment APIs, security expectations, webhook signing, and 54-FZ fiscalization requirements have changed considerably since then. Adopting it directly would create compliance, security, and maintainability risk, and any fork would become internal payment infrastructure your team owns forever.
- What should a Laravel developer use instead of this bundle for YooKassa payments?
- Build a Laravel-native adapter around the current YooKassa REST API using Laravel's HTTP client, config repository, and queue system, or wrap a maintained YooKassa SDK in a service provider. Define a PaymentGateway contract with create, capture, refund, status, and webhook-handling methods so the gateway stays swappable. Store payment state, gateway IDs, and idempotency keys in your own tables, and run webhook processing through queued jobs with retries.
- Can I use rispo/yandexkassa-bundle as a reference implementation for a Laravel integration?
- Yes, and that is the sensible use of it. Read the bundle and its SDK calls to understand legacy Yandex Kassa flows and naming, then reimplement against the current YooKassa API instead of copying the old service wiring. The MIT license permits reuse of code and patterns, but the glue is Symfony-specific and the payment API details are outdated. Budget for a rewrite rather than a port.
- Does using a hosted YooKassa checkout flow reduce PCI scope compared with this bundle?
- A redirect or hosted checkout flow keeps card data off your servers, which meaningfully reduces PCI scope, but that property comes from the gateway flow, not from this bundle. You are still responsible for webhook verification, reconciliation, refunds, partial captures, and receipt or fiscalization handling under 54-FZ where applicable. Decide the flow and evidence requirements with your merchant account owner before choosing any package.