ui phase 6

dev/shared-working-context/frontend/requests/for-backend.md

@@ -710,3 +710,69 @@ delivers fixes in its own change. **Frontend never edits backend code to "fix" a
   produces the JSON blob today.
 - **Status:** open — the client keeps the defensive multi-key parse until this lands; no user-facing defect
   today (the address still renders when any recognizable key is present), just an unenforced contract.
+
+## REQ-046 — Checkout/receipt enrichment: nurse identity on the summary + a client-readable payment reference — filed by ui-phase-6 — 2026-07-18
+- **Need:** Two additions to the checkout/payment surfaces:
+  1. `nurseAvatarUrl` (string, nullable) and `nurseVerified` (bool) on `CheckoutSummaryDto` — the C6 identity
+     moment ("who am I paying for").
+  2. A client-readable **tracking code** and **paid-at timestamp** for a captured payment — either on the
+     pending-callback poll target or a dedicated confirm-read: `trackingCode` (string, nullable — a
+     customer-quotable reference) and `paidAt` (UTC ISO, nullable) on `PaymentOutcomeDto`
+     (`GET booking_requests/get/{id}`-derived today per REQ-017).
+- **Why:** C6 now shows the nurse's avatar + a verified badge next to the payable total, and the
+  confirmation screen is rebuilt as a screenshot-worthy receipt (کد پیگیری in a copyable row + Shamsi
+  payment date-time) — Iranian users screenshot payment receipts and expect a reference number to quote in
+  a dispute. Neither field exists on the wire today; the mock supplies both (nurse is always seed-verified,
+  no avatar in the f7 mock store; `trackingCode` = the PSP `gatewayReferenceCode`, `paidAt` = the capture
+  timestamp) and the real `paymentClientApi` leaves them `null` — the receipt hides the row rather than
+  render a fabricated code (extends REQ-016/017).
+- **Proposed shape:** `CheckoutSummaryDto { …, nurseAvatarUrl: string|null, nurseVerified: boolean }`;
+  `PaymentOutcomeDto { …, trackingCode: string|null, paidAt: string|null }`.
+- **Status:** open — mock-only until served; real path hides the identity avatar/badge and the tracking
+  code/paid-at rows gracefully.
+
+## REQ-047 — Customer payment-transactions list (card + BNPL) — filed by ui-phase-6 — 2026-07-18
+- **Need:** A customer-scoped read of every payment transaction the caller made — proposed
+  `GET api/v1/bookings/payment_history` (owner-scoped) →
+  `[{ transactionId, bookingRequestId, bookingId, status, amountIrr, createdAt }]`.
+- **Why:** The wallet's «پرداخت‌ها» tab is the fix for the audit's top finding — the Wallet tab was a
+  permanently empty installments-only shell for every card-paying customer (the default path; BNPL is
+  mock-gated). No endpoint serves a card payment history today. The client added `getPaymentHistory` to the
+  `PaymentApi` seam; the mock returns the in-memory transaction list, the real `paymentClientApi` targets
+  this proposed route (404s until delivered — the tab renders its empty state until then). BNPL rows are
+  sourced separately from `services/bnpl`'s wallet installments (REQ-024) and merged client-side for display
+  — this REQ covers the card half only.
+- **Proposed shape:** as above; `status` reuses the existing `PaymentTransactionStatus` enum
+  (`pending|succeeded|failed`).
+- **Status:** open — wallet «پرداخت‌ها» renders the empty state on the real path until delivered.
+
+## REQ-048 — Customer "all my refunds" list — filed by ui-phase-6 — 2026-07-18
+- **Need:** A customer-scoped read of every refund the caller owns — proposed `GET api/v1/refunds/my`
+  (owner-scoped) → the same thin shape `GET refunds/{id}/status` already returns, as an array.
+- **Why:** The wallet's «استردادها» tab renders every refund via the shared `RefundStatusCard`. b11's only
+  customer-facing refund reads are by-booking (REQ-021) and by-id — there's no "list everything I've been
+  refunded" read, and REQ-021's by-booking route requires already knowing which booking to ask about. The
+  client added `getMyRefunds` to the `RefundsApi` seam (mock-primary per `USE_REFUNDS_MOCK`, extends
+  REQ-019/020/021); the real `refundsClientApi` targets this proposed route.
+- **Proposed shape:** `GET api/v1/refunds/my` → `RefundStatusWire[]` (the same per-item shape as
+  `refunds/{id}/status`).
+- **Status:** open — wallet «استردادها» renders the empty state on the real path until delivered.
+
+## REQ-049 — Invoice fiscal fields: payment method, transaction reference, seller fiscal identity — filed by ui-phase-6 — 2026-07-18
+- **Need:** Three additions to `InvoiceDto` so the invoice is a document a family can file for
+  reimbursement/dispute:
+  1. `paymentMethod: 'card' | 'bnpl' | null`.
+  2. `transactionReference: string | null` (opaque, the settling payment/BNPL reference).
+  3. `sellerFiscalIdentity: { legalName, economicCode: string|null, address: string|null } | null` — a
+     platform-level fact (not per-invoice data), read from wherever the مودیان enrollment config lands.
+- **Why:** The invoice page was print-capable but not audit-worthy (no payment method, no transaction
+  reference, no seller tax/economic identity — the things a real Iranian VAT invoice carries). Buyer name
+  and the service/visit-date recap are composed client-side today (a UI join over the customer's own
+  profile + the booking detail read — no money math, per phase §3.5), but payment method/reference and the
+  seller identity have no client-side source and must be served. The mock populates all three for card
+  payments (`paymentMethod: 'card'`, `transactionReference` = the gateway reference, a placeholder
+  `sellerFiscalIdentity`); BNPL-settled invoices and the real path leave them `null` — the invoice hides
+  those rows rather than render fabricated fiscal data. Extends REQ-018.
+- **Proposed shape:** as above.
+- **Status:** open — invoice renders the reconciling money breakdown + مودیان status unconditionally; the
+  three new rows render only when served.