Product Decisions This Supports
- Build vs. buy for internal payment admin tooling. If your stack is Laravel + Filament and you already use
shetabit/payment, this replaces a custom "transactions & gateways" admin screen — typically 1–3 sprints of engineering plus ongoing maintenance. That is the core buy decision this package informs.
- Roadmap sequencing for ops tooling. It lets you ship payment visibility (transaction list, status, gateway configuration) as a thin plugin instead of a bespoke module, freeing the team to spend the same sprint on revenue-facing features.
- Support and finance workflows. A back-office view of payment records supports customer-support lookups ("did this order actually pay?"), reconciliation spot-checks, and manual status correction — decisions about whether to invest in a dedicated support console or accept the built-in one.
- Multi-gateway strategy. Because it wraps Shetabit's driver abstraction, it supports the product decision to route through multiple Iranian PSPs (Zarinpal, IDPay, Pay.ir, etc.) without building per-gateway admin screens.
- Feature scoping for MVP / regional launches. For an Iran-market product, it materially lowers the cost of the "we need a payments admin panel before launch" line item.
- Defer / no-build decisions. Its existence is a legitimate reason to not prioritize a custom admin panel on the roadmap — provided the risk assessment below clears.
When to Consider This Package
Consider it when:
- You are already committed to Filament for admin and Shetabit Payment for gateway integration — the package is a UI layer over both, so it only pays off inside that exact stack.
- Your market is Iran, and your PSP set is covered by Shetabit's drivers.
- You need internal, low-blast-radius tooling — an admin read/configure surface, not a payment authorization path. It should not sit on the critical money-movement path.
- You are at MVP or early-growth stage, where velocity outweighs the cost of a bespoke panel.
- You can accept a small-community dependency and are willing to pin a version, review the source, and fork if needed.
Look elsewhere when:
- Your gateways are Stripe, Adyen, Paddle, or other non-Iranian PSPs — Shetabit is the wrong abstraction entirely.
- You are not on Filament (Nova, Livewire-only, Inertia/Vue admin, custom React console) — the plugin's value collapses to a set of Eloquent models you would have to re-skin.
- Payments are regulated, audited, or high-volume, requiring vendor SLAs, security review, PCI-adjacent controls, or guaranteed maintenance. Eleven stars and a single maintainer do not meet that bar.
- You need guaranteed long-term support or have a policy against unvetted third-party dependencies in financially sensitive areas.
- Your team would spend more time auditing and wrapping the plugin than writing the ~2–5 screens it provides.
Diligence checklist before adoption: read the source end-to-end (it is small and MIT-licensed), confirm compatibility with your Filament major version, check whether it exposes raw transaction mutation (a risk surface — restrict via policies), pin the version in composer.json, and record a fork-and-own contingency in your ADR.
How to Pitch It (Stakeholders)
For executives: This is a small, free (MIT) plugin that gives our admin panel a ready-made screen for viewing payment transactions and managing gateway settings. It removes a chunk of internal tooling work from the launch path — roughly a sprint or more — at essentially zero license cost. The trade-off is dependency risk: it is a young, single-maintainer project, so we treat it as an accelerator, not a foundation. We isolate it behind our own admin layer, pin the version, and can replace it with in-house code in days if it stalls. It touches back-office screens only, never the live payment flow, so the downside is contained.
For engineering: Adopt only if we are on Filament + shetabit/payment; otherwise skip. It is a thin Filament resource layer over Shetabit's models — review the migrations, lock down mutation actions behind Filament policies, and wrap the resources so a future fork or rewrite is a contained change. Do not let it become a dependency of the checkout path. Budget half a day for source review and a compatibility check against our Filament version before committing.
Recommendation: Conditional adopt for Iran-market Laravel/Filament products at MVP stage, as internal tooling with a documented exit plan. Reject for regulated, high-volume, or non-Filament contexts.