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:
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user