docs: sync from backend 19f7eb9, frontend 60ee6fb — Task #10 AML screening

08 - Operations/Incident Response.md

@@ -13,7 +13,7 @@ Runbooks for the most likely production incidents, plus communication templates
 
 | Sev | Meaning | Response time | Examples |
 |-----|---------|---------------|----------|
-| **Sev 1** | Site fully down or unable to process payments | 15 min | Backend container in crashloop; Mongo unreachable; SHKeeper API permanently failing |
+| **Sev 1** | Site fully down or unable to process payments | 15 min | Backend container in crashloop; Mongo unreachable; Request Network API/webhooks failing |
 | **Sev 2** | Major feature broken for a large share of users | 1 hour | Email sending broken; Redis disk full; chat undelivered |
 | **Sev 3** | Minor / cosmetic issue, isolated user reports | next business day | Single failed webhook; one user can't upload PDF |
 | **Sev 4** | No user impact, hygiene item | backlog | Backup older than 24h; disk > 80%; missed deploy |
@@ -133,35 +133,34 @@ The app gracefully degrades when Redis is unreachable for short windows — don'
 
 ---
 
-### 3.4 SHKeeper API down (payments blocked)
+### 3.4 Request Network API/webhook down (payments degraded)
 
-**Symptoms.** Backend logs show repeated `SHKeeper request failed: ECONNREFUSED` or non-2xx responses from `$SHKEEPER_API_URL`. Buyers see "Payment unavailable" in checkout. Sev 1 — money is involved.
+**Symptoms.** Backend logs show repeated Request Network API failures, webhook delivery failures, or payments stuck in pending/safety-pending. Buyers see "Payment unavailable" or a checkout that never confirms. Sev 1 — money is involved.
 
 **Runbook.**
 
 ```bash
-# 1. Confirm SHKeeper itself is reachable
-curl -fsS -H "X-Shkeeper-Api-Key: $SHKEEPER_API_KEY" \
-  "$SHKEEPER_API_URL/api/v1/healthcheck"
+# 1. Confirm Request Network API is reachable
+curl -fsS -H "Authorization: Bearer $REQUEST_NETWORK_API_KEY" \
+  "$REQUEST_NETWORK_API_BASE_URL"
 
-# 2. If 5xx from SHKeeper → it's their side
+# 2. If 5xx from Request Network -> provider/API side
 #    - Check their status page / contact provider
 #    - Toggle a banner in the frontend warning buyers
-#    - Consider switching SHKEEPER_FORCE_PAYOUT_DEMO=true so QA still works
-#      (do NOT do this for real customer money)
+#    - Pause new checkout creation if confirmations cannot be reconciled
 
 # 3. If our network can't reach it:
 #    - test from the host: curl from the host vs from inside the container
-docker exec nickapp-backend curl -v "$SHKEEPER_API_URL"
+docker exec nickapp-backend curl -v "$REQUEST_NETWORK_API_BASE_URL"
 #    - DNS / firewall changes?
 
 # 4. While blocked, monitor stuck payments
 docker exec nickapp-mongodb mongosh --eval \
   "use marketplace; db.payments.find({status:'pending', createdAt:{\$lt: new Date(Date.now() - 30*60*1000)}}).count()"
 
-# 5. Once SHKeeper is back, the app retries automatically. Verify the
-#    backlog drains. If a payment is stuck > 24h, manually verify against
-#    SHKeeper and use fix-transaction-hashes.js if needed.
+# 5. Once Request Network/webhook delivery is back, replay or reconcile
+#    pending events. If a payment is stuck > 24h, manually verify the
+#    on-chain transfer, Transaction Safety Provider result, and ledger state.
 ```
 
 **Always communicate.** Even short payment outages erode trust — post a status update.
@@ -422,7 +421,7 @@ Store postmortems alongside this vault — suggested path `/Users/mojtabaheidari
 | Payments lead | <name> | <name> | DM |
 | Infrastructure | <name> | <name> | DM |
 | Product / customer comms | <name> | <name> | #customer-comms |
-| SHKeeper provider contact | <email> | — | email |
+| Request Network/provider contact | <email> | — | email |
 | SMTP provider | <email> | — | email |
 
 ---

08 - Operations/Monitoring.md

@@ -134,7 +134,7 @@ Notable log lines to look for:
 | `🚀 Server running on port 5001` | App fully started |
 | `🔌 User connected: <id>` | Socket.IO connection |
 | `📥` | Inbound HTTP request log |
-| `💳 SHKeeper` | SHKeeper webhook / API call |
+| `💳 Request Network` | Request Network webhook / API call |
 | `🔐 Webhook verification` | Webhook signature check result |
 | `❌ Error` | Manual error log (also captured by Sentry) |
 
@@ -183,7 +183,7 @@ Today these are read manually from logs / Sentry. As Prometheus is added, encode
 | Webhook signature failures | log `Webhook verification failed` | 0 | > 0 |
 | Request Network webhook 4xx | nginx access log `/api/payment/request-network/webhook` | 0 | any real provider delivery returning 4xx |
 | Request Network safety-pending payments | `db.payments.find({"metadata.transactionSafety.status":"pending"})` | explained/short-lived | pending > 10 min without operator note |
-| SHKeeper API errors (5xx) | log + Sentry | 0 | > 5/min sustained |
+| Request Network API errors (5xx) | log + Sentry | 0 | > 5/min sustained |
 | Payouts stuck in `pending` > 30 min | `db.payments.find({type:'payout',status:'pending',createdAt:{$lt:ISODate(30 min ago)}})` | empty | non-empty |
 | Missing `transactionHash` after `completed` | the same query that drives `fix-transaction-hashes.js` | empty | non-empty |
 

08 - Operations/Payment and Trezor Verification Report.md

@@ -10,7 +10,7 @@ Date: 2026-05-24
 Scope:
 
 - Task 3 provider-neutral payment migration.
-- Request Network optional pay-in, webhook, and reconciliation support.
+- Request Network primary pay-in, webhook, and reconciliation support.
 - Internal funds ledger and release/refund ledger gates.
 - Optional Trezor safekeeping support.
 
@@ -84,7 +84,7 @@ Before enabling Request Network for a non-test cohort:
 2. Run backend typecheck.
 3. Test one Request Network sandbox pay-in with webhook callback.
 4. Confirm reconciliation dry-run output is empty or expected.
-5. Keep `PAYMENT_ROLLBACK_PROVIDER=shkeeper`.
+5. Keep the Request Network rollback/support runbook current; SHKeeper is historical context, not the current primary rollback target.
 
 Before enabling Trezor safekeeping enforcement: