Filament Payments Laravel Package

Technical Evaluation

Architecture fit. tomatophp/filament-payments is a FilamentPHP panel plugin, not a payments platform. That framing drives the go/no-go: it is an accelerator for the admin-side of payments (transaction list, status filters, gateway configuration, a "Pay" table action, a hosted payment page) and for initiation via a single facade (FilamentPayments::pay(PaymentRequest::...) → redirect URL). It ships Eloquent models, migrations, Filament resources, a public Livewire payment page (/pay/{trx}), and gateway drivers (StripeV3, PayPal, Paymob, Tap, Myfatoorah, Plisio, Cryptomus). It presumes your back office already runs Filament; if it does not, this package is irrelevant and should be rejected outright. The important architectural property is favorable: all supported gateways are hosted-redirect flows, so card data never touches your servers and PCI scope stays minimal. The important architectural gap is equally clear: nothing in the README evidences a ledger, reconciliation engine, idempotency model, refund/partial-capture workflow, or webhook verification contract. A TPM should treat this as "payments admin UI + initiation wrapper," and budget separately for the money-correctness layer.

Integration feasibility. High for a greenfield Filament app, moderate for an existing one. It is composer require + filament-payments:install + one ->plugin() line, but the hidden prerequisites are real: Spatie Media Library migrations must be published and run, and release notes show filament-translations-component became an unlisted hard dependency (v1.0.14). Gateway credentials are configured through the Filament UI, i.e. secrets live in the database — that needs an encryption-cast, audit, and rotation story before it reaches production. Migration files are publishable and have been edited by community PRs (v1.0.20 changed the payments table), so you should review and own the schema rather than trusting the published stub to match upstream.

Technical risk. Concentrated, and mostly sustainability rather than capability:

• Bus factor / validation. 55 stars, 0 dependents, effectively one maintainer (3x1io) with a handful of drive-by contributors. There is no third-party production signal to cite in a risk review. Mitigation is a fork-and-own contingency plan and a small internal patch queue.
• Semver discipline. v1.0.21 shipped a breaking change (signed, expiring payment links; owner enforcement; CSRF-protected POST cancel) inside a patch-level band. v5.0.1 appears to bump a major version for a homepage URL change. You cannot infer upgrade cost from version numbers — pin exact versions and read every release note.
• Extensibility. Release v1.0.15 literally documents "created custom payment following example but didnt worked #6." If your roadmap needs Adyen, Mollie, Braintree, Checkout.com, Razorpay, or the still-unchecked Paddle / Lemon Squeezy / PayTabs, assume a fork, not a driver plugin. That is the single biggest lever on total cost of ownership.
• Money correctness. v1.0.13 changed wallet amounts from integer to float. Float money is an audit finding. Verify minor-unit integer storage, rounding behavior, and multi-currency before committing.
• Security maturity. Owner enforcement and signed links arrived only at 1.0.21 — implying earlier versions permitted direct transaction-ID access. The trajectory is improving; the baseline was late.

Key questions for the maintainer / spike.

1. Are webhook callbacks verified (signature + replay window), and is processing idempotent on gateway transaction ID?
2. What happens to a payment whose callback never arrives — is there a reconciliation command, or is it manual?
3. Refunds, partial refunds, and captures: in scope, or read-only?
4. Is the PaymentRequest/driver contract frozen, and what is the supported Filament major-version matrix?
5. Where are gate secrets stored and how are they encrypted/rotated?
6. Test coverage and CI status; is there a test-mode/sandbox abstraction per gateway?

Integration Approach

Stack fit. Laravel + Filament (Livewire/Alpine/Tailwind) + Spatie Media Library; optional pairing with filament-subscriptions via the afterSubscription hook; filament-translations-component as an implied dependency. Database-agnostic in principle, but validate against your engine (Postgres/MySQL) since migrations have been community-edited. Confirm the Filament major version constraint against your panel before the spike — this is the most common hard stop.

Migration path. Sequence it so no irreversible step happens in production:

1. composer require tomatophp/filament-payments with an exact pinned version.
2. Publish and run the Media Library migrations (this is a shared dependency — check for collision with an existing Media Library install).
3. Run filament-payments:install, register FilamentPaymentsPlugin::make() in the panel provider.
4. Publish config, migrations, views, lang; review the payments/gates schema manually and reconcile it into your normal migration review — do not auto-migrate in prod.
5. Configure one gateway in sandbox mode through the UI, with credentials sourced from your secrets manager rather than hand-typed into a form.

Compatibility. Two seams to pin: the Filament version (breaks on panel majors) and the gateway driver contract (unstable, see #6 upstream). Anything you wrap — the facade call, the PaymentAction, the public payment page route — should sit behind your own thin service class so a fork or replacement doesn't ripple across feature code.

Sequencing.

• Week 1 — Spike. Throwaway Filament app, Stripe test mode, end-to-end: initiate → hosted page → callback → status transition. Gate decision: does the callback actually update state reliably, and is it idempotent under replay?
• Week 2 — Integration. Wire the facade into one low-risk flow (e.g. a subscription upgrade) behind a feature flag. Build the reconciliation job and webhook signature verification outside the plugin, in your own code — assume the package does not provide them.
• Week 3–4 — Harden. Secrets encryption, audit logging on gate config changes, expiry window tuning for filament-payments.links, ops runbook for stuck pending payments.
• Ongoing — Build-vs-fork checkpoint. Revisit at gateway #3, or the moment a roadmap gateway appears in the unchecked list. That is the natural fork trigger, and cheaper to decide before the admin UI is load-bearing.

Leverage estimate. Realistic saving is 2–3 engineer-weeks on the payments admin surface (list/view/filter, gate config UX, payment action) — meaningful, not transformative. The gateway work, reconciliation, and money correctness remain yours.

Operational Impact

Maintenance. You own the upgrade treadmill. The plugin must track Filament majors, and with a single-maintainer cadence plus breaking changes landing in patch releases, treat every bump as a mini-project: read the changelog, re-review the schema, retest callbacks. Budget ~1–2 engineer-days per Filament major and a standing fork of the repo. Note also that the 2026-10-13 release date in the metadata is inconsistent with a package whose history sits in 2024–2025 — a small data-hygiene flag worth corroborating against Packagist before you rely on release recency as a liveness signal.

Support. GitHub issues only. No vendor, no SLA, no security disclosure policy visible. Escalation path is your own team. For a payments-adjacent component that is a governance finding — document it as accepted risk, or scope the package to non-critical-path flows (internal ops UI) where an outage is survivable.

Scaling. Initiation volume is low and hosted-redirect offloads the heavy lifting to the gateway, so nothing here scales badly. Two watch items: (a) the public payment page is a stateful Livewire route — plan for session affinity or sticky routing if the checkout page sits behind a load balancer, and don't put it behind aggressive caching; (b) payment records share your primary application database, so reporting queries over a growing payments table need indexes and likely a read replica. Throughput risk lives in webhook ingestion and reconciliation jobs, which are outside the package and must be queued, backpressured, and monitored by you.

Failure modes to instrument.

• Lost callback → payment stuck pending indefinitely with no automatic recovery → silent revenue leakage and support tickets. Requires a scheduled reconciliation sweep against gateway APIs.
• Duplicate/replayed webhook → double credit if no idempotency key on gateway transaction ID. Highest-severity failure; test it explicitly.
• Expired signed link (filament-payments.links) → customers clicking a slow-delivered email hit a dead payment page. Tune TTL to your email delivery p99.
• Owner enforcement (filament-payments.enforce_owner) → payments tied to a user break for guest/anonymous checkout or admin-initiated "pay by link" flows. Validate against your actual funnel.
• Schema drift → community edits to upstream migrations cause divergence across environments; mitigated only by owning the migrations.
• Secret rotation in the DB → gate credentials change with no deploy; needs an audited admin action and a documented rollback.
• Float wallet rounding → cent-level discrepancies that surface in finance reconciliation months later.

Ramp-up. Low for a competent Filament developer — the facade and PaymentAction are genuinely ergonomic, and a working Stripe test-mode flow is a half-day. The harder ramp is domain, not API: webhook idempotency, reconciliation, PCI scoping, and refund semantics are not taught by this package, and the README's brevity can create false confidence in exactly those areas. Staff the integration with someone who has shipped a payment flow before, even if they only review.

Recommendation. Adopt as a bounded accelerator for the payments admin surface in an existing Filament back office, pinned and behind a thin abstraction, with reconciliation and webhook verification built in-house. Do not adopt it as your payments platform, your ledger, or in a path where a single-maintainer outage is unacceptable. Re-evaluate — likely toward a fork — at the third gateway.