Payture Inpay Client Laravel Package

Technical Evaluation

Architecture fit. lamoda/payture-inpay-client is a narrow, single-purpose SDK wrapping the Payture InPay REST API — a Russian payment gateway used primarily for card payments, 3-D Secure flows, refunds, and chargebacks. Architecturally this is a thin adapter, not a framework: it maps PHP method calls to Payture's HTTP endpoints and returns response DTOs. That is a good fit for a Laravel service layer if we treat it as an infrastructure detail behind our own PaymentGateway interface. It should not leak Payture types into domain/application code; if it does, that is a smell we must wrap.

The package is framework-agnostic PHP (Composer, PSR-4), which means there is almost certainly no Laravel ServiceProvider auto-discovery. Integration cost is therefore a manual binding in a provider plus a config file — trivial for one engineer, but must be sequenced deliberately. It is not a Laravel package in the "install and php artisan" sense.

Integration feasibility. Basic charge/refund integration is low-effort: merchant key + password in config, one service class, one adapter. The real feasibility question is scope coverage — InPay has multiple methods (pay, refund, state query, 3-D Secure redirects, optional Apple/Google Pay, recurring). We need to confirm the client covers each method we intend to use, or whether we must extend it. Because there are 7 stars and 0 external dependents, we cannot rely on someone else having exercised those paths; every method we adopt is a path we own.

Technical risk. Payment is a high-blast-radius domain, and the package's signals are weak on community support but acceptable on stewardship: MIT license, a real corporate maintainer (Lamoda), and a recent release (2024-02-01). The dominant risks are (1) key-person/upstream abandonment — a single-org repo with no visible contributor base; (2) PCI and secret-handling posture — we must verify the client does not log card data or PAN-bearing payloads; (3) idempotency — payment APIs require client-side idempotency/retry semantics, and a thin SDK likely does not provide them; (4) API drift — Payture's API evolves and a low-traffic client may lag; (5) dependency pinning — Guzzle/PSR-18 version constraints may collide with the rest of our stack.

Key questions.

• Which InPay methods does the client expose, and does it match our actual payment flows (3-D Secure, refunds, partial refunds, recurring, state reconciliation)?
• Does it verify Payture callback/notification signatures, or do we implement that ourselves?
• Is there test coverage / a sandbox contract test, or are we the first to exercise these paths?
• What PHP and Guzzle version constraints does composer.json declare, and do they fit our support matrix?
• Does it sanitize or suppress logging of sensitive payloads?
• Who is the current maintainer and what is the response SLA for issues/security patches?

Integration Approach

Stack fit. The package composes cleanly with a Laravel app as a constructor-injected service behind a bounded interface. Recommended shape: App\Payments\Contracts\PaymentGateway (our interface) → PaytureGatewayAdapter (wraps the SDK) → SDK client. Bind the interface in a dedicated PaymentsServiceProvider, keep merchant credentials in config/payments.php sourced from env/secret manager, and never resolve the SDK client directly from the container outside the adapter. This keeps the blast radius of replacing the SDK to a single class.

Migration path. Two viable paths. If we are greenfield on Payture, adopt the SDK now behind the adapter and move on. If we already have hand-rolled Payture HTTP calls, use the SDK only if it demonstrably covers our existing calls; otherwise stay direct and adopt the SDK opportunistically. In either case, the abstraction layer is the migration insurance — it lets us swap to Payture's direct REST, a maintained fork, or another PSP without touching application code. Given the thin community, I would treat this package as a starting point we may fork, not a dependency we assume will be maintained for us.

Compatibility. Verify three things before committing: (1) PHP version range vs. our runtime (Laravel 10/11 on PHP 8.2/8.3 is the common case); (2) Guzzle/PSR-18 constraint vs. our existing HTTP client stack — version-pin conflicts here are the most likely install-time failure; (3) absence of Laravel auto-discovery (we register manually). Also confirm the license file is present and the copyright notice is retained if we fork.

Sequencing.

1. Spike (1–2 days): install in a scratch Laravel app, exercise charge/refund/state against Payture's sandbox merchant; capture request/response fixtures.
2. Contract tests: commit fixtures as golden tests against the adapter so SDK upgrades cannot silently change behavior.
3. Adapter + provider + config: build the interface boundary, credential handling, and structured logging with sensitive-field redaction.
4. Hardening layer: idempotency keys, retry policy with backoff, timeout budgets, reconciliation job against Payture's state-query endpoint.
5. Staging: end-to-end with Payture test credentials, including 3-D Secure redirect round-trip and webhook verification.
6. Production: canary on a low-volume payment method or small traffic slice; pin the Composer version exactly; monitor authorization success rate, latency, and reconciliation mismatches.
7. Fork contingency: if upstream goes quiet, fork under our org with the same MIT terms and continue maintenance in-house.

Operational Impact

Maintenance. Realistically, we are the de facto maintainers. With 7 stars, zero dependents, and a single-org history, there is no community to absorb upgrades. Budget a modest but recurring allocation: dependency bumps (Guzzle, PHP minor versions), Payture API changes, and security patching. Pin to an exact version in composer.json and treat upgrades as deliberate, tested events — never ^ ranges on a package this lightly trafficked.

Support. Two support surfaces: Payture (merchant account, API behavior, settlement, dispute handling) and the client itself (ours, since community support is effectively nil). Define an internal on-call path for payment failures that distinguishes PSP-side errors, network/infra failures, and client bugs — Payture's error codes must be mapped explicitly in the adapter, not passed through raw.

Scaling. The SDK is not the throughput bottleneck; Payture is. Horizontal scaling is fine — the client is stateless per request — but payment traffic requires connection reuse, sensible timeouts (short for authorization, longer for reconciliation), and a circuit breaker so a slow PSP does not exhaust PHP-FPM workers. Run reconciliation as a queued, rate-limited job, not inline with the user request.

Failure modes. The dangerous ones are ambiguous, not loud: a timeout on a charge request can mean "declined" or "approved but response lost," and without idempotency keys and a state-query reconciliation you will double-charge or leave orders unpaid. Other modes: duplicate submissions on user retry, webhook signature verification gaps if the SDK does not handle it, unredacted PAN in logs (compliance incident, not just a bug), and silent breakage on PHP/Guzzle upgrades. Rate limiting and PSP-side outages should degrade gracefully — queue and retry, or fail safe with a clear user message.

Ramp-up. Code ramp-up is fast — the package is small and a mid-level PHP engineer can read it in an afternoon. The real ramp is domain: Payture's InPay semantics, 3-D Secure redirect flows, refund and partial-refund rules, settlement timing, and chargeback handling. Plan for one engineer to own payments end-to-end, pair with finance for reconciliation definitions, and document the adapter's error taxonomy and retry semantics before go-live. Given the low community signal, I would not spread this across multiple engineers early; a single accountable owner is the safer operating model.