Passage en production

Le passage en production change l’état de votre workspace, pas votre code. Votre intégration conserve la même URL de base et le même code ; vous remplacez une clé cpk_test_ par une clé cpk_live_.

La porte d’approbation

1. Déposez votre dossier KYB. Informations sur l’entreprise, documents, et l’identité structurée des personnes qui la dirigent ou la détiennent, le tout depuis les réglages du tableau de bord.
2. Complétez l’identité structurée. Le passage en production exige au moins un bénéficiaire effectif (UBO), et chaque bénéficiaire effectif comme chaque dirigeant doit avoir ses champs détaillés renseignés. Ces champs sont exigés au passage en production, pas au premier écran d’inscription : un compte peut donc sembler complet et rester bloqué ici.
3. Attendez l’approbation du KYB. Un workspace ne peut pas être activé tant que son KYB n’est pas APPROVED. Une tentative renvoie 422 avec un message nommant le statut courant.
4. Un opérateur active le mode production. Ce n’est pas une action en libre-service.
5. Créez une clé cpk_live_ et remplacez l’ancienne. Même URL de base, même code, même recette de signature.

Si l’étape 2 ou 3 est incomplète, l’appel échoue en 422 en précisant laquelle : une identité incomplète nomme les personnes et les champs manquants ; un KYB non approuvé nomme son statut.

Ce qui ne se transfère pas depuis la Sandbox

Sandbox et production partagent le code, mais les ressources sont propres à chaque réseau, et le savoir d’avance est ce qui rend la journée de mise en production sans histoire. À recréer côté production :

• Les clés API. Une clé cpk_test_ ne peut jamais toucher le mainnet. Créez votre clé cpk_live_ depuis le tableau de bord, avec les seuls scopes que votre intégration utilise réellement.
• Les endpoints webhook. Les endpoints s’enregistrent par réseau, chacun avec son propre secret. Enregistrez vos endpoints de production avec une clé de production (ou depuis le tableau de bord en mode Live) et conservez les nouveaux secrets ; vos endpoints sandbox ne recevront pas les événements de production.
• Les wallets et les customers. Les wallets sandbox vivent sur les testnets. Vos wallets de production se créent avec la clé de production : mêmes requêtes, même code.
• La sécurité des retraits. La liste d’autorisation, ses bénéficiaires et les limites de retrait sont une configuration côté production, sur la page Security du tableau de bord. Rien de ce que vous avez fait en Sandbox ne les préconfigure.

À lire avant votre premier retrait en production

Un workspace en production démarre avec la liste d’autorisation des retraits ACTIVE. C’est délibéré : sécurisé par défaut, et c’est la surprise du premier jour la plus fréquente.

Concrètement, votre premier retrait en production n’est pas un simple appel d’API. La destination doit d’abord figurer sur la liste d’autorisation, et ajouter un bénéficiaire est une action protégée, pas une écriture ordinaire, avec un délai de sécurité (24 h par défaut) avant que la nouvelle adresse devienne utilisable. Les retraits d’un montant élevé sont en outre retenus pour une double validation (un second membre approuve), selon la politique de votre workspace.

Anticipez-le : ajoutez vos premiers bénéficiaires le jour de la mise en production, avant d’en avoir besoin, pour que le délai de sécurité soit écoulé au moment de votre premier vrai retrait.

Cela diffère volontairement de la Sandbox. Les clés Sandbox ne reçoivent pas les scopes de retrait, précisément pour que vous n’appreniez pas un parcours de retrait sans liste d’autorisation à satisfaire, puis ne découvriez ces contrôles pour la première fois en production.

Avant votre premier vrai client

Une liste de contrôle qui mérite d’être parcourue une fois, sérieusement, avant que l’argent réel ne circule :

• Branchez-vous sur code, jamais sur le texte d’error. La formulation du message peut changer ; le code est le contrat. Voir Codes d’erreur.
• Créditez sur DEPOSIT_CONFIRMED uniquement, et lisez required_confirmations sur le dépôt au lieu d’inscrire un seuil en dur.
• Vérifiez la signature de chaque webhook et dédupliquez sur l’identifiant de livraison, stable d’une retentative à l’autre. Recette et contrat dans Webhooks.
• Envoyez une Idempotency-Key sur les POST mutants, pour qu’un timeout réseau ne devienne jamais une double action.
• Protégez le secret de production. Gestionnaire de secrets, jamais dans le code ni les journaux ; pensez à la liste d’autorisation d’IP et à l’expiration optionnelles de la clé.
• Testez votre endpoint webhook de production de bout en bout avant que le premier client ne le fasse pour vous.

Ce qui ne change pas

• L’URL de base est la même. Il n’y a pas d’hôte distinct pour la production.
• La recette de signature est identique.
• Les valeurs operationId, et donc les noms de méthodes de vos SDK, ne changent pas.
• Le réseau est déduit de la clé : cpk_test_ pour le testnet, cpk_live_ pour le mainnet. Vous ne l’envoyez pas.