Yandexkassa Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. That is the single most important fact to internalize before anything else. There is no Rispo\YandexKassaBundle\YandexKassaServiceProvider, no config/yandexkassa.php, no facade, no Illuminate\Support\ServiceProvider registration. composer require rispo/yandexkassa-bundle will happily install the code, but Laravel's container will not autowire anything, and there is no bundle concept to register.

Where to look first, in order:

1. RispoYandexKassaBundle.php — the bundle entry point. It exists only to satisfy Symfony's Bundle interface. It will tell you nothing about payments.
2. DependencyInjection/ — the Configuration.php and RispoYandexKassaExtension.php describe the actual config keys (shop ID, scart / secret key, callback URLs). This is the closest thing to "documentation" in the repo.
3. Resources/config/services.xml (or .yml) — this is where the real wiring lives. Read it to discover which service IDs are defined and which classes they map to. Those class names are what you would port.
4. The underlying client classes it wraps — usually a thin HTTP client around Yandex Kassa's REST API (payment creation, order status, refunds).

Realistically, your "first use case" for a Laravel project is not to install this bundle but to (a) read it as a reference implementation, or (b) skip it entirely and use a maintained PHP SDK such as yookassa/yookassa-php-sdk, which is framework-agnostic and works fine inside a Laravel service.

If you are in a genuine Symfony 2/3 legacy app, then the first use case is: register the bundle in app/AppKernel.php, configure rispo_yandex_kassa: in config.yml with your shop ID and secret, and inject the payment service into a controller. But that is the Symfony path, not yours.

Implementation Patterns

Because you cannot consume the bundle directly, the practical patterns fall into two buckets: porting and replacing.

Porting the bundle's logic into a Laravel service. The bundle's classes are plain PHP; the Symfony coupling is all in DI and config. A workable pattern:

• Create a small App\Services\YandexKassa\ namespace.
• Copy the client classes (the ones that build payment requests and parse responses) verbatim — they usually have no Symfony dependencies.
• Replace the Symfony service definitions with a config/yandexkassa.php file and a single YandexKassaServiceProvider that binds a configured client singleton.
• Map the config keys you found in DependencyInjection/Configuration.php (shopId, scart, callback URLs, test/live mode) to env() calls.

Replacing with a modern SDK. This is the pattern most Laravel developers should actually follow:

• composer require yookassa/yookassa-php-sdk
• Register a singleton client in a service provider, pulling credentials from config('services.yookassa.*').
• Create payments in a controller or dedicated PaymentService; handle the webhook (Yandex calls your notification_url) in a controller that verifies the event and dispatches a queued job.
• Yandex Kassa was rebranded to YooKassa and the API moved to v3. The 2016 bundle targets the older v1/v2-era endpoints, which will not match current docs at yookassa.ru/developers. Any code you port must be rewritten against the current API.

Workflow you'll be re-implementing either way:

1. Build a payment object (amount, currency, capture flag, description, metadata, confirmation.return_url).
2. POST to the payments endpoint with Idempotence-Key (a UUID per logical payment).
3. Redirect the user to the returned confirmation.confirmation_url.
4. Receive the webhook POST on your notification_url, fetch the payment by ID to confirm status (never trust the webhook body alone), and update your order row.
5. Handle refunds by POSTing to the refunds endpoint with the payment ID.

Integration tips. Keep the idempotence key tied to your own order ID so a retried job does not double-charge. Store the Yandex payment ID on your orders table so webhooks and refunds can be correlated without guessing. Gate the webhook route with CSRF exception in VerifyCsrfToken and return 200 fast — Yandex retries on non-2xx.

Gotchas and Tips

It is abandoned. Last release was 2016-07-09, 14 stars, zero dependents. Nothing in that repo is being maintained against a payment API that has changed multiple times since. Do not put it on a production payment path in a new project.

It is not installable-usable in Laravel the way you'd expect. Even after composer require, nothing is bound in the container. If you try app(RispoYandexKassaBundle::class) you'll get a resolution error or an unconfigured object. The services.xml/services.yml wiring is Symfony-only.

PHP and Symfony version constraints will fight your Composer resolver. A 2016 Symfony 2/3 bundle will pin symfony/* to ^2.7|^3.0 ranges and possibly PHP ~5.5|~7.0. Installing it into a Laravel 10/11 project on PHP 8+ will either refuse to install or drag in ancient Symfony packages you do not want. If you must inspect it, do so in a scratch directory, not in your app's composer.json.

The API endpoints are stale. Yandex Kassa → YooKassa rebrand, API v3, different auth (Basic auth with shopId + secret key still, but different object shapes), different notification format. Any endpoint URLs or request bodies in the 2016 code should be treated as historical reference, not as a spec.

Configuration lives in Symfony YAML conventions. DependencyInjection/Configuration.php uses the Symfony Config component with TreeBuilder, scalarNode, arrayNode etc. Reading it is fine, but do not try to feed Symfony-style config arrays into Laravel's config() — you need to translate the tree into a flat array yourself.

Debugging a port: the bundle's HTTP layer is the only place worth setting breakpoints. Log the raw request body and response from the payment creation call; most integration bugs are mismatched field names (amount.value as a string vs. float, missing Idempotence-Key header, wrong currency code casing).

Extension points you might want (and won't get from the bundle in Laravel): a webhook event class + listener so you can fan out to multiple handlers, a PaymentGateway interface so tests can swap in a fake, and a queued job for webhook processing so you respond with 200 before doing DB work. None of these exist in the bundle — plan to write them.

Recommendation: treat rispo/yandexkassa-bundle as a reading reference for how someone once modelled Yandex Kassa objects in PHP, and build your Laravel integration on yookassa/yookassa-php-sdk behind your own service provider and webhook controller. You'll spend less time fighting Symfony compatibility than porting dead code.