Passer au contenu principal
Utilisez un client existant pour les retraits fiat, les ordres de paiement et les comptes virtuels. Le client doit être actif et appartenir à l’entreprise authentifiée. Sans customerId, le flux appartient à l’entreprise ; l’intégration du client ne débloque pas une intégration d’entreprise manquante.

​
Identité et sessions

Commencez les retraits avec customerId dans rates et les dépôts avec customerId dans la cotation. Transmettez sessionId ensuite ; le serveur hérite du client. Un customerId répété doit correspondre. Changer le client, la route, le réseau ou les paramètres exige une nouvelle session. La découverte des actifs, devises et moyens de dépôt n’accepte pas customerId.

​
Retirer en fiat

Rates, méthodes de paiement, exigences, résolution, cotation et exécution acceptent customerId facultatif. Les cotations et exécutions des adresses enfants aussi. Les retraits v1 hérités l’acceptent lorsque leur DTO inclut le contexte client. Noah et Infinia prennent actuellement en charge cette identité ; l’API ne la remplace pas par celle de l’entreprise.

​
Résolution du paiement

Si la résolution renvoie status: requires_action, affichez nextStep.schema et envoyez continuation avec resolutionId, stepId et data à la même opération. Conservez paymentMethodData original. Continuez jusqu’à resolved, puis envoyez la réponse complète comme resolvedPaymentMethod pour la cotation et l’exécution. Les réponses héritées sans status ni nextStep sont résolues.

​
Reprise de l’intégration

Les échecs d’éligibilité sont des erreurs HTTP, pas des réponses data réussies. Consultez details.code, details.customerId, details.provider et details.onboarding.action. Suivez la méthode, le chemin et le corps renvoyés. Pour create_case, utilisez le client existant ; pour resume_case, consultez le dossier ; pour wait, attendez ; pour contact_support, contactez l’assistance. Ne créez pas automatiquement un autre client ou dossier si le dossier est en attente ou rejeté.

​
Déposer en fiat

La cotation, la résolution des exigences et la création d’ordres acceptent customerId. Avec sessionId, assetId, currency, amount et rail sont hérités ; sans session, ils sont obligatoires. customer contient les coordonnées facultatives du payeur et ne remplace pas customerId. Pour le KYC intégré, utilisez additionalDataRequirements.data comme valeurs initiales et validez le schéma actuel avant additionalData. L’intégration hébergée est vérifiée séparément.

​
Comptes virtuels

Les exigences, la création et la régénération v2 acceptent déjà customerId, y compris pour les adresses enfants. Les exigences valident l’appartenance du client et son éligibilité auprès du fournisseur. Utilisez additionalDataSchema, pas les schémas d’ordres. La création renvoie 201 avec created: true pour un nouveau compte, ou 200 avec created: false si un compte existant est réutilisé.

​
Montants et frais

debitAmount est le débit total dans l’actif source. amountFiat est le paiement fiat avant deductions ; soustrayez-les une fois pour obtenir le montant du bénéficiaire. transactionFee est exprimé dans le cryptoactif source et peut inclure des frais supplémentaires autonomes, les frais totaux de méthode et le traitement. Il ne représente pas toujours tous les frais : les coûts déjà prélevés par le fournisseur peuvent être financés et le spread est inclus dans le taux. N’ajoutez pas de frais à debitAmount. Le champ transactionFeeCurrency n’existe pas.

​
Voir aussi

Webhooks d’integration des clients Actualiser l’integration — Demandez de nouveaux taux de retrait ou une nouvelle cotation de dépôt pour créer une nouvelle session fiat. Ne réutilisez pas une session antérieure à l’approbation. Les changements peuvent émettre des webhooks customer.onboarding.* ; un dossier inchangé ne garantit pas un nouvel événement.

​
Operations client

Les ID du client et du dossier sont obligatoires. Le dossier actualisé est renvoyé dans data.case.