Product Decisions This Supports
- Launch readiness for a public payment surface. This package exposes an unauthenticated donation endpoint that moves money; v2.1.7 is the release that makes it defensible in a security review — bounded donor input, normalised emails, generic responses for Stripe API failures (no internal detail leaked to donors or attackers), and configurable per-IP throttling. That is a go/no-go input for launch, not a nice-to-have.
- Build vs buy on donations. Stripe checkout + Statamic user linkage + dependency hygiene is commodity plumbing. Buying keeps the team out of Stripe integration maintenance and out of the blast radius of upstream CVEs (four advisories closed here by bumping Laravel 12.69.3, CommonMark 2.10.3, Flysystem 3.36.0, with Composer constraints blocking the affected versions).
- Rate-limit policy is a product decision, not a config detail. Defaults are 5 requests/minute and 50/day per IP. Validate against real traffic shapes before a campaign: giving days, matching-gift drives, corporate NAT/shared office IPs, kiosks and in-person collection points will all throttle as a single IP. Tune per campaign or you'll silently reject legitimate donors.
create_users (default true) sets our donor-data posture. Out of the box every donation creates a Statamic user — good for donor portal, retention and email follow-up; bad for data minimization and GDPR/CCPA retention arguments. Pick deliberately and document it; flipping the default later is a migration, not a toggle.- Finance and ops reporting improve. Stripe customer reuse means fewer duplicate customers, cleaner receipts, and more reliable donor lifetime-value and reconciliation reporting.
- Debuggability trade-off needs a compensating decision. Generic Stripe error responses are the right security call but remove donor- and support-visible signal. Budget for server-side logging/alerting and for support scripts that explain declines, or the first campaign will generate avoidable support load.
- Standing release gate. 45 tests / 130 assertions plus a clean Composer audit is a checkable acceptance criterion — adopt it as the bar for future upgrades of this dependency.
- Roadmap forcing function. The package tracks current Laravel 12, so its release cadence constrains our own framework upgrade windows; plan them together rather than discovering the coupling mid-upgrade.
When to Consider This Package
Consider it when:
- You're on Laravel 12 with Stripe for donations and Statamic as CMS/user store, and want a maintained turnkey checkout rather than owning payment plumbing.
- You need a public donation endpoint that already clears a security review (throttling, bounded input, no PII or internal errors in responses) without building those controls yourself.
- You want donor records connected to CMS users for retention, receipts or a donor portal.
- You have a small team without a dedicated payments engineer, and a release gate of tests + clean dependency audit is sufficient assurance for your risk appetite.
Look elsewhere when:
- You need multi-currency tax handling, complex recurring/subscription logic, or PSPs other than Stripe (PayPal, Adyen).
- Your user model isn't Statamic, or you need full control of the checkout UI and donor journey.
- Per-IP throttling doesn't fit your traffic — kiosks, shared corporate IPs, or event-based giving may need per-donor or per-session limits instead.
- You require a formal third-party security audit, SOC 2 attestation, or vendor SLA. "Composer audit is clean" and passing tests are not the same as an audited supply chain; this is a small, effectively single-maintainer package, so assess bus factor, response time on advisories, and pin/vendor accordingly before making it load-bearing for revenue.
How to Pitch It (Stakeholders)
Executives: This release closes four dependency security advisories and hardens the public donation page against abuse — rate limits, bounded input, and no internal error details exposed — with no change to the donor experience. It means we can pass security review and run a campaign on the current stack without added headcount, and we have evidence: 45 passing tests, 130 assertions, clean dependency audit. Two decisions need us, not engineering: the default rate limits (5/minute, 50/day per IP) may be too tight for giving days and shared-IP audiences, and donations currently create CMS user records by default, which is a privacy and data-retention choice we should make explicitly.
Engineering: Dependency upgrade to Laravel 12.69.3, CommonMark 2.10.3 and Flysystem 3.36.0, with Composer constraints preventing installation of affected versions. Endpoint hardening adds bounded donor input, normalised emails, Stripe customer reuse, generic Stripe failure responses, and configurable per-IP throttling. One behavioural default to review before deploy: create_users defaults to true, so donations create Statamic users. Note that generic error responses reduce debuggability — add logging/alerting to compensate. This is a small, single-maintainer upstream; track its release cadence, pin sensibly, and treat its tests-plus-audit bar as our gate for future bumps.