Cashier Laravel Package

Technical Evaluation

Architecture fit. vandarpay/cashier is a Laravel service-provider package that wraps Vandar's Internet Payment Gateway (IPG) and Direct Debit APIs behind a Cashier-style fluent interface. Architecturally it assumes a conventional Laravel application: package auto-discovery, a publishable config file, environment-based credentials, and Eloquent-backed persistence for payment/mandate records. It is a good fit only if the host application is already a Laravel monolith (or a Laravel service) and the business is transacting in IRR/IRT through an Iranian PSP. It is not a general-purpose payment abstraction; it is a thin, vendor-specific binding.

Integration feasibility. Composer installation and config publishing are trivial. Real feasibility gates are external: a Vandar merchant account, Iranian business registration/KYC, and the operational realities of Iranian payment rails (callback reachability, TLS termination, currency denomination in Rial vs. Toman). The IPG flow is straightforward (create payment → redirect → verify callback). Direct Debit is materially harder: it introduces mandate creation, customer consent capture, mandate lifecycle state, and settlement timing that the package can only partially abstract. A spike in Vandar's sandbox is the right first gate before any commitment.

Technical risk. This is an 11-star, single-vendor package last released in February 2024. The dominant risks are bus factor and abandonment, not code quality per se: there is no evidence of a broad contributor base, a security review, or a published compatibility matrix. Payment code is high-blast-radius — callback verification, idempotency, signature validation, and amount-integrity checks must be independently verified, not assumed. Laravel major-version drift (L11/L12), Guzzle/PSR conflicts, and upstream Vandar API schema changes are live risks. Treat the package as a starting scaffold you will own and harden, not as a supported dependency.

Key questions.

• Which Laravel and PHP versions are actually supported and tested (CI, not README)?
• Does the package verify callback signatures and enforce idempotency, or does it leave that to the caller?
• Are refunds, partial captures, and settlement reconciliation in scope, or only authorize/capture?
• How complete is Direct Debit mandate lifecycle (create, revoke, retry, expiry)?
• What are the currency units (Rial vs. Toman), and where is that normalized?
• What is the vendor's support/SLA commitment, and is there a maintained sandbox?
• Is the code audited for secret handling, logging of PAN-adjacent data, and TLS verification?

Integration Approach

Stack fit. Best suited to a Laravel 9/10-era application on PHP 8.1+ using Blade, Livewire, or Inertia for the redirect surfaces. It composes cleanly with queued jobs, Laravel's HTTP client, and event/listener patterns. It is a poor fit for polyglot or non-Laravel stacks (Symfony, Node, Go services), and a poor fit if checkout runs in a separately deployed frontend that cannot receive server-side callbacks.

Migration path. Do not let vendor DTOs leak into the domain. Define an internal PaymentGateway port (create intent, verify, refund, mandate operations) and implement it with this package as the adapter. That gives you three things: a seam to swap PSPs, a place to enforce idempotency and amount checks, and a testable contract independent of Vandar. If an existing gateway is in place, run the new adapter behind a feature flag and shadow-route a small percentage of traffic before cutover.

Compatibility. Validate composer.json constraints against your Laravel/PHP versions first; resolve Guzzle and illuminate/support conflicts early. Confirm namespace and config-key collisions if another Cashier variant is installed. Critically, lock down the currency convention at the adapter boundary — mixing Rial and Toman is the single most common production incident in this domain — and centralize it in one place with tests.

Sequencing.

1. Sandbox spike: prove IPG create/verify and one Direct Debit mandate end-to-end.
2. Adapter + port interface, with contract tests and currency normalization.
3. Harden callbacks: signature verification, idempotency keys, replay protection, timeout/retry policy.
4. Reconciliation job that independently queries Vandar for settlement status and flags divergence.
5. Internal pilot with low transaction caps and manual refund runbook.
6. Progressive rollout; document a rollback to the previous gateway.

Operational Impact

Maintenance. Assume you own the code. Pin the exact version, vendor the source into your repo (or a fork) so upstream disappearance is not an outage, and assign a named owner. Budget recurring effort for Laravel upgrades and Vandar API changes — realistically a few days per quarter, more during framework majors.

Support. Community support is effectively nil at this star count. Vendor support depends entirely on your commercial relationship with Vandar, not on this repository. Plan for self-support: subscribe to Vandar's developer changelog and maintain an internal runbook covering credential rotation, callback failures, and manual reconciliation.

Scaling. Throughput is bounded by Vandar's gateway, not the package. The practical scaling concerns are within your app: synchronous HTTP calls in the request path should be given strict timeouts and, where appropriate, moved to queued jobs with bounded retries; callback handlers must be horizontally scalable and idempotent; database writes for payment state need row-level locking or unique constraints to prevent double-processing under concurrency.

Failure modes. Expect and design for: lost or duplicated callbacks (network, deploy mid-flight), token expiry between redirect and verify, currency-unit mismatch, partial Direct Debit mandate failures and revocations, upstream schema drift after a Vandar API change, TLS/proxy and geo/DNS blocking affecting callback reachability, and silent package breakage on a Laravel upgrade. Each needs an explicit detection signal and a manual recovery path — reconciliation jobs and alerting on unverified-but-charged transactions are non-negotiable.

Ramp-up. For a Laravel-fluent engineer, the IPG path is a day of work; the Direct Debit domain (mandates, consent, settlement timing) is the real learning curve and warrants product and compliance involvement, not just engineering. Allocate roughly one to two weeks for a careful first integration including hardening and runbook, and treat the first production month as a monitored pilot with manual reconciliation.