Filament Withdrawals Laravel Package

Product Decisions This Supports

• Financial Operations Platform: Still accelerates withdrawal management for fintech, crypto, or SaaS payout flows — but the v5.0.1 patch is now a mandatory gate in the build-vs-buy case, not a nice-to-have.
• Security & Compliance Posture (new): The fix closes a serious data-exposure path — relation fields previously resolved any class and any column typed into the field editor, so a field pointing at App\Models\User + password could surface every user's password hash inside a withdrawal request form. For products under SOC 2, PCI-adjacent, or GDPR review, this is the difference between "evaluate later" and "safe to ship."
• Data-Minimization by Default (new): Hidden attributes (password, remember_token, anything in $hidden) are now never rendered, even if explicitly listed. That aligns the package with least-privilege expectations auditors ask about, and reduces the chance a non-technical admin misconfigures a form into a leak.
• Admin Panel Efficiency: Unchanged — pre-built Filament resources for methods, requests, and approvals cut internal-tool build time.
• Customization Roadmap: Extensibility is now allowlist-driven. The relations config key becomes a product-owned surface area: adding a relation field is a deliberate, reviewable config change rather than an ad-hoc form edit. Plan for that as a small ongoing admin/ops responsibility, not a one-time setup.
• Migration Cost for Existing Adopters (new): The allowlist ships empty. Any live withdrawal method using relation fields will immediately render with no options until the config is published and populated. That is a real (if narrow) regression window — schedule the upgrade with a config change, not as a background patch.
• Build vs. Buy: Adoption case is now stronger on the security side (a fix shipped) but carries a patch-responsiveness dependency — this class of bug existed until v5.0.1, so plan for monitoring releases and applying security updates quickly.
• Use Cases: Crypto exchanges (fiat/crypto withdrawals), subscription platforms (refunds/payouts), marketplaces (seller payouts), banking/financial SaaS (user-fund transfers).

When to Consider This Package

Adopt if:

• Your product uses Filament as its admin panel framework.
• You need structured withdrawal workflows (methods, requests, approvals) without reinventing UI/UX.
• You are on v5.0.1 or later — do not adopt or remain on earlier versions given the relation-field exposure.
• Your team can own a small allowlist config (relations in config/filament-withdrawals.php) and treat additions to it as reviewable changes.
• You need pre-built validation (wallet balances, method availability) and audit trails, and you want hidden model attributes excluded by default.
• Your team prioritizes speed over full customization (MVP launch, internal tools).

Look elsewhere if:

• You’re not using Filament (package is tightly coupled to it).
• You need multi-currency or complex tax compliance (no built-in support).
• Your withdrawal logic is highly bespoke (real-time fraud detection, custom APIs, dynamic per-tenant relation schemas that an allowlist can’t express cleanly).
• You cannot commit to prompt security-patch adoption — a small, low-adoption codebase means you are your own support line.
• You require enterprise-grade support or vendor SLAs.
• You are mid-freeze on an older version and cannot change config: upgrading without populating the allowlist will silently disable existing relation fields.

How to Pitch It (Stakeholders)

For Executives: "v5.0.1 is a security release and we should take it. It closes a flaw where an admin-configured withdrawal form field could pull sensitive columns — including password hashes — from any database table into an operator-facing screen. That's exactly the kind of finding a security review or auditor would raise against us. The upgrade itself is small: publish a config file and list the specific models and columns we actually want exposed. Cost is hours, not weeks. Two caveats worth knowing: relation-based fields go blank until we list them, so we schedule the config change with the upgrade; and because this package is small and MIT-licensed with limited adoption, we own the responsibility for tracking and applying future security patches — I'd add it to our dependency watch list. Net: the package still saves us roughly 3–6 weeks of withdrawal-workflow build, and post-fix its default posture (hidden fields never shown, allowlist required) is easier to defend in a review than our own custom implementation would be."

For Engineering: "Filament-Withdrawals v5.0.1 — upgrade required, security fix:

• The bug: relation fields in withdrawal forms would instantiate any class and read any column typed into the field editor (::all() on an arbitrary class). A field set to App\Models\User + password exposed password hashes to anyone viewing the withdrawal request form.
• The fix: relation fields are now restricted to a new relations allowlist in config/filament-withdrawals.php; anything not listed renders with no options and is never queried. $hidden attributes are never displayed even if listed. The field editor now offers allowlisted models/columns as server-validated selects.
• Upgrade step: php artisan vendor:publish --tag="filament-withdrawals-config" then populate, e.g. 'relations' => [\App\Models\Bank::class => ['name']].
• Breaking behavior: allowlist is empty by default — existing relation fields will show no options until configured. Audit withdrawal methods for relation fields before deploying.
• Still true: pre-built Filament resources for methods/requests/approvals, extensible form fields via FilamentWithdrawalFormFields, migration/publish tags, ~7 stars, MIT license. Tradeoff: Filament-only and a single-maintainer dependency we must watch for patches — but still roughly 50% less dev effort than a custom build, and safer defaults than we'd likely ship ourselves."*

For Design/UX: "The UI is unchanged — same polished, consistent withdrawal workflow screens (see screenshots), brandable via register(). One visible difference: relation-style fields that aren't on the security allowlist will appear empty rather than populated. If a flow depends on one, flag it to engineering so the model and column get allowlisted before we ship the upgrade — better an empty dropdown in staging than in production."