Sdk Bundle Laravel Package

Product Decisions This Supports

• Lemon Way vs. Stripe Connect vs. Mangopay vs. Adyen for Platforms. The existence of this bundle is evidence that a licensed European payment institution — one that holds funds in escrow, KYC-verifies payees, and pays out over SEPA — is reachable from a PHP stack. That is a real input to a vendor-selection decision, independent of whether the bundle itself is good.
• Escrow/payout roadmap scoping. Reading the bundle's surface area cheaply enumerates the API verbs our marketplace epics will need: wallet creation, IBAN registration, KYC document upload, money-in (card/SEPA), wallet-to-wallet transfers, money-out, refunds. Use it to write acceptance criteria before anyone books a sprint.
• Build vs. buy on the integration layer. This is not an integration you buy into (0 stars, 0 dependents, Bitbucket-only, unmaintained). The real decision it informs is: do we own a thin, tested Lemon Way adapter behind our own PaymentProvider interface, or defer the vendor call entirely?
• Regulatory posture estimation. Choosing a licensed PI as the funds holder shifts our compliance burden — we typically become a distributor/agent rather than the institution. That is a materially different product and legal stance from a pure Stripe Connect split-payment model, and it belongs in a roadmap review, not a ticket.
• Ecosystem gap analysis for the PHP market. The artifact being Symfony-only tells us Lemon Way's PHP tooling skews toward Symfony/legacy. A Laravel shop has no first-class path — that is a budgeting signal for glue engineering, and a reason to prefer a direct REST client over inheriting someone else's abstraction.
• Stack-fit evidence, not stack-fit solution. Confirms the integration is feasible from PHP while simultaneously confirming this specific package is not adoptable in Laravel. Both facts are decision-relevant.

When to Consider This Package

Consider it — as reference material, not a dependency — when:

• You are actually on Symfony with an existing DI container, and the bundle's wiring genuinely saves time on a sandbox spike or internal back-office tool.
• You want to learn the Lemon Way API shape (required credentials, client constructor arguments, endpoint/environment switching) without reading the vendor docs end to end.
• You are doing a throwaway feasibility proof to validate that Lemon Way supports your flows, prior to a formal vendor decision.
• Someone owns a fork: pinned, audited, and accepted as a maintenance burden.

Look elsewhere — or decline outright — when:

• You are on Laravel. A Symfony bundle assumes bundles, services.yaml, config trees, and service tags. Bridging that into Laravel's container is strictly more work than writing a 300-line HTTP client plus a service provider. There is no supported install path.
• The code touches real money. Unmaintained, zero-adoption, Bitbucket-hosted, no CI, no security disclosure channel: unacceptable supply-chain risk in a payments path. Payments need idempotency keys, bounded retries, webhook signature verification, settlement reconciliation, and SCA/3DS handling — none of which you should inherit from a dead package.
• You want multi-PSP optionality. If EU expansion could mean running two providers, abstract behind your own interface on day one. Binding the domain to a wrapper you don't own forecloses that.
• Volume is low or flows are simple. Below a few hundred transactions a month with no escrow requirement, a managed checkout (Stripe, Adyen) is less product surface, less compliance, and less code than a PI relationship.
• You cannot staff a French-speaking compliance counterparty. Lemon Way onboarding and KYC assume a European, often French-language, relationship — an operational commitment, not just an API commitment.

How to Pitch It (Stakeholders)

For executives: The package is a non-event — 0 stars, 0 dependents, Symfony-only, unmaintained, hosted on a personal Bitbucket namespace. It should not appear in our dependency tree. It is a breadcrumb: it confirms Lemon Way is integrable from PHP and lets us scope our escrow/marketplace-payout roadmap without burning engineering time on discovery. The decision on the table is vendor, not package. If we want to hold funds on behalf of users — marketplace payouts, delayed seller settlement, rental deposits — we are buying a licensed payment institution relationship. The integration is the cheap part; the compliance posture is the expensive, strategic part.

For engineering: Treat the bundle as documentation. Extract its configuration keys and service definitions to learn what the SDK requires, then build a small internal adapter behind our own PaymentProvider interface: Laravel service provider, config/lemonway.php, typed DTOs, idempotent request IDs, webhook verification with replay protection, request/response logging with PII redaction, and a reconciliation job against settlement statements. Route all outbound calls through Laravel's HTTP client so we inherit timeouts, retries, and logging. Never install the bundle into a Laravel app; never take a transitive dependency on an unmaintained package in a money path.

For the roadmap owner: Sequence it as a one-week sandbox spike, then wrap, then harden webhooks and reconciliation before any live traffic, then cut over behind a feature flag with a dual-run period. Assume the bundle contributes roughly 5% of total effort — the estimation risk sits in Lemon Way's object model (accounts vs. wallets, IBAN statuses, KYC states, money-in/money-out semantics, refund windows, PSD2/SCA), not in code volume.

Recommendation: Decline adoption of the package. Run a two-day spike against the Lemon Way sandbox using our own thin client, and bring a formal build-vs-buy paper — Lemon Way vs. Stripe Connect vs. Mangopay — to roadmap review before committing to escrow features. Adopt the pattern, not the package.