Skip to main content

Disponibilité

Appelez GET /services et choisissez une méthode active pour le pays, la devise et l’opération. Les services crypto sont marqués method_type: "CRYPTO". accepted_coins liste les actifs disponibles pour les demandes de paiement lorsque la configuration les fournit. Les dépôts et payouts crypto utilisent un wallet USD actif. Le tableau de bord ne propose les méthodes crypto qu’après la sélection d’un wallet USD. Le serveur vérifie aussi la devise, le propriétaire et le statut du wallet avant d’accepter un payout. Le code public de méthode est CRYPTO. L’administration contrôle la disponibilité à trois niveaux : fournisseur, capacité (pays/devise/opération/méthode) et itinéraire. Une méthode désactivée disparaît du catalogue et les nouvelles demandes correspondantes sont refusées. Les frais restent configurés côté serveur. Les règles globales et les règles ciblées par pays, devise et méthode s’appliquent avant l’envoi au fournisseur. Ne calculez pas le montant final comme une source de vérité côté client.

Demander un paiement crypto

Pour une application, créez une collecte avec POST /payments. Dans le tableau de bord Marchand, le même parcours utilise POST /payment-intents. Utilisez payment_method: "CRYPTO", la méthode publique renvoyée par GET /services.
payer ne requiert pas de numéro de téléphone pour cette méthode. L’API renvoie une redirect_url si le fournisseur a créé un lien de paiement. Redirigez le payeur vers ce lien. Utilisez GET /payment-intents/{id} ou les webhooks BizConnectPay pour suivre le statut final. Conservez provider_reference pour le rapprochement.

Effectuer un décaissement crypto

Utilisez POST /payouts pour une application ou POST /withdrawals dans le tableau de bord Marchand. L’opération débite un wallet actif. payment_method doit correspondre à un service crypto de décaissement renvoyé par le catalogue. destination contient l’adresse blockchain.
amount_type accepte fiat ou crypto. Pour fiat, amount est exprimé dans currency. Pour crypto, il est exprimé dans l’actif demandé. asset_code doit être autorisé par l’itinéraire; ne supposez pas qu’un actif est disponible parce qu’il apparaît dans un exemple. destination_memo est facultatif et dépend du réseau. fee_bearer accepte merchant ou customer lorsque l’itinéraire le permet. Le serveur vérifie le solde, applique les frais configurés, réserve les fonds et utilise une clé d’idempotence pour éviter un double paiement. Enregistrez l’identifiant BizConnectPay et provider_reference; ne soumettez pas directement une seconde demande si le résultat initial est incertain.

Suivre les statuts

Un statut intermédiaire ne signifie pas que le transfert a réussi. Traitez uniquement les statuts finaux documentés par l’API comme définitifs. Votre webhook BizConnectPay contient l’événement et l’objet de transaction normalisé; consultez Webhooks pour la signature, les nouvelles tentatives et la validation.