Sdk Bundle Laravel Package

Technical Evaluation

Architecture fit. The artifact and the target stack do not fit. lemonway/sdk-bundle is a Symfony bundle — it integrates via a Bundle subclass, a DependencyInjection\Extension, a Configuration tree, and services.yaml loading. Laravel has no bundle registry, no config-tree semantics, and no service-tag compiler pass pipeline. It cannot be installed and activated in a Laravel application in any supported way. What the bundle actually delivers is narrow: it reads a credentials config block, constructs the underlying Lemon Way SDK client, and registers it in the container. That is roughly 100–200 lines of glue, and it is the entirety of the value.

For a TPM, the correct framing is that this package is not a dependency candidate but an information asset. It is a readable specification of (a) the configuration surface the Lemon Way client requires, and (b) the API operations a marketplace/escrow roadmap will need — wallet creation, IBAN registration, KYC upload, money-in, P2P transfer, money-out. That knowledge is directly usable in estimation even though the code is not usable in runtime.

Integration feasibility. Low for the bundle, moderate for the underlying SDK, high for a thin in-house client. The viable path is to discard the bundle and either wrap the Lemon Way PHP SDK behind a Laravel service provider, config file, and facade, or — more likely, given the SDK's probable staleness — write a small REST client against Lemon Way's documented API. The surface in scope is small: a handful of endpoints, typed DTOs, idempotency keys, and webhook verification. This is a one-to-two-day build for an engineer comfortable with Laravel's container, not a multi-week integration.

Technical risk. High, and concentrated in provenance and domain rather than code complexity. Zero stars, zero dependents, a personal Bitbucket namespace, no CI badge, no test suite evidence, no security disclosure channel, no Packagist trust signal. In any other domain that is merely unattractive; in a payments path — SEPA transfers, card acquiring, wallet balances, KYC document handling, PSD2/SCA — it is disqualifying. Secondary risks: an unknown pinned SDK version, probable Symfony 2.x/3.x and Guzzle 5/6 era constraints that will collide with Laravel's Guzzle 7 requirement, an ambiguous or absent license, and installation only via a raw VCS repository entry (which would require Bitbucket credentials in CI). The TPM should also flag the category risk: adopting a wrapper you do not own binds your domain model to a vendor and forecloses multi-PSP optionality, which is a roadmap-level constraint, not a sprint-level one.

Key questions.

1. Which Lemon Way API generation does the wrapped SDK target — legacy XML v1 or REST v2? This determines the whole integration design and the sizing.
2. Which SDK version and PHP constraint is pinned, and does it conflict with our runtime and Guzzle major?
3. What is the license, and what is the maintainer's relationship to Lemon Way — official, partner, or individual?
4. How are credentials and environments handled — merchant ID/key/secret, IP allowlisting, 2FA/SCA, sandbox vs. production switching?
5. Does it cover the flows actually on our roadmap: refunds, KYC status polling, webhook signature verification, settlement file reconciliation?
6. What is the Composer install path, and does it require Bitbucket credentials or a private VCS entry in CI?
7. What is the compliance posture — are we a distributor/agent of a licensed PI, and who owns the French-language onboarding relationship?

Integration Approach

Stack fit. None directly; the bundle is non-adoptable and should be downgraded in the backlog to "design reference." The supported architecture is: config/lemonway.php + a Laravel service provider + a typed client wrapper behind our own PaymentProvider interface, with all outbound calls routed through Laravel's HTTP client so we inherit retries, timeouts, connection reuse, and structured logging with PII redaction. The interface boundary is the important TPM decision here — it is what preserves the option to switch to Stripe Connect, Mangopay, Adyen for Platforms, or Swan later without touching domain code.

Migration path. There is no migration, because there is nothing to migrate from. Decompile the bundle's value in three steps: (a) read its Configuration class to extract the exact configuration keys and defaults the SDK expects; (b) read the service definitions to learn the client's constructor signature and collaborators; (c) read any environment/endpoint-switching logic. Rebuild that as an internal package under our own namespace, versioned separately, with tests. The bundle is never installed on any branch, including spikes — a throwaway spike that imports it risks normalizing the dependency.

Compatibility. Verify before writing code: PHP constraint vs. our runtime, Guzzle major version, PSR-4 autoload correctness, and whether the underlying Lemon Way SDK is still receiving releases. If the SDK is also stale, prefer the thin in-house REST client over inheriting an unmaintained HTTP layer — the API is documented and the needed surface is small enough that ownership is cheaper than inheritance.

Sequencing.

1. Vendor spike (≈1 week): sandbox credentials, exercise two or three in-scope flows (wallet create → IBAN register → money-in → payout) against Lemon Way's test environment with our own client.
2. Formal build-vs-buy paper to roadmap review: Lemon Way vs. Stripe Connect vs. Mangopay on compliance posture, onboarding effort, pricing, and language/counterparty risk.
3. Wrap: service provider, config, facade, DTOs, logging, startup assertions separating sandbox and production credentials.
4. Webhooks before go-live: inbound callback handling with signature verification, idempotency keys, replay protection, and out-of-order tolerance. This is where payment integrations actually fail.
5. Reconcile: settlement/statement reconciliation job — the control that catches everything the other steps miss.
6. Harden: timeouts, bounded retry with backoff on idempotent operations only, circuit breaking, dead-letter queue for failed money movements.
7. Production cutover behind a feature flag with a dual-run period against the existing flow.

Operational Impact

Maintenance. We own it permanently. There is no upstream to merge from — the Bitbucket repository is a single-maintainer artifact with no dependents, so community patch velocity is effectively zero. Budget a quarterly review of the Lemon Way API/SDK version for deprecations, and treat Bitbucket hosting itself as a supply-chain concern: no Packagist provenance, no advisory feed, no build-time availability guarantee.

Support. Lemon Way supports their API and our merchant account. Nobody supports this bundle. Escalation for integration defects terminates in our own team, and that cost must be priced into the estimate — this is not "free open source," it is unowned glue with a payments blast radius.

Scaling. The wrapper is a thin HTTP client, so scaling is an application concern: connection reuse, per-endpoint timeouts, bounded retries on idempotent calls only, queueing of non-interactive money movements, and respect for Lemon Way rate limits. The product rule to enforce: money movement should not sit on the request/response path of a user-facing page where it can be deferred.

Failure modes.

• Duplicate money movement from retries without idempotency keys — highest severity in this domain.
• Partial failure on multi-step operations (wallet created, IBAN registration failed) leaving orphaned state; requires a reconciliation sweep, not just error handling.
• Webhook loss, duplication, or reordering desynchronizing local state from Lemon Way's ledger.
• Credential/environment confusion — sandbox keys in production or vice versa; enforce with separate config and startup assertions.
• KYC upload failures (size/format/timeout) silently blocking merchant onboarding.
• Silent upstream deprecation — an API version retired and the unmaintained client failing at runtime rather than at deploy.

Ramp-up. Low code-surface, high domain-surface. An engineer can read the entire bundle in an hour; learning Lemon Way's object model — accounts vs. wallets, IBAN statuses, KYC states, money-in/money-out semantics, refund windows, PSD2/SCA — takes considerably longer and is where estimation error will concentrate. Assume the bundle contributes roughly 5% of total integration effort and near-zero of the risk reduction. Pair the work with whoever owns payments compliance, and staff the vendor relationship with someone able to operate a French/European counterparty.

TPM bottom line. Leverage the artifact as a scoping and vendor-evaluation input; do not adopt it. Recommend a short sandbox spike and a formal Lemon Way vs. Stripe Connect vs. Mangopay decision paper before committing roadmap capacity to escrow or marketplace-payout features.