Product Decisions This Supports
- Build vs. buy for payments in a Laravel codebase. This package sits in the "buy" column for Russian-market acquiring: it wraps Tinkoff/T-Bank payment initiation, 3-D Secure auth flows, request signing/token verification, and webhook notification handling behind a Cashier-style API. The decision it informs is whether to own ~2–4 weeks of payment-flow plumbing plus ongoing compliance upkeep, or adopt a maintained driver.
- Roadmap sequencing for subscription/marketplace billing. Because it follows Cashier conventions (billable models, payment objects, notification endpoints), adopting it keeps recurring billing on the standard Laravel path — meaning subscription, dunning, and invoice features can be scoped as incremental work rather than a custom integration project.
- Payment-method coverage as a feature decision. Adding a local acquirer is a go-to-market enabler for RU-based customers. The PM question it answers is "can we ship in this market without a bespoke integration epic?" — not "which payment features do we build next?"
- Risk/supportability decision. An actively versioned package (this release lands as a patch, v2.6.1) is a signal for the maintenance-cost line in your roadmap. Patch releases are the cheapest kind of dependency churn: pin, scan the diff, bump. This one gives you no reason to schedule work — but also no evidence to stop watching it. Treat it as "stable, continue" rather than "validated."
- Vendor-lock-in and portability planning. A Cashier-shaped abstraction is a hedge: if you ever multi-acquire (e.g., add another provider), the blast radius of a switch is narrowed to the driver layer. That is a genuine architectural argument for choosing this over a one-off SDK.
Honest caveat for the record: v2.6.1 ships with a changelog link and no described changes — no breaking changes, no features, no deprecations. There is no product-relevant delta here. The assessment below is a first-pass baseline, not a response to this release.
When to Consider This Package
Adopt when all of these hold:
- You are building on Laravel and already use (or plan to use) Laravel Cashier conventions for billing — the value is the convention alignment, not the HTTP client.
- Your customer base or entity requires Tinkoff/T-Bank acquiring specifically, including 3-D Secure and their notification/signature scheme.
- You want webhook verification, idempotency, and notification routing handled by the package rather than in application code — this is the bulk of the maintenance you are avoiding.
- You can accept a community-maintained dependency for a money-critical path, and you have (or will build) your own reconciliation, refund, and dispute handling on top.
Look elsewhere when:
- PCI scope or regulatory requirements push you toward a fully managed billing platform (Stripe/Adyen/YooKassa-hosted, or a merchant-of-record) rather than a driver — this package reduces integration work, not compliance obligations.
- You need multi-provider routing on day one; a driver-shaped package helps, but you will still own the abstraction.
- The project is not Laravel, or you are on an older Laravel/PHP version whose support window isn't stated — verify compatibility before committing; a patch release tells you nothing about support matrices.
- You require a vendor SLA, security review, or named maintainer accountability. Read the release cadence over the last 12 months and the issue/PR responsiveness before betting a revenue path on it.
How to Pitch It (Stakeholders)
For executives (one paragraph): We can enable Tinkoff/T-Bank payments in our Laravel app by adopting a maintained open-source driver instead of building the integration ourselves — saving an estimated multi-week engineering effort and the recurring cost of keeping 3-D Secure and webhook signature handling current. It keeps our billing on the standard Laravel Cashier path, so future subscription and invoicing work is additive rather than a rewrite, and it limits lock-in by keeping the provider behind a swappable layer. The cost is a community dependency on a revenue-critical path, which we mitigate with version pinning, our own reconciliation and refund logic, and a monitored upgrade cadence. The latest release (v2.6.1) is a routine patch with no breaking changes or new functionality — no action required beyond a dependency bump and a changelog review.
For engineering (specifics): Cashier-style driver for Tinkoff acquiring — payment init, 3-D Secure flow, request signing, notification/webhook handling. We pin to a minor line, review the v2.6.1 diff before bumping (release notes are a bare changelog link, so read the commits), and keep reconciliation/refunds/disputes in our own domain layer. Add integration tests around the webhook signature path and idempotency before we depend on it in production; those are the failure modes that cost money.
Decision requested: Approve adoption as the RU acquiring driver for the billing workstream, contingent on a documented compatibility check and a webhook/idempotency test suite.