# Types d’événements (/fr/webhooks/events)
Sélectionnez parmi ces 23 types d’événements, ou activez un abonnement à tous les types. Chaque notification utilise l’[enveloppe commune des événements](/webhooks#event-envelope) ; cette page indique ce que chaque famille d’événements place dans `data`.
## Familles d’événements [#event-families]
| Famille | Événements | `data` contient |
| -------------------------------------------------- | ---------- | --------------------- |
| [Paiements](#payments) | 7 | `payment` |
| [Remboursements](#refunds) | 6 | `payment` et `refund` |
| [Commerçants](#merchants) | 2 | `merchant` |
| [Onboarding des commerçants](#merchant-onboarding) | 8 | `onboarding` |
La plupart des intégrations commencent par `payment.succeeded`, `payment.failed` et `payment.refund.succeeded`. Les plateformes qui effectuent l’onboarding de commerçants ajoutent `merchant.onboarding.approved` et `merchant.onboarding.action_required`.
## Paiements [#payments]
Ces événements décrivent l’ensemble du paiement, quels que soient les processeurs de paiement et les canaux pris en charge. Ils contiennent `data.payment`, y compris les champs `status` et `statusId` du paiement.
| Événement | Quand est-il envoyé ? |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `payment.created` | Un paiement est enregistré. |
| `payment.updated` | Son statut passe à `pending` ou à un autre statut sans nom d’événement dédié. Ce n’est pas une notification pour chaque modification de champ. |
| `payment.succeeded` | Son statut passe à `success`. |
| `payment.failed` | L’ensemble du paiement passe à `failed` ; il ne s’agit pas de l’échec d’une tentative de paiement individuelle. |
| `payment.canceled` | Son statut passe à `cancelled`. |
| `payment.refunded` | Tapaya marque le paiement comme `refunded`. |
| `payment.action_required` | Son statut passe à `actionNeeded`. |
La création d’un paiement dans un état autre qu’en attente envoie à la fois `payment.created` et l’événement de statut correspondant, si vous êtes abonné aux deux. Enregistrer à nouveau le même statut n’envoie ni nouvel événement de statut ni `payment.updated`.
`status` et `statusId` prennent ces valeurs dans les instantanés de paiement et de remboursement :
| `statusId` | `status` | Signification |
| ---------- | -------------- | ------------------------------------------------ |
| `1` | `pending` | Le traitement n’a pas atteint de résultat final. |
| `2` | `success` | Le paiement ou le remboursement a réussi. |
| `3` | `cancelled` | Le paiement ou le remboursement a été annulé. |
| `4` | `refunded` | Tapaya indique que le paiement est remboursé. |
| `5` | `failed` | Le paiement ou le remboursement a échoué. |
| `6` | `actionNeeded` | Une action supplémentaire est nécessaire. |
Les futurs identifiants de statut inconnus utilisent `status: "unknown"` et conservent leur `statusId` numérique. Les noms d’événements utilisent `succeeded` et `canceled` ; les valeurs de statut utilisent `success` et `cancelled`.
## Remboursements [#refunds]
Les événements de remboursement contiennent à la fois `data.payment` et `data.refund`. Le remboursement a ses propres identifiant, jeton, statut, montants demandés et de règlement et devises correspondantes. Utilisez l’identifiant du remboursement pour le suivre indépendamment du paiement parent.
| Événement | Quand est-il envoyé ? |
| --------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| `payment.refund.created` | Un remboursement est enregistré. |
| `payment.refund.updated` | Son statut passe à `pending` ou à un autre statut sans nom d’événement dédié. |
| `payment.refund.succeeded` | Son statut passe à `success`. |
| `payment.refund.failed` | Son statut passe à `failed`. |
| `payment.refund.canceled` | Son statut passe à `cancelled`. |
| `payment.refund.action_required` | Son statut passe à `actionNeeded`. |
La création d’un remboursement dans un état autre qu’en attente peut aussi envoyer l’événement de statut correspondant. Un remboursement réussi ne décrit pas à lui seul le statut final de l’ensemble du paiement : vérifiez `data.payment.status` et toute notification distincte `payment.refunded`.
## Commerçants [#merchants]
Les événements de commerçant contiennent `data.merchant` avec un `id`, un `token` et un instantané du statut enregistré du commerçant.
| Événement | Quand est-il envoyé ? |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `merchant.created` | Un commerçant est créé dans votre organisation. |
| `merchant.status_changed` | L’activation, le statut de fiche commerçant de base, la présence d’un profil, ou un compte, une soumission, une approbation ou un refus auprès d’un processeur change. |
```json title="data"
{
"merchant": {
"id": "019a0000-0000-7000-8000-000000000005",
"token": "example_merchant_token",
"status": {
"isActive": true,
"isShellMerchant": false,
"profileOnboarded": true,
"processors": [
{
"paymentProcessorId": 2,
"hasAccount": true,
"submitted": true,
"approved": true,
"rejected": false,
"submittedAt": "2026-10-29T10:00:00+00:00",
"approvedAt": "2026-10-30T12:00:00+00:00",
"rejectedAt": null
}
]
}
}
}
```
* `profileOnboarded` signifie qu’un profil existe. Cela ne signifie pas qu’un processeur a approuvé le commerçant ni que chaque moyen de paiement est prêt.
* Les identifiants de compte auprès du processeur et les messages de refus privés du processeur ne sont pas inclus. L’identifiant du processeur ci-dessus est illustratif.
* Mettre à jour des valeurs inchangées ou modifier des informations du commerçant sans rapport n’envoie aucun événement. Il n’existe ni événement `merchant.updated` ni événement de suppression de commerçant.
## Onboarding des commerçants [#merchant-onboarding]
Les événements d’onboarding contiennent `data.onboarding`. Son `status` correspond au dernier segment du nom de l’événement, et certains événements ajoutent les champs indiqués ci-dessous.
| Événement | Quand est-il envoyé ? |
| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `merchant.onboarding.started` | Le premier profil commerçant et les données d’onboarding sont enregistrés. |
| `merchant.onboarding.profile_completed` | Le premier profil commerçant complet est enregistré. |
| `merchant.onboarding.document_added` | Un nouveau document est enregistré. Ajoute `documentId`, `documentTypeId`, `paymentProcessorId`, et `source: "cache"` pour un document stocké temporairement. |
| `merchant.onboarding.stakeholder_completed` | Les données d’onboarding d’une partie prenante sont complétées. Ajoute `stakeholderId`. |
| `merchant.onboarding.submitted` | L’onboarding est prêt à être soumis à un processeur. Ajoute `paymentProcessorId`. |
| `merchant.onboarding.approved` | Un compte auprès d’un processeur est approuvé pour la première fois. Ajoute `paymentProcessorId`. |
| `merchant.onboarding.rejected` | Tapaya refuse l’onboarding après un examen manuel. Ajoute `reason`, avec `requiredAction` défini sur `null`. |
| `merchant.onboarding.action_required` | Tapaya demande des informations supplémentaires après un examen manuel. Ajoute `reason` et `requiredAction`. |
```json title="data"
{
"onboarding": {
"status": "action_required",
"reason": "The submitted company document is no longer valid.",
"requiredAction": "Upload a current company registration document."
}
}
```
* `profile_completed` arrive actuellement en même temps que `started`. Aucun des deux ne signifie une approbation par le processeur.
* `document_added` contient des métadonnées, pas le fichier. Le transfert d’un document stocké temporairement vers le processeur n’envoie pas à nouveau cet événement.
* `stakeholder_completed` couvre aussi les données complétées via une invitation. Enregistrer à nouveau les mêmes données complétées n’envoie pas à nouveau cet événement.
* `submitted` est la notification indiquant que l’onboarding est prêt ; elle ne confirme pas qu’une requête est parvenue au processeur. Il n’existe pas d’événement distinct `merchant.onboarding.ready`.
* `approved` est propre à chaque processeur. L’approbation par un processeur n’implique pas l’approbation par tous.
* `rejected` et `action_required` proviennent uniquement de l’examen manuel de Tapaya, jamais directement d’un processeur de paiement. Répéter une décision n’envoie pas de nouvel événement, les identités des examinateurs ne sont pas incluses, et la décision ne modifie pas les indicateurs d’approbation des processeurs.
Les événements d’onboarding et de statut du commerçant décrivent différents aspects d’un changement. Le même profil enregistré ou la même approbation par un processeur peut produire les deux familles d’événements si vous êtes abonné aux deux ; ne supposez aucun ordre entre elles. Les événements ne sont pas générés rétroactivement pour l’activité d’onboarding passée.
## Tests de diagnostic [#diagnostic-tests]
Utilisez l’action de test de la Platform pour envoyer `webhook.test`. Il inclut `test: true`, `merchantId: null` et `data.message`, sans état de paiement ni de commerçant. Il ne peut pas être sélectionné dans un abonnement aux événements.
Consultez [Vérifier et tester](/webhooks/receiving#send-a-test-webhook) pour vérifier la livraison sans créer de paiement.