Files
baya-monorepo/product/business/08-payments-and-escrow.html
2026-06-24 01:32:46 +03:30

61 lines
12 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>8. Payments &amp; Escrow — Balinyaar docs</title>
<link rel="stylesheet" href="../assets/doc.css">
</head>
<body>
<div class="layout">
<aside class="sidebar">
<a class="brand" href="../index.html"><span class="dot"></span> Balinyaar docs</a>
<p class="tagline">Trust-first home-nursing marketplace · Iran</p>
<nav><div class="group"><div class="label">Start here</div><ul><li><a href="../index.html">Docs home</a></li><li><a href="../overview/platform-summary.html">Platform summary &amp; ground truths</a></li></ul></div><div class="group"><div class="label">Business requirements</div><ul><li><a href="index.html">Overview &amp; MVP scope</a></li><li><a href="01-actors-and-onboarding.html">1. Actors &amp; onboarding</a></li><li><a href="02-nurse-verification.html">2. Nurse verification</a></li><li><a href="03-service-catalog-and-pricing.html">3. Service catalog &amp; pricing</a></li><li><a href="04-search-and-matching.html">4. Search &amp; matching</a></li><li><a href="05-booking-and-scheduling.html">5. Booking &amp; scheduling</a></li><li><a href="06-evv-and-service-delivery.html">6. EVV / service delivery</a></li><li><a href="07-cancellation-and-refunds.html">7. Cancellation &amp; refunds</a></li><li><a class="active" href="08-payments-and-escrow.html">8. Payments &amp; escrow</a></li><li><a href="09-installments-bnpl.html">9. Installments / BNPL</a></li><li><a href="10-payouts.html">10. Payouts to nurses</a></li><li><a href="11-reviews-trust-and-safety.html">11. Reviews, trust &amp; safety</a></li><li><a href="12-messaging-and-emergencies.html">12. Messaging &amp; emergencies</a></li><li><a href="13-tax-invoicing-and-legal.html">13. Tax, invoicing &amp; legal</a></li><li><a href="14-notifications-and-admin.html">14. Notifications &amp; admin</a></li></ul></div><div class="group"><div class="label">Database model</div><ul><li><a href="../data-model/index.html">Overview &amp; decisions</a></li><li><a href="../data-model/diagrams.html">Diagrams</a></li><li><a href="../data-model/01-identity-and-access.html">1. Identity &amp; access</a></li><li><a href="../data-model/02-geography.html">2. Geography</a></li><li><a href="../data-model/03-services-and-pricing.html">3. Services &amp; pricing</a></li><li><a href="../data-model/04-verification-and-credentials.html">4. Verification &amp; credentials</a></li><li><a href="../data-model/05-booking-and-scheduling.html">5. Booking &amp; scheduling</a></li><li><a href="../data-model/06-payments-ledger-and-refunds.html">6. Payments, ledger &amp; refunds</a></li><li><a href="../data-model/07-payouts.html">7. Payouts</a></li><li><a href="../data-model/08-bnpl.html">8. BNPL / installments</a></li><li><a href="../data-model/09-messaging.html">9. Messaging</a></li><li><a href="../data-model/10-reviews-and-records.html">10. Reviews &amp; records</a></li><li><a href="../data-model/11-notifications.html">11. Notifications</a></li><li><a href="../data-model/12-audit-config-and-reference.html">12. Audit, config &amp; reference</a></li><li><a href="../data-model/13-partner-centers-and-future.html">13. Partner centers &amp; future</a></li></ul></div><div class="group"><div class="label">Payments deep-dive</div><ul><li><a href="../payments/index.html">Overview &amp; exec summary</a></li><li><a href="../payments/iranian-payment-reality.html">Iranian payment reality</a></li><li><a href="../payments/escrow-ledger.html">Escrow as a ledger</a></li><li><a href="../payments/bnpl-landscape.html">BNPL landscape &amp; finding</a></li><li><a href="../payments/cancellation-and-payout.html">Cancellation &amp; nurse payout</a></li><li><a href="../payments/integration-notes.html">Integration &amp; schema touchpoints</a></li><li><a href="../payments/sources.html">Recommendations &amp; sources</a></li></ul></div><div class="group"><div class="label">Research &amp; strategy</div><ul><li><a href="../research/index.html">Overview &amp; exec summary</a></li><li><a href="../research/market-and-competitors.html">Market &amp; competitors</a></li><li><a href="../research/problems-and-risks.html">Problems &amp; risks</a></li><li><a href="../research/verification.html">Verification (research)</a></li><li><a href="../research/legal-landscape.html">Legal landscape</a></li><li><a href="../research/go-to-market.html">Go-to-market &amp; sources</a></li></ul></div><div class="group"><div class="label">Notes &amp; more</div><ul><li><a href="../notes/open-questions.html">Open questions</a></li><li><a href="../notes/future-ideas.html">Future ideas</a></li><li><a href="../wireframes/index.html">Wireframes</a></li><li><a href="../fa/index.html">Farsi documents</a></li></ul></div></nav>
</aside>
<main class="main"><div class="content">
<div class="topbar"><button class="theme-toggle" type="button" onclick="__t()">theme</button></div>
<h1 id="8-payments-escrow">8. Payments &amp; Escrow</h1>
<p><a href="index.html">← Business Requirements</a></p>
<h2 id="a-business-requirements">(a) Business requirements <a class="anchor" href="#a-business-requirements" aria-hidden="true">#</a></h2>
<ul>
<li>The family pays the <strong>gross</strong> booking price <strong>through the platform</strong> by card via a licensed PSP's IPG. The platform is the <strong>merchant-of-record</strong>; the payment lands net of provider/Shaparak fees.</li>
<li><strong>Escrow is an internal ledger state, not platform-held cash.</strong> The platform models money state with a minimal <strong>double-entry <code>ledger_entries</code></strong> ledger: each money event posts <strong>balanced</strong> legs grouped by a transaction group. Account types: <code>escrow_held</code>, <code>platform_revenue</code>, <code>nurse_payable</code>, <code>refund_payable</code>, <code>bnpl_fee_expense</code>, <code>nurse_clawback_receivable</code>. The ledger is the <strong>single source of truth</strong> for "how much is held," "how much do we owe nurses now," and "what is our commission income" — replacing fragile inference from scattered status booleans.<ul>
<li>On a successful card payment: debit <code>escrow_held</code> (gross), credit <code>platform_revenue</code> (Balinyaar commission), credit <code>nurse_payable</code> (nurse payout).</li>
</ul>
</li>
<li><strong>Settlement-sharing (تسهیم).</strong> The compliant marketplace primitive is splitting one incoming card payment across multiple <strong>registered IBANs</strong> (the nurse's share and the platform's commission) at settlement, performed by Shaparak/the provider — the platform never touches the actual split. The internal ledger mirrors this split; the per-booking fee snapshot freezes it.</li>
<li><strong>Per-booking the three amounts are stored separately and never conflated:</strong> <code>gross_price_irr</code> (what the customer is charged), <code>balinyaar_commission_irr</code> (platform's cut — drives the nurse payout), and (for BNPL) <code>bnpl_commission_irr</code> (the provider's merchant discount — a platform expense). <code>nurse_payout_amount = gross_price_irr balinyaar_commission_irr</code>.</li>
<li><strong>Webhook idempotency is mandatory before money moves.</strong> Every PSP/BNPL callback is stored raw and <strong>deduplicated by a unique external event id</strong> in <code>payment_webhook_events</code> before any money state mutates — preventing double-confirmed bookings and double-settlements from at-least-once, retried callbacks.</li>
<li><strong>Payment uniqueness:</strong> at most one <code>succeeded</code> payment transaction per booking, and the Shaparak reference is unique — enforced so a retried success webhook cannot double-confirm.</li>
<li><strong>Multi-provider failover.</strong> Provider settlement cut-offs are a real continuity risk (the Toman/Jibit Nov-2024 suspensions cut businesses off mid-cycle). The payment layer abstracts the provider behind configuration so a blocked provider can be swapped, and the reconciliation ledger survives a provider being cut off.</li>
</ul>
<h2 id="b-iran-specific-considerations">(b) Iran-specific considerations <a class="anchor" href="#b-iran-specific-considerations" aria-hidden="true">#</a></h2>
<ul>
<li><strong>The load-bearing legal constraint:</strong> a پرداخت‌یار may <strong>not</strong> hold customer deposits, run wallets, or move money between merchants; the Shaparak ban on inter-merchant/inter-facilitator transfers means the "delay the تسهیم and redistribute later from a platform pool" pattern is regulatory grey-to-prohibited. The compliant posture is: collect via the provider, model escrow as an <strong>internal ledger over funds custodied at the licensed provider/partner bank</strong>, and pay out by provider-side settlement to <strong>verified, registered nurse IBANs</strong>. A bank-grade escrow product (e.g., Vandar میندو / معاملات امن) is the only true hold/release/refund mechanism, and its EVV-triggered hold is unverified — so the platform never assumes it can lawfully custody the cash itself.</li>
<li><strong>PSP received ≠ cash in bank.</strong> Iranian PAYA settlement is cyclic (T+0/T+1, holiday-deferred), so the ledger separates a clearing/receivable state from settled cash, making bank reconciliation possible.</li>
<li>Toman/PSP units differ from internal Rials; convert only at the API boundary. Amounts are BIGINT IRR internally to avoid float/rounding bugs.</li>
</ul>
<h2 id="c-mvp-vs-deferred">(c) MVP vs DEFERRED <a class="anchor" href="#c-mvp-vs-deferred" aria-hidden="true">#</a></h2>
<ul>
<li><strong>MVP:</strong> card payment via one licensed PSP; internal double-entry <code>ledger_entries</code> escrow; per-booking three-way amount split; تسهیم-style commission/nurse-share modeling; <code>payment_webhook_events</code> idempotency; single-succeeded-transaction-per-booking guard; provider abstraction for failover.</li>
<li><strong>DEFERRED:</strong> a nurse-facing wallet with on-demand withdrawal (facilitator wallet prohibition risk); multiple simultaneous live PSPs at launch (abstraction is built, second provider added later); bank-grade EVV-triggered escrow product integration.</li>
</ul>
<h2 id="d-supporting-database-entities">(d) Supporting database entities <a class="anchor" href="#d-supporting-database-entities" aria-hidden="true">#</a></h2>
<p><code>payment_gateways</code>, <code>payment_transactions</code> (unique Shaparak ref, single-succeeded-per-booking), <strong><code>payment_webhook_events</code></strong>, <strong><code>ledger_entries</code></strong>, <code>bookings</code> (<code>gross_price_irr</code>, <code>balinyaar_commission_irr</code>, <code>platform_fee_rate</code>, <code>nurse_payout_amount</code>), <code>refunds</code>, <code>nurse_bank_accounts</code> (verified registered IBANs).</p>
<blockquote><p><strong>Related:</strong> Deep fintech detail — <a href="../payments/escrow-ledger.html">Escrow Ledger</a>. Data model — <a href="../data-model/06-payments-ledger-and-refunds.html">Payments Ledger &amp; Refunds</a>.</p>
</blockquote>
<a class="back-to-top" href="#">↑ Back to top</a>
</div></main>
</div>
<script>
(function(){var k='balinyaar-docs-theme';var s=localStorage.getItem(k);
if(s)document.documentElement.setAttribute('data-theme',s);
else if(matchMedia('(prefers-color-scheme: dark)').matches)document.documentElement.setAttribute('data-theme','dark');})();
function __t(){var d=document.documentElement;var n=d.getAttribute('data-theme')==='dark'?'light':'dark';
d.setAttribute('data-theme',n);localStorage.setItem('balinyaar-docs-theme',n);}
</script>
</body>
</html>