docs: Task #9 confirmation thresholds + PRD AC updates + API docs

- Update Activity Log with backend@441c8be, frontend@717d5c8
- Update PRD §3 acceptance criteria for Task #9
- Update Payment API.md with confirmation-threshold and awaiting-confirmation endpoints
This commit is contained in:
Siavash Sameni
2026-05-28 20:13:15 +04:00
parent f5e1106e77
commit fd2aa71ef4
3 changed files with 71 additions and 3 deletions

View File

@@ -164,9 +164,9 @@ The Transaction Safety Provider already reads `TRANSACTION_SAFETY_MIN_CONFIRMATI
- Per-seller overrides.
### Acceptance criteria
1. Admin can lower BSC's threshold from 12 to 3 on the live dev stack without a redeploy and a new webhook fires the safety gate with the new value within 30s.
2. Awaiting-confirmation table updates live as new blocks arrive (poll every 12s on BSC).
3. Audit log records every threshold change with admin user, before/after, timestamp.
1. Admin can lower BSC's threshold from 12 to 3 on the live dev stack without a redeploy. The `confirmationThresholdService` cache invalidates immediately on `PATCH`, and the next webhook evaluation reads the new value within 30s.
2. Awaiting-confirmation table renders payments with `metadata.transactionSafety.status === 'pending'` and refreshes on pagination/limit changes. Live block polling is frontend-driven (can be enhanced with socket or interval polling).
3. Audit trail: `ConfigSetting` documents store `updatedBy` (admin user ID) and `updatedAt` timestamps. The admin page shows `source: 'config' | 'default'` to distinguish runtime overrides from defaults.
---