Php Sdk Laravel Package

Technical Evaluation

Architecture fit. Despite the Composer-style name, lemonway/php-sdk is not an SDK — it is a reference implementation (php-client-directkit-xml, "PHP example calling DirectKit XML API with simple HTTP request"). It hand-builds XML envelopes and POSTs them to a Lemonway endpoint; there is no PSR-4 autoloading, no versioned release history, no tests, and no framework wiring. From a TPM's perspective, treat it as protocol documentation you can execute, not a dependency you install. If it enters the codebase at all, it must sit behind a PaymentGateway port in an infrastructure adapter. It should never surface XML strings or Lemonway vocabulary (wallets, wlLogin, wlRef) in the domain layer, or provider choice becomes a rewrite instead of a config change.

Integration feasibility. The valuable asset here is knowledge, not code: endpoint shapes for sandbox vs. production (/mb/{account}/directkitxml/), the required auth parameters per call (wlLogin, wlPass, walletIp, language, version), IP whitelisting, and request/response envelopes for wallet creation, card registration, MoneyInWebInit/MoneyIn, KYC upload, SEPA transfers, and refunds. That is several days of reverse-engineering removed from the estimate. The code itself will be copied and rewritten, not required. Realistic scoping: a two-week discovery-plus-adapter effort, dominated by Lemonway semantics and compliance onboarding, not by HTTP plumbing.

Technical risk.

• Unmaintained and unpinned. No semver, no Packagist constraint, no upgrade path. You fork it or you copy it — and then you own every line forever.
• Legacy protocol. DirectKit XML is the older surface; Lemonway steers integrators toward DirectKit JSON with OAuth2. A mid-project rewrite is the expensive failure case, so the deprecation question is a gating decision, not a footnote.
• Compliance exposure. Card registration and money-in drag PCI DSS, PSD2/SCA, and 3-D Secure into scope. If the sample posts raw PAN to your server, adopting it as-is puts you in scope where hosted fields/iframe would not.
• Robustness gaps. String-concatenated XML (injection vector), no timeouts, no retry policy, no idempotency, no structured error mapping, credentials in plain config. None of this is optional before real money moves.
• No validation signal. Six stars, zero dependents, no CI. Nobody has run this in production and told you about it.

Key questions.

1. Is the DirectKit XML endpoint still supported, and what is the published deprecation timeline versus JSON/OAuth2? (This determines whether the spike is worth funding.)
2. Does the sample require raw card data on our servers, or does it demonstrate hosted/iframe card entry? (This determines PCI scope and, therefore, cost.)
3. What are the contractual SLAs, rate limits, and support channels — and do we have a signed Lemonway relationship with sandbox credentials and whitelisted IPs?
4. Who owns reconciliation, refunds, and disputes operationally — us or Lemonway?
5. Is there a private, maintained client we could license instead of forking a public sample?
6. Does our stack need multi-currency or webhook tooling that this sample simply does not address?

Integration Approach

Stack fit. Laravel 8+/PHP 8.x with Composer is fine, but the sample predates modern conventions and will need porting rather than requiring. Natural home: app/Infrastructure/Payments/Lemonway/, promoted to a private Composer package (acme/lemonway-client) if more than one service consumes it. Configuration belongs in config/services.php with env-backed credentials, never in source.

Migration path.

1. Spike against sandbox to confirm endpoints, auth parameters, and the XML envelope still behave as the sample implies. Start with a read-only call — GetWalletDetails or GetWalletStatus on a manually created wallet — to validate credentials, IP whitelist, and XML parsing in one step. Do not open with MoneyIn/SendPayment; they are irreversible and noisy to debug.
2. Replace the transport. Discard the sample's raw cURL in favor of Laravel's Http client. That single change buys timeouts, retry with backoff, Http::fake() for tests, request/response events, and centralized logging.
3. Wrap in an adapter. LemonwayClient implements the PaymentGateway port; requests and responses become DTOs/value objects, not SimpleXMLElement. Map Lemonway error codes into a domain error taxonomy instead of leaking raw XML. Bind it as a singleton so config, logging, and instrumentation live in one place.
4. Model the async edges. MoneyInWebInit returns a redirect URL; terminal state arrives via return URL and/or server callback. Persist intent before redirect, key on wlRef/reference, and reconcile with a scheduled job.
5. Harden. Idempotency keys on every money-moving call, signature/IP verification on callbacks, structured logging with PII redaction, secrets in Vault/SSM.
6. Decide XML vs. JSON before building breadth. Keep the adapter interface stable so the implementation can be swapped later — the port is what makes that migration cheap.

Compatibility. Audit for PHP 5.x/7.x idioms and removed functions before porting. Assume no composer.json platform constraints, no namespaces, no type declarations, and no DI — nothing is mockable until it is rewritten. Budget the port accordingly rather than assuming it is a drop-in.

Sequencing recommendation. Gate the work: protocol spike first, then a go/no-go on XML versus JSON. If XML is on a short deprecation runway, stop and build against JSON from day one. If XML is confirmed stable, proceed to adapter, then a read-only call, then a sandbox money-in, then reconciliation, then production. Each step is a checkpoint a TPM can report against; each is independently abortable.

Operational Impact

Maintenance. Zero upstream maintenance — you own every line forever. Mitigate by forking into your own VCS with a real composer.json, a version tag, and tests around XML serialization and error mapping, so it becomes a controlled internal asset rather than a vendored mystery. Budget recurring effort for protocol drift and for the eventual JSON migration.

Support. No OSS community (6 stars, 0 dependents, no issue-tracker signal). Support is entirely commercial, through the Lemonway contract — meaning your incident response depends on a third party's business hours in a French regulatory context. That belongs in the risk register, not just the vendor file.

Scaling. The sample is synchronous and single-request: no connection reuse, no batching, no rate-limit awareness. Lemonway enforces its own limits, so throughput will be bounded by the provider, not by the PHP layer. Design accordingly: queue money-moving operations, exponential backoff on 5xx and network errors, never retry a non-idempotent call without a stored reference, and keep a per-account concurrency cap. Architect for the ceiling rather than discovering it at peak.

Failure modes to instrument explicitly.

• Partial multi-step flows — wallet created but card registration failed, leaving orphaned state.
• Lost responses on money-in — the call succeeded server-side, the response never arrived; without idempotency this becomes a duplicate charge.
• 3-D Secure redirect abandonment — user closes the browser mid-challenge; state must be recoverable, not lost.
• HTML error pages parsed as XML — provider maintenance or WAF blocks return non-XML; parsing must fail loudly into a known error type.
• Credential rotation — password-based auth means rotation is a deploy unless config reload is planned.
• Callback reordering and duplicates — handlers must be idempotent and state-machine-checked.

Ramp-up. Code complexity is trivial; domain complexity is not. Expect one to two weeks for a competent Laravel engineer to be productive, most of it spent on Lemonway semantics rather than the sample: wallet vs. account, fees and commission models, IBAN/BIC validation, SEPA direct debit, KYC document types, and PSD2/SCA rules. Someone on the team must own payments domain knowledge — reconciliation, refunds, and disputes are where these projects actually fail, and no SDK solves them.

TPM verdict. Fund this as a timeboxed discovery spike and adapter build, not an install. Its leverage is that it prices the "buy" side of a build-vs-buy decision and surfaces real integration surface area before contract signature. Adopt the knowledge, fork the code, wrap it behind an interface, confirm the XML deprecation timeline as a hard gate, and staff a payments domain owner alongside the engineer. The dominant costs will be KYC/compliance onboarding and reconciliation — plan and communicate the budget around those, not around the HTTP calls.