Moip Sdk Php Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance. v3.1.0 does not add a service provider, publishable config, facade, or Laravel-native integration; it remains a thin OOP client over Moip's REST API. The new surface (getBalances(), transfer creation, getPasswordLink(), item category on addItem()) extends the domain model rather than changing the packaging model. The adapter-layer recommendation still holds: config file, service provider binding a configured singleton, gateway interface, DTOs, no SDK types leaking into controllers or models. If anything, the widened surface strengthens the case for the abstraction — there are now more resources a product team may want to reach, and each one should be exposed deliberately through the adapter rather than by injecting the SDK directly.

Integration feasibility. This is the material change. The previous assessment's central premise was that the repository was archived with a last release in January 2018. A tagged v3.1.0 with linked commits falsifies that premise: the project is receiving commits, merging fixes, and cutting releases. That shifts feasibility from "fork or abandon" to "consume with verification." The verification burden is not eliminated, merely relocated:

• Release-line continuity. v3.1.0 implies an existing 3.x line. The 2.x→3.x changelog must be read before adoption; the breaking changes almost certainly live in 3.0.0, not here. We need to confirm what 3.x requires of PHP, Guzzle, and PSR interfaces.
• Maintenance signal strength. One release is a data point, not a trend. Establish cadence: how many releases in the trailing twelve months, how are issues triaged, is the repository un-archived and is there a named maintainer or org?
• API currency. New endpoints for balances and bank-account transfers suggest the client is tracking a current Moip API version, which reduces (but does not remove) the API-lifecycle risk previously flagged.
• Laravel fit. Still unverified from release notes alone; a composer.json and dependency-resolution audit under the target Laravel version remains the gating step.

Technical risk. Downgraded from high to moderate, with the composition changed. Abandonment risk is substantially reduced but not retired — the SDK now has recent activity, but there is no evidence yet of a support commitment, security policy, or long-term maintainer. Dependency-drift risk is likely improved by a 3.x line that presumably targets modern PHP and Guzzle, but this must be confirmed rather than assumed; a 3.x that still pins Guzzle 6 would leave the original conflict intact. API-lifecycle risk is reduced by the presence of newer resources. The residual risks are: dependency resolution against Laravel 9/10/11, the absence of upstream security disclosure process, and the possibility that activity is bursty rather than sustained. Treat the fork option as contingency rather than default.

Key questions.

• Is the 3.x line actively maintained — what is the release cadence, issue-triage latency, and is there a named owner or organizational sponsor?
• What PHP, Guzzle, and PSR constraints does 3.x declare, and do they resolve cleanly under the target Laravel version?
• What changed in 3.0.0, and what is the upgrade cost from any 2.x code already in the estate?
• Do the new balances/transfers capabilities imply marketplace or split-payment support we now need to design for, and do they change our Moip account configuration or compliance obligations?
• Does the project publish a security policy or CVE-response path, and what is the cadence of dependency updates?
• Retained from prior assessment: webhook signature verification and idempotency, and whether Moip remains the correct provider for the target market.

Integration Approach

Stack fit. Unchanged. Wrap, don't call directly. The new resources are an argument for discipline, not against the abstraction: balances and transfers are money-movement operations that should sit behind an audited service class with explicit authorization, logging, and possibly dual control, not be reachable from a controller.

Migration path. Reordered in light of the release:

1. Consume 3.x behind the abstraction — now the preferred path, contingent on a clean dependency resolution and a satisfactory answer on maintenance cadence.
2. Fork only the specific gaps — if 3.x resolves but lacks a needed fix or a security patch cadence, maintain a narrow patch set on top of the upstream tag rather than vendoring the whole library.
3. Replace with an alternative client — retained as fallback; the gateway interface keeps this a one-class change.

The prior "fork and modernize the archived code" path is demoted; modernizing a 2018 codebase is no longer the expected work.

Compatibility. Audit composer.json for the 3.x line against the host application: PHP constraint, Guzzle major version, PSR interface versions. Read the 3.0.0 changelog for breaking changes before any upgrade from 2.x. Confirm the new methods (getBalances, transfer creation, getPasswordLink) behave against the sandbox and that their request/response shapes match current Moip documentation.

Sequencing.

1. Maintenance and dependency audit: release cadence, composer.json constraints, changelog review, resolution test under the target Laravel version. Timebox to days.
2. Sandbox spike, extended to cover the new surface: OAuth, customer, order with item category, credit card and boleto payment, webhook receipt, balance retrieval, and a transfer to a saved bank account.
3. Build the adapter: config, service provider, gateway interface, DTOs, and an audited transfer service.
4. Webhook endpoint with idempotency keys, signature/authentication checks, durable queue handoff, reconciliation job.
5. Observability and sandbox contract tests on a schedule; wire the maintenance audit into the dependency-review process.
6. Expose to product flows only after 1–5.

Operational Impact

Maintenance. Materially improved but not free. The upstream now appears to accept fixes, which means we can consume patches instead of authoring them. That benefit is conditional on the activity being sustained and on our dependency-review process actually picking up new tags. Maintain a lightweight internal record of the pinned version, a quarterly check for new releases and CVEs, and a documented upgrade path. Retain the option to fork if upstream activity lapses; do not delete the contingency.

Support. Still no commercial support channel and no vendor relationship covering the SDK itself. Moip's API documentation and support remain the escalation path for platform issues; the SDK's issue tracker is now a plausible secondary channel, which it was not before. Internal documentation of the adapter, credential rotation, and transfer authorization remains essential.

Scaling. Unchanged. Synchronous HTTP client; scaling is a function of the host application, Moip rate limits, and checkout-path latency. Queue long-running payment calls where UX permits. Webhook ingestion stays decoupled via a queue. The new balance and transfer endpoints add outbound call volume to money-movement paths — apply the same retry, circuit-breaking, and idempotency treatment, and treat transfers as non-idempotent unless an ownId is supplied (the release adds ownId get/set on transfers, which is the correct mechanism for exactly this).

Failure modes.

• OAuth token expiry or revocation causing cascading 401s; token caching, refresh, alerting.
• Webhook duplicates, failures, and out-of-order events; idempotency keys, signature checks, reconciliation.
• Duplicate or misdirected transfers — newly relevant given the transfer capability; require ownId as an idempotency key, enforce authorization, and reconcile against balances.
• Maintenance regression — upstream activity stalls and the package quietly returns to archived status; requires the scheduled maintenance check rather than an assumption of health.
• Dependency CVEs or resolution conflicts on framework upgrades; requires the dependency audit and isolation option.
• Silent API drift breaking an otherwise healthy client; requires scheduled contract tests against the sandbox.
• Timeout and partial-failure states in order/payment creation producing inconsistent local state; requires reconciliation and explicit state machines.
• Item category regression — the new addItem() argument is optional in the release, but confirm it is not silently required by Moip for certain product types, which would break existing order creation on upgrade.

Ramp-up. Moderate, unchanged for the core SDK. The new surface adds Brazilian money-movement domain knowledge — balance semantics, transfer settlement timing, and bank-account verification — on top of the existing CPF/CNPJ, boleto lifecycle, installment, and split-payment topics. Assign one senior engineer as owner for the adapter and the upstream-version relationship, and extend the internal knowledge-sharing session to cover transfers, ownId idempotency, and the transfer authorization rule.