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)
[ ] RIB enregistré dans le dashboard
[ ] Au moins un utilisateur secondaire avec MFA activé (no single point of failure humain)

[ ] Clés pk_test_ créées avec scopes minimaux par cas d'usage
[ ] Clés pk_live_ créées et stockées dans un secret manager (Vault, AWS Secrets Manager, Doppler)
[ ] Aucune clé pk_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. errors)
[ ] Backoff exponentiel sur 429 / 5xx
[ ] Logging structuré des requêtes/réponses (avec masquage de la clé)
[ ] Timeout client 15s minimum

[ ] 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_id) dans votre log)
[ ] Réponse 2xx en moins de 15s (traitement long job async)
[ ] Retries de votre côté disabled (HayBTech retry pour vous, doublonner cause des doublons)
[ ] Plan de réponse aux 5 retries HayBTech (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 (mode test) ou > 30 min (live)

[ ] HTTPS partout (incluant les success_url / failed_url)
[ ] CSP qui autorise connect-src https://app.haybtech.com
[ ] Pas d'auth middleware sur la route /webhooks/haybtech (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. HayBTech 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 HayBTech : 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 webhook confirmation
[ ] Tests de double-réception (même event_id envoyé 2 fois DB inchangée)
[ ] Tests de retry HayBTech (5xx puis 200 traité une seule fois)
[ ] Test (clés sk_test_…) de chaque type d'événement attendu (success, failed, cancelled, expired)

[ ] CGV mises à jour avec la mention "Paiements traités par HayBTech"
[ ] Politique de confidentialité mentionnant la transmission des données payeur à HayBTech
[ ] Reçus/factures fournis aux clients pour chaque transaction réussie
[ ] Procédure de remboursement documentée (canal, délai, contact)

[ ] 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 HayBTech)
[ ] Page status interne faisant le lien avec les contacts support HayBTech

[ ] Bascule des clés pk_test_ vers pk_live_ dans la config prod
[ ] Première transaction live : envoyer un test à un compte interne (5 000 XOF), vérifier toute la chaîne
[ ] Notification équipe support : "HayBTech actif depuis [date]"
[ ] Procédure de rollback : comment revenir à pk_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. changelog)
[ ] 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.