Événements

Chaque valeur de Jeko-Event, le corps qui l'accompagne, et quel abonnement le reçoit

Tous ces événements partent par le même POST. L'en-tête Jeko-Event dit lequel. Le corps change. Seul l'escrow répète event dans le JSON. Pour les autres, ce champ n'existe pas.

events: null sur un abonnement (le défaut) reçoit chaque événement routé vers cet abonnement. Une liste qui ne contient que TRANSACTION_COMPLETED laisse tomber les autres.

Qui reçoit

Deux abonnements peuvent être appelés pour le même événement :

Entreprise (storeId absent), plus l'URL legacy du Dashboard. Elle est candidate pour chaque événement.
Magasin, seulement si l'expéditeur vise ce storeId.

Événement	Magasin visé
`TRANSACTION_COMPLETED`	Le magasin de la transaction. Magasin du marchand, ou magasin dédié si la clé plateforme a encaissé là
`SERVICE_PROVIDER_LINK_REQUEST`	Le magasin dédié du Service Provider. Les autres magasins du marchand ne le reçoivent pas
`ESCROW_HELD`, `ESCROW_RELEASED`, `ESCROW_REFUNDED`	Le magasin du pot. Avec une clé plateforme, c'est le magasin dédié
`COMPLIANCE_VERIFICATION_COMPLETED`	Le magasin dédié du Service Provider qui a ouvert la vérification

TRANSACTION_COMPLETED

Paiement complété, ou transfert complété ou échoué. Un paiement qui échoue n'envoie pas cet événement. L'absence de notification ne distingue pas un échec d'un paiement encore en cours.

Le corps est la transaction, sans champ event. Les champs sont détaillés dans Intégration.

{
  "id": "txn_1234567890",
  "amount": { "amount": 10000, "currency": "XOF" },
  "fees": { "amount": 100, "currency": "XOF" },
  "status": "success",
  "counterpartLabel": "John Doe",
  "counterpartIdentifier": "+2250701234567",
  "paymentMethod": "wave",
  "transactionType": "payment",
  "businessName": "Ma Boutique",
  "storeId": "01a0b1c2-d3e4-7f89-a0b1-c2d3e4f5a6b7",
  "storeReference": "STORE-001",
  "storeName": "Magasin Principal",
  "description": "Payment for order #12345",
  "executedAt": "2024-01-15 14:30:25",
  "transactionDetails": {
    "id": "d22c81f3-ee04-4ec5-8bd2-cd8af5dabcfc",
    "reference": "PAY-2024-001",
    "paymentLinkId": "abc123def456"
  }
}

transactionType vaut payment ou transfer. status vaut pending, success ou error.

SERVICE_PROVIDER_LINK_REQUEST

Demande de rattachement, puis ses changements de statut. Ce n'est pas une transaction : pas de amount, pas de fees. Le détail du parcours est dans Rattacher un marchand.

{
  "id": "c1e15642-cdb5-404a-b028-26a51c94059b",
  "status": "pending",
  "merchantBusinessId": "59ae202a-f583-4a15-970f-9e99bd1e0baa",
  "merchantBusinessName": "Magasin de Jean",
  "serviceProviderBusinessId": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
  "serviceProviderBusinessName": "Ma Marketplace",
  "ownerPhone": "+22507012345",
  "expiresAt": "2026-08-30T12:00:00.000Z",
  "createdAt": "2026-08-23T12:00:00.000Z",
  "serviceProviderMemberId": null
}

serviceProviderMemberId est renseigné quand le marchand a approuvé. L'idempotence se fait sur id.

ESCROW_HELD

Le client a payé, les fonds sont retenus. Ce n'est pas une transaction dépensable : reste vide pour ce job. Voir Escrow.

Jeko-Event vaut ESCROW_HELD. Le corps répète event. Lisez l'en-tête d'abord.

{
  "event": "ESCROW_HELD",
  "escrowId": "7c2d1a90-0b1e-4c3a-9f11-2e8c4d6a1b20",
  "storeId": "59ae202a-f583-4a15-970f-9e99bd1e0baa",
  "status": "held",
  "amount": { "amount": 985000, "currency": "XOF" },
  "paymentRequestId": "d22c81f3-ee04-4ec5-8bd2-cd8af5dabcfc",
  "paymentLinkId": null,
  "businessName": "Boutique Example",
  "storeName": "Cocody",
  "walletAvailableBalance": { "amount": 0, "currency": "XOF" }
}

walletAvailableBalance est le solde opérable. Il ne bouge pas pendant le hold.

ESCROW_RELEASED

Libération manuelle ou à holdUntil. Le solde opérable est crédité. Le corps ajoute transactionId, l'identifiant de la ligne type=escrow créée sur .

{
  "event": "ESCROW_RELEASED",
  "escrowId": "7c2d1a90-0b1e-4c3a-9f11-2e8c4d6a1b20",
  "transactionId": "a1b2c3d4-e5f6-7890-abcd-ef0123456789",
  "storeId": "59ae202a-f583-4a15-970f-9e99bd1e0baa",
  "status": "released",
  "amount": { "amount": 985000, "currency": "XOF" },
  "paymentRequestId": "d22c81f3-ee04-4ec5-8bd2-cd8af5dabcfc",
  "paymentLinkId": null,
  "businessName": "Boutique Example",
  "storeName": "Cocody",
  "walletAvailableBalance": { "amount": 985000, "currency": "XOF" }
}

ESCROW_REFUNDED

Remboursement au payeur. Rien de dépensable n'apparaît sur . Pas de transactionId.

{
  "event": "ESCROW_REFUNDED",
  "escrowId": "7c2d1a90-0b1e-4c3a-9f11-2e8c4d6a1b20",
  "storeId": "59ae202a-f583-4a15-970f-9e99bd1e0baa",
  "status": "refunded",
  "amount": { "amount": 985000, "currency": "XOF" },
  "paymentRequestId": "d22c81f3-ee04-4ec5-8bd2-cd8af5dabcfc",
  "paymentLinkId": null,
  "businessName": "Boutique Example",
  "storeName": "Cocody",
  "walletAvailableBalance": { "amount": 0, "currency": "XOF" }
}

COMPLIANCE_VERIFICATION_COMPLETED

Vérification KYC ou KYB d'un marchand rattaché à un Service Provider, quand le statut devient succeeded ou failed. Le sondage GET reste valable. Voir Conformité.

{
  "id": "fc86b752-c92e-44cb-a1c5-73d5ec256982",
  "type": "kyc",
  "status": "succeeded",
  "merchantBusinessId": "59ae202a-f583-4a15-970f-9e99bd1e0baa"
}

type vaut kyc ou kyb. status vaut succeeded ou failed.