Yandex Checkout Sdk Php Laravel Package

Product Decisions This Supports

• Marketplace and platform monetization. Release 1.6.9 adds support for the platform_fee_amount parameter on Transfer and Source. This is the parameter that lets a platform retain a commission when funds move to a seller or recipient. It directly enables product decisions around take-rate, split payouts, and seller economics rather than requiring custom API calls outside the SDK.
• Feature feasibility: seller payouts and split payments. If the roadmap includes multi-vendor checkout, seller onboarding payouts, or platform-retained fees, this release removes a concrete integration blocker in the Laravel/PHP client. It makes those features more estimate-friendly because the parameter is now first-class in the package.
• Build vs. buy for payment integration. An actively maintained SDK that tracks provider API capabilities (here, platform fees on transfers) weakens the case for building and maintaining an in-house API client. The decision shifts toward buying/adopting the package and investing engineering effort in ledger, reconciliation, and compliance instead.
• Roadmap sequencing. This is an additive, non-breaking release. It can be scheduled as a routine dependency upgrade, but the product-facing work — fee accounting, seller statements, refunds of platform fees, tax treatment — is a separate roadmap item and should be planned explicitly.
• Use cases unlocked or de-risked: marketplace commission retention, aggregator payout flows, partner/referral revenue share, and any flow where the platform must be paid out of a transfer rather than via a separate invoice.
• Evidence caveat. The only input for this assessment is the 1.6.9 release note. It confirms parameter support but does not establish test coverage, documentation quality, or edge-case behavior for fee handling. Treat the capability as available, not as fully validated.

When to Consider This Package

Consider adoption when:

• The product is a Laravel or plain PHP application using YooKassa/YooMoney as a payment provider, and the team wants a maintained client rather than hand-rolled HTTP signing, idempotency, and error mapping.
• The business model involves platform fees, marketplace payouts, or transfers to third parties, and platform_fee_amount on Transfer/Source is on the near-term roadmap. Version 1.6.9 is the minimum version that exposes this without custom requests.
• The team values small, incremental upgrades: this release is additive and non-breaking, so it fits a routine dependency-bump cadence.
• Engineering capacity is limited and the team prefers to spend it on domain logic (ledger, reconciliation, seller UX) rather than on payment plumbing.

Look elsewhere or pause when:

• The stack is not Laravel/PHP, or the provider is not YooKassa — the package’s value is largely in framework integration and provider-specific request/response handling.
• You need a full payout orchestration or ledger product. This is an API client, not a money-movement system; fee calculation, balances, negative-balance handling, and reconciliation remain your responsibility.
• Compliance, KYC, and licensing are the real constraint. An SDK does not change regulatory obligations for holding or splitting funds.
• Package maintenance, versioning discipline, or security posture cannot be verified. The release note alone does not demonstrate a support policy; check release cadence, issue responsiveness, and test coverage before making it a critical dependency.
• Your flow requires provider capabilities not represented in the SDK; confirm against provider docs whether the needed endpoints and parameters are wrapped or would still require custom calls.

How to Pitch It (Stakeholders)

For executives: The payment SDK we use for YooKassa now supports platform fees on transfers (version 1.6.9). In plain terms, it lets us take our commission directly when we pay out to sellers, instead of bolting on a workaround. That unblocks marketplace-style revenue mechanics and reduces custom payment code we would otherwise own. The upgrade itself is low-risk and additive; the real investment is in the accounting and seller-facing reporting around fees, which we should scope as product work, not assume the SDK provides.

For engineering: Version 1.6.9 is an additive release adding platform_fee_amount to Transfer and Source. No breaking changes are indicated. The upgrade path is a routine dependency bump; the integration work is passing the fee through your payout service and persisting the fee amount alongside transfer records. Before relying on it in production, add tests for fee calculation, idempotency on retries, partial refunds of platform fees, and reconciliation against provider reports. Note that the SDK transports the paramed — it does not compute fees, enforce limits, or handle ledger consistency. Those remain our design decisions.

For product: This is an enabler, not a shipped feature. It means seller payouts with platform commission are now technically straightforward on our current stack. The remaining decisions are commercial and operational: take-rate, who absorbs fees, how fees appear on seller statements, and how refunds and disputes treat the platform portion. Confirm these before committing to a launch date.