Php Sdk Laravel Package

Product Decisions This Supports

• PSP selection and vendor evaluation. This repository is the fastest way to scope what a Lemonway integration actually requires before signing anything. It exposes the real surface area — wallet creation, KYC document upload, IBAN validation, SEPA credit transfers, refunds, and multi-party payouts — so the decision is grounded in evidence rather than a sales deck.
• Build vs. buy for money movement. For a marketplace, crowdfunding platform, or remittance product, the alternative to Lemonway is building a wallet ledger, reconciliation engine, and regulatory coverage in-house. This sample lets you put a credible estimate against the "buy" side of that comparison.
• Roadmap sequencing. It separates commodity capabilities (payouts, IBAN checks, e-money accounts) from genuinely differentiating ones, which helps place escrow, split payments, and seller onboarding correctly on the roadmap.
• Integration-risk pricing. The code itself is a signal: XML-over-raw-HTTP, no Composer manifest, no typed DTOs, no tests, no retry or idempotency layer. That is precisely the work your team must do on top of it — and that estimate belongs in the business case, not in a post-launch surprise.
• Use cases it directly informs: EU marketplaces, crowdfunding, gift and cash-out flows, and any product needing licensed e-money accounts with SEPA payout rails.

When to Consider This Package

Consider it when:

• Lemonway is already on your PSP shortlist and you need a timeboxed technical spike to learn the DirectKit XML contract — endpoints, authentication parameters, request/response envelopes, and error codes.
• You want a concrete artifact to anchor a build-vs-buy estimate against Mangopay, Adyen for Platforms, or Stripe Connect.
• Your team is on PHP/Laravel and needs a scaffold for a proof of concept — explicitly not a production dependency.

Look elsewhere when:

• You need a maintained, versioned, Composer-installable SDK with semantic versioning, typed models, tests, and an upgrade path. This is example code, not a library — six stars and zero dependents is the honest signal.
• You need modern client ergonomics: PSR-18/PSR-17 HTTP abstraction, retries, idempotency keys, structured logging, or framework integration.
• Your stack is not PHP, or you need strong multi-currency and webhook tooling out of the box.
• You are tempted to vendor it straight into production. Treat it as documentation. Put any integration behind your own PaymentProvider interface so swapping providers later is a configuration change rather than a rewrite.
• The DirectKit XML endpoint has no confirmed support runway. If Lemonway's forward path is JSON/OAuth2, build against that from day one.

How to Pitch It (Stakeholders)

For executives: Lemonway is a licensed EU payment institution supplying wallets, escrow, and SEPA payouts without us holding a license or building a ledger ourselves. This repository is their public PHP sample, not a production SDK — its value is that it lets us price the integration before we commit. The strategic question is whether their licensing and payout model fits our marketplace; the sample removes guesswork from the estimate. The dominant costs will be KYC/compliance onboarding and reconciliation operations, not the HTTP calls — those are where comparable projects overrun.

For engineering: Read it as a specification, not a dependency. Use it to learn the DirectKit XML contract, credential handling, and error taxonomy, then implement a thin, tested client behind our own PaymentProvider interface using Laravel's HTTP client or PSR-18. Budget explicitly for idempotency, retry/backoff, state reconciliation against settlement files, callback signature verification, and sandbox-driven contract tests — none of that exists here, and all of it is mandatory before we move real money. Sequence it as a two-week discovery-plus-adapter effort: protocol spike first, then confirm the XML deprecation timeline before building breadth.