Moip Laravel Package

Product Decisions This Supports

• Brazil market entry / checkout feature scoping. If Brazil is on the roadmap, this package gives a concrete estimate of the integration surface for MoIP/Pagar.me: order creation, credit card and boleto, checkout redirects, and webhook status handling. Use it to size the payments epic before committing engineering time.
• Build vs. buy vs. wrap. The real decision is "direct REST integration vs. a Laravel-native wrapper." This package is a thin, MIT-licensed wrapper that collapses config, service container bindings, facades, and webhook plumbing into one dependency — a useful data point for whether a wrapper layer is worth owning.
• Prototype vs. production routing. Because it is fluent and container-driven, it is well suited to a time-boxed spike: validate the checkout and notification loop with real sandbox credentials in days, not weeks, and de-risk the "can we even take boleto?" question early.
• Reference architecture, not just a dependency. Even if we never ship it, it is a readable blueprint for how to structure a payment provider abstraction in Laravel: config-driven credentials, environment separation, testable service bindings, and a webhook controller boundary. That pattern is reusable for whichever gateway we ultimately pick.
• Legacy maintenance triage. If any existing product already depends on it, this drives a maintain / fork / replace decision — the package has been archived, so "do nothing" is itself a decision with a cost.
• Roadmap deprioritization signal. If Brazil, boleto, or MoIP/Pagar.me are not on the near-term roadmap, this drops out of consideration entirely and should not consume evaluation cycles.

When to Consider This Package

Consider it when:

• You have an existing Laravel app already integrated with the legacy MoIP API and need to keep the lights on. The wrapper preserves the current call surface and avoids a rewrite.
• You want a fast, throwaway prototype to validate Brazilian payment flows (card + boleto + webhook round-trip) before committing to a production stack.
• You need a reference implementation or a permissively licensed (MIT) starting point to vendor and fork into an internally owned payment module.
• Your team is small, Laravel-native, and values config/container integration over raw HTTP clients — and you accept ownership of the code.

Look elsewhere when:

• This is a new production build. The package is archived with a last release in January 2018. That predates modern PHP and Laravel versions, current Pagar.me API generations, and — critically — PIX, which is now table stakes for Brazilian checkout. No security patches, no maintenance, no API drift protection.
• You need capabilities the description does not cover: subscriptions/recurring, split payments, or antifraud. Verify coverage explicitly; do not assume.
• You need a supported vendor relationship. For production, prefer the official Pagar.me SDK or a maintained gateway abstraction, and budget for direct REST work.
• Compliance is load-bearing. A wrapper does not reduce PCI DSS scope or Brazilian regulatory obligations; if the compliance story is the blocker, a library choice will not solve it.
• You are standardizing payments across multiple countries. A single-gateway, single-country, frozen wrapper will not serve as a multi-provider abstraction.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Laravel wrapper around MoIP, a Brazilian payment gateway now part of Pagar.me. It is not a strategic bet — it has 38 stars, was last released in 2018, and is archived. Its value to us is decision velocity, not production readiness: it lets us prototype Brazilian card and boleto checkout quickly and gives us a clean reference pattern for payment provider abstraction. Recommendation: fund a short, time-boxed evaluation spike using it as a prototype and blueprint; do not adopt it as the production payments dependency without a fork-and-own plan, and note that it predates PIX entirely.

To engineering: Fluent API for payments and orders, credit card and boleto support, checkout redirects, and webhook/notification handling, wired into Laravel via service provider, config, and facade — so credentials and environments stay out of code and are testable. The trade-off is stark: excellent ergonomics, zero maintenance. Treat it as vendored source, not a versioned dependency. Expect to own PHP/Laravel compatibility, API drift against current Pagar.me endpoints, and any new payment method (PIX especially). If we adopt, the first task is a fork with a named owner and a documented exit path.

Framing the risk honestly: Low cost of trying, high cost of depending. The recommended posture is evaluate and reference now, replace before production — capture the learning and the architectural pattern, and keep the production gateway decision separate from the prototype decision.