> ## Documentation Index
> Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Checklist de mise en production

> Vérifications techniques, sécurité et business à effectuer avant de basculer votre intégration LigdiCash en production.

Cette checklist couvre les points critiques à valider avant d'ouvrir votre intégration aux clients finaux. Parcourez-la dans l'ordre — chaque section s'appuie sur la précédente.

## Sécurité

<AccordionGroup>
  <Accordion title="Les clés API ne sont pas exposées côté client">
    L'Apikey et l'Auth Token ne doivent apparaître ni dans le code JavaScript du navigateur, ni dans une app mobile, ni dans un dépôt Git public.

    * [ ] Variables d'environnement serveur uniquement (`process.env`, `.env` non commité)
    * [ ] `.gitignore` inclut le fichier `.env`
    * [ ] Pas de clé dans les logs applicatifs
    * [ ] Pas de clé dans les réponses d'API retournées au frontend
  </Accordion>

  <Accordion title="Le callback re-vérifie le statut via l'endpoint confirm">
    Ne jamais faire confiance au payload reçu dans le callback — il peut être forgé. Appelez toujours `/confirm` avec le token stocké à la création.

    * [ ] Le handler de callback appelle `/checkout-invoice/confirm` avant toute action métier
    * [ ] Le token utilisé pour `confirm` est celui stocké à la création (pas le `token` du callback)
    * [ ] Un payload malformé ou avec un `transaction_id` inconnu est ignoré silencieusement
    * [ ] Voir [Sécurisation du callback](/api-paiement/callback/securisation)
  </Accordion>

  <Accordion title="La callback_url est accessible publiquement">
    LigdiCash doit pouvoir atteindre votre endpoint de callback depuis Internet.

    * [ ] URL accessible depuis une IP externe (pas `localhost` ou IP privée)
    * [ ] HTTPS recommandé (HTTP accepté par LigdiCash, mais déconseillé en production)
    * [ ] Pas de règle firewall bloquant les IPs LigdiCash
    * [ ] Si whitelisting requis : contactez le support LigdiCash pour obtenir les IPs à autoriser (max 3 IPs par projet)
  </Accordion>

  <Accordion title="Les identifiants de transaction sont non-devinables">
    Un `transaction_id` séquentiel (`1`, `2`, `3`...) permet à un attaquant d'énumérer vos transactions.

    * [ ] Utilisez un UUID v4 ou un ID préfixé avec suffixe aléatoire (`txn_` + timestamp + aléatoire)
    * [ ] Voir [Pattern transaction\_id](/concepts/transaction-id-pattern)
  </Accordion>
</AccordionGroup>

## Technique

<AccordionGroup>
  <Accordion title="Flux payin avec redirection">
    * [ ] `customer` est vide (`""`) dans tous les exemples de payin redirect
    * [ ] `cancel_url` pointe vers la page d'annulation, `return_url` vers la page de succès (pas inversé)
    * [ ] L'URL de paiement s'ouvre dans le même onglet, un nouvel onglet ou un popup — jamais dans une iframe
    * [ ] Le frontend vérifie le statut réel via le backend après retour sur `return_url` (la redirection n'est pas une preuve de paiement)
  </Accordion>

  <Accordion title="Flux payin sans redirection (le cas échéant)">
    * [ ] `external_id` et `otp` sont vides (`""`) dans les requêtes où ils ne sont pas utilisés
    * [ ] Le mode d'authentification (OTP USSD / SMS / Approbation) est correctement documenté dans l'UX pour chaque opérateur
    * [ ] Pour le mode OTP SMS : la requête initiale est soumise avec `otp: ""`, puis re-soumise avec l'OTP reçu
    * [ ] Pour le mode Approbation (Moov) : le callback est la seule confirmation — pas de polling insuffisant
  </Accordion>

  <Accordion title="Gestion du callback">
    * [ ] Le handler est idempotent (deux appels avec le même `transaction_id` n'exécutent la logique qu'une fois)
    * [ ] Les deux formats de callback sont gérés (`application/json` et `application/x-www-form-urlencoded`)
    * [ ] Voir [Idempotence du callback](/api-paiement/callback/idempotence) et [Parser custom\_data](/api-paiement/callback/parser-custom-data)
  </Accordion>

  <Accordion title="Base de données et traçabilité">
    * [ ] La transaction est créée en base **avant** l'appel à LigdiCash
    * [ ] Le `token` LigdiCash est stocké dès la création de la facture
    * [ ] Les logs d'entrée et de sortie (requêtes LigdiCash + callbacks reçus) sont conservés
    * [ ] Voir [Architecture recommandée](/guides/architecture-recommandee)
  </Accordion>

  <Accordion title="Fallback polling">
    * [ ] Un job périodique vérifie les transactions restées `pending` depuis plus de quelques minutes
    * [ ] Le polling s'arrête après un délai raisonnable (ex : 24h) — les transactions ne passent jamais automatiquement en `notcompleted`
    * [ ] Le polling utilise le `token` stocké à la création, pas un token issu du callback
  </Accordion>
</AccordionGroup>

## Payout (si applicable)

<AccordionGroup>
  <Accordion title="Flux payout vers wallet LigdiCash">
    * [ ] Le client destinataire possède un compte LigdiCash (requis pour `/withdrawal/create`)
    * [ ] La sémantique de `top_up_wallet` est correctement implémentée : `1` = fonds dans le wallet, `0` = virement automatique vers le mobile money lié
  </Accordion>

  <Accordion title="Flux payout vers mobile money direct">
    * [ ] Le numéro de téléphone est au format `22670XXXXXXX` (sans `+`, sans espaces)
    * [ ] L'endpoint `/straight/payout` est utilisé (pas `/withdrawal/create`) pour les destinataires sans compte LigdiCash
  </Accordion>
</AccordionGroup>

## Business et opérationnel

<AccordionGroup>
  <Accordion title="Compte marchand et projet API">
    * [ ] Le compte marchand LigdiCash est actif et vérifié (KYC complété)
    * [ ] Le projet API est en mode production (pas de compte de test)
    * [ ] Les opérateurs souhaités sont activés sur le projet API (vérifiez dans le dashboard)
    * [ ] Visa activé séparément si vous en avez besoin (contrat spécifique)
  </Accordion>

  <Accordion title="Gestion des erreurs côté UX">
    * [ ] Chaque code d'erreur LigdiCash est mappé à un message lisible par l'utilisateur
    * [ ] L'utilisateur est informé clairement si son paiement échoue, avec une invitation à réessayer
    * [ ] Voir [Erreurs courantes](/erreurs/erreurs-courantes)
  </Accordion>

  <Accordion title="Communication avec LigdiCash">
    * [ ] Votre `callback_url` a été testée en conditions réelles
    * [ ] Vous avez un groupe d'intégration Microsoft Teams LigdiCash pour les urgences en production
    * [ ] Si whitelisting IP requis : les IPs de votre serveur ont été transmises au support technique LigdiCash
  </Accordion>
</AccordionGroup>

## Tests pré-production

Avant le go-live, effectuez au moins un test de bout en bout pour chaque flux que vous intégrez.

| Scénario                                    | À tester                                                                 |
| ------------------------------------------- | ------------------------------------------------------------------------ |
| Paiement réussi                             | Le statut passe à `completed`, la commande est confirmée                 |
| Paiement annulé par l'utilisateur           | La `cancel_url` est atteinte, la commande reste `pending` puis expire    |
| Callback reçu deux fois                     | La logique métier n'est exécutée qu'une fois                             |
| Transaction toujours `pending` après 10 min | Le polling de fallback la met à jour correctement                        |
| Clé API invalide                            | L'erreur est capturée et loggée, l'utilisateur voit un message générique |

<Warning>
  LigdiCash n'a pas d'environnement sandbox distinct. Les tests sont effectués avec un compte de test réel fourni par l'équipe LigdiCash pendant la période d'intégration. Contactez [developper@ligdicash.com](mailto:developper@ligdicash.com) pour obtenir un accès de test.
</Warning>

## Pages associées

* [Architecture recommandée](/guides/architecture-recommandee) — structure backend
* [Sécurisation du callback](/api-paiement/callback/securisation) — pattern de re-vérification
* [Pattern transaction\_id](/concepts/transaction-id-pattern) — identifier les transactions
* [Gestion des erreurs](/erreurs/vue-ensemble) — codes et stratégies