plans: names late credit final contract nits

plans/names-codes/2026-10-21-store-api.md

@@ -492,12 +492,12 @@ A paid order whose name someone registered first keeps what it is worth as a bal
 
 - **What it is:** US cents, held per order and owned by that order's owner code. Balances are never merged, across orders or wallets: one order's balance pays for one new order at a time. A balance never expires.
 - **Credited:** with the order's `price`, in the write that makes a paid order `taken` (paid by invoice, from a balance, or both), so a `taken` order with a payment always has a balance. A move to a cheaper name adds the difference (`/name`, above). A code order gets none: codes carry no money, and its code is released (section 4). A late payment (section 1) adds its money to the closed order's own balance (owner, 2026-10-22). It covers money that arrives on any name invoice after it closed (a difference invoice included), and money received while the invoice was open that it still holds when the provider closes it or a cancel meets it.
-  - *Only confirmed money is credited.* Stripe: the succeeded amount. BTCPay: when the invoice reads `Settled`, or every payment of its payment method reads `Settled`, all of `paymentMethodPaid`; otherwise the sum of the `Settled` payments' `value`, capped at `paymentMethodPaid`, so the credited crypto never exceeds the received and reaches it exactly once everything settles. Crypto is counted in integer atomic units (satoshi for BTC, piconero for XMR); an amount with more decimals than its unit fails the read. BTCPay settles a payment at the invoice's own speed policy (`checkout.speedPolicy`, fixed when the invoice was made); a late credit needs at least one confirmation, so money on an invoice made under `HighSpeed` (which settles at zero confirmations) is never credited automatically, whatever the configuration says later, and goes to the alert below.
-  - *At the lower rate* (owner, 2026-10-22): new confirmed crypto is credited at the lower of the invoice's rate and the provider's current rate (BTCPay's store rates, through the configured provider), and rounded down to the cent, so a credit never exceeds its value at either rate. The rates and the cents are stored with each credit. A failed rate read credits nothing yet, and the credit is tried again, never at a guessed rate: a failed read is an error, a missing pair, a rate with errors, a rate at or below 0, or a rate below half the invoice's (`minCurrentRateFraction`, an owner-visible constant), which is taken as a glitch and logged as an error.
+  - *Only confirmed money is credited.* Stripe: the succeeded amount. BTCPay: when the invoice reads `Settled`, or every payment of its payment method reads `Settled`, all of `paymentMethodPaid`; otherwise the sum of the `Settled` payments' `value`, capped at `paymentMethodPaid`, so the credited crypto never exceeds the received and reaches it exactly once everything settles. Crypto is counted in integer atomic units (satoshi for BTC, piconero for XMR); an amount with a non-zero digit past its unit (trailing zeros are accepted) cannot be counted: that money is not credited and reaches the alert, while the rest of the read, and every badge or on-time order, goes on as before. BTCPay settles a payment at the invoice's own speed policy (`checkout.speedPolicy`, fixed when the invoice was made; a missing or unknown policy counts as `HighSpeed`); a late credit needs at least one confirmation, so money on an invoice made under `HighSpeed` (which settles at zero confirmations) is never credited automatically, whatever the configuration says later, and goes to the alert below.
+  - *At the lower rate* (owner, 2026-10-22): new confirmed crypto is credited at the lower of the invoice's rate and the provider's current rate for the coin against US dollars, the service's currency (BTCPay's store rates, through the configured provider), computed exactly and rounded down to the cent, so a credit never exceeds its value at either rate. The rates and the cents are stored with each credit. A failed rate read credits nothing yet, and the credit is tried again, never at a guessed rate: a failed read is an error, a missing pair, a rate with errors, a rate at or below 0, A rate below half the invoice's (`minCurrentRateFraction`, an owner-visible constant) is not used either: it is logged as an error, as it may be a glitch or a real fall, and the credit waits.
   - *Once:* each credit adds only the confirmed crypto (or, for Stripe, cents) not yet credited from that invoice, under the invoice's lock, with each credit numbered per invoice and unique, so a repeated, growing or reorganised report, or a second instance, never credits twice, and an unconfirmed payment that is replaced or dropped never credits.
   - *Which invoices:* a name invoice whose order is `unpaid` and not live, whatever the invoice's own status (a late `Settled` invoice reads `paid` while its order stays `unpaid`).
   - *When:* after the settlement that recorded the payment commits, by the poller, and again by the poller's pass (at its idle cadence) for any such invoice whose confirmed money is not all credited, so a crash or a failed rate read loses nothing. A cancel by the buyer reads no rate: its late money is credited by the poller. The rate read never runs under the invoice's lock, happens only when crypto is due, and is made once per currency pair per pass.
-  - *Pending and the alert:* money received but not confirmed (a mempool payment, Monero confirming with a zero figure) is pending and logged at info. The operator is alerted once per invoice, and again only when more money arrives, when money on a closed invoice is still not all credited and its payment was first seen longer ago than the poller's read window (`settleWindow`, about 72 hours). The alert names the crypto received, confirmed and credited (cents for Stripe), and its reason: unconfirmed money ("refund by hand only a transaction confirmed on chain that BTCPay no longer monitors; one still `Processing` there waits"), or confirmed money waiting on the rate read ("do not refund; fix the rate read"). Only one instance logs it, by a conditional write of the alert's mark.
+  - *Pending and the alert:* money received but not confirmed (a mempool payment, Monero confirming with a zero figure) is pending and logged at info. The operator is alerted once per invoice, and again only when more money arrives, when money on a closed invoice is still not all credited and its payment was first seen longer ago than the poller's read window (`settleWindow`, about 72 hours). The alert names the crypto received, confirmed and credited (cents for Stripe), and its reason: unconfirmed money ("refund by hand only a transaction confirmed on chain that BTCPay no longer monitors; one still `Processing` there waits"), confirmed money waiting on a failing rate read ("do not refund; fix the rate read"), or confirmed money waiting because the current rate is below the floor (naming both rates: "the coin's price fell by more than half since the invoice; the owner decides: credit at the current rate, or refund by hand"); or money that could not be counted in units. Only one instance logs it, by a conditional write of the alert's mark.
 - **Spent:** only by `/spend` (below), signed by the owner, for a new order of the same owner. When the balance covers the new name's price, the price is spent at once and the rest stays as balance. When it does not, all of it pays, and an invoice is made for the difference.
 - **Held:** while that invoice is open, the new order holds the balance: no other spend and no refund takes it. Settlement queues the new order and spends what it held, in one transaction. Whatever closes the invoice unpaid (a cancel, its expiry, the poller's sweep, a next order closing it as overdue, section 1) releases the hold in the transaction that closes the order. A payment that arrives after that is a late payment (section 1): it is credited to the closed order's own balance, and the released balance is not touched. A hold by an order whose invoice is past its expiry time with no money received reads as free (`held` false), and the next `/spend` of that balance closes that order first, in its own transaction, as section 1 closes an overdue order (below). A refund does not: it waits for the poller's sweep to close the holder.
 - **Refunded:** only by support, when the buyer writes with the order's reference (its invoice id, or its registration id for an order without an invoice). The operator command `//refund <reference> <cents>` (task plan, T26) sets the balance to 0 and adds the cents to `refunded`, which counts every refund of the balance (one can be credited again later, by a late payment or a move); support then pays them back by hand, by the methods that paid them, which the command lists back through every balance the money came from. A held balance is never refunded, overdue holder or not: the command names the holder and its invoice's expiry, and support runs it again once the poller has closed the holder. There is no refund endpoint, no automatic refund, and no refund address given to the service.