Journal et recette ERP

Ce document décrit le journal des communications ERP et la checklist de recette avant mise en production.

Journal communications

Toute interaction HTTP entre Epayment et l'ERP est tracée dans le journal des communications (portail régie et admin).

Champ	Valeur typique ERP
direction	OUT (Epayment appelle l'ERP) ; IN réservé aux webhooks ERP futurs
system	erp:rest, erp:fake
method	GET, POST
path	Chemin relatif appelé (ex. /dues, /payment-confirmations)
status_code	Code HTTP réponse
latency_ms	Durée aller-retour
request_body / response_body	JSON redacté (secrets masqués)

Consultation

Audience	Emplacement UI
Officer régie	Portail régie → Journal (filtre system ERP)
Super-admin	Admin → Communications

Le sandbox (fake) journalise les probes payment confirmation sans appel HTTP réel. Les probes REST déclenchent des appels effectifs visibles dans le journal.

Diagnostic courant

Symptôme	Vérification journal
Probe connexion échoue	Ligne GET /health : code 4xx/5xx, timeout
Dues vides inattendues	GET /dues : corps réponse, paramètre subject_ref
Confirmation non reçue ERP	POST /payment-confirmations : présence ligne, code réponse
Auth invalide	401/403 sur toutes les opérations

Probes intégrés (UI régie / admin)

Probe	Action	Sandbox	REST
Connexion	Health check	Données fictives	GET {health_path}
Dues	Preview créances	Données fictives	GET {dues_list_path}?subject_ref=
Disbursement	Preview lignes lot	Données fictives	GET {disbursement_batch_path}?batch_ref=
Payment confirmation	Push test	Journal uniquement	POST {payment_confirmation_path}

Références probe par défaut : subject_ref=DEMO-SUBJECT, erp_due_ref=DEMO-DUE.

Checklist recette collecte (portail citoyen)

Connexion et configuration

• [ ] Adaptateur rest actif avec base_url production ou pré-production
• [ ] Auth validée (probe connexion OK, ok: true sur health)
• [ ] Chemins correspondance alignés avec l'ERP (dues_list_path, payment_confirmation_path)
• [ ] Mappings services complets ou service par défaut défini

Pull dues

• [ ] GET /dues?subject_ref={contribuable_test} retourne { "items": [...] } strict
• [ ] Chaque item respecte le contrat dues (voir Contrat REST)
• [ ] erp_due_ref unique par ligne ouverte
• [ ] Preview dues UI régie cohérente avec réponse ERP brute
• [ ] service_label affiché après enrichissement catalogue

Paiement et confirmation

• [ ] Paiement test portail citoyen (mobile money ou agence)
• [ ] ERP reçoit POST /payment-confirmations avec erp_due_ref, notice_ref, transaction_id, amount_minor, paid_at
• [ ] Bloc payment présent avec channel (MOBILE_MONEY, CASH ou CARD)
• [ ] Idempotence : second POST même transaction_id géré côté ERP sans double comptabilisation
• [ ] Ligne journal POST /payment-confirmations en 2xx

Paiement partiel (si applicable)

• [ ] Dues avec allow_partial: true et minimum_amount_minor définis
• [ ] Montant encaissé transmis dans amount_minor de la confirmation
• [ ] Solde résiduel cohérent côté ERP après confirmation

Checklist recette disbursement

• [ ] GET /disbursements?batch_ref={lot_test} retourne lignes valides
• [ ] payment_method : AIRTEL_MONEY, MTN_MOMO ou BANK_TRANSFER (voir contrat)
• [ ] Objet payout conforme au mode de paiement
• [ ] Preview lignes UI régie avant soumission batch
• [ ] Batch sandbox connecteur fake exécuté sans erreur bloquante
• [ ] Rapport post-exécution exportable et réconciliable avec l'ERP

Critères de passage production

Critère	Seuil
Probes automatisés	100 % verts sur environnement cible
Parcours citoyen bout en bout	Au moins un paiement MM et un paiement agence si les deux canaux sont ouverts
Latence health	Stable sous le SLA interne régie (typ. < 2 s P95)
Journal	Aucune erreur 5xx non expliquée sur 24 h de tests
Rotation secrets	Procédure documentée et testée une fois

Documentation associée

• Mise en service
• Contrat REST
• Portail citoyen
• Paiements en masse