Paypal Fake Laravel Package

Product Decisions This Supports

• Test strategy for PayPal-integrated checkout flows — puntodev/paypal-fake lets teams exercise payment, subscription, refund, and webhook paths in CI without hitting PayPal sandbox endpoints or managing sandbox credentials/secrets. This directly de-risks "build vs. stub it ourselves" decisions: adopting a maintained fake removes an internal test-utility codebase from the roadmap.
• Roadmap sequencing for PHP/Laravel platform upgrades — 2.0.0 requires PHP 8.5 and puntodev/paypal ^7.0. Any roadmap item that moves the platform to PHP 8.5 must sequence the PayPal SDK upgrade and this test-double upgrade together; conversely, a decision to stay on PHP 8.4 freezes this package at 1.0.2 (still supported, but no further fixes).
• Release-gating and environment parity — the fake enables deterministic, offline test suites, which supports decisions about how much of the payment surface is covered by automated gates vs. manual QA in sandbox.
• Dependency footprint / supply-chain posture — this is a small, single-maintainer test-only dependency. That is a low-risk addition under a "test-only dependencies are cheap" policy, but it is a bus-factor consideration if the team makes it the backbone of payment CI.
• Upgrade cost estimation for Q-planning — the 2.0.0 change set is exclusively dependency bumps (PHP 8.5, SDK ^7.0) plus Dependabot/CI housekeeping. No new features, no new test helpers, no deprecations beyond the version floor. Effort is bounded by the host project's PHP 8.5 readiness, not by rework in the test suite.

When to Consider This Package

Adopt when:

• The product integrates PayPal via puntodev/paypal and the team wants payment-related tests (create order, capture, refund, webhook handling) to run in unit/integration suites without network calls.
• The project is on, or planning, PHP 8.5 and puntodev/paypal ^7.0 — the only configuration 2.0.0 supports.
• You want reduced CI flakiness and no PayPal sandbox secrets in CI, and you value a fake that stays version-locked to the real SDK's contract.
• Test coverage of failure modes (declined payments, API errors) matters and you'd otherwise hand-roll mocks.

Look elsewhere / stay put when:

• The project is on PHP 8.4 or earlier, or on puntodev/paypal 6.x or below — remain on the 1.0.x line and plan the platform upgrade first. Do not attempt a partial upgrade.
• You need a fake for a different payment provider or a provider-agnostic abstraction; this is PayPal-specific.
• You require a maintained test double with committed SLAs, multiple maintainers, or a long-term support window — 2.0.0 ships with a single maintainer and a hard PHP 8.5 floor, which is a real risk for teams with slower upgrade cadences.
• You are on a non-Laravel/plain-PHP stack with no dependency on the underlying SDK; a bespoke stub is cheaper.

How to Pitch It (Stakeholders)

To executives: This is a small, test-only library that lets our engineers test PayPal checkout without touching PayPal's servers. The new 2.0.0 release adds no product features — it simply requires PHP 8.5 and the next major version of our PayPal SDK. Practically, it means the cost of the payment-integration upgrade is now coupled to our PHP 8.5 migration: we get better payment test reliability for free when we upgrade the platform, and nothing breaks if we don't. There is no direct revenue impact, but it lowers the risk of shipping a payment bug and keeps PayPal secrets out of CI. Risk to flag: single maintainer and a strict version floor, so we should not make it the sole safety net for payments.

To engineering: 2.0.0 is a breaking release driven entirely by dependency floors — PHP 8.5+ and puntodev/paypal ^7.0. Everything else in the release is CI/Dependabot housekeeping and release-note labelling. Treat it as a lockstep upgrade: bump puntodev/paypal to ^7.0, confirm runtime is PHP 8.5, then bump this package and re-run the payment test suite. If we're not ready for PHP 8.5, pin to 1.0.2 and add a tracking ticket; there is no functional gap in staying behind, only a freeze on fixes. Because it is a fake, failures surface as test failures, not production incidents — but that also means the fake's fidelity is our only early warning, so budget a short verification pass against real PayPal sandbox when the SDK major changes.