Moip Laravel Package

Technical Evaluation

Architecture fit. The package is a textbook Laravel-era integration: a service provider binds a client into the container, a config file externalizes credentials and environment (sandbox vs. production), and a facade exposes a fluent builder for orders, payments, and checkout redirects. For a Laravel 5.x application, this is a low-friction fit — no custom bootstrapping, no hand-rolled HTTP layer, and credentials stay out of code. For anything on Laravel 8+, the fit degrades sharply: the package predates the modern skeleton and its illuminate/* and Guzzle constraints almost certainly block a clean composer require.

Integration feasibility. Feasible only under a narrow set of conditions: an existing Laravel 5.5–5.8 codebase, PHP 7.x, and an active MoIP merchant account still issuing MoIP v2 credentials. Under those conditions, the fluent API and built-in checkout/boleto handling remove meaningful implementation effort. Outside them, integration becomes a fork-and-maintain exercise rather than a dependency addition, which changes the cost model entirely — you are not adopting a package, you are adopting a codebase.

Technical risk. This is the dominant concern and it is structural, not incidental:

• Archived status (last release 2018-01-25). No security patches, no PHP 8 compatibility fixes, no Laravel 6+ support, no maintenance of transitive dependencies (notably Guzzle). In a payment path, an unpatched HTTP dependency is a compliance and audit finding, not just a nuisance.
• Gateway lineage. MoIP was absorbed into Pagar.me, and the MoIP API is on a deprecation trajectory in favor of Pagar.me's current API. Building new functionality on MoIP endpoints means building on a surface the vendor is actively steering customers away from.
• PCI and payment-method exposure. Credit card and boleto flows carry direct PCI scope and settlement semantics. An unmaintained wrapper in this path is a materially different risk class than an unmaintained UI helper.
• Low adoption (38 stars). Small user base means limited battle-testing of edge cases — webhook replay, partial refunds, boleto settlement timing — and limited community pressure to fix them.

Key questions.

1. Are we integrating with MoIP specifically, or with Pagar.me? If Pagar.me, this package is the wrong tool and the evaluation ends here.
2. What Laravel and PHP versions are in scope today, and what is the upgrade horizon? A pending Laravel upgrade invalidates the package.
3. Is boleto support a hard requirement, or is credit card the only live method? Boleto's async settlement is where most of the operational complexity and most of the package's value sits.
4. Do we have a MoIP merchant account with valid v2 credentials, and has the vendor communicated an API sunset date?
5. Are we willing to own a fork indefinitely? If not, the decision is to build a thin internal adapter instead.
6. What is our PCI scope today, and does routing card data through this wrapper change it?

Integration Approach

Stack fit. Assume Laravel 5.5–5.8 with PHP 7.0–7.2 as the supported envelope. Anything newer requires a fork: bumping illuminate/* to the target major, upgrading Guzzle, resolving PHP 8 type and deprecation issues, and re-testing the fluent builders against live sandbox responses. Budget that fork as real engineering work, not as a dependency bump.

Migration path. The recommended path is not to install the package directly into application code. Instead:

1. Isolate behind an interface. Define a PaymentGateway contract in application code covering the operations we actually use — create order, capture payment, issue boleto, handle notification, refund. This is the single most valuable step and it is cheap.
2. Adapt the package to that contract. If we adopt artesaos/moip, it lives inside one adapter class. Application code never sees the facade. This makes the eventual swap to Pagar.me's current API a contained change rather than a refactor.
3. Prefer a thin native client if the fork cost is high. Given the archived state, a ~300-line client built on Laravel's Http facade against the MoIP endpoints we need may be less total risk than resurrecting a 2018 dependency tree — and it produces code we can actually patch.

Compatibility. Expect breakage in three places: Composer constraints against modern Laravel, Guzzle major-version conflicts with other installed packages, and PHP 8 runtime deprecations. Treat all three as known work items with test coverage against the MoIP sandbox, not as unknowns to discover during rollout.

Sequencing.

1. Confirm gateway identity and API sunset posture with the vendor — this gates everything.
2. Confirm current Laravel/PHP versions and the upgrade horizon.
3. Decide: fork the package, or build a thin client. Decide before writing any integration code.
4. Define the PaymentGateway contract and land it with no implementation.
5. Build the adapter against sandbox; cover order creation, card capture, boleto issuance, notification handling, and refund.
6. Feature-flag the integration; run in sandbox through a full order lifecycle including boleto settlement and a refund.
7. Production rollout behind the flag, with the legacy path retained for rollback.

Operational Impact

Maintenance. The package is archived, so maintenance is entirely ours. Assume an internal fork with a named owner, a pinned commit, and a standing obligation to track PHP and Laravel upgrades independently of upstream. If no team is willing to own that, this is a disqualifying finding — an unowned payment dependency is an outage waiting for a reason.

Support. Community-only, and the community is small and dormant. Vendor documentation for the MoIP API will be sparse and increasingly stale as Pagar.me redirects effort to its current platform. Escalation for gateway-side issues runs through Pagar.me support with MoIP-specific questions, which is a slow path. Plan for internal expertise rather than external rescue.

Scaling. The wrapper is thin — it adds negligible overhead, so throughput is bounded by the gateway, not the package. The real scaling concern is synchronous HTTP inside request cycles: card authorization and boleto issuance should not block user-facing requests where avoidable, and notification processing must be queued. Webhook volume during peak sales is the load characteristic to design for.

Failure modes. These are the ones to instrument and rehearse:

• Webhook loss or duplication. No delivery guarantee; handlers must be idempotent and keyed on gateway transaction ID. Duplicate processing of a payment confirmation is a reconciliation incident.
• Notification authenticity. Verify the source and payload; an unauthenticated status callback that flips an order to paid is a fraud vector, and the package's handling here is 2018-era and must be reviewed rather than trusted.
• Status mapping drift. MoIP status enums mapped incorrectly to internal states produce silent order-state corruption. Map explicitly and test every terminal state.
• Timeout and retry semantics. HTTP timeouts on capture create ambiguous outcomes — the payment may have succeeded. Capture operations need idempotency keys and a reconciliation job, not blind retries.
• Async boleto settlement. Boleto is not real-time; orders must tolerate a pending state for days and reconcile against the gateway's settlement report.
• Credential/environment confusion. Sandbox and production credentials share a config file; a misconfigured deploy that points production traffic at sandbox is a classic and silent failure.
• Dependency rot. A transitive dependency CVE with no upstream patch path forces emergency forking under incident pressure.

Ramp-up. Low for a Laravel developer — the fluent API and facade follow familiar conventions, and a working order flow is a day or two of sandbox work. The non-obvious cost is domain ramp-up: MoIP's order/payment/notification model, boleto settlement timing, refund semantics, and the Pagar.me migration landscape. Budget for that separately from framework familiarity, because it is where integration mistakes actually originate. Overall recommendation: adopt only behind an internal PaymentGateway abstraction, with explicit fork ownership and a documented exit path to Pagar.me's current API; otherwise build the thin client directly and skip the dependency.