Skip to main content
Connect émet sept événements. Ils sont livrés aux endpoints webhook de votre marketplace, et à ceux du vendeur s’il en a déclaré.

​
S’abonner

Déclarez vos endpoints comme pour n’importe quel événement Yabetoo (voir Webhooks), en vous abonnant aux noms ci-dessous.
Abonnez-vous au nom nu, sans préfixe. Le type porté par le corps de l’événement est connect.transfer.created, pas evt.connect.transfer.created. Un abonnement à la forme préfixée ne matche rien.

​
L’enveloppe

accountId désigne le COMPTE CONNECTÉ, jamais votre marketplace. C’est le vendeur que l’événement concerne. La livraison chez vous est résolue à partir de son lien de contrôle.Si vous routez vos webhooks par accountId, prévoyez-le : sur un événement connect.*, ce n’est pas votre identifiant que vous lirez.

​
Le catalogue

Émis à chaque allocation réussie.data (camelCase) : id (ctr_…), controllerAccountId, connectedAccountId, sourceWalletId, destinationWalletId, amount, fee, reversedAmount, currency, availableAt, idempotencyReference, sandboxId, createdAt, updatedAt, account.
data (camelCase) : id (ctrr_…), connectTransferId, controllerAccountId, amount, currency, idempotencyReference, sandboxId, createdAt, updatedAt, account.
Émis à la capture d’un encaissement direct.data (camelCase) : id (afee_…), controllerAccountId, connectedAccountId, chargeId, intentId, transferId, amount, refundedAmount, currency, feePayer, idempotencyReference, sandboxId, createdAt, updatedAt, account.
Il n’est pas émis quand votre commission vaut zéro : en mode plateforme pure, aucune ligne de commission n’est écrite. Son absence ne veut pas dire que la capture a échoué.
data (snake_case) : account, application_fee (afee_…), refund, amount (ce que ce remboursement a repris), refunded_amount (cumul), currency.Non émis si le montant repris est nul.
Émis quand un crédit passe du solde en attente au solde disponible. C’est le signal pour déclencher un versement.data (snake_case) : account, wallet, amount, currency, source_transaction.
Le seul signal que la politique « pas de crédit » s’est déclenchée. Sans lui, vous découvrez le 402 par un acheteur mécontent.data (snake_case) : account, charge, refund_amount, required, seller_available, marketplace_balance, shortfall, currency.
data (snake_case) : account, allocation (ctr_…), required, seller_available, shortfall, currency.
Pas de marketplace_balance ici, contrairement au refus de remboursement : sur une reprise, votre solde n’est jamais sollicité.
La casse des champs de data n’est pas uniforme. Les charges utiles dérivées d’un objet (transfer, reversal, application_fee.created) sont en camelCase ; les trois autres sont en snake_case. Ne présumez pas d’une convention unique : c’est un défaut de contrat connu, à ne pas découvrir en production.

​
Les deux événements qui n’existent pas

connect.account.created et connect.account.updated ne sont pas émis aujourd’hui. N’attendez pas de webhook à la création d’un vendeur ni au changement de son état de vérification : lisez son état avec GET /v1/connect/accounts/{acct} et sa conformité avec GET /v1/connect/accounts/{acct}/compliance.

​
Idempotence de livraison

Les deux événements *_blocked_insufficient_funds n’ont aucune ancre d’idempotence : trois refus successifs produisent trois événements. C’est correct (trois refus ont bien eu lieu), mais c’est différent des cinq autres. Dédupliquez sur event.id si votre traitement n’est pas idempotent.

​
Vérification et sécurité

La vérification de signature et les règles de rejeu sont communes à tous les webhooks Yabetoo : voir Webhooks : vue d’ensemble.