House standard: a payment is final only after GP_CONFIRMATIONS (default 10)
on-chain confirmations. Add a terminal `confirmed` invoice state after `paid`
and drive it from the existing kernel-confirmation poll.
- config: GP_CONFIRMATIONS (default 10, must be >= 1).
- invoice: additive `confirmed` status (open -> paid -> confirmed); `paid`
stays a real, backward-compatible state. mark_confirmed() + a confirmations
reader off the paying payment.
- poll: track live confirmation depth per payment; advance the paying invoice
paid -> confirmed at the threshold and enqueue a payment.confirmed webhook
(once, on the transition). Self-terminating per payment.
- APIs: GET /invoice/{id}, GET /pay/{token}/status and GET /payment/{id} now
expose status + confirmations + confirmations_required.
- checkout: received -> confirming (n of N) -> confirmed, zero-JS meta-refresh
kept live through the confirming state.
- webhook: payment.confirmed carries confirmed_height + confirmations (the woo
and medusa connectors already consume this event).
- migration 0008: payment.confirmations, invoice.confirmed_at.
- tests: threshold transition, config default 10, payload shape, API wiring.
2ro
580c313e6d
