Implement Moyasar payments flow with webhooks

docs/execplans/payments-moyasar.md

@@ -11,17 +11,17 @@ After this change, the backend can create Moyasar payments, track their state tr
 ## Progress
 
 - [x] (2026-02-28 14:35Z) Created ExecPlan for payments integration (Moyasar + webhooks + idempotency).
-- [ ] Inspect current payments models, endpoints, and any Moyasar scaffolding to align naming.
-- [ ] Define payment state model and idempotency tracking.
-- [ ] Implement payment creation service and API endpoint.
-- [ ] Implement webhook endpoint with signature verification.
-- [ ] Add tests for creation, idempotency, and webhook reconciliation.
-- [ ] Update `docs/risks.md` to close payment integration gaps once tested.
+- [x] (2026-02-28 15:05Z) Inspected payments models/endpoints and aligned naming with Moyasar scaffolding.
+- [x] (2026-02-28 15:20Z) Defined payment state model extensions and idempotency tracking fields.
+- [x] (2026-02-28 15:40Z) Implemented payment creation service and API endpoint with provider gateway.
+- [x] (2026-02-28 15:55Z) Implemented webhook endpoint with secret verification and status mapping.
+- [x] (2026-02-28 16:10Z) Added tests for creation, idempotency, and webhook reconciliation.
+- [x] (2026-02-28 16:20Z) Updated `docs/risks.md` to close payment integration gaps once tested.
 
 ## Surprises & Discoveries
 
-- Observation: None yet.
-  Evidence: No implementation work has started.
+- Observation: The payments gateway needed an HTTP client dependency, so `requests` was added to backend requirements.
+  Evidence: `ModuleNotFoundError: No module named 'requests'` when running migrations after adding gateway calls.
 
 ## Decision Log
 
@@ -34,10 +34,13 @@ After this change, the backend can create Moyasar payments, track their state tr
 - Decision: Use a dedicated webhook endpoint with signature verification.
   Rationale: Ensures authenticity of provider callbacks and protects state integrity.
   Date/Author: 2026-02-28, Codex
+- Decision: Store provider payloads and webhook payloads on the payment record for auditability.
+  Rationale: Helps trace payment transitions without introducing a separate event table yet.
+  Date/Author: 2026-02-28, Codex
 
 ## Outcomes & Retrospective
 
-Planned changes will provide end-to-end payment creation, reconciliation via webhooks, and idempotency protections, filling the largest Phase 1 reliability gap.
+Payment creation, idempotency handling, and webhook reconciliation are implemented for Moyasar. Tests cover creation, idempotency, and webhook status transitions, reducing the largest Phase 1 reliability gap. Refund/capture operations remain future work if required.
 
 ## Context and Orientation
 
@@ -132,3 +135,4 @@ Example overlap-safe webhook logic:
 - `backend/apps/payments/views.py` must expose `PaymentCreateAPIView` and `payment_webhook` with signature verification.
 
 Plan Maintenance Note: Created on 2026-02-28 to implement Moyasar payments with idempotency and webhook reconciliation as the next Phase 1 reliability milestone.
+Plan Maintenance Note (Update): Marked steps complete and recorded dependency and audit decisions after implementing payments and tests on 2026-02-28.

docs/risks.md

@@ -15,9 +15,8 @@ This file tracks known gaps and risks to address in future iterations.
 - No cancellation rules or refund logic.
 
 ## Payments
-- Payment integration is not implemented. Current API only stores records and a Moyasar scaffold exists.
-- Webhook handling and payment status reconciliation missing.
-- Idempotency handling for payment creation missing.
+- Moyasar payment creation, webhook reconciliation, and idempotency are implemented.
+- Refund/capture operations are not implemented yet if required.
 
 ## Data And UX
 - Ratings are not recalculated from reviews.