Checklist d'intégration

Tout ce qu'il faut vérifier avant de passer en production.

Compte

[ ] Compte créé et email vérifié
[ ] KYC validé (niveau ≥ 2 pour accepter, niveau 3 pour payouts)
[ ] Compte bancaire de règlement (numéro de compte et banque) enregistré dans le dashboard
[ ] Au moins un utilisateur secondaire avec MFA activé (no single point of failure humain)

[ ] Clés sk_test_ créées avec scopes minimaux par cas d'usage
[ ] Clés sk_live_ créées et stockées dans un secret manager (Vault, AWS Secrets Manager, Doppler)
[ ] Aucune clé sk_live_ dans un repo git public, un fichier .env versionné, une variable d'env publique
[ ] IP whitelist activée si votre infra a des IPs fixes
[ ] Procédure de rotation documentée (responsable, fréquence, runbook)

[ ] Toutes les requêtes mutantes envoient Idempotency-Key (UUID v4 client-generated)
[ ] La clé idempotency est persistée côté client jusqu'à confirmation finale
[ ] Header Authorization: Bearer ... sur 100 % des appels
[ ] Gestion des codes d'erreur 4xx / 5xx (cf. codes d'erreur)
[ ] Backoff exponentiel sur 429 / 5xx
[ ] Logging structuré des requêtes/réponses (avec masquage de la clé)
[ ] Timeout client 15s minimum
[ ] Montants en leones avec 2 décimales maximum ("150.00"), devise SLE
[ ] Numéros au format E.164 : +232 suivi de 8 chiffres

[ ] Endpoint webhook créé dans le dashboard (HTTPS obligatoire)
[ ] Secret stocké dans le secret manager
[ ] Signature vérifiée sur le body brut (pas après parsing JSON)
[ ] Timestamp vérifié (|now - t| ≤ 300s)
[ ] Comparaison HMAC en temps constant (hash_equals / crypto.timingSafeEqual)
[ ] Idempotency côté votre serveur (UNIQUE(event, data.id) dans votre log)
[ ] Réponse 2xx en moins de 15s (traitement long → job async)
[ ] Retries de votre côté disabled (SOAMTAR retry pour vous, doublonner cause des doublons)
[ ] Plan de réponse aux 5 tentatives d'envoi SOAMTAR (alerter ops si échec persistant)

[ ] Cron quotidien qui pull GET/v1/payments?status=success et croise avec votre DB
[ ] Si écart : appel POST/v1/payments/{id}/verify pour forcer la sync
[ ] Alertes sur les transactions pending > 1h (sandbox) ou > 30 min (live)

[ ] HTTPS partout (incluant les return_url / cancel_url)
[ ] CSP qui autorise connect-src https://app.so-amtar.com
[ ] Pas d'auth middleware sur la route /webhooks/soamtar (bypassé pour le bon endpoint)
[ ] Logging masqué : pas de clé API ni signature dans vos propres logs
[ ] Audit trail interne sur chaque opération de paiement (qui, quand, depuis quelle IP)
[ ] Aucune donnée sensible dans les query strings : jamais ?phone=, ?email=, ?token= ou ?api_key= sur les appels à l'API. Utilisez le body JSON. SOAMTAR masque ces valeurs dans ses propres logs si elles apparaissent en query string, mais votre propre infra (reverse proxy, CDN, browser history) ne le fait pas.
[ ] URL d'endpoint webhook enregistrée dans SOAMTAR : HTTPS public uniquement. Les URLs loopback, IPs privées et TLDs internes sont rejetées à l'enregistrement.

[ ] Tests unitaires sur la vérification de signature webhook (succès + 3 cas d'échec)
[ ] Tests d'intégration sur le flow complet : init → PIN du client → webhook → confirmation
[ ] Tests de double-réception (même événement envoyé 2 fois → DB inchangée)
[ ] Tests de retry SOAMTAR (5xx puis 200 → traité une seule fois)
[ ] Test sandbox de chaque type d'événement attendu (success, failed, cancelled, expired)

[ ] CGV mises à jour avec la mention "Paiements traités par SOAMTAR"
[ ] Politique de confidentialité mentionnant la transmission des données payeur à SOAMTAR
[ ] Reçus/factures fournis aux clients pour chaque transaction réussie
[ ] Procédure de remboursement documentée (canal, délai, contact). Les remboursements passent par POST/v1/refunds (recrédités sur le portefeuille Orange Money du payeur) ; refund.success / refund.failed sont gérés.

[ ] Dashboard interne avec : volume de transactions, taux de succès, latence, taux d'erreur
[ ] Alerte si taux de succès chute sous 90 % en 5 min
[ ] Alerte si webhook depuis plus de 30 min sans réception (cas incident SOAMTAR)
[ ] Page status interne faisant le lien avec les contacts support SOAMTAR

[ ] Bascule des clés sk_test_ vers sk_live_ dans la config prod
[ ] Première transaction live : envoyer un test à un numéro Orange Money interne (Le 50.00), vérifier toute la chaîne
[ ] Notification équipe support : "SOAMTAR actif depuis [date]"
[ ] Procédure de rollback : comment revenir à sk_test_ en 5 min si incident

[ ] Rotation secret webhook tous les 6 mois
[ ] Rotation clés API tous les 6 mois
[ ] Mise à jour des handlers d'événements à chaque nouveau type ajouté (cf. journal des versions)
[ ] Revue trimestrielle des permissions (qui a accès au dashboard, IP whitelist à jour)

Tout coché ? Vous êtes prêt pour le go-live. Voir aussi Test → Production.