Filament Payment Manager Laravel Package

Technical Evaluation

Architecture fit: This is a Filament panel plugin, so it fits only if the application already runs Filament as its admin layer and uses Shetabit Payment as its gateway abstraction. It is not a payment library itself — it is a management surface over the configuration that Shetabit Payment consumes. That makes the fit narrow but clean when the stack already matches: no new dependency in the payment runtime path, just an admin UI. For any team not on Filament, or using direct gateway SDKs instead of Shetabit, the fit is effectively zero and should not drive a Filament adoption decision.

Integration feasibility: Composer install, plugin registration in the Filament panel provider, config publish, and migrations. The real feasibility question is version compatibility — Filament ships aggressive major versions (v3 → v4) and ecosystem plugins routinely lag. Confirm the supported Filament, Laravel, and PHP matrix from composer.json and CI before committing. Equally important: determine whether the plugin persists gateway settings to the database or edits config files, and whether those keys match what Shetabit reads at runtime. A UI that writes values the payment path ignores is worse than no UI.

Technical risk: Highest risks are: (1) bus factor and abandonment — 11 stars, single maintainer, no visible backing; (2) credentials in the admin UI — gateway keys and secrets become editable data, so encryption at rest, Filament authorization policies, and audit logging are mandatory and unlikely to be provided out of the box; (3) coupling to Shetabit's config schema, which can shift between releases; (4) ecosystem friction — Iranian gateway ecosystem implies Packagist/CI access constraints and a thin troubleshooting community. Security review should be a go/no-go gate, not a follow-up task.

Key questions: Which Filament, Laravel, and PHP versions are supported and tested in CI? Does it encrypt gateway credentials at rest, and with what key management? Does it expose transaction or payment records, or only gateway configuration? How does it reconcile DB-stored settings with config/payment.php, and which wins at runtime? Does it integrate with Filament policies so only privileged admins can change gateways? What is test coverage and release cadence? Is there a stated intent to track Filament majors? Does it support multi-tenant or multi-panel setups?

Integration Approach

Stack fit: The target stack is Laravel + Filament admin + Shetabit Payment. On that stack, the plugin is a cheap way to give ops or finance a UI for gateway toggles and credentials instead of hand-editing env and config files. Off that stack, this is not a lever — do not adopt Filament solely to use it.

Migration path: Inventory existing gateway configuration first (env vars, config/payment.php, hardcoded values) and decide the single source of truth. Then install on a branch, publish config and migrations, register in the panel provider, run migrations against a scratch database, and verify the plugin's schema maps to Shetabit's expected shape. Backfill existing values, then decommission the old config path rather than running both in parallel — dual sources of truth is the most likely source of silent misconfiguration.

Compatibility: Pin exact versions of Filament, Laravel, PHP, and Shetabit Payment, and add a CI job that installs the plugin against that pinned matrix. Because the package is small, assume you will fork and patch: vendoring or a Composer patches workflow keeps a Filament upgrade from blocking the entire admin panel.

Sequencing: (1) Disposable-environment spike to validate install and CRUD; (2) security review of credential storage, access control, and audit trail; (3) runtime validation — an edit in the UI must change actual payment behavior in a staging transaction; (4) backfill and cutover of configuration; (5) production rollout behind admin permissions; (6) scheduled Filament upgrade drills. Budget a fork-and-own contingency before go-live, not after.

Operational Impact

Maintenance: Treat this as internal code, not a vendor dependency. Low stars and a single maintainer mean upgrades, Filament major bumps, and security patches are the adopting team's responsibility. Assign an owner, track upstream commits, and plan to vendor or fork. Maintenance cost is low while Filament is stable and spikes at every Filament major release.

Support: Community-only via GitHub issues, with no SLA and no commercial backing. Knowledge will concentrate in whoever integrates it, so document the config model and credential handling explicitly. For payment-adjacent code, "no support" is a material risk given the blast radius of a misconfigured gateway.

Scaling: The admin UI does not scale with transaction volume — it is a control plane, not a data plane. Runtime scaling remains Shetabit's and the gateways' concern. Watch config caching closely: if gateway settings are read per request from the database, ensure they are cached and invalidated on update; if cached without invalidation, an admin change silently fails to apply.

Failure modes: A Filament upgrade breaks the plugin and locks the admin panel; a Shetabit schema change makes the UI write unusable settings; credentials leak through database dumps or overly permissive Filament roles; config drift between file and database yields a "saved but ignored" state; misconfiguration (wrong merchant ID, sandbox flag left on) causes payment failures with weak observability. Each needs a detection path — audit logging, validation on save, and an alert on payment failure rate.

Ramp-up: Low for engineers already fluent in Laravel and Filament — roughly a day or two to integrate and validate. Higher for everyone else: Shetabit's gateway model, Iranian payment gateway semantics, Persian/RTL UI expectations, and payment compliance add domain ramp-up. Finance and ops users need a short runbook covering which settings are safe to change and what the approval process is, since the plugin hands them production payment credentials.