Payment Laravel Laravel Package

Technical Evaluation

Architecture fit The package is a thin Laravel integration layer — service provider, config, facade — over a driver-per-PSP abstraction. Its value proposition is not the gateway logic itself but the uniform interface: one contract, one Payment::driver('tinkoff') style entry point, and the ability to swap or add providers (PayOnline, Tinkoff, Yandex.Kassa/YooMoney, processing.kz, upc.ua) without rewriting checkout code. For a Laravel application already built around the service container and facades, the conceptual fit is good and idiomatic for its era (Laravel 5.x package conventions). Treat it as a reference architecture first and a dependency second.

Integration feasibility Low technical effort, high diligence effort. MIT license and a small surface area mean forking is trivial; 15 stars, 0 dependents, and a last release of 2018-10-01 mean there is no ecosystem validation and no upstream to lean on. Composer constraints almost certainly pin illuminate/support to 5.x, so a modern Laravel (9/10/11/12) install will fail resolution and require a fork plus a compatibility pass. The real feasibility question is per-gateway: each driver is an independent integration with its own sandbox, credentials, redirect flow, and signature scheme, so effort scales linearly with the number of PSPs you actually need.

Technical risk High. Unmaintained payment code is a security and compliance liability, not just a stale dependency:

• API drift. Every named gateway has been rebranded or materially changed since 2018 (Yandex.Kassa → YooMoney, Tinkoff → T-Bank, PayOnline rebranded). Endpoint URLs, auth schemes, and notification formats should be assumed stale until proven against current documentation.
• Security surface. Signature/checksum verification, callback authenticity, TLS handling, and secret management must all be re-audited. A payment package inside PCI scope cannot be taken on trust from an unmaintained source.
• Missing modern requirements. SCA/3-D Secure v2, idempotency keys, partial capture, refunds, recurring/auto-payments, and Russian fiscalization (54-FZ receipt data) are likely absent or naive.
• No safety net. No tests of unknown quality, no issue tracker activity, no CVE pipeline, no downstream users to surface breakage.
• Money-handling correctness. Amount units (kopeks vs. rubles), currency handling, and rounding are classic defects in packages of this vintage.

Key questions to answer in a spike

1. What Laravel/PHP versions do the composer constraints actually permit, and how much of the code breaks on PHP 8.1+?
2. Does the driver contract cleanly separate initiate payment, handle callback, refund, and status query — or is it redirect-only?
3. How is webhook/callback authenticity verified per driver, and is it enforced or optional?
4. Are there any tests, and do they run against sandboxes or mocks?
5. How are credentials and per-environment config handled (config cache, env leakage)?
6. Which of the five gateways do we actually need, and what is current transaction volume per gateway?
7. Is there idempotency, or can a retried callback double-charge/double-credit?
8. Who owns the fork, and what is the review bar for payment-path changes?

Integration Approach

Stack fit Only a clean fit for a Laravel 5.5–6.x application. For anything newer, plan on adopting the pattern rather than the package: fork it, or reimplement the driver interface natively and pull each PSP's current SDK or REST docs directly. If the product only needs one or two gateways, the abstraction's value drops sharply and direct integration is the lower-risk path.

Migration path

1. Fork and vendor privately (VCS/Satis or a path repository) — do not depend on Packagist for an abandoned payment package.
2. Compatibility pass: widen composer constraints, replace removed helpers, modernize service-provider registration and config publishing, add PHP 8 types and strict comparisons.
3. Introduce your own port: define an application-level PaymentGateway interface and wrap each package driver as an adapter. This is the single most important step — it makes every driver individually replaceable and caps the blast radius of a gateway rewrite.
4. Re-verify each driver against current gateway documentation and sandboxes before it touches production traffic.
5. Harden the cross-cutting concerns the package won't give you: idempotency keys, a payments/transactions ledger table, queued webhook processing, signed callback verification, and structured logging for reconciliation.

Compatibility Expect PHP 7.1-era syntax and Laravel 5-era container usage. Laravel package auto-discovery should work once constraints are fixed. Verify PSR-4 autoloading, config merge/publish behavior, and facade alias registration on the target framework version; check that no driver depends on deprecated Guzzle major versions.

Sequencing Spike and code read (2–3 days) → fork with CI and a baseline test harness → adapter layer in the host app → re-validate the highest-volume gateway first and ship it behind a feature flag → migrate remaining gateways one at a time → deprecate the fork's unused drivers. Never migrate all gateways in one release; each is an independent failure domain.

Operational Impact

Maintenance You inherit full ownership the moment you fork. The codebase is small enough to read in a day, but it is payment code: expect an initial 1–2 engineer-weeks for fork, compatibility, adapter layer, and per-gateway validation, then a steady 2–5 days per quarter for gateway API changes, certificate rotations, and dependency hygiene. Establish change control (review + sandbox test + staged rollout) for anything on the payment path; this is not a "merge and deploy" area.

Support No upstream maintainer, no issue triage, no security advisories, no community channel. All escalation is "read the gateway's current docs and debug against the sandbox." That is workable for a team with Russian/CIS payment experience and a real problem for one without — several of these gateways document primarily in Russian and change policy without changelogs.

Scaling Transaction volume is not the constraint; concurrency and correctness are. Drivers will almost certainly be synchronous HTTP calls, so slow gateway responses tie up PHP-FPM workers — add aggressive timeouts, retries with backoff, and a circuit breaker. Keep webhook endpoints stateless and horizontally scalable, push processing onto a queue, and make every handler idempotent so gateway retries cannot double-post to the ledger. There is no package-level state to scale; the database ledger you build around it is what needs care.

Failure modes

• Silent API drift after a gateway-side change — payments start failing or, worse, succeed without your system recording them.
• Signature/checksum mismatch after a certificate or algorithm rotation.
• Redirect/callback URL misconfiguration across environments, stranding customers post-3DS.
• Duplicate charges from retried callbacks due to missing idempotency.
• Amount-unit and rounding errors (kopeks vs. rubles) producing off-by-100x charges.
• Missing refund/partial-capture/fiscalization support discovered at month-end reconciliation.
• Credentials leaking via committed config or cached config in the wrong environment.
• No webhook audit trail, making reconciliation and dispute resolution manual and slow.

Mitigate with a daily reconciliation job against each gateway's reporting API — this is the single highest-value operational control for any payment integration and it catches drift the package will never tell you about.

Ramp-up Code comprehension is a 1-day task for a mid-level Laravel developer. Gateway-domain comprehension is the real cost: budget a week per gateway for someone to learn the flow, sandbox it end-to-end, and write the runbook (credentials, callback URLs, test cards, escalation contacts). Keep at least two people able to operate the payment path, and document the fork's divergence from upstream from day one — future maintainers will otherwise assume it is just an old Composer package.