Payture Inpay Client Laravel Package

Product Decisions This Supports

• Checkout payment method expansion (RU/CIS): This package is the integration layer for Payture's InPay API — the hosted payment page flow. It directly supports the decision to add card payments for Russian-market customers without building PSP connectivity from scratch.
• Build vs. buy for payment glue: It reframes the "build" option. Instead of estimating a multi-week Payture integration epic, engineering can wrap this client in days. That shifts the cost/benefit math in favor of shipping payments sooner.
• PCI scope reduction: InPay is a redirect/hosted-page flow, meaning card data never touches your servers. This is a compliance-driven product decision (lighter PCI DSS scope, fewer security obligations) that the package makes practical.
• Roadmap sequencing: If Payture is your PSP for the region, this package is a dependency of any roadmap item involving card acceptance — checkout conversion work, saved-card / repeat purchase flows, 3-D Secure handling, and refunds. Treat it as an enabler, not a feature.
• Use cases it unlocks: one-off card checkout, stored-card repeat payments, and any flow where redirecting to a PSP-hosted page is acceptable UX.
• Risk-sizing for the payments epic: The low maturity signals (7 stars, 0 dependents, single vendor origin) are themselves a PM input — they justify budgeting for a fork/wrapper and a security review rather than assuming zero maintenance cost.

When to Consider This Package

Consider it when:

• You are committed to Payture as your payment provider and specifically using the InPay API.
• Your stack is PHP, and you are comfortable adding a thin internal wrapper (service provider, config, error mapping) if you're on Laravel — this is a framework-agnostic client, not a Laravel package.
• Your scope is narrow: initiate payment, redirect, handle the return/callback. You are not asking the package to solve webhooks, reconciliation, refunds UI, or multi-PSP routing — you'll build those around it.
• You can accept vendor maintenance risk: MIT license is permissive and fork-friendly, but the project has a small community and no downstream dependents. Plan to pin the version and be prepared to own the fork.
• You value speed over ecosystem polish, and a security/architecture review of a few hundred lines of HTTP glue is a reasonable trade.

Look elsewhere when:

• You are not using Payture, or you need a provider-agnostic abstraction across multiple PSPs (Stripe, Adyen, YooKassa, etc.).
• You require an actively maintained SDK with a community, changelog cadence, and responsive issue triage — this has none of that.
• You want Laravel-native ergonomics out of the box (facades, publishable config, queued webhook handling, testing fakes). You'd have to build that yourself.
• You need generated/typed clients from an OpenAPI spec, strict static analysis, or formal SLAs and vendor support contracts.
• Your compliance posture demands a vendor with a security disclosure process and documented maintenance guarantees.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed PHP client from Lamoda that lets us connect to Payture's hosted payment page quickly. It turns a bespoke payment integration into a short wrapper task, which shortens time-to-market for card payments in the Russian market and keeps card data off our infrastructure — reducing PCI compliance scope. The trade-off is maturity: it is a low-profile open-source byproduct with a tiny community and no downstream dependents. The cost is negligible and the license permits forking, so the recommendation is to adopt it behind our own internal payment interface, pin the version, and treat it as code we may need to own. Net: meaningful speed-to-market gain, contained and manageable risk.

For engineering: It's a thin, unopinionated HTTP client for Payture's InPay API — payment initiation, redirect, and callback flows. There is no Laravel integration, no webhook handling, no idempotency, no retry policy, and no test harness we should rely on. The plan is to wrap it in a single PaymentGateway adapter behind our domain interface, add structured error mapping, idempotency keys, logging/observability, and integration tests against Payture's sandbox. Pin the dependency, vendor it if necessary, and keep the wrapper thin enough that replacing the client is a one-file change. Assume we own maintenance from day one.