Mangopay Bundle Laravel Package

Product Decisions This Supports

• Marketplace / payout architecture: Evaluating whether to build multi-party payment flows (buyer → escrow wallet → seller payout, platform commission, refunds, KYC'd payees) on MangoPay's e-wallet model. MangoPay is an EU-licensed PSP built around wallets and payouts, which fits marketplaces, crowdfunding, and platform-mediated commerce far better than a plain card processor.
• Build vs. buy on payment orchestration: A bundle like this represents the "buy + thin wrapper" path — adopt MangoPay as the regulated money-movement layer and avoid building ledger, escrow, and payout reconciliation in-house. The existence of an MIT integration layer lowers the perceived integration cost in a build-vs-buy comparison; treat its staleness as part of the total cost of ownership.
• Framework/tooling fit for the roadmap: This is a Symfony bundle, not a Laravel package. If the roadmap is Laravel-based, this asset informs a "no" decision on direct adoption and a "yes" to using the official MangoPay PHP SDK behind an internal service/port instead.
• Roadmap sequencing for EU expansion: If the product roadmap includes EU sellers, SCA/PSD2 compliance, or payouts in EUR, evaluating MangoPay now de-risks a later migration away from a US-centric processor.
• Use cases this maps to: two-sided marketplaces, creator payouts, milestone/escrow releases, refund-and-chargeback workflows, and platform-fee capture.
• Risk register input: 26 stars, 0 dependents, and a last release in May 2019 should be logged as a maintenance/supply-chain risk in any dependency or vendor assessment.

When to Consider This Package

Consider it only when all of the following hold:

• The stack is Symfony (ideally 3.x/4.x era given the 2019 release), not Laravel.
• MangoPay is already, or is about to be, the chosen PSP — this bundle is a wrapper, not a differentiator.
• You need a fast proof of concept for wallet creation, pay-in, transfer, and payout flows, and want pre-wired service definitions and config rather than writing them.
• You are comfortable forking and maintaining it, since the upstream is effectively dormant.

Look elsewhere — specifically, at the official MangoPay PHP SDK wrapped in your own adapter — when:

• The application is Laravel. A Symfony bundle's DI extension, service config, and event model do not carry over; you would be reimplementing it anyway.
• You need current API coverage (MangoPay's API has evolved substantially since 2019: SCA, updated KYC/document endpoints, new payout and reporting surfaces). A seven-year-old wrapper will lag, and payment APIs are not safe to lag on.
• You require an actively maintained dependency with a security-response path, or your policy gates on release recency and dependent count (0 dependents is a signal no one else is exercising these code paths).
• You would otherwise introduce a framework-specific dependency into a domain (payments) where you want the integration isolated behind your own interface regardless.

Recommended posture: use it as a reference implementation for MangoPay's object model and flow sequencing; ship your own thin client over the official SDK.

How to Pitch It (Stakeholders)

For executives: MangoPay gives us EU-regulated wallet, escrow, and payout infrastructure that would take a year and a license to build — the classic buy-not-build call for a marketplace. This specific package is a small open-source (MIT) Symfony wrapper with a modest community footprint (26 stars) and no release since 2019. It is not the thing we would ship; it is evidence that the integration is a known, bounded problem and a useful sketch of the API surface. Recommendation: adopt MangoPay as a vendor if the EU marketplace case is approved, and budget a small, isolated integration layer over their official SDK rather than depending on this bundle.

For engineering: Treat troopers/mangopay-bundle as reference material, not a dependency. It is Symfony-only, so it is a non-starter for our Laravel services, and it predates several years of MangoPay API changes. The right shape is an internal payments port — one interface for wallet creation, pay-in, transfer, payout, refund, and KYC status — with a MangoPay adapter on the official PHP SDK behind it. That keeps the vendor swappable, keeps payment logic framework-agnostic, and lets us test flows without hitting the sandbox. Cost is low (days, not weeks) and it removes the maintenance risk of a dormant third-party bundle entirely.