# 7. Cancellation & Refunds

[← Business Requirements](index.md)

## (a) Business requirements
- Cancellation/refund rules are **tiered and structured**, not a single blunt "default 100%". The platform defines `cancellation_policies` tiers by **lead time** and **initiating actor**:
  - **Free** cancellation more than 24h before start.
  - **Partial** refund (e.g., 50%) under 24h.
  - **Customer no-show:** up to 100% charge.
  - **Nurse no-show:** full refund to the customer **and** a penalty/forfeiture for the nurse.
- The **applicable policy is snapshotted onto the booking** at booking time (mirroring the per-booking fee-rate snapshot), so later policy edits never rewrite history. The **resolved** cancellation fee / refund percentage is recorded on the refund event.
- For multi-session engagements, **cancellation is per remaining session:** cancelling mid-engagement refunds only the un-started sessions, while completed-and-verified sessions remain payout-eligible.
- **Refunds are admin-only** — there is no customer self-service refund. A refund is initiated by an admin and **must be linked to a support ticket** (`tickets`) that holds the conversation and dispute evidence.
- A refund **decomposes across the two fee legs** — how much of the platform commission and how much of the nurse payout is being reversed — because the booking gross is `platform commission + nurse payout`.

## (b) Iran-specific considerations
- A flat percentage is too blunt for شبانه‌روزی live-in engagements and Iranian holiday-period bookings; tiered, snapshotted policy reduces dispute load.
- **The refund money path depends on whether the nurse has already been paid** (Section 8/10): pre-payout it is a clean reversal; post-payout it becomes a platform-funded refund plus a nurse clawback, because an Iranian bank transfer to a nurse's IBAN is effectively irreversible.
- For BNPL bookings, the refund **never** goes nurse→customer or Balinyaar→customer directly — it is initiated through the BNPL provider's revert/cancel API (Section 8/9).

## (c) MVP vs DEFERRED
- **MVP:** tiered `cancellation_policies`; per-booking policy snapshot; admin-only, ticket-linked refunds; per-session cancellation for engagements; nurse-no-show vs customer-no-show handling; fee-leg decomposition on refunds.
- **DEFERRED:** automated nurse no-show penalty (manual admin action at launch); self-service partial-refund UI; holiday-specific cancellation overrides.

## (d) Supporting database entities
**`cancellation_policies`**, `bookings` (policy snapshot, `dispute_window_ends_at`), `refunds` (admin-only, `ticket_id`, fee-leg decomposition, `refund_channel`), `tickets`, `nurse_clawbacks` (post-payout case), `ledger_entries`.

## (e) As built (backend-phase-11)
Decisions fixed while building the refund/clawback/invoice engine (config-driven where possible):
- **Refund channel canonical code:** the out-of-band bank refund is stored and served as **`manual`** (the wire
  code), not `manual_bank` — they are the same channel. Full set: `psp_card` | `bnpl_revert` | `manual`.
- **Ticket link is config-gated until b15.** `refunds.ticket_id` is a nullable column with **no FK yet**
  (`tickets` arrives in b15). "A refund must link a ticket" is enforced by the `refund_ticket_required` config
  flag, **default `false`** so admin refunds are testable today; b15 wires the FK and flips it on.
- **BNPL refund ETA** is `now + config(bnpl_refund_eta_business_days, default 10)` business days (Fridays skipped),
  surfaced as `expected_customer_refund_eta`; the refund sits in `processing` until reconciled. Card refunds are
  immediate (`succeeded`, no ETA). Card and BNPL post the **same** reversal ledger legs.
- **Pre-payout vs post-payout fork** is decided by whether the nurse was already paid — derived from the booking's
  `dispute_window_ends_at` close until b13 ships `nurse_payouts` (a `refund_assume_nurse_paid` override exists).
  Clawback **recovery/netting is b13**; b11 only opens the `pending` receivable + supports admin write-off.

> **Related:** Data model — [Payments Ledger & Refunds](../data-model/06-payments-ledger-and-refunds.md).
