← Payments overview

# The Iranian Payment Reality

## 2.1 The rails: card → PSP → Shaparak → registered IBANs #

Every card payment in Iran is acquired by a licensed PSP and cleared through Shaparak (the national switch), which settles to bank-registered IBANs (شِبا) of the merchant/beneficiaries. There is no native marketplace-escrow construct the way a US/EU platform would hold buyer cash in trust. The platform does not — and legally may not — sit in the money path as a custodian.

## 2.2 The license class: پرداخت‌یار (payment facilitator) and the custody prohibition #

An MVP marketplace like Balinyaar rides on a پرداخت‌یار (payment facilitator / aggregator) arrangement under a contracted PSP and the CBI/Shaparak agreement. A facilitator is explicitly forbidden from:

- holding customer deposits,
- operating wallets,
- paying interest,
- granting credit / guarantees,
- temporarily using merchant balances.

Settlement must go only to merchant-registered bank accounts, and only Shaparak can withdraw from the special facilitator settlement account (حساب ویژه پرداخت‌یاری). Unauthorized fund-holding draws penalties, license suspension, and AML exposure. This is the single load-bearing constraint of the whole design: Balinyaar cannot be the custodian of buyer funds. (VERIFIED — way2pay, Zibal legal blog, finolaw, peivast.)

## 2.3 تسهیم (settlement-sharing) — the compliant marketplace primitive #

The legitimate way to pay many providers is تسهیم / تسویه اشتراکی (settlement-sharing): a single incoming card payment is split across multiple registered IBANs (the nurse's net share + the platform's commission) and credited directly by Shaparak/the provider to each party. The platform never touches the actual split. ZarinPal markets this for marketplaces (بازارگاه) with split-by-ratio to each partner's registered Sheba; Zibal, Sadad, SizPay, Vandar, Jibit, Zibal, PayPing, IDPay offer variants. (VERIFIED.)

> Caveat (CONFIGURABLE): ZarinPal's تسهیم appears gated to a "golden" (طلایی) membership tier; all timing/minimum/limit numbers (e.g. ~100,000 IRR minimum, processing windows, "no beneficiary limit") came from single doc reads and must be reconfirmed at contracting.

## 2.4 The banned move: inter-merchant / inter-facilitator transfers and held pools #

A tempting design — "collect into a platform pool, hold until EVV check-out, then redistribute" — is regulatory grey-to-prohibited. Shaparak explicitly banned inter-facilitator and inter-merchant fund transfers and wallet-style holding. A delayed but pre-fixed split to the same registered IBANs may be tolerable; moving/holding funds in a platform-controlled pool to release conditionally is the banned behavior. The only clean hold/release/refund mechanism is a bank-grade escrow product (e.g. Vandar میندو / معاملات امن — buyer pays into trust, released to seller on confirmation, refundable on seller failure), but even that is flagged as regulatorily fragile and its API-level EVV trigger is unverified. Practical conclusion: model escrow as an internal ledger over whichever provider primitive you contract; do not assume you can lawfully custody cash yourself. (VERIFIED ban; the "delay-then-hold" pattern is the OVERSTATED part of the original research.)

## 2.5 Provider cut-off continuity risk (Toman / Jibit, Nov 2024) #

In November 2024 the CBI abruptly cut Toman's and Jibit's settlement/withdrawal services with no stated cause, disrupting businesses including millions of Snapp drivers who could not settle. Wallet/balance facilitator models have been blocked and re-permitted before (Vandar's gateway was blocked then unblocked by Shaparak). Design for multi-provider failover and a reconciliation ledger that survives a provider being cut off mid-cycle. (VERIFIED — zoomit, way2pay, ecoiran.)

## 2.6 Tax: سامانه مودیان and VAT = 10% #

- Iran's سامانه مودیان (taxpayer / e-invoicing system) requires electronic invoices (صورتحساب الکترونیکی) with a 22-digit number, a memory tax-id (شناسه یکتای حافظه مالیاتی), and a digital signature. The SELLER issues the invoice and remits VAT; the buyer cannot. For a marketplace this maps cleanly: each nurse is the taxable seller of the nursing service; Balinyaar's taxable supply is ONLY its commission (the Snapp/Tapsi precedent). (VERIFIED.)
- VAT is 10%, not 9%: the standard rate rose from 9% to 10% in 1403 (govt 7% + municipal 3%) and remains 10% in 1404. Any VAT field hardcoded at 9% is stale — use 10% and make it a configurable parameter, since it has changed two years running. (VERIFIED correction.)
- مودیان enrollment is phased in by revenue threshold (individuals with sales above ~144bn IRR through end of 1404 must issue e-invoices from Tir 1405). Whether the home-nursing service itself is VAT-exempt (medical exemption) is UNCERTAIN — do not assume; model a config-driven VAT rate that can be 0.

↑ Back to top