Trigger Events

wajub trigger emits real test events to your account — to exercise your webhook handlers without a real payment.

6 min read

wajub trigger creates test objects and emits the corresponding webhooks. Combined with wajub listen, this is the fastest way to exercise a handler.

Trigger an event

Emit payment.succeeded

wajub trigger payment.complete

# ✓ created payment trx.Test8x2k
# ✓ payment.succeeded event emitted → evt.Tst7Yh2

Available triggers

A curated subset, not the full event catalog

wajub trigger only covers a handful of common scenarios — it does not (yet) cover every event in the full catalog (transfers, invoices, disputes, sub-accounts, payment links, …). Run wajub trigger --list for the authoritative, up-to-date list.

customer.createdtriggeroptional

Creates a test customer → fires `customer.created`.

customer.updatedtriggeroptional

Creates then updates a test customer → fires `customer.updated`.

payment.completetriggeroptional

Creates a payment and completes it with a simulated Mobile Money success → fires `payment.succeeded`.

payment.failedtriggeroptional

Creates a payment and fails it with a simulated Mobile Money decline → fires `payment.failed`.

payment.cancelledtriggeroptional

Creates and cancels a payment (simulated Mobile Money cancellation) → fires `payment.cancelled`.

payment.pendingtriggeroptional

Creates a payment and leaves it pending — no immediate webhook.

refund_completetriggeroptional

Completes a payment then refunds it successfully → fires `refund.processing` then `refund.succeeded`.

refund_failedtriggeroptional

Completes a payment then triggers a refund that deterministically fails → fires `refund.processing` then `refund_failed`.

Trigger name vs. event name

The string you pass to wajub trigger is a scenario name, not always the literal webhook event type. payment.complete, for example, fires the real payment.succeeded event (there is no payment.complete webhook). Only refund_complete/refund_failed happen to reuse underscore-style names close to their corresponding webhook events (refund.succeeded / refund_failed) — check the event catalog for the event type your handler should actually switch on.

Customize the payload

Override fields to reproduce a specific case:

Custom amount and channel

wajub trigger payment.complete -d amount=250000 -d currency=XOF -d channel=sn.wave

--amount=<int>flagoptional

Amount for the created resource (default: 5000).

--currency=<string>flagoptional

ISO currency code (default: XAF).

--channel=<string>flagoptional

Payment channel (default: cm.mtn).

--phone=<string>flagoptional

Payer phone number (advanced).

-d, --data=<key=value>flagoptional

Override a payload field (repeatable).

--listflagoptional

List available triggers.

Real test objects

Objects created by trigger actually exist in your sandbox environment: you will find them in the Dashboard and in Konsole, with the same signature as in production.

Receive webhooks locallyConnect listen + trigger.Test scenariosSandbox numbers and edge cases.Event catalogAll available types.

Edit this page on GitHub

Need help?

Contact support GitHub Discussions Service Status