Event catalogue

Konsole offers 60 event types to subscribe to. 57 of them actually reach an endpoint, and the three that do not are named at the bottom of this page. They all arrive in the same envelope, described in Webhooks; only data changes from one to the next, and data is always the full resource, identical to what the REST endpoint for that resource returns.

This page is the complete list, grouped by what the event is about, with the thing worth doing when it lands.

How an endpoint decides to fire

Subscription matching is a plain string comparison against the events array you registered. Three cases, and no fourth.

Prefix wildcards do not exist. payment.* is a literal string that no event is ever equal to. If you want everything under one resource, list its types.

How the names are built

resource.verb, verb in the past tense, both lowercase. The verbs are stable across resources, which makes the list shorter to remember than it looks.

Three spellings cost people an afternoon: it is succeeded, never completed or complete; it is cancelled with two l; and Sync uses deauthorized with a z while everything else in the platform is British spelling.

Payments

The six states a payment moves through. Only payment.succeeded means money.

payment.failed carries failure_reason in data. The field is absent, not null, when there is no reason to give.

Payment splits

Emitted when a single payment is debited in several instalments, using split_count or split_amounts on POST /payments.

data is the full payment, plus a split object naming which instalment this was.

"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"
}

The parent payment reaches payment.succeeded only once every instalment has succeeded. Counting payment.split.succeeded yourself to decide the order is complete is a way to ship an order that is half paid.

Refunds

data.transaction is the id of the payment being refunded, as a string, not a nested object.

Transfers

Payouts out of your balance, whether to a mobile money wallet, a bank account or a card.

Customers

The payload of customer.deleted is the customer after anonymisation: the name reads Deleted User <pseudonym>, and the email, phone and date of birth are gone. If you need the original values for your own records, you must have kept them.

Beneficiaries

Payment links

A payment made through a link emits payment.*, not link.*. The link events are about the link object itself.

link.expired appears in the Konsole picker but belongs to the per link webhook system, not to your account endpoints. Subscribing to it on an account endpoint produces nothing.

Invoices

Disputes

Chargebacks and complaints. These are the events with the shortest deadlines attached to them.

Accounts, for Sync platforms

These describe a connected merchant on a Sync platform, not your own account.

account.deauthorized fires for both deletion and revocation. There is no separate account.deleted.

Balance and fees

balance.updated sends the movement itself, which is what you want for a ledger.

The eight figures GET /balance returns are not in this payload. Call the endpoint when you need the totals.

Compliance

Emitted while your account is being verified, and whenever your file changes state afterwards.

For a platform onboarding merchants, compliance.verified is the signal that a connected account may start taking live payments. Do not infer it from anything else.

Providers

Emitted when the set of rails available to your account changes.

Worth subscribing to if you cache the channel list rather than calling GET /channels on every checkout.

Webhook endpoints

Useful on a platform account where several people can change the configuration. Note that the endpoint receiving this event may be the one that was just changed.

What data actually contains

data is the resource serialised by the same code that serves the REST endpoint, with two consequences worth knowing.

Null fields are removed, not sent as null. A payment with no description has no description key at all. Read with a default, never assume the key exists.

The payload is always in the latest API version. Version pinning applies to your API calls, not to webhook deliveries: the envelope's api_version is the platform's current version at the moment the event was recorded, and the body is shaped for that version. Pinning your account to 2026-08-01 does not change what your endpoint receives.

Events people look for and do not find

Three types you can subscribe to that never arrive

Konsole lets you tick them. Nothing is ever delivered.

The first two are visible in Events, so you can still audit a checkout after the fact. You just cannot be notified of them.

Sandbox and live are separate streams

An endpoint belongs to one environment. A sandbox endpoint only ever receives sandbox events, and a live endpoint only live ones. Two things change in the payload:

• livemode is false in sandbox and true in live.
• Event ids are prefixed evt_test_ in sandbox and evt_ in live.

A handler that hardcodes an id length or slices a prefix off will break when it meets the other environment.

Sync platforms receive a copy

When a payment, refund or transfer belongs to a merchant connected through Sync, the event is delivered twice: once to the merchant's own endpoints, and once to the platform's, as a separate event with its own id. The platform's copy carries an extra account object so you know which connected merchant it came from.

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

Deduplicate on the event id, not on the payment id: the two copies describe the same payment and carry two different event ids, deliberately.