Cashier Laravel Package

Product Decisions This Supports

• Market entry / localization decision: This is essentially a market-access enabler. If Iranian IPG (Internet Payment Gateway) and Direct Debit are on the roadmap, this package is a shortcut to processing payments and pulling recurring debits without building the Shaparak/Vandar token-exchange, redirect, callback, and verify flows from scratch.
• Subscription & installment billing roadmap: Direct Debit support is the notable differentiator versus Laravel Cashier's Stripe/Paddle paths. It underpins recurring plans, installment checkout, and mandate-based collection — features that are otherwise a multi-sprint build.
• Build vs. buy for the payment layer: Buy/integrate is defensible for v1: a thin MIT-licensed wrapper over a REST API is cheaper than a bespoke integration. The strategic question is not "build or buy" but "integrate then own" — fork the package and treat it as internal code.
• Vendor concentration risk: Choosing Vandar as PSP is the real decision; the package is downstream of it. This assessment should feed the PSP selection doc (fees, settlement SLA, Shaparak compliance, Direct Debit mandate rules), not stand alone.
• Scope control: Explicitly not a multi-gateway abstraction. If the roadmap anticipates a second PSP or non-Iranian markets, decide now whether to wrap this behind an internal PaymentGateway interface so you can swap later.
• Not a fit for: international expansion, card-not-present flows outside Iran, or any product where the payment path needs a maintained, audited, actively released dependency.

When to Consider This Package

Consider it when:

• Vandar is the chosen or shortlisted PSP and the stack is Laravel (check the version constraints against your app — last release is Feb 2024, so validate Laravel 11/12 compatibility before committing).
• You need both one-off IPG payments and Direct Debit mandates in one integration; that overlap is the package's core value.
• Traffic is early-stage or moderate, and a payment outage is recoverable (not a 24/7 high-volume revenue path).
• Your team is willing to fork it into the repo, add tests around callback verification, idempotency keys, and retry/timeout behavior, and own it. At 11 stars and a single release cadence, treat this as source code you adopt, not a dependency you trust.
• You have an engineer who can read the Vandar API docs and validate the package against them — the package should be treated as an accelerator, not an authority on correctness.

Look elsewhere when:

• You need multi-gateway routing, failover, or a PSP-agnostic billing domain model. Use Laravel Cashier (Stripe/Paddle) for supported markets, or build a thin internal adapter layer.
• You require an actively maintained dependency with a security response process, changelog discipline, and community issue triage — none of which a low-star, single-maintainer package reliably provides.
• You need capabilities beyond what's exposed: complex refunds, partial captures, dispute handling, detailed webhook reconciliation, or multi-currency.
• Compliance review flags an unaudited payment dependency. Payments are a high-trust surface; "MIT licensed" is not "reviewed."

Gate to adoption: a one-week spike that (a) runs an end-to-end sandbox payment and a Direct Debit mandate, (b) confirms Laravel version support, (c) verifies license and dependency tree, and (d) produces a fork with regression tests. If the spike fails, integrate the Vandar REST API directly — the surface area is small.

How to Pitch It (Stakeholders)

To executives: This is a market-access component, not a platform bet. It lets us accept Iranian payments and run Direct Debit billing — recurring and installment revenue models — in weeks rather than a quarter, at zero license cost (MIT). The trade-off is maintenance risk: the package is small, low-adoption, and last released in early 2024. We mitigate by forking it into our codebase and owning it, keeping our payment layer behind an internal interface, and capping exposure until volume justifies a formal build. Net: low cost, fast time-to-revenue, manageable and bounded risk.

To engineering: Treat it as a reference implementation, not a black box. It wraps Vandar's IPG redirect/verify flow and Direct Debit mandate calls. Plan to: fork and pin it; verify Laravel version compatibility; add tests for callback verification, idempotency, and network retry; add logging and alerting on payment failures; and isolate it behind an internal gateway interface so a second PSP or a direct API integration is a swap, not a rewrite. Budget roughly one week of spike plus hardening, and confirm the license and transitive dependencies in the same pass.

Recommendation: Conditional adopt — proceed only after a sandbox spike passes and the code is forked and owned internally; otherwise integrate the Vandar API directly, which is a modest incremental effort given the package's thin surface.