Payment Laravel Yandex Laravel Package

Technical Evaluation

Architecture fit. The package is a multi-gateway driver library sitting on top of Laravel's service container: a service provider, a published config file, and a family of driver classes behind a shared payment interface. That is the correct shape for a Laravel integration and maps cleanly onto a hexagonal port/adapter design — our domain code calls a PaymentGateway contract, the package supplies an adapter. The architectural concern is not the pattern, it is the blast radius of the pattern: the abstraction is broad (five providers across three jurisdictions) and shallow-maintained, which is the worst combination for payments. Breadth means five sets of signature algorithms, five error-code taxonomies, and five callback dialects, all owned by a maintainer with 15 stars and no dependents.

Integration feasibility. Feasible only as a source of extracted code, not as a Composer dependency. Last release 2018-10-01 places it in the Laravel 5.5–5.7 / PHP 7.0–7.2 window. On Laravel 9+ we should expect breakage from removed helpers (str_random, array_get, str_slug), facade aliasing changes, and Symfony HTTP client versioning. The MIT license is permissive and is the single most valuable property here: we can legally fork, vendor, and modify without negotiation. The 0.659 score and 11.43 opportunity signal align with "cheap to acquire, expensive to own."

Technical risk. Concentrated in three places:

1. Deprecated counterparts. Yandex.Kassa rebranded to YooMoney in 2020 with API migration; Tinkoff is now T-Bank with a newer acquiring API and an official SDK; PayOnline is a legacy platform. Any hardcoded endpoint or signature scheme from 2018 is likely stale for at least two of the five drivers.
2. Callback verification. Webhook signature validation is the security-critical path in any payment library. Unmaintained crypto/verification code is not a maintenance debt, it is an incident waiting to happen — silent bypass produces no error, just wrong money.
3. No deployment evidence. Zero dependents means no production telemetry, no issue tracker history of real edge cases, and no community backstop if the maintainer disappears. Assume the package is already abandoned.

Key questions.

• Which gateways do we actually need? If it is T-Bank or YooMoney, stop — use the provider's official PHP SDK and close this evaluation. The package's residual value is concentrated in processing.kz (Kazakhstan) and upc.ua (Ukraine), where PHP SDK coverage is thin.
• Are we on redirect/hosted-page flow (SAQ A) or posting card data to our own servers (SAQ D)? If the latter, this package is disqualified regardless of code quality.
• Do we require partial refunds, holds/voids, recurring, or 3-D Secure step-up? Does each driver model them, or does the interface flatten them away?
• Is webhook handling idempotent, and does it verify signatures with constant-time comparison?
• Is the upstream repo still responsive to issues, and is there a maintained fork? Check commit graph, not star count.
• What are our PHP and Laravel version targets, and does composer.json constrain them or pin Guzzle to a version that conflicts?

Integration Approach

Stack fit. Workable across Laravel 8–11 after porting, not before. The package's only real dependencies should be Guzzle and ext-json; verify that it does not pull in abandoned transitive packages (old guzzlehttp/guzzle 6.x, phpunit 6.x in require-dev, or nesbot/carbon 1.x) that will collide with the host application's lockfile. The driver abstraction itself is framework-agnostic enough to survive the port.

Migration path. Do not composer require this and do not let it into the application's dependency graph. Fork the repository, tag it internally as a private package (internal/payments-gateway), and strip it down to the one or two drivers in scope. Delete the rest — dead drivers are dead attack surface and dead maintenance cost. Wrap the result behind our own PaymentGateway interface so that a future swap to an official SDK is a one-adapter change, not a domain refactor. Publish the config under our namespace and move all credentials to secrets management, not .env reads inside the package.

Compatibility. Expect concrete fixes: widen Composer constraints, replace removed Laravel helpers, swap facades for constructor injection, modernize the HTTP client calls (->get()/->post() signatures, timeout and connect_timeout defaults, RequestException handling), and audit the signature/callback code line by line. Treat the callback verifier as a security review, not a refactor. Add contract tests that run against each provider's sandbox so API drift is detected in CI rather than in production.

Sequencing.

1. Spike (2–3 days). One gateway, sandbox merchant account, end-to-end pay → callback → refund. This is a go/no-go gate.
2. Security audit (2–3 days). Signature verification, replay protection, amount/currency parsing, logging of card-adjacent data. Gate two.
3. Extract & adapt (3–5 days). Vendor the single driver, wrap in our interface, delete unused drivers, wire config into secrets.
4. Harden (2–3 days). Explicit timeouts, bounded retries with idempotency keys, structured logging, metrics on success rate and latency per gateway.
5. Canary. Feature-flag one gateway behind a percentage rollout with a dual-write reconciliation job comparing our ledger to provider settlement reports.
6. Second gateway only if separately justified — re-run steps 1–4, budget 4–6 engineer-days each.

Operational Impact

Maintenance. This is the dominant cost and it is entirely ours. Upstream is effectively static since 2018; there will be no security patches. Estimate 8–12 engineer-days for the initial port and hardening of one driver, then 2–4 engineer-days per quarter per live gateway for API drift, certificate rotation, and provider-side deprecations. The first forced migration is likely to be whichever of YooMoney/T-Bank we touch — budget for it as a scheduled project, not an incident.

Support. No vendor support. Provider support desks will help with API behavior but will correctly disclaim responsibility for a third-party 2018 library. The practical consequence: a payment outage at 02:00 is debugged by whoever is on call, with no upstream escalation path. That requires someone on the team who has actually read the driver code — a single-point-of-failure risk we should consciously accept or explicitly mitigate with a second trained engineer.

Scaling. Throughput is a non-issue; payment volume is orders of magnitude below web traffic, and the flow is redirect-based rather than high-QPS. The scaling risks are qualitative: synchronous outbound HTTP inside the request path (add timeouts, push confirmation to queued webhook handlers), webhook endpoints that must absorb provider retry storms, and lack of idempotency keys causing duplicate order state under retry. Design the callback handler to be idempotent and queue-backed from day one; retrofitting that after a duplicate-charge incident is far more expensive.

Failure modes to instrument for.

• Signature verification failing open (no error, accepted callback) — the worst case, and the one an unmaintained library makes most likely.
• Replayed or duplicated callbacks producing double fulfillment.
• Amount/currency unit bugs (kopecks vs. rubles, tenge formatting) — silent, and only visible in reconciliation.
• Hardcoded or deprecated provider endpoints returning HTML error pages that the client parses as success.
• Missing timeouts causing worker exhaustion when a provider degrades.
• No correlation ID between our order, the provider's payment ID, and our logs — makes every incident slower.

Ramp-up. The code surface is small; a mid-level PHP engineer can be productive in the driver within 2–3 days. The real ramp is domain knowledge, not this package: idempotency, PCI scope boundaries, reconciliation, and refund/chargeback semantics. Plan 1–2 weeks before someone is genuinely safe to modify the payment path unsupervised. Given a 15-star, zero-dependent dependency, assume the team is learning the provider's API and the library simultaneously — the sandbox contract tests from step 1 are the cheapest mitigation for that.

Bottom line. Conditional go, narrowly scoped. Use this package only for the gateways where no maintained official PHP SDK exists — realistically processing.kz and upc.ua — and only via fork-and-vendor behind our own interface. For T-Bank and YooMoney, the official SDKs win on every axis: support, currency of API surface, and security review burden. Adopting all five drivers as-is would be the wrong call for a payments path.