Yandexkassa Bundle Laravel Package

Product Decisions This Supports

• Market entry / checkout for Russian customers. Yandex Kassa (rebranded YooKassa in 2018) is one of the two or three default payment gateways for RUB billing — cards, Sberbank, wallets. This package represents one historical integration path for that gateway inside a PHP e-commerce or subscription flow.
• Framework scope correction. Despite the brief describing a "Laravel/PHP package," this is a Symfony 2/3 bundle (RispoYandexKassaBundle). It cannot be installed into a Laravel application as-is and would need a bridge layer. Any roadmap item assuming drop-in Laravel support should be closed or re-scoped.
• Build vs. buy (historically). The bundle bundled payment-request construction, signature/checksum handling, and callback handling — the tedious, error-prone parts of a Kassa integration. In 2016 it plausibly saved 1–3 engineer-weeks.
• Legacy maintenance triage. The only live decision this supports today is: do we keep, patch, or replace the payment layer in an existing Symfony 2/3 app? The 2016-07-09 last release, 14 stars, and 0 dependents make this a "vendor-at-risk" line item, not a strategic investment.
• Not a differentiator. Payments are table stakes; no product roadmap priority should be allocated to adopting this package versus using the vendor's official SDK.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an existing Symfony 2.3–3.x application on PHP 5.6–7.0, and the integration is already wired in.
• Your Kassa contract is on the legacy protocol (the checkOrder / deposition / XML-notification era) and the gateway has not yet forced a migration on you.
• You have a concrete audit confirming the bundle's checksum/signature logic matches your current merchant configuration.
• You have in-house PHP capacity to own the code outright — it is effectively a fork, not a dependency.

Look elsewhere — emphatically — if any of the following apply:

• Laravel or any non-Symfony stack. No compatibility; you would be porting, not adopting.
• New build. Use the official YooKassa PHP SDK (yookassa/yookassa-sdk-php) or the vendor's REST API v3 directly. It is maintained, documented, and covers the current protocol.
• PHP 7.4+ / 8.x. A 2016 Symfony 2/3 bundle will not survive modern PHP without real work; expect fatal errors and unmaintained transitive dependencies.
• Security, PCI-DSS, or compliance-sensitive scope. 14 stars, no dependents, no visible CI or test suite, no security contact, and eight years of silence is a supply-chain risk in the highest-risk part of your codebase.
• You need current Kassa features — SBP/QR, recurring payments, 54-FZ fiscalization receipts, payout/split, or webhook signature verification — none of which existed in 2016.

How to Pitch It (Stakeholders)

For executives: There is no business case for adopting this package. It is an eight-year-old Symfony 2/3 bridge to a payment provider that has since rebranded and changed its API. It has 14 stars, no downstream dependents, and no release since July 2016 — meaning no security patches, no PHP 8 support, and no one to call when it breaks. Payments is the single highest-consequence integration in a commerce product; an unmaintained dependency there is an unquantified revenue and compliance exposure. Recommendation: do not adopt. If it is already in a legacy system, budget a 2–4 week replacement with YooKassa's official SDK and fund it in the current quarter, not at the next incident.

For engineering: Treat this as reference reading only — a compact illustration of the legacy Kassa handshake (signature construction, callback shape) that can inform a migration spec. Do not vendor it. The maintained path is the official YooKassa PHP SDK against REST API v3, wrapped behind your own PaymentGateway interface so the next gateway swap is a day, not a quarter. Concretely: define the interface, port the existing checkout/refund/webhook flows, add signature-verification tests with the vendor's sandbox, and keep the legacy bundle pinned in a branch until the old traffic drops to zero.

Risk summary if we proceed anyway: unmaintained code in the payment path, no framework or PHP-version support, likely protocol obsolescence, zero community to absorb bugs, and the migration cost paid later at incident-driven urgency and premium rates.