Weave Code
Moip Laravel Package
artesaos/moip
Laravel integration for the Moip payment gateway, providing a fluent API to create orders, process payments, manage customers, and handle Moip webhooks and notifications within your PHP application.
Integration of MoIP payment intermediary with Laravel 5
Frequently asked questions about Moip
- Does artesaos/moip support Laravel 8, Laravel 9, or PHP 8?
- No. The package was archived in January 2018, and its illuminate/* and Guzzle version constraints target the Laravel 5.5 to 5.8 / PHP 7.0 to 7.2 era. On Laravel 8+ a plain composer require will almost certainly fail dependency resolution. Making it run on a modern stack is a fork-and-maintain exercise: bumping the framework constraints, upgrading Guzzle, fixing PHP 8 type and deprecation issues, then re-testing the fluent builders against live sandbox responses.
- How do I install artesaos/moip in a Laravel application?
- Install it with Composer, then register the package's service provider and facade alias in config/app.php (or rely on package auto-discovery if your Laravel version supports it). Publish the bundled configuration file with php artisan vendor:publish so you can supply credentials and select the sandbox or production environment. Keep the token and key in your .env file rather than committing them to the config. Because the package is abandoned, pin the exact version and expect to vendor a fork if you need any changes.
- How do I configure Moip sandbox versus production credentials?
- The published config file externalizes your MoIP token, key, and the target environment, so switching between sandbox and production is a configuration change rather than a code change. Generate the credentials in the MoIP dashboard for the matching environment and load them from environment variables. Test the full order and payment flow in sandbox first, since boleto settlement and notification timing behave differently from production.
- How do I create a customer, order, and payment with the Moip facade?
- The facade exposes a fluent builder: you create a customer, create an order with that customer and its items, then create a payment against the order, all through chained method calls instead of raw HTTP requests. The service provider binds the underlying client into the container, so the facade resolves it without manual bootstrapping. Because the package is unmaintained, verify method signatures against the source rather than assuming the README matches the released code.
- Can artesaos/moip process credit card and boleto payments?
- Yes. The package covers credit card and boleto flows, including checkout redirect handling and the payment creation calls behind each method. Boleto is where most of the operational value sits, because its asynchronous settlement is the part developers least want to hand-roll. Note that routing card data through an unmaintained wrapper has direct PCI scope implications, so confirm with your compliance owner before using it for cards in production.
- Does artesaos/moip support subscriptions and recurring billing?
- Yes. The package includes support for subscriptions and recurring billing on top of the one-off order and payment flows. In practice, recurring billing depends on webhook handling for status changes, so you should treat those two features as a pair. Test renewal and failed-payment paths explicitly, since the small user base means edge cases are not well battle-tested.
- How does artesaos/moip handle Moip webhooks and payment notifications?
- The package provides handling for Moip notifications so you can react to payment status updates instead of polling. Do not trust the incoming payload blindly: verify the notification against the MoIP API before mutating order state in your database. Webhook replay and out-of-order delivery are common with any gateway, so make your handlers idempotent and keyed on the MoIP resource identifier.
- Is artesaos/moip safe to use for production payments in 2024?
- It is a hard sell. The repository is archived with no releases since January 2018, meaning no security patches, no PHP 8 fixes, no Laravel 6+ support, and no maintenance of transitive dependencies such as Guzzle. In a payment path, an unpatched HTTP dependency is a compliance and audit finding rather than an inconvenience. Adoption is also low, which limits both battle-testing and community pressure to fix edge cases like webhook replay and partial refunds.
- What is the difference between Moip and Pagar.me, and which package should I use?
- MoIP was absorbed into Pagar.me, and the MoIP API is on a deprecation trajectory in favor of Pagar.me's current API. If your integration target is Pagar.me, this package is the wrong tool and the evaluation ends there. Start from the vendor's current SDK or a thin native client against the Pagar.me API. Only pursue artesaos/moip if you specifically need legacy MoIP v2 endpoints with a valid merchant account.
- How should I wrap artesaos/moip so I can migrate off it later, and how do I test it?
- Define a PaymentGateway interface in your own code covering only the operations you actually use - create order, capture payment, issue boleto, handle notification, refund - and put the package behind a single adapter implementing it. Application code then never touches the facade, so swapping to Pagar.me's current API later is a contained change instead of a refactor. Test the adapter against the MoIP sandbox and mock the interface for unit tests so your suite does not depend on live gateway calls. If the fork cost is high, skip the package entirely and build a thin internal client that satisfies the same interface.
Weaver
How can I help you explore Laravel packages today?