From 2d87e1c92f60e2adaa9b0702e3d50d0056283586 Mon Sep 17 00:00:00 2001 From: shum Date: Thu, 22 Oct 2026 10:06:28 +0000 Subject: [PATCH] plans: names docs late credit ledger --- plans/names-codes/2026-10-09-name-codes.md | 2 +- plans/names-codes/2026-10-09-names-web-store-plan.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/plans/names-codes/2026-10-09-name-codes.md b/plans/names-codes/2026-10-09-name-codes.md index 827178bb36..2abcfcb29d 100644 --- a/plans/names-codes/2026-10-09-name-codes.md +++ b/plans/names-codes/2026-10-09-name-codes.md @@ -525,7 +525,7 @@ Migration `20261010_names` runs in SQLite and Postgres. The badge tables (`sx_ba - A row found applied on chain with no receipt for any of its hashes is `mined`, with no hash known to have mined. - The service answers identical repeats from the table after a restart. The per-name cap counts its rows of the last hour. - **`sx_badge_service_name_transactions`:** the registration or edit, `kind` (commit, register, edit), `raw`, `tx_hash`, `registrar_nonce`, `sent_at`, `mined_block`, `status`. The sender resumes from the rows with no receipt. -- **`sx_badge_service_name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_credited` (the cents of a late payment already credited to the order's balance). Payments gain `confirmed_amount` (confirmed money only, only rising), which the late credit reads. +- **`sx_badge_service_name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_alerted_at`. Payments gain `confirmed_amount`, `confirmed_crypto` and `invoice_rate` (confirmed money only, only rising). Each late credit is a `name_late_credits` row with the confirmed crypto, the invoice's and the current rate, the lower one used, and the cents (owner, 2026-10-22: the lower of the two rates). - Today's invoice queries are badge-only. So each of these gains this table: `GET /api/invoice/:id`, cancel, settlement, the poller's unpaid and overdue scans and its expiry update, and the lookups by `provider_ref`. - Settling a name invoice queues its registration, instead of requiring a code hash. This happens in the transaction that marks the invoice paid; the invoice's and the registration's changes are published to the long poll only after that commit. It applies only to an invoice still open. - An invoice settled after it expired or was canceled leaves its registration `unpaid` and credits its confirmed money to that order's balance. Its order page and history row say "Paid after the invoice closed; kept as your balance", with Use and Refund. diff --git a/plans/names-codes/2026-10-09-names-web-store-plan.md b/plans/names-codes/2026-10-09-names-web-store-plan.md index 9295b913ee..5fbdefcc12 100644 --- a/plans/names-codes/2026-10-09-names-web-store-plan.md +++ b/plans/names-codes/2026-10-09-names-web-store-plan.md @@ -581,7 +581,7 @@ An order carries the name's hash and length, the duration, the owner address, th - A row found applied on chain with no receipt for any of its hashes is `mined`, with no hash known to have mined. - The service answers identical repeats from the table after a restart, and the per-name cap counts its rows. - **`name_transactions`:** `registration_id` or the edit's id, `kind` (commit, register, edit), `raw`, `tx_hash`, `registrar_nonce`, `sent_at`, `mined_block`, `status`. The sender resumes from the rows with no receipt. - - **`name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_credited` (the cents of a late payment already credited to the order's balance). The amount is the invoice's own. Payments gain `confirmed_amount` (confirmed money only, only rising), which the late credit reads. + - **`name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_alerted_at`. The amount is the invoice's own. Payments gain `confirmed_amount`, `confirmed_crypto` and `invoice_rate` (confirmed money only, only rising). Each late credit is a `name_late_credits` row with the confirmed crypto, the invoice's and the current rate, the lower one used, and the cents (owner, 2026-10-22). - **The badge tables are untouched**, so there is no table rebuild. - **Invoice queries:** today's are badge-only, so each gains the name side. - The queries: the shared `invoiceRowSelect` (inner-joined to `badge_code_invoices` and `badge_codes`); `qGetInvoice`, behind `GET /api/invoice/:id`, cancel and settlement (`settlementInvoice`); the poller's `qUnpaidRefs`, `qOverdueInvoices` and `qExpireOverdue` (whose update requires a `badge_code_invoices` row); and the lookups by `provider_ref`.