Recevoir un paiement

Du choix du token à la livraison de la commande, avec des payins créés par l'API.

  1. 1

    Choisissez le token et le réseau

    GET /v1/summary/tokens liste les tokens de la plateforme par réseau, avec min_receipt et max_receipt. La liste n'est pas filtrée par votre compte : la création du payin confirme si le token accepte les dépôts pour vous sur ce réseau.

    bash
    curl "https://bridge.bifrostcrypto.com/v1/summary/tokens" \
  -H "X-Bifrost-Invoke: YOUR_API_KEY"
  2. 2

    Créez le payin

    POST /v1/payin avec un reference_id unique dans votre système, le montant (process_by crypto_amount ou fiat_amount), webhook_url et, si vous le souhaitez, expires_at en secondes (4 heures par défaut). Conservez l'internal_reference de la réponse et montrez au client la wallet, et le memo quand le token l'exige.

    bash
    curl -X POST "https://bridge.bifrostcrypto.com/v1/payin" \
  -H "X-Bifrost-Invoke: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reference_id":"order_1001","crypto_currency":"USDT","network":"BinanceSmartChain","process_by":"crypto_amount","crypto_amount":"50","webhook_url":"https://your-site.com/webhook","customer_info":"customer_42"}'
  3. 3

    Recevez le webhook

    Vérifiez X-Bifrost-Signature sur le corps brut, répondez 2xx en moins de 30 secondes et traitez ensuite. Le même avis peut arriver plusieurs fois : dédoublonnez sur data.internal_reference avec event.

  4. 4

    Vérifiez le montant avant de livrer

    Le payin est terminé dès que received_amount atteint minimum_payment pour cent de crypto_amount, ce qui peut être moins que le total. Comparez data.received_amount à data.crypto_amount et décidez quoi faire de la différence.

  5. 5

    Choisissez quand livrer

    payment_detected signifie que le transfert a été vu (funds_available false) : livrer maintenant est votre décision et comporte un risque d'annulation. payment_confirmed signifie qu'il est définitif (funds_available true).

  6. 6

    Traitez les exceptions

    payment_reversed : le réseau a annulé le paiement et le crédit a été retiré ; check-payin renvoie désormais le statut reversed. is_duplicated true : un paiement supplémentaire ou sur un autre réseau a créé un nouveau payin avec ses propres références ; rattachez-le à la commande par customer_info.

  7. 7

    Rapprochez

    GET /v1/check-payin/{internal_reference} renvoie le payin à tout moment. GET /v1/statements liste les mouvements du solde : DEPOSIT pour le crédit, RATE et FEE pour les frais.

Que faire en cas d'échec

POST /v1/payin n'a pas d'Idempotency-Key. C'est le reference_id qui empêche un second payin.

SituationQue faire
Timeout ou pas de réponse sur POST /v1/payinRenvoyez avec le même reference_id. Si la réponse est duplicate_reference_id, la première requête a abouti : récupérez-la avec GET /v1/list-payin?reference_id=…
400Corrigez la requête. La renvoyer telle quelle donne la même réponse.
500, 502 ou 503Rien n'a été créé. Réessayez plus tard avec le même reference_id.
429Attendez le nombre de secondes indiqué par Retry-After.
Le webhook n'est pas arrivéLes envois sont répétés jusqu'à 10 fois, à environ 5 minutes d'intervalle. En attendant, lisez le payin avec GET /v1/check-payin/{internal_reference}.

Les payins créés dans le panneau ne sont pas renvoyés par l'API.