diff --git a/docs/CRYPTO_PROBLEMS.rst b/docs/CRYPTO_PROBLEMS.rst
index 2fc1b01..6065fb8 100644
--- a/docs/CRYPTO_PROBLEMS.rst
+++ b/docs/CRYPTO_PROBLEMS.rst
@@ -3,6 +3,21 @@ Cryptocurrency Payment Problems and Solutions
 
 This document outlines the various failure modes in cryptocurrency payment processing and proposed solutions for each.
 
+Payment Processing UI Behavior
+------------------------------
+
+**Real-Time Status Updates**:
+- Quote page polls for payment status and updates immediately when payment detected
+- Status changes from "pending" → "received" → "confirmed" in real-time
+- Payment buttons and QR codes are disabled once payment is received
+- Prevents duplicate payments through UI lockout
+
+**Automatic Redirects**:
+- Upon confirmation (as fast as 2 confirmations for small digital goods)
+- Users are automatically redirected to invoice or product download page
+- Digital products: Direct to download page
+- Physical products: To invoice with shipping details
+
 Transaction Failure Scenarios
 -----------------------------
 
@@ -32,7 +47,7 @@ Transaction Failure Scenarios
 **Problem**: Customer sends more than required amount (e.g., $12 instead of $10)
 
 **Current Behavior**:
-- If payment >= expected, order completes
+- If payment >= expected, order completes and user redirected to invoice/download
 - Automatic refund of excess minus 9% restocking fee (if refund address configured) (✓ RESOLVED)
 - Remaining funds auto-swept to cold wallet after refund (✓ RESOLVED)
 
@@ -90,7 +105,8 @@ Transaction Failure Scenarios
 **Problem**: Customer accidentally pays twice for same order
 
 **Current Behavior**:
-- First payment completes order
+- First payment completes order and user redirected to invoice/download
+- Quote page shows "payment received" status, preventing duplicate attempts
 - Second payment automatically refunded minus 9% restocking fee (✓ RESOLVED)
 - Multiple duplicate payments handled correctly (✓ RESOLVED - see "The MONERO DOOM Scenario")
 
@@ -134,6 +150,7 @@ could steal funds from other payments sharing the same subaddress. The solution
 **Current Behavior**:
 - System uses risk-based confirmation requirements (✓ RESOLVED)
 - Order waits for required confirmations based on amount/product type
+- Upon reaching required confirmations, user automatically redirected to invoice/download
 
 **Implemented Solutions**:
 - ✓ Risk-based confirmation requirements (petty/mid/high tiers)