Yandex Checkout Sdk Php Laravel Package

Technical Evaluation

Architecture fit Release 1.6.9 is an additive, backward-compatible change to an existing Laravel/PHP payments integration: it exposes the platform_fee_amount parameter on Transfer and Source request objects. For a TPM this is a low-blast-radius extension of an existing domain object rather than a new subsystem. It fits cleanly into any architecture that already routes payouts/splits through the package's Transfer/Source abstractions, and requires no change to service providers, config, or the surrounding Laravel application structure.

Integration feasibility High. The change is a new optional parameter surfaced through existing objects, so adoption is a matter of passing the field where a Transfer or Source is constructed. There is no new dependency, no new API surface beyond one parameter, and no configuration migration. The practical constraint is upstream, not in the package: the merchant account must be enabled for platform fees on the provider side, and the fee semantics (who bears the fee, fixed vs. percentage, currency rules, min/max bounds) must match the provider's contract. Integration effort is estimated at hours, not days, for a team already on the package.

Technical risk Low-to-moderate overall:

• Compatibility risk: low. Optional parameter, no signature breaks expected.
• Semantic-versioning risk: low but worth flagging. A new capability shipped under a patch version (1.6.9) rather than a minor bump can cause consumers with pinned constraints or changelog-driven upgrade policies to miss it, and it complicates automated dependency review.
• Financial correctness risk: moderate. Fee parameters affect money movement. Incorrect values, rounding, or double-counting the fee between platform and recipient can produce reconciliation drift that surfaces days later, not at request time.
• Provider-behavior risk: moderate. Validation rules, supported currencies, and error codes for platform_fee_amount are defined by the payment provider and can differ by account tier; the package will not shield the team from those rules.
• Test-coverage risk: unknown. Release notes do not state whether the parameter is covered by tests or whether the provider sandbox supports it.

Key questions

1. Is the parameter validated client-side (numeric type, precision, currency), or passed through verbatim to the provider?
2. Does the package expose this on both the object constructors and any related DTOs/builders/serializers, or only one path?
3. Is the change covered by tests, and is it exercisable in the provider's sandbox for our account?
4. Is platform_fee_amount mutually exclusive with, or additive to, any existing fee/commission fields we already send?
5. What is the documented minimum package version and provider API version required for platform fees on our account type?
6. Are there rounding or currency-minor-unit conventions we must apply before passing the value?

Integration Approach

Stack fit Fits a standard Laravel payments integration with no architectural adjustment. Assuming the application already wraps the package behind a service or action layer (recommended), the change is confined to that layer: map an internal fee policy to platform_fee_amount when building Transfer and Source payloads. Teams that call the package's objects directly from controllers will still integrate fine, but should use this release as a prompt to introduce a thin wrapper so future fee-policy changes are not spread across the codebase.

Migration path Non-breaking and incremental:

1. Pin/bump to ^1.6.9 in composer.json (or the exact constraint your policy requires) and run composer update in a branch.
2. Add the parameter behind a configuration flag or feature toggle, defaulting to off/absent so behaviour is unchanged until explicitly enabled.
3. Implement fee calculation in one place (a dedicated fee resolver) rather than at call sites.
4. Enable in sandbox, then in production for a single low-value payout path before broadening.

Because the field is optional, a staged rollout with a kill switch is straightforward and rollback is a config flip, not a redeploy.

Compatibility Backward compatible with existing Transfer/Source usage; existing calls that omit the parameter should behave exactly as before. Verify the package's PHP and Laravel version constraints against the current runtime as part of the bump, and confirm no transitive dependency shifts in the lockfile diff. The main compatibility question is provider-side, not code-side: staging and production merchant accounts must both have platform fees enabled, otherwise the parameter may be rejected or silently ignored depending on provider behaviour.

Sequencing

1. Confirm provider-side enablement and fee rules with the payments/account team (blocking).
2. Bump the dependency and review the lockfile diff (low effort).
3. Implement the fee resolver and wire it into Transfer/Source construction behind a flag.
4. Add tests covering fee present, fee absent, currency edge cases, and provider error responses.
5. Sandbox verification, including reconciliation of a completed transfer.
6. Canary in production on a single low-value path, then general rollout.
7. Update internal runbooks and the finance reconciliation mapping.

Operational Impact

Maintenance Minimal ongoing maintenance: one optional parameter, no new infrastructure. The real maintenance surface is the fee policy itself, which now lives in application code and needs an owner (typically payments/finance engineering) and a documented source of truth. Expect periodic review when the provider changes fee rules or adds currencies.

Support Support burden should be near zero for the code change. The foreseeable support cases are business-level: disputes over who absorbs the platform fee, rounding discrepancies in customer-facing amounts, and "why was the fee not applied" tickets caused by account-level enablement rather than the package. Pre-empt these with a short internal note explaining what the parameter does and where it is configured.

Scaling Negligible performance impact—one additional field per request. Scaling concerns are financial, not technical: as payout volume grows, rounding and fee-accumulation errors compound across many small transfers. Ensure reconciliation reports break out platform fees separately so volume growth does not mask per-transaction drift.

Failure modes

• Parameter sent but platform fees not enabled on the merchant account → provider rejection or silently ignored fee.
• Fee exceeds transfer amount or violates currency minimum/maximum → validation error at request time.
• Rounding mismatch between internal ledger and provider → reconciliation breaks discovered downstream.
• Fee applied on one path (e.g. Transfer) but not the parallel path (e.g. Source) → inconsistent economics between payout flows.
• Patch-version release missed by pinned constraints → environment drift where staging has the capability and production does not.

Each of these is detectable with explicit tests, a canary rollout, and a reconciliation check on the first live transactions.

Ramp-up Low. A developer familiar with the existing integration needs well under a day to implement and test; unfamiliar developers need perhaps one to two days, mostly to understand the provider's platform-fee model rather than the package. The highest-leverage ramp-up artifact is a one-page internal doc covering: what platform_fee_amount does, the fee formula, which account types support it, and how to verify a fee landed correctly in reconciliation.