Passer en live

Passer en production tient en une ligne de configuration. Tout ce qui rend ce passage sûr se fait avant de modifier cette ligne, et c'est l'objet de cette page : une checklist que vous pouvez vraiment cocher, puis la liste de ce qui se comporte différemment en production et qui n'a pas pu être testé dans la sandbox.

Avant tout, faites vérifier votre compte

La production s'ouvre quand votre dossier de conformité est approuvé, et pas une minute plus tôt. Les clés live existent avant cela et elles s'authentifient, mais toutes leurs limites sont à zéro. Activation du compte et KYC détaille le dossier et l'examen.

Soumettez-le tôt. L'examen prend jusqu'à 48 heures, et votre intégration sandbox continue de fonctionner pendant ce temps. L'ordre logique est donc de déposer le dossier d'abord, puis de dérouler le reste de cette page pendant qu'il est examiné.

La checklist

Cochez ces points dans votre propre environnement. Chaque élément se vérifie en exécutant du code, pas en faisant confiance. Votre progression est conservée dans ce navigateur : vous pouvez y revenir.

Checklist de mise en production

0/23

• Clés et accès
• Clés de production lues depuis des variables d'environnement, jamais depuis le code source.
• La clé privée n'atteint jamais un navigateur, un binaire mobile ou une ligne de log.
• Une clé restreinte qui ne porte que les scopes que vous appelez vraiment.
• Une liste d'IP autorisées sur la clé de production, pour qu'une clé divulguée ne serve à rien ailleurs.
• Quelqu'un d'autre que vous sait renouveler une clé et redéployer, et l'a déjà fait une fois en sandbox.
• Paiements
• La commande est livrée sur le webhook payment.succeeded, jamais sur la redirection de retour.
• failed, cancelled et expired mènent chacun à un parcours sensé dans votre interface.
• Un en-tête Idempotency-Key sur chaque POST /payments et POST /transfers.
• Montants envoyés dans l'unité principale, et relus avec le champ currency à côté.
• Votre propre reference unique sur chaque paiement, pour qu'une soumission en double renvoie 409.
• Webhooks
• Un endpoint de production enregistré, avec son propre secret de signature dans votre environnement.
• Chaque signature entrante vérifiée avant de faire confiance au payload.
• L'endpoint répond 2xx en moins de dix secondes et met son vrai travail en file d'attente.
• Livraisons dédupliquées grâce à l'en-tête X-Wajub-Delivery-Id.
• Vous avez vu une nouvelle tentative se produire : cinq tentatives, à 30 s, 1 min, 5 min, 10 min et 1 h.
• Pannes et charge
• Attente progressive sur 429, en lisant retry_after dans le corps plutôt qu'en devinant.
• Timeouts réseau et 5xx relancés avec la même clé d'idempotence.
• Solde vérifié avant une série de payouts, et non découvert en pleine boucle.
• Alertes sur un pic d'échecs, envoyées là où un humain regarde.
• Konsole accessible à la personne d'astreinte.
  Voir le guide →
• Équipe
• Rôles attribués selon le moindre privilège, pour que le support ne puisse pas créer de clés.
• Double authentification imposée à toute l'équipe.
• Au moins deux personnes peuvent accéder au Dashboard, vérifié en se connectant.

Ce qui change une fois en live

C'est la partie qu'une sandbox ne peut pas vous apprendre : lisez-la avant de basculer, pas après.

Cinq fonctionnalités ne vous ont jamais été accessibles. Les liens de paiement, les factures, les taxes, Shield et les identifiants fiscaux des clients refusent tous les clés sandbox avec 403 This feature is only available in live mode. Si votre intégration utilise l'une d'elles, ce code s'exécute pour la première fois en production. Prévoyez une répétition ciblée sur ces parcours précisément.

Votre limite de requêtes dépend de votre offre, pas de votre environnement. Pay as you go autorise 120 requêtes par minute, Growth 360, Scale 720, et Enterprise n'a pas de plafond. Sur une offre sans plafond, les en-têtes X-RateLimit-* sont totalement absents : tout code qui les lit doit traiter leur absence comme normale, et non comme un zéro.

Le secret de signature des webhooks est différent. Il appartient à un endpoint, et un endpoint appartient à un seul environnement. Enregistrer la même URL en production vous donne une nouvelle valeur whsec_. Recopier celle de la sandbox est la raison la plus fréquente pour laquelle un premier webhook live échoue à la vérification de signature.

Les identifiants perdent leur segment test_. Un paiement sandbox est trx_test_… et son équivalent en production est trx_…. Rien dans votre code ne doit dépendre de ce segment, et tout ce qui reconnaît des identifiants par motif doit être vérifié une fois avant de basculer.

L'argent peut vraiment manquer. Un payout échoue sur un solde insuffisant, un portefeuille a son propre plafond journalier inférieur au vôtre, et un client peut tout simplement ne pas confirmer. Rien de tout cela n'arrive dans une sandbox, où le résultat dépend du numéro de test que vous avez composé.

Faire la bascule

Faites ces quatre étapes dans un seul déploiement plutôt que sur tout un après-midi. Une intégration à moitié basculée envoie des paiements live vers un webhook sandbox, et vous ne le remarquerez qu'au rapprochement.

1. Enregistrez vos endpoints de webhook de production et copiez chaque nouveau secret de signature.
2. Placez la clé de production et ces secrets dans votre environnement de production.
3. Déployez. Le SDK ne demande aucun autre changement, la clé seule détermine l'environnement.
4. Vérifiez dans Konsole que votre première requête de production a bien été authentifiée en live.

Votre premier vrai paiement

Payez-vous vous-même. Prenez le plus petit montant accepté par votre opérateur, en général 100 XAF, et déroulez tout le parcours avec votre propre téléphone.

Quatre conditions doivent être réunies avant d'ouvrir les portes. La transaction atteint succeeded. Votre endpoint de production a reçu payment.succeeded et la signature a été vérifiée. Le montant apparaît dans votre solde. Et votre propre base de données a enregistré la commande comme payée, par le même chemin de code que celui qu'un client déclencherait.

Ensuite, remboursez-le. Le remboursement est le seul parcours que personne ne teste avant d'en avoir besoin, et le jour où l'on en a besoin n'est jamais un jour calme.

En cas de problème

Revenir en arrière consiste à redéployer votre clé sandbox. Aucune donnée n'est perdue et rien n'est à annuler côté Wajub, car les deux environnements n'ont jamais rien partagé. Les paiements déjà encaissés restent où ils sont, et vous pouvez tous les inspecter dans Konsole pendant que vous réparez ce qui a cassé.