Filament Payments Laravel Package

Product Decisions This Supports

• Build vs. buy on the payments back office. The package collapses "gateway abstraction + admin payments console" into a composer require plus one install command. The decision this informs is whether we staff a sprint to build that internals, or adopt and spend the sprint on checkout UX instead.
• Gateway roadmap sequencing. The README's unchecked list (Paddle, Lemon Squeezy, Binance, PayTabs, Moyaser, Payfort, Fawery) is effectively an external, community-maintained backlog. Use it to triage which markets are "free" to enter later versus which require funded engineering now.
• Market entry / geographic expansion. Coverage of Stripe, PayPal, Paymob, Tap, MyFatoorah, and Cryptomus materially lowers the cost of launching in Egypt, KSA, and the UAE versus a Stripe-only stack. This is the package's strongest strategic argument and should be weighed in any market prioritization conversation.
• Monetization and pricing experiments. The documented FilamentSubscriptions::afterSubscription hook means plan upgrades can be wired to a payment redirect with a few lines. That makes packaging and price-point tests cheap enough to run, rather than a roadmap item.
• Support-cost and ops-tooling decisions. A filterable payments list, grouped statuses, per-payment detail view, and editable gate configuration reduce "where is my payment?" escalations and remove routine reconciliation work from engineering.
• Tenancy and configuration surface. The "Payment Gates / Gate Options" model implies a settings UI. This forces an explicit decision: is gateway configuration admin-only, or does it become a customer or reseller-facing capability?
• Checkout scope decisions. The PaymentRequest contract covers customer, billing, and shipping but not line items or tax. That is sufficient for simple single-amount charges and digital goods; it is a signal that anything invoice-shaped is out of scope and needs its own design.
• Vendor-risk posture. 55 stars and zero dependents means we are not following a crowd. The decision this supports is adopt-with-fork versus hard dependency — and that should be made deliberately, at adoption time, not during an incident.

When to Consider This Package

Adopt when:

• A Filament admin panel already exists or is committed to. This is a panel plugin, not a headless payments service — without Filament, most of the value disappears.
• Two or more gateways are needed quickly, especially MENA/GCC processors that have no equivalent first-party Laravel package.
• The billing model is simple: one charge per transaction, hosted redirect flow, customer pays the full amount.
• The team is small and shipping the payments CRUD UI themselves would come out of product scope.
• tomatophp/filament-subscriptions is already in the stack; the integration is first-class and documented.

Look elsewhere or plan to build when:

• Recurring billing is required: proration, dunning, invoicing, tax/VAT calculation, revenue recognition. Use Stripe Billing, Paddle, Chargebee, or Laravel Cashier.
• Refunds, partial refunds, disputes, and payout reconciliation must be first-class. These are absent from the feature list — verify they exist in the driver implementations before committing, and assume you own them if not.
• Webhook idempotency and signature verification at scale are hard requirements. Treat this as an audit item, not an assumption.
• Marketplace, split payments, or escrow are on the roadmap.
• Procurement requires PCI attestation evidence, SOC2 posture, an SLA, or a supported vendor. A low-adoption MIT package maintained by a single author will not clear that bar.
• A required gateway is not on the supported list and hiring a driver author is not possible. A public issue reports that following the custom-payment example did not work, so budget real engineering time, not an afternoon.
• The backend serves mobile clients directly and the Filament UI is not the delivery surface.

Non-negotiable prerequisites if adopted: pin an exact version, audit the callback and webhook paths yourself, and assume maintenance ownership. The 1.0.21 release hardened payment links with signing, expiry, CSRF-protected cancellation, and owner enforcement — a security-driven breaking change. That is reassuring evidence of an attentive maintainer, but it is also a reminder that the security model is still evolving.

How to Pitch It (Stakeholders)

For executives: We can replace roughly a sprint of payments back-office work with a library install. It gives us an admin console to inspect, filter, and reconcile payments, a single gateway-agnostic entry point for checkout, and — most importantly — regional coverage in Egypt, Saudi Arabia, and the UAE through Paymob, Tap, and MyFatoorah, which would otherwise be bespoke integration work per market. It is MIT licensed with no per-transaction fee and no lock-in at the orchestration layer. The risk is maturity, not licensing: low adoption and a single maintainer mean we should treat it as a fast start, and treat the gateway layer as ours rather than theirs. Recommended posture: adopt behind a pinned version with a fork budget set aside.

For engineering: It is a Filament plugin registered on the panel provider, shipping its own migrations plus a hard dependency on spatie/laravel-medialibrary. The developer surface is deliberately small — a facade plus typed request objects (PaymentRequest, PaymentCustomer, PaymentBillingInfo, PaymentShippingInfo) and a reusable table PaymentAction so any resource row can trigger a payment from a table action. Gateways are implemented as discrete drivers, which makes adding one a contained, testable unit rather than a cross-cutting concern. Recent releases have hardened payment links and tightened ownership checks, so the security posture is being actively maintained. Our obligations before shipping: pin the version, verify webhook signature handling and idempotency in each driver we enable, confirm refund behavior, and confirm whether the custom-driver extension path works for our use case.