Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Mango Pay Bundle Laravel Package

teknoo/mango-pay-bundle

Symfony bundle integrating the MangoPay payment API, providing ready-to-use services for managing users, wallets, bank cards, transfers, and payment operations within Symfony applications. Simplifies configuration and wiring of MangoPay into your service container.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

  • Architecture fit: Poor for a Laravel codebase. This is a Symfony bundle (Symfony 2.7+) that wires the MangoPay PHP SDK into Symfony’s DI container as services. Laravel has no bundle/kernel/container-definition compatibility, so the package cannot be installed and used as intended.
  • Integration feasibility: Low. A Laravel team would need to bypass the bundle and integrate the underlying MangoPay PHP SDK directly, or port the bundle’s service definitions into a Laravel service provider. The bundle’s value is thin: configuration and service registration, not payment-domain logic.
  • Technical risk: High. The package is explicitly archived and unmaintained, last released in 2019, has 2 stars and 0 dependents. Payment integrations are security- and compliance-sensitive; stale SDK wiring, PHP version drift, and unpatched dependencies are material risks. The bundle targets Symfony 2.7-era conventions and likely conflicts with modern Laravel PHP requirements.
  • Key questions: Is the underlying MangoPay PHP SDK still actively maintained and compatible with our PHP/Laravel version? Can we integrate the SDK directly with a small internal service provider? What MangoPay capabilities do we need—webhooks, idempotency, payouts, KYC, refunds? Do we require PCI/compliance review? Is the MIT license sufficient for a fork, and who owns maintenance?

Integration Approach

  • Stack fit: Not a fit for Laravel. Treat it as a Symfony-only artifact. For Laravel, use the official MangoPay PHP SDK via Composer and implement a Laravel service provider, facade, and configuration file internally. For a legacy Symfony 2.7/3.x application, the bundle may technically install, but archived status still argues against new adoption.
  • Migration path: Do not migrate the bundle into a Laravel application. If inherited in a Symfony app, freeze it, document current behavior, and plan replacement with direct SDK usage behind an internal interface. For Laravel, run a short spike: install the SDK, configure credentials via environment variables, wrap the client in a MangoPayService, and add contract tests against sandbox credentials.
  • Compatibility: Verify PHP version constraints for both Laravel and the MangoPay SDK. The 2019 bundle likely assumes older Symfony DI and PHP versions; modern Laravel requires PHP 8.1+. Composer resolution may fail or require unsafe overrides. Avoid --ignore-platform-reqs in production.
  • Sequencing: 1) Confirm MangoPay SDK support status and API version. 2) Prototype direct SDK integration in Laravel. 3) Implement config, webhook verification, idempotency, and logging. 4) Add sandbox integration tests. 5) Use the bundle only as a reference for service wiring ideas, not as a dependency. 6) Obtain security/compliance sign-off before production.

Operational Impact

  • Maintenance: Effectively zero upstream maintenance. Archived status means no bug fixes, security patches, or compatibility updates. Any use creates a fork-and-own burden. Direct SDK integration also requires ownership, but avoids maintaining obsolete Symfony bundle glue.
  • Support: No community support; 2 stars and 0 dependents indicate negligible ecosystem. The vendor’s contact offer is not a substitute for an SLA. Internal engineering ownership and vendor support for MangoPay itself must be confirmed.
  • Scaling: The bundle is a thin DI wrapper and is unlikely to be the scaling bottleneck. Actual scaling concerns are MangoPay API rate limits, webhook throughput, retry/idempotency behavior, and payment reconciliation—none of which this bundle solves.
  • Failure modes: Stale SDK breaks against MangoPay API changes; PHP/Symfony incompatibility blocks upgrades; unpatched dependencies create security exposure; misconfigured DI services fail at runtime; missing webhook/idempotency handling causes duplicate or lost payment events; no test coverage increases regression risk.
  • Ramp-up: Low effort to understand the bundle’s small surface area, but high effort to safely own a payment integration. A TPM should budget for SDK evaluation, sandbox testing, webhook/error-handling design, compliance review, and ongoing dependency maintenance—not for bundle adoption. Recommendation: do not adopt; use direct MangoPay SDK integration in Laravel.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode
jjsquady/round-robin