Mercadopago Fake Laravel Package

Product Decisions This Supports

• Test strategy for payment flows (build vs. buy): this package replaces hand-rolled Mercado Pago HTTP stubs/fakes with a maintained fake. The decision it informs is whether to keep paying engineering time to maintain in-house test doubles or adopt a dependency — and whether that dependency's release cadence is acceptable.
• Platform upgrade sequencing (roadmap): 2.0.0 hard-requires PHP 8.5 and puntodev/mercadopago ^8.0. This makes the fake a forcing function on your PHP and SDK upgrade roadmap — it is now a trailing indicator of the runtime version you must already be on.
• CI reliability / cost: a deterministic fake (no sandbox calls, no network, no credentials in CI) directly affects flaky-test rate, pipeline duration, and whether payment tests can run on every PR vs. nightly.
• Dependency risk register: the fake's major version is pinned to the real SDK's major. Every upstream SDK major forces a matching fake major, so the package adds a second coupled upgrade to every Mercado Pago integration change.
• Scope boundaries for QA: clarifies that unit/integration coverage of your payment orchestration lives in the fake, while real-sandbox or contract testing is a separate, deliberate line item.

When to Consider This Package

Consider adoption when:

• You are on puntodev/mercadopago (not the official mercadopago/sdk-php) — the fake targets that SDK's surface, so it is only useful inside that ecosystem.
• You are already on PHP 8.5, or are willing to gate this upgrade behind your PHP 8.5 migration. On PHP 8.4 or below you must stay on 1.0.x, which means accepting an unsupported-version path and no further fixes.
• Your test suite currently stubs Mercado Pago by hand, or hits the sandbox in CI, and you want deterministic responses for approval/rejection/pending/webhook scenarios.
• You want payment tests to run on every PR and in offline/dev environments.
• You accept a small, single-maintainer dependency with a weekly Dependabot cadence and a release notes process that flags breaking changes explicitly (a good sign, but still a bus-factor consideration).

Look elsewhere (official SDK test helpers, contract tests against sandbox, or an in-house fake) when:

• You use the official Mercado Pago PHP SDK, or call the REST API directly.
• You need genuine end-to-end validation of credentials, webhook signature verification, or Mercado Pago-side behaviour — a fake cannot validate those, and over-relying on it creates false confidence.
• You cannot move to PHP 8.5 on a timeline that keeps you on a supported major; running 1.0.x indefinitely is a debt, not a plan.
• Your compliance/security posture requires a maintained vendor with an SLA.

How to Pitch It (Stakeholders)

To executives: this is a small open-source testing utility for our Mercado Pago integration. The value is straightforward — it lets us test payment flows deterministically without touching Mercado Pago's sandbox, which cuts CI flakiness and shortens the feedback loop on payment changes. The cost is not licence fees but timing: the new 2.0.0 release requires PHP 8.5 and a matching major of the Mercado Pago SDK, neither of which we run today. So this is not a "adopt now" decision; it is a decision to sequence it behind our PHP 8.5 upgrade, and to keep the payment test suite on the current 1.0.x line until then. No spend, no vendor contract, modest ongoing maintenance risk from a single-maintainer project.

To engineering: 2.0.0 is a breaking release with no functional changes — it is purely a platform bump (PHP >= 8.5, puntodev/mercadopago ^8.0). That means the upgrade itself is low-risk if the platform upgrade lands first; the real work is the PHP 8.5 and SDK 8 migration, not this package. Two things to note before committing: (1) the fake's major tracks the SDK's major, so every future SDK major is a paired upgrade — budget for that; (2) the fake must not become our only payment test. Keep a thin layer of sandbox/contract tests for webhook signatures, auth, and any Mercado Pago behaviour we don't control. Recommended path: pin 1.0.x now, add a tracking ticket for PHP 8.5 + SDK 8 + fake 2.0 as a single coordinated change, and re-evaluate if the package goes more than one SDK major behind.