Moip Bundle Laravel Package

Technical Evaluation

tear/moip-bundle is a Symfony bundle from 2017 that wraps the MoIP payment gateway. It is effectively abandoned: 2 stars, 0 dependents, no release since October 2017, and a package score of 0.07. There is no meaningful community validation, no evidence of maintained CI, and no visible maintainer bench. For a TPM, the default posture should be do not adopt as a production dependency; evaluate it only as a reference for MoIP API behavior.

Architecture fit. The package is Symfony-specific, not Laravel-native. It will not plug into a Laravel service container, queue, or HTTP client stack without an adapter layer. Even in Symfony, bundles are a legacy packaging model; modern Symfony applications use Flex recipes and explicit service wiring. A thin, unmaintained bundle around a payment gateway adds indirection without adding safety.

Integration feasibility. Technically installable only on the PHP/Symfony versions it was built for—likely PHP 5.6/7.x and Symfony 2.8/3.x. On PHP 8+ or Symfony 5/6/7 it will almost certainly conflict through Composer constraints or deprecated APIs. Payment integration is a high-risk domain: authentication, idempotency, webhooks, refunds, reconciliation, and PCI scope. An abandoned wrapper is the wrong place to carry that risk.

Technical risk. High. Risks include unpatched transitive dependencies, an obsolete HTTP client without modern timeout/retry behavior, no compatibility with current MoIP/Wirecard APIs, and unclear handling of webhook signatures or idempotency. MoIP's corporate history—acquisition by Wirecard and subsequent restructuring—means the provider's brand, account terms, and API surface should be re-confirmed before any design work. The package may encode assumptions about endpoints or payloads that no longer exist.

Key questions.

• Is MoIP still the contractually required provider, and which current API version and account entity apply?
• Which payment methods are in scope: credit card, boleto, subscriptions, split, refunds, chargebacks?
• What is our PCI scope and tokenization model?
• Are we on Laravel or Symfony, and which PHP version is non-negotiable?
• Is there an official SDK or certified REST API we can use directly?
• Who owns payment operations, reconciliation, and on-call escalation?
• What is the deadline and budget for a direct integration versus a fork?

Integration Approach

Stack fit. Poor for Laravel. Laravel shares Symfony components but does not consume Symfony bundles. Leveraging this package would mean either (a) running a legacy Symfony service alongside Laravel, which adds a network hop and operational surface, or (b) copying selected classes into Laravel—at which point the package is reference material, not a dependency. For a Symfony 2.8/3.x estate, it may install, but that estate is itself end-of-life and should not anchor a new payment integration.

Migration path. Do not migrate onto this package. If it is already in production, isolate it behind an internal PaymentGateway interface immediately, then replace the implementation with a direct MoIP REST client. The interface should cover authorization, capture, refund, webhook verification, status lookup, and reconciliation export. Run the old and new paths in parallel in sandbox, then canary a small traffic slice before cutover.

Compatibility. Verify composer.json constraints for PHP, Symfony, Guzzle, and PSR packages. Expect conflicts with modern Laravel/Symfony and PHP 8. Check whether the bundle relies on deprecated Symfony APIs such as bundle auto-registration, old event dispatchers, or container-aware controllers. Any fork must be vendored under a private namespace with pinned dependencies and a documented patch policy.

Sequencing.

1. Confirm provider status, API version, credentials, and sandbox access.
2. Spike a direct REST integration for the two highest-value flows: card charge and webhook status update.
3. Define the internal payment abstraction and persistence model, including idempotency keys and audit logging.
4. Implement refunds, reconciliation, and failure handling.
5. Build contract tests against the sandbox and a certification checklist with finance/ops.
6. Parallel-run and reconcile against gateway settlement reports.
7. Decommission the bundle or fork; remove it from Composer.

Operational Impact

Maintenance. Adoption means owning a fork indefinitely. There is no upstream to patch security issues, track API changes, or fix PHP compatibility. Every PHP or framework upgrade becomes our problem. The package should be flagged in dependency audits and excluded from new work.

Support. No vendor support for the bundle. Gateway support covers official APIs, not this wrapper. Internal on-call must understand payment flows, credential rotation, webhook replay, and reconciliation. A TPM should budget for payment-domain ownership, not just code ownership.

Scaling. The bundle does not address scaling. Payment scaling is dominated by gateway rate limits, idempotent retries, queue-based webhook processing, and settlement reconciliation. The old HTTP client may lack connection pooling, configurable timeouts, and retry semantics, increasing tail latency and duplicate-charge risk under load.

Failure modes. Expect silent breakage when MoIP changes endpoints or payloads; timeout-induced double charges without idempotency; duplicate or out-of-order webhooks; partial refunds; boleto settlement mismatches; credential expiry; and unhandled gateway error codes. These are business-level failures—lost revenue, chargebacks, reconciliation breaks—not just exceptions.

Ramp-up. The codebase is small, so reading it is fast; the real ramp-up is payment-domain knowledge and provider-specific behavior. Plan one to two engineers for a two-to-four-week direct-integration spike, plus finance/ops time for reconciliation and compliance review. Leverage the package only to shortcut discovery of MoIP request shapes; do not let it set the architecture.