Yandexkassa Bundle Laravel Package

Technical Evaluation

Architecture fit: Poor for a Laravel codebase. rispo/yandexkassa-bundle is a Symfony 2/3 bundle, not a Laravel package. It relies on Symfony bundle conventions, dependency injection, service configuration, and likely Symfony HTTP/event components. Laravel has no bundle system, so adoption would require a compatibility bridge or extracting the payment logic into a Laravel-native service.

Integration feasibility: Low as a direct dependency, medium as a reference implementation. The MIT license permits reuse, but installing the bundle into a modern Laravel app would likely create dependency conflicts with PHP 8.x and current Laravel/Symfony components. A TPM should treat it as an old integration example for Yandex Kassa/YooKassa concepts, not as production infrastructure.

Technical risk: High. The last release was 2016-07-09, the package has 14 stars and 0 dependents, and it targets Symfony 2/3-era PHP. Payment APIs, security expectations, webhook handling, and fiscalization requirements have changed significantly since then. Using it directly would increase security, compliance, and maintainability risk. Opportunity score 0.39 supports a cautious “reference-only” evaluation.

Key questions:

• Is the target gateway Yandex Kassa legacy API or the current YooKassa API?
• Which payment methods are required: bank cards, SBP, wallets, recurring payments, refunds?
• What are the fiscalization/54-FZ receipt requirements, if any?
• What Laravel and PHP versions must be supported?
• Who owns merchant credentials, webhook secrets, and reconciliation operations?
• Is PCI scope reduced by hosted checkout/redirect flow, and what evidence is required?
• Is a maintained YooKassa SDK or direct REST integration acceptable?
• What SLA and support expectations exist for payment failures?

TPM recommendation: Do not adopt the bundle as a Laravel dependency. Leverage it only to understand legacy flows, then budget for a Laravel-native YooKassa adapter or a maintained SDK.

Integration Approach

Stack fit: Weak. The package assumes Symfony 2/3 runtime conventions; Laravel uses service providers, facades, config files, middleware, queues, and Eloquent/DB abstractions. Direct installation is not a normal Composer integration path for Laravel.

Migration path: If the goal is Laravel/PHP, reimplement the required gateway behavior behind a Laravel service contract:

• Define a PaymentGateway interface with create, capture, refund, status, and webhook handling.
• Implement a YooKassa adapter using Laravel’s HTTP client and config repository.
• Store payment state, idempotency keys, gateway IDs, and webhook events in application tables.
• Move webhook processing to queued jobs with retries and dead-letter handling.
• Keep the old bundle available only in a sandbox/reference repository for comparison.

Compatibility: Expect PHP 5/7-era assumptions and Symfony 2/3 dependencies. Modern Laravel applications on PHP 8.1+ should assume incompatibility until proven by a time-boxed Composer spike. The package is unlikely to satisfy current security, static analysis, or dependency vulnerability policies.

Sequencing:

1. Confirm gateway contract and account type with YooKassa/Yandex Kassa.
2. Run a sandbox spike using the current YooKassa REST API, not the bundle.
3. Build the Laravel adapter and payment state model.
4. Add webhook verification, idempotency, reconciliation, and refund flows.
5. Parallel-run against sandbox/test transactions and compare legacy behavior.
6. Cut over behind a feature flag and retire the bundle/reference path.

Operational Impact

Maintenance: High burden if adopted directly. The package is unmaintained, ancient by payment-integration standards, and has no dependent ecosystem to surface fixes. Any fork would become internal payment infrastructure owned by the team.

Support: Effectively community-only, with no vendor SLA. YooKassa API changes, deprecations, and security guidance will need to be tracked independently. The 0 dependents and 14 stars indicate limited production validation.

Scaling: Application-side scaling is modest because payment processing is mostly external API calls and webhook handling. The real scaling concerns are queue throughput, webhook retries, idempotency, database consistency, and gateway rate limits, not the bundle itself.

Failure modes:

• Webhook loss, duplication, or out-of-order delivery.
• Double charges or missed captures without idempotency.
• Refund and receipt/fiscalization mismatches.
• Expired or deprecated gateway API behavior.
• Secret leakage through old configuration patterns.
• Dependency conflicts or runtime failures on modern PHP.
• Inability to patch security issues without owning a fork.

Ramp-up: A Laravel team should plan for days to evaluate the reference behavior and one to two weeks to productionize a direct integration with tests, reconciliation, and compliance checks. The bundle may reduce initial discovery time slightly, but it should not reduce the engineering estimate for a production payment flow.