Payture Inpay Client Laravel Package

Getting Started

This is a plain PHP client, not a Laravel package — there is no service provider, facade, or publishable config. Start with composer require lamoda/payture-inpay-client, then read src/ directly; the README is minimal, so the class signatures and the tests/ directory are your real documentation. The tests double as executable examples of how requests are built and what responses look like.

Get sandbox credentials from Payture first and confirm the API host (sandbox: https://sandbox.payture.com/, production: https://payture.com/). Configuration is just your merchant key plus the base URL passed into the client constructor — no environment-variable magic.

The first end-to-end use case to get working is the simplest one: initiate a one-step InPay payment. Construct the client with merchant key and host, call the "pay" method with an order id, amount, client IP, and your return URL, receive a session URL back, and redirect()->away($sessionUrl). Then add a return route that picks the order id out of the query string, calls the status/"get" method server-side, and persists the result. Once that loop works in sandbox, every other operation (refunds, two-stage confirm/cancel, recurring) is the same client object with a different call.

Implementation Patterns

Bind it as a singleton. Create config/payture.php (merchant key, host, environment), a small PaytureServiceProvider, and resolve a single configured client instance from the container. Keeping one client lets you share the underlying HTTP client — and therefore your Guzzle middleware for logging, retries, and correlation IDs — in one place.

Wrap it in an application service. The package returns its own response types; map them to your domain objects (PaymentResult, a PaymentStatus enum) in a thin service layer. This is the highest-value pattern here because the package is small and low-traffic — you want a seam that lets you swap or shim it later.

Persist payment state locally. Create a payments table keyed on your order id and Payture's order id/session. Store request, response, status, amount, and session type on every call. The return redirect is user-controlled, so it cannot be your source of truth — the status endpoint is.

Model the flow as jobs and events. On return, dispatch a queued job that calls the status endpoint, updates the payment row, and fires PaymentSucceeded/PaymentFailed events that drive fulfillment. Do refunds the same way so slow Payture responses don't block an admin UI.

Switch environments via config, not code. Sandbox and production differ only by host and credentials — model that as a config enum, not two branches.

Testing. The client accepts a PSR-18/Guzzle HTTP client, so inject a MockHandler seeded with the XML fixtures from the package's own tests. That gives deterministic tests of your wrapper without touching Payture.

Gotchas and Tips

• You own the Laravel glue. No provider, config, or facade ships with it — budget half a day for the integration layer, and treat it as real code you'll maintain.
• This is a redirect flow, not a webhook. Payture sends the user's browser back with query params; there is no server-to-server callback. Never mark an order paid from the redirect alone — always verify via the status endpoint.
• Amount units are a classic footgun. Confirm in the source whether the amount is in kopecks (minor units) or rubles before you ship; add a value object/cast so callers can't pass the wrong unit twice.
• Order IDs must be unique and URL/XML safe. Sanitize any user-derived component before it becomes an order id.
• Return URL must be HTTPS and externally reachable in production; Payture validates it.
• Two-stage (Block / Confirm / Cancel) is a different flow from one-step. Pick the session type at initiation and store it on the payment record so the follow-up call is unambiguous.
• Exceptions are thin. Catch the package's base exception, but also handle transport-level Guzzle exceptions. Log the raw XML response on failure — it's often the only useful debugging artifact.
• Recurring/Charge needs saved card references and consent handling — treat it as a separate feature with its own docs pass, not an extension of the basic flow.
• Pin the version (^x.y). With 7 stars and 0 dependents, the maintainer owes you nothing. Because everything sits behind your own service interface, the fallback to a hand-rolled client is a contained change.