Tapaya
PrésentationWebhooksTypes d’événements

Types d’événements

Choisissez les changements de paiement, de remboursement, de commerçant et d’onboarding nécessaires à votre intégration.

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 ; cette page indique ce que chaque famille d’événements place dans data.

Familles d’événements

FamilleÉvénementsdata contient
Paiements7payment
Remboursements6payment et refund
Commerçants2merchant
Onboarding des commerçants8onboarding

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

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énementQuand est-il envoyé ?
payment.createdUn paiement est enregistré.
payment.updatedSon 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.succeededSon statut passe à success.
payment.failedL’ensemble du paiement passe à failed ; il ne s’agit pas de l’échec d’une tentative de paiement individuelle.
payment.canceledSon statut passe à cancelled.
payment.refundedTapaya marque le paiement comme refunded.
payment.action_requiredSon 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 :

statusIdstatusSignification
1pendingLe traitement n’a pas atteint de résultat final.
2successLe paiement ou le remboursement a réussi.
3cancelledLe paiement ou le remboursement a été annulé.
4refundedTapaya indique que le paiement est remboursé.
5failedLe paiement ou le remboursement a échoué.
6actionNeededUne 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

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énementQuand est-il envoyé ?
payment.refund.createdUn remboursement est enregistré.
payment.refund.updatedSon statut passe à pending ou à un autre statut sans nom d’événement dédié.
payment.refund.succeededSon statut passe à success.
payment.refund.failedSon statut passe à failed.
payment.refund.canceledSon statut passe à cancelled.
payment.refund.action_requiredSon 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

Les événements de commerçant contiennent data.merchant avec un id, un token et un instantané du statut enregistré du commerçant.

ÉvénementQuand est-il envoyé ?
merchant.createdUn commerçant est créé dans votre organisation.
merchant.status_changedL’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.
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

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énementQuand est-il envoyé ?
merchant.onboarding.startedLe premier profil commerçant et les données d’onboarding sont enregistrés.
merchant.onboarding.profile_completedLe premier profil commerçant complet est enregistré.
merchant.onboarding.document_addedUn nouveau document est enregistré. Ajoute documentId, documentTypeId, paymentProcessorId, et source: "cache" pour un document stocké temporairement.
merchant.onboarding.stakeholder_completedLes données d’onboarding d’une partie prenante sont complétées. Ajoute stakeholderId.
merchant.onboarding.submittedL’onboarding est prêt à être soumis à un processeur. Ajoute paymentProcessorId.
merchant.onboarding.approvedUn compte auprès d’un processeur est approuvé pour la première fois. Ajoute paymentProcessorId.
merchant.onboarding.rejectedTapaya refuse l’onboarding après un examen manuel. Ajoute reason, avec requiredAction défini sur null.
merchant.onboarding.action_requiredTapaya demande des informations supplémentaires après un examen manuel. Ajoute reason et requiredAction.
data
{
  "onboarding": {
    "status": "action_required",
    "reason": "The submitted company document is no longer valid.",
    "requiredAction": "Upload a current company registration document."
  }
}

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

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 pour vérifier la livraison sans créer de paiement.

Il manque quelque chose sur cette page ?Demandez une fonctionnalité. Nous joignons cette page pour que l’équipe ait le contexte.