Filament Mercadopago Laravel Package

Product Decisions This Supports

• Feature scoping for payments in Filament admin panels. This package sits in the "wire a payment provider into our existing admin UI" category. It informs whether checkout, payment status, and reconciliation screens are something we configure or something we build. Decision: build vs. buy — leaning buy for the last mile, build for anything customer-facing and product-differentiating.
• LatAm market entry / pricing work. MercadoPago is the practical default for Brazil, Argentina, and Mexico (Pix, boleto, local card rails). If a roadmap item includes LatAm customers, this package is a candidate to shorten the payments portion of that work from weeks to days.
• Roadmap sequencing for billing. If we're not yet on a subscription model that justifies a heavier abstraction (e.g., Laravel Cashier + Stripe), a thin MercadoPago/Filament integration can unblock paid pilots without committing to a billing platform.
• Admin/ops tooling investment. Anything that puts payment state in front of support staff reduces manual back-and-forth. This is a cheap way to test whether support actually needs payment visibility in the admin panel before we invest in a real back-office build.

Release note (v1.0.1): the only change is a Dependabot bump of actions/checkout 7.0.0 → 7.0.1 in CI. No application code, no public API, no migrations, no config changes. Upgrade cost to us: zero. This release does not change any of the decisions above — treat it as a signal of basic maintenance hygiene, nothing more.

Caveat worth flagging to the team: our assessment is currently based on release metadata and the package's stated purpose, not on a code review or feature inventory. Before committing, someone should confirm what's actually implemented (preference creation, webhook handling, refunds, sandbox mode) versus what we'd still have to write.

When to Consider This Package

Adopt it when:

• We are already running Filament for internal admin and need MercadoPago payments surfaced there — the integration cost is otherwise a bespoke build we'd own forever.
• The requirement is a narrow payment slice: create a preference/checkout, read status back, show it to operators. That's the shape a package like this optimizes for.
• We want to validate a LatAm paid offering quickly and are comfortable with a small, single-maintainer dependency in a non-core path (with the code vendored or pinned).
• We're willing to write our own thin adapter around it so the rest of the codebase doesn't import the package directly.

Look elsewhere when:

• We need a gateway-agnostic billing layer (Stripe + MercadoPago + others behind one interface). Use a payments abstraction or a mature billing product instead; do not let a Filament plugin become your payments architecture.
• We need complex subscription lifecycle: proration, dunning, retries, tax, invoicing. That's Laravel Cashier territory or a dedicated billing service — not a UI plugin.
• We have enterprise support or SLA requirements, or a security review process that a v1.x, single-maintainer, low-adoption package won't survive. Version 1.0.0 → 1.0.1 with only a CI bump is thin evidence of production hardening.
• The payment UI must live in the customer-facing app rather than the admin panel — Filament is an internal tool; this is likely the wrong surface.
• PCI/compliance scope is unclear. Confirm the integration is redirect/hosted-checkout and that no card data ever touches our servers.

How to Pitch It (Stakeholders)

To executives: MercadoPago is how a large share of LatAm customers expect to pay, and this package lets us put that capability into our existing admin tooling in days rather than a multi-week build. It's a low-cost, reversible experiment for market validation — not a platform commitment. The trade-off is vendor concentration: one small maintainer, early version, limited adoption. We mitigate by pinning the version, reviewing the code before use, and keeping our own interface in front of it so we can swap providers without a rewrite. Recommended: adopt behind an adapter for the LatAm pilot; revisit if volume justifies a real billing platform.

To engineering: It's a Filament plugin wrapping MercadoPago — a UI-and-glue layer, not a payments engine. Use it strictly at the edges (admin resources, status views); keep business logic behind our own PaymentGateway contract so this dependency never leaks into domain code. Pin to ~1.0.1, vendor or lock it, and add a test around webhook handling since that's the failure mode that actually costs money. v1.0.1 is a no-op for us — a Dependabot CI bump only, no upgrade work required. Before we build on it, do a short read of the source to confirm webhook verification, idempotency, and sandbox support; if those are missing, we're writing them ourselves regardless of what we pay for the package.