Robokassa Bundle Laravel Package

Technical Evaluation

Architecture fit

• Framework mismatch is the headline. karser/robokassa-bundle is a Symfony bundle (DI extension + KarserRobokassaBundle), not a Laravel package. It has no service provider, no publishable config, no facade, and no Laravel-idiomatic contracts. In a Laravel codebase it is not installable in the normal sense — it is source material.
• It is an adapter over a second abandoned abstraction. The bundle implements JMSPaymentCoreBundle's PaymentSystem/PaymentInstruction model. That means adopting it imports two EOL layers (JMS Payment and Symfony 2/3-era DI) to solve what is fundamentally a ~300-line HTTP + signature problem.
• Actual transferable value is protocol knowledge, not code. The reusable asset is the documented shape of Robokassa's flow: InvoiceURL redirect, ResultURL server callback, SuccessURL/FailURL returns, InvId correlation, and the signature construction over MerchantLogin:OutSum:InvId:Password. Roughly 80% of the package's worth is that specification; 20% is implementation.
• No first-class webhook/durability model. There is no idempotency, replay protection, retry queue, or reconciliation job. For a TPM this matters more than the bundle's internal elegance — those are exactly the gaps that produce payment incidents.
• Architecturally, the right fit is a port/adapter. If your Laravel app already or should define a PaymentGateway interface with vendor-neutral DTOs (PaymentIntent, CallbackResult, ReconciliationRecord), Robokassa becomes one adapter among several (YooKassa, Tinkoff, Stripe). The bundle can inform that adapter; it cannot be it.

Integration feasibility

• Composer constraints almost certainly block modern PHP. Expect php: ^5.6 || ^7.0 and symfony/symfony: ^2.8 || ^3.0 in composer.json. Verify directly — this is a 10-minute check that gates the whole decision.
• The gateway itself is simple, so reimplementation risk is low. Robokassa's core flow is a signed redirect and a signed GET/POST callback. A native Laravel implementation is a controller, a signature service, and a job.
• Effort asymmetry is decisive. Reading and hardening someone else's 2018 Symfony code costs more than writing 300 lines you fully control and can test.

Technical risk

• Abandonment (high). Last release 2018-04-12; single maintainer; 16 stars; 0 dependents. There is no community pressure to patch security or protocol drift. Opportunity score 0.34 corroborates low strategic value.
• Compliance risk (high, if selling in Russia). 54-FZ fiscalization requires receipt payloads — line items, VAT rates, payment method/object — passed with the payment request (typically as URL-encoded JSON in the receipt parameter). A 2018 bundle almost certainly predates or under-supports this. This is a potential hard blocker, not a nice-to-have.
• Protocol drift (medium). Robokassa has expanded signature algorithms (MD5/SHA256/SHA512), added SBP and recurrent payment flows, and evolved callback semantics. Validate the bundle's assumptions against current merchant-cabinet documentation before trusting any detail.
• Security surface (medium). Legacy PHP payment code frequently uses loose comparison for signature validation and lacks timing-safe comparison or replay/InvId uniqueness enforcement. Assume you must re-audit rather than inherit.
• Licensing is clean (low risk). MIT — forking, vendoring, and commercial use are unencumbered. This is the package's best attribute.

Key questions

1. What are the exact composer.json constraints (PHP, Symfony, JMS Payment)? Does it run at all on PHP 8.x?
2. Is the target market Russia/CIS, and does the merchant require 54-FZ receipts and SBP? (If yes, the bundle is likely non-viable as-is.)
3. Are we greenfield on Laravel or migrating a legacy Symfony 2/3 app that already uses this bundle?
4. Do we need recurring/auto-payments, refunds, or partial refunds — and does the bundle expose them?
5. What is our webhook durability requirement, and does Robokassa retry failed callbacks? What is the retry schedule?
6. Is there an internal PaymentGateway abstraction already, or would this be the first?
7. Who owns payment code long-term — is there an engineer who can own a forked/hardened adapter?
8. Are there tests, CI, or static analysis upstream? (Assume no until proven otherwise.)

Integration Approach

Stack fit

• Recommended posture: reference-only. Treat the repository as a protocol cheat-sheet and a validation oracle for sandbox testing. Do not add it to composer.json under any Laravel version currently supported.
• Build a native adapter at app/Services/Payments/Robokassa/ implementing an internal PaymentGateway contract. Components: RobokassaSignature (algorithms + hash selection), RobokassaClient (HTTP via Laravel's Http facade, explicit timeouts and retries), ResultController (callback endpoint), Payment model + state machine, ReconcileRobokassaPayments job.
• Keep vendor DTOs out of the domain. Robokassa's InvId/OutSum string fields and kopeck precision must be normalized at the boundary; downstream code should see integer minor units and internal IDs.

Migration path

• If currently on a legacy Symfony app using this bundle: do not upgrade in place. Wrap the existing integration behind an interface, freeze it, and route new traffic to a replacement adapter. This gives you a rollback lever without a big-bang cutover.
• If migrating Symfony → Laravel: extract the payment domain into a standalone package before the framework migration, so the framework move and the payment rewrite are not the same project.
• If greenfield: skip the bundle entirely. Start from Robokassa's current merchant documentation and the sandbox.

Compatibility

• Pin explicitly: PHP version, Laravel major, ext-json, ext-hash, and hash algorithm availability.
• Confirm the target Robokassa API surface (signature algorithm, receipt parameter format, callback HTTP method and encoding) against the live merchant cabinet — the 2018 assumptions may be stale in either direction.
• Verify callback encoding and parameter casing exactly (OutSum vs outSum, InvId vs invId); casing mismatches are a common source of silent signature failures.

Sequencing

1. Spike, 2–3 days. Read composer.json; stand up Robokassa sandbox/test credentials; confirm signature construction and receipt requirements; test a full redirect → callback cycle with a hand-rolled script.
2. Decision gate. If 54-FZ/SBP are required and unsupported, close out the bundle as a reference and scope the native build. Record the decision — it will be re-litigated.
3. Adapter build, 1–2 weeks. Gateway contract, signature service, client, unit tests against captured fixtures from the spike.
4. Callback endpoint + idempotency. Unique constraint on InvId; state machine that rejects illegal transitions; return the exact response body Robokassa expects for acknowledgement.
5. Reconciliation job. Scheduled pull of pending payments older than N minutes; this is the safety net for lost callbacks and is non-negotiable.
6. Compliance review. Fiscalization payload correctness signed off by finance/legal, not engineering alone.
7. Canary rollout. Low-value transactions first, with alerting on signature failures and reconciliation mismatches.

Operational Impact

Maintenance

• You own the code entirely — there is no upstream. No security patches, no PHP 8.x fixes, no Symfony/Laravel compatibility work will arrive. That is acceptable for a 300-line adapter you wrote; it is not acceptable for a forked third-party abstraction layer.
• Dependency decay is the dominant long-term cost if you fork rather than rewrite: JMS Payment is itself unmaintained, so you inherit an unmaintainable dependency to save a few days of work. Net-negative trade.
• Fork hygiene if you do fork: vendor the code under your namespace, delete the Symfony DI extension, keep the protocol logic, and add a test suite. Budget roughly the same effort as a rewrite — which is why a rewrite wins.

Support

• Package support: none. Single maintainer, no releases since 2018, no dependent community. Issues are unlikely to be triaged.
• Gateway support: available through Robokassa's merchant channels — technical account managers, sandbox, and documentation. Lean on this; it substitutes for most of what the package would have provided.
• Institutional support: designate a named owner for payment integration. Payment code with no owner is the most common root cause of multi-day revenue incidents.

Scaling

• The package is stateless request/response — it contributes nothing to and nothing against scaling. Scaling is a function of your callback endpoint.
• Callback endpoint must be horizontally safe: idempotent writes, no in-request external calls beyond the DB, queue off downstream work (receipts, emails, fulfillment).
• Robokassa callback volume is low relative to read traffic but bursts on retries. Ensure the endpoint degrades gracefully under duplicate-callback storms rather than amplifying them.
• Clock skew and InvId allocation must be handled at the application layer — the bundle offers no guidance and a fork inherits that gap.

Failure modes

Ramp-up

• Robokassa protocol: ~1–2 days for a backend engineer with payment experience, given decent documentation and sandbox access.
• Native Laravel adapter end-to-end (including tests and reconciliation): ~2–4 weeks for one engineer, part-time.
• Porting the Symfony bundle instead: ~2–3 weeks plus ongoing ownership of a legacy abstraction — strictly worse on every axis except initial familiarity for a Symfony-native engineer.
• Onboarding cost is front-loaded and small. The real ramp-up risk is organizational: if no one owns the integration post-launch, the failure modes above become inevitabilities rather than risks.

TPM recommendation: Do not adopt. Score the package as reference material only. The MIT license, simple protocol, and tiny surface area mean a native Laravel adapter is cheaper, safer, and fully supportable — and the 2018 timestamp plus 0 dependents means the alternative carries all the risk with none of the leverage. Gate the decision on one question: does the merchant require 54-FZ receipts and SBP? If yes, this package is disqualified outright rather than merely deprecated.