Catalogue des événements

Konsole propose 60 types d'événements auxquels vous abonner. 57 d'entre eux atteignent réellement un endpoint, et les trois qui ne l'atteignent pas sont nommés en bas de cette page. Ils arrivent tous dans la même enveloppe, décrite dans Webhooks ; seul data change de l'un à l'autre, et data contient toujours la ressource complète, identique à ce que renvoie l'endpoint REST de cette ressource.

Cette page est la liste complète, regroupée par sujet, avec ce qu'il vaut la peine de faire à la réception de chaque événement.

Comment un endpoint décide de se déclencher

La correspondance des abonnements est une simple comparaison de chaînes avec le tableau events que vous avez enregistré. Trois cas, pas un de plus.

Les jokers de préfixe n'existent pas. payment.* est une chaîne littérale à laquelle aucun événement n'est jamais égal. Si vous voulez tout ce qui concerne une ressource, listez ses types.

Comment les noms sont construits

resource.verb, le verbe au passé, le tout en minuscules. Les verbes sont les mêmes d'une ressource à l'autre, ce qui rend la liste plus courte à retenir qu'il n'y paraît.

Trois orthographes font perdre un après-midi : c'est succeeded, jamais completed ni complete ; c'est cancelled avec deux l ; et Sync utilise deauthorized avec un z alors que tout le reste de la plateforme suit l'orthographe britannique.

Paiements

Les six états que traverse un paiement. Seul payment.succeeded signifie que l'argent est là.

payment.failed transporte failure_reason dans data. Le champ est absent, et non null, quand il n'y a aucun motif à donner.

Paiements fractionnés

Émis quand un même paiement est débité en plusieurs tranches, via split_count ou split_amounts sur POST /payments.

data contient le paiement complet, plus un objet split qui indique de quelle tranche il s'agit.

"split": {
  "id": "splt_9mWvL2xR7tB5nY4hC6dF",
  "split_number": 2,
  "amount": 500000,
  "currency": "XAF",
  "split_currency": "XAF",
  "status": "succeeded",
  "reference": "order-4172-2",
  "provider_reference": "MP260115.1032.B41209",
  "initiated_at": "2026-01-15T10:32:04+00:00",
  "succeeded_at": "2026-01-15T10:32:41+00:00"
}

Le paiement parent n'atteint payment.succeeded qu'une fois toutes les tranches réussies. Compter vous-même les payment.split.succeeded pour décider que la commande est complète, c'est le meilleur moyen de livrer une commande à moitié payée.

Remboursements

data.transaction est l'id du paiement remboursé, sous forme de chaîne, pas d'objet imbriqué.

Transferts

Les payouts depuis votre solde, que ce soit vers un portefeuille Mobile Money, un compte bancaire ou une carte.

Clients

Le payload de customer.deleted est le client après anonymisation : le nom devient Deleted User <pseudonym>, et l'e-mail, le téléphone et la date de naissance ont disparu. Si vous avez besoin des valeurs d'origine pour vos propres données, vous devez les avoir conservées.

Bénéficiaires

Liens de paiement

Un paiement effectué via un lien émet payment.*, pas link.*. Les événements de lien concernent l'objet lien lui-même.

link.expired apparaît dans le sélecteur de Konsole mais appartient au système de webhooks propre à chaque lien, pas aux endpoints de votre compte. S'y abonner sur un endpoint de compte ne produit rien.

Factures

Litiges

Rétrofacturations et réclamations. Ce sont les événements assortis des délais les plus courts.

Comptes, pour les plateformes Sync

Ces événements décrivent un marchand connecté à une plateforme Sync, pas votre propre compte.

account.deauthorized se déclenche aussi bien pour une suppression que pour une révocation. Il n'existe pas de account.deleted distinct.

Solde et frais

balance.updated envoie le mouvement lui-même, c'est ce qu'il vous faut pour un registre.

Les huit montants que renvoie GET /balance ne figurent pas dans ce payload. Appelez l'endpoint quand vous avez besoin des totaux.

Conformité

Émis pendant la vérification de votre compte, puis chaque fois que votre dossier change d'état.

Pour une plateforme qui inscrit des marchands, compliance.verified est le signal qu'un compte connecté peut commencer à accepter des paiements live. Ne le déduisez de rien d'autre.

Prestataires

Émis quand l'ensemble des prestataires et des canaux disponibles sur votre compte change.

Utile si vous mettez en cache la liste des canaux au lieu d'appeler GET /channels à chaque checkout.

Endpoints de webhook

Utile sur un compte plateforme où plusieurs personnes peuvent modifier la configuration. Notez que l'endpoint qui reçoit cet événement peut être celui qui vient d'être modifié.

Ce que contient réellement data

data est la ressource sérialisée par le même code que celui qui sert l'endpoint REST, avec deux conséquences à connaître.

Les champs null sont retirés, pas envoyés à null. Un paiement sans description n'a tout simplement pas de clé description. Lisez avec une valeur par défaut, ne supposez jamais que la clé existe.

Le payload est toujours dans la dernière version de l'API. La version fixée s'applique à vos appels API, pas aux livraisons de webhooks : l'api_version de l'enveloppe est la version courante de la plateforme au moment où l'événement a été enregistré, et le corps est structuré pour cette version. Épingler votre compte sur 2026-08-01 ne change pas ce que reçoit votre endpoint.

Les événements qu'on cherche et qui n'existent pas

Trois types auxquels vous pouvez vous abonner mais qui n'arrivent jamais

Konsole vous laisse les cocher. Rien n'est jamais livré.

Les deux premiers sont visibles dans Événements, vous pouvez donc toujours auditer un checkout après coup. Vous ne pouvez simplement pas en être notifié.

Sandbox et live sont deux flux séparés

Un endpoint appartient à un seul environnement. Un endpoint sandbox ne reçoit que des événements sandbox, et un endpoint live que des événements live. Deux choses changent dans le payload :

• livemode vaut false en sandbox et true en live.
• Les ids d'événement sont préfixés evt_test_ en sandbox et evt_ en live.

Un handler qui code en dur la longueur d'un id ou qui retire un préfixe cassera dès qu'il rencontrera l'autre environnement.

Les plateformes Sync reçoivent une copie

Quand un paiement, un remboursement ou un transfert appartient à un marchand connecté via Sync, l'événement est livré deux fois : une fois aux endpoints du marchand, et une fois à ceux de la plateforme, sous forme d'événement distinct avec son propre id. La copie de la plateforme porte un objet account supplémentaire pour que vous sachiez de quel marchand connecté elle provient.

"account": {
  "id": "acc_7Yh2MpL4tRb3nP8sZcXv",
  "reference": "boutique-akwa"
}

Dédupliquez sur l'id de l'événement, pas sur l'id du paiement : les deux copies décrivent le même paiement et portent volontairement deux ids d'événement différents.