Tests en Sandbox

Chaque nouveau compte démarre en sandbox (account_type: "sandbox"). Le sandbox vous permet d'exercer l'intégration complète — authentification, création de transactions, réception de webhooks et rapprochement — avant que de l'argent réel ne circule.

Comment fonctionne le sandbox

• Le mode de votre compte figure dans la charge utile utilisateur sous account_type ("sandbox" | "prod"). Lisez-le depuis GET /api/auth/me/.
• La surface de l'API, les formes des requêtes/réponses, les statuts et les webhooks sont identiques à la production — seul l'indicateur de mode diffère. Le code écrit pour le sandbox fonctionne sans changement en production.
• Un administrateur vous promeut en production lorsque vous êtes prêt (Passage en production).

Ce qu'il faut vérifier avant le passage en production

Parcourez chaque scénario et confirmez que votre système se comporte correctement :

1. Authentification — un jeton valide renvoie 200 depuis GET /api/auth/me/ ; un jeton invalide/expiré renvoie 401 et votre client se rafraîchit ou se réauthentifie.
2. Créer un paiement — POST /api/payments/transaction/ renvoie 201 avec une reference et transaction_status: "Received".
3. Protection contre les doublons — renvoyer le même merchant_reference renvoie 400 (et votre code le traite comme « déjà soumis », pas comme un nouveau débit).
4. Erreurs de validation — une currency/service inconnue, un champ manquant, ou un jeton non-marchand renvoie le 400/403 attendu et vous affichez error.message / error.details à l'utilisateur.
5. Webhook de succès — votre point de terminaison reçoit le callback Success, renvoie 200, et est idempotent lorsque le même callback arrive deux fois.
6. Webhook d'échec — vous gérez un callback Failed (pas de livraison, utilisateur informé).
7. Rapprochement — vous pouvez lister et ré-interroger les transactions pour récupérer après un webhook manqué (voir Rapports).

Checklist pré-production

Lorsque toutes les cases sont cochées, demandez l'accès en production — voir Passage en production.