Laravel Cashier Braintree Laravel Package

Product Decisions This Supports

• Gateway selection (Braintree vs. Stripe vs. Paddle). This package is downstream of that decision, never a reason for it. Braintree is PayPal-owned, which shapes checkout UX (cards, PayPal, Venmo), international coverage, dispute handling, and the shape of the billing support queue — a multi-year commitment. Use this package to cost the Braintree path, not to choose it.
• Build vs. buy vs. inherit. A Cashier-style API converts subscription plumbing — trials, coupons, proration, swap, cancel/resume, card updates, webhook reconciliation — from "build" into "integrate," compressing time-to-market for a standard paid tier from quarters to weeks. The honest framing: because the repo is archived, "buy" quietly becomes "inherit and fork." The real decision on the table is whether the team will own a payment-integration fork, not whether to adopt a maintained library.
• Roadmap scoping and non-goals. The package covers the happy-path subscription lifecycle. It does not deliver usage-based metering, tiered overages, tax-compliant invoicing, revenue recognition, or marketplace payouts — knowing that boundary keeps an epic from promising more than the integration can carry.
• Maintenance and upgrade allocation. Last release 2019-10-09 (4.0.0), archived read-only, 5 stars, 0 dependents, Braintree SDK pinned at 4.x. Adoption books a recurring, unfunded-by-upstream cost line: dependency patching, Laravel/PHP compatibility, and security response. This is a budget item, not a footnote.
• Exit and contingency planning. Three credible paths — fork and own it, strip the abstraction and call the Braintree SDK directly, or migrate to maintained Cashier for Stripe/Paddle. Each is a roadmap item with a different cost, and the choice should be made before billing becomes load-bearing. The low opportunity score and zero-dependents signal argue for treating this as a reference implementation to inform scope, not a runtime dependency.
• Support and incident posture. Recurring billing is high blast radius: a dropped webhook means wrong entitlements or wrong charges. This dependency argues for a dedicated on-call path, webhook replay tooling, and reconciliation reports budgeted alongside the feature — not after launch.
• Compliance scope. Braintree's Drop-in UI keeps card data out of your systems, a durable PCI-surface reduction that holds regardless of how the package-health question resolves.

When to Consider This Package

Consider it only in narrow, explicitly costed cases:

• You already run it. A legacy Laravel 5.x/6.x app with the package in composer.json and live Braintree subscriptions. The question is upgrade-and-fork strategy, not adoption.
• You need a readable reference implementation. The 4.0.0 README carries full Cashier documentation alongside the code — useful for learning the contract (subscriptions, swaps, proration, the Billable trait, WebhookController) before writing a thin first-party layer.
• You have a short-lived or internal surface — a pilot, internal tool, or time-boxed paid tier you expect to replace — where inheriting an unmaintained fork is an acceptable, named trade.
• You are prepared to fork deliberately, with a named owner, fork branch, pinned commit SHA, and a plan to track Laravel and Braintree SDK releases yourself.

Look elsewhere when:

• This is a new build. Archives are read-only; there will be no fix for a Laravel major, a PHP minor, or a Braintree SDK break. Expect dependency-resolution failures before runtime bugs.
• You need an SLA, security patching, or a support contact. There is none. Zero dependents and a 2019 release mean the ecosystem has already voted.
• The gateway decision is still open. Evaluate Braintree vs. Stripe as the decision, and benchmark against actively maintained Cashier for Stripe or Paddle.
• Your billing model is usage-based, metered, multi-currency with tax, or requires invoicing/revenue recognition. Out of scope for a thin wrapper regardless of who maintains it.
• You are not on Laravel, or you are on a Laravel version released after 2019 — the release notes state no support matrix.
• Your compliance posture demands minimal, auditable third-party code in the payment path. Fewer moving parts beats convenience here.
• Pricing is still unsettled. Committing to Braintree's subscription abstractions early is real switching cost if you later go hybrid or consumption-based.

Before any commitment, verify in code — not the README: the supported Laravel/PHP matrix (run the suite against our actual composer.json), webhook signature verification and idempotency behavior, retry handling, and whether tests actually cover refunds, disputes, and subscription state transitions.

How to Pitch It (Stakeholders)

To executives: This is a Laravel-native wrapper that turns "build a subscription billing system" into "configure a documented one" — weeks instead of quarters for a standard paid tier. The caveat is decisive: it is archived, five stars, no dependents, nothing shipped since October 2019. So the ask isn't "adopt this library," it's "we can reuse its shape, but we must own it." The decision that deserves the room is the one underneath — this path means Braintree, not Stripe, with real consequences for checkout UX, PayPal/Venmo coverage, and our support queue. Approve the provider direction plus the maintenance headcount, or redirect to a maintained Cashier integration. Do not approve the package in isolation.

To engineering: The appeal is convention over invention — subscription lifecycle, payment-method updates, and webhook handling in Laravel idioms, with full Cashier documentation now living in the README, so new hires can read the code. The costs are structural: the repo is read-only, the Braintree SDK has moved well past 4.x, and there is no path to Laravel-version support except the one we build. Concretely that means forking into an internal namespace, pinning a commit SHA, and owning the upgrade calendar for PHP, Laravel, and Braintree. Run a compatibility spike in a throwaway branch first — resolve against our actual composer.json, run the package suite, then exercise sandbox flows end-to-end (trial + coupon subscription, swap with and without proration, quantity update, cancel-at-period-end, cancelNow, resume, charge, refund, and a signed webhook). Price the alternative in the same breath: a thin first-party wrapper over the Braintree SDK is typically a few weeks of work and strictly more auditable. Note where correctness actually lives — webhook signature verification, idempotency, retries, reconciliation. The package covers the happy path; the failure path is ours either way. If pricing moves to metered or usage-based, budget a real migration rather than assuming this stretches.

To finance and support: Billing becomes a system of record we must reconcile, not just a checkout page. This covers charges and subscription state; it does not produce tax-compliant invoices, line-item reporting, or revenue recognition — plan that tooling separately. Because no upstream will fix defects, add a support workflow and runbook for failed payments, dunning, and webhook replay before launch, with reconciliation running from day one and a tested rollback path. The Drop-in UI does keep card data out of our systems, a real and durable reduction in compliance scope regardless of how the dependency question resolves.