Shaparak Laravel Package

Product Decisions This Supports

• Market entry into Iran. If any part of the roadmap involves accepting payments from users with Iranian Shetab cards, this package is the shortest path from "we need payments in Iran" to a working Laravel checkout. It converts a multi-month localization + integration project into sprint-level work — a roadmap-unlock decision, not a feature decision.
• Build vs. buy for PSP integration. The alternative is integrating each Iranian IPG (Zarinpal, Sadad/Melli, Behpardakht/Mellat, Parsian, Saman/Sep, Asan Pardakht, etc.) individually — each with its own SOAP/REST quirks, signing schemes, redirect flows, and callback verification. Adopting a unified handler is almost always cheaper than maintaining N bespoke integrations, and it keeps the payments epic scoped to one workstream.
• Multi-gateway strategy. A single handler is the enabler for routing logic: failover when a PSP is down, routing by fee, success rate, card type, or settlement speed. That's a direct lever on payment failure rate — often the highest-ROI payments work — without re-architecting checkout.
• Feature scoping and ownership boundaries. Because the package owns the gateway boundary, it clarifies what our app owns (order state machine, idempotency, ledger reconciliation, refunds) versus what the PSP owns. That separation is the input for sizing the payments epic and sequencing it against other roadmap work.
• Use cases: B2C e-commerce and digital goods sold into Iran; SaaS billed to Iranian customers (with the caveat that recurring/renewal support is PSP-dependent and usually needs a fallback); marketplace and B2B invoicing with hosted payment pages.

When to Consider This Package

Adopt it when:

• Your stack is Laravel/PHP and you expect to stay there.
• You need one or more Iranian IPGs and want a single, config-driven integration surface instead of per-PSP code.
• Your payment needs are standard: authorize, redirect, callback verify, capture, and ideally refund/reverse.
• Your team is small and cannot justify building and maintaining a payments abstraction in-house.
• You can accept a community package (~32 stars) as a dependency and wrap it behind your own interface.

Look elsewhere or build in-house when:

• The license is unresolved. The repo reports NOASSERTION, meaning GitHub could not identify a standard license. For a payments dependency this is a legal blocker until counsel confirms terms — do not ship customer funds through it before that clears.
• You're not on Laravel, or you need a framework-agnostic SDK.
• You need an SLA, vendor support, or an audited security review trail. A small package with a likely single maintainer is a bus-factor risk; a PSP outage during settlement is a business incident, not a bug ticket.
• You need capabilities the Iranian gateways themselves don't expose — true recurring billing, tokenized card-on-file, chargebacks as a first-class flow, or multi-currency. An abstraction cannot exceed the underlying IPGs, so validate each gateway's feature set against the roadmap before committing.
• You need PCI-adjacent guarantees. Treat the package as convenience glue, never as a compliance boundary.

How to Pitch It (Stakeholders)

Executives (summary): This is the cheapest credible way to open the Iranian market inside our existing Laravel product — it replaces several bespoke PSP integrations with one dependency, cutting the payments epic from months to weeks and reducing ongoing maintenance. The trade-off is dependency risk: it's a small open-source project with an unresolved license, so we adopt it behind our own abstraction and pilot one gateway before committing.

Engineering: It's Laravel-native, config-driven, and gives us a uniform interface across IPGs, so gateway choice becomes a routing and config concern rather than a rewrite. Our job is to own what the package shouldn't: an internal PaymentGateway contract it implements, idempotent callback handling, the order state machine, ledger reconciliation jobs, and sandbox plus contract tests per PSP. Isolate it so a swap is a one-file change.

Legal / security: Flag the NOASSERTION license and the small maintainer base as production gates. Request license clarification and a dependency review before any real money flows through it.

Recommendation: Time-boxed pilot on a single gateway with low-value traffic, behind an abstraction layer with a documented fallback to direct PSP integration. Revisit the build-vs-buy call if the package stalls or the license cannot be resolved.