Payload Reference¶

The result_url callback is POSTed with the transaction object directly as the request body — unlike the other API responses, it is not wrapped in a {"success": ..., "data": ...} envelope. The shape is otherwise identical to the data object returned by Transaction Status Query.

Confirmed payload¶

{
  "status": "success",
  "status_description": "Transaction proccessed successfully",
  "transaction_type": "B2C",
  "transaction_id": "<TRANSACTION_ID>",
  "gateway_reference": null,
  "merchant_reference": "<YOUR_UNIQUE_REFERENCE>",
  "rail_reference": "<RAIL_REFERENCE>",
  "amount": 10,
  "is_paid": true,
  "charges": 0,
  "currency_code": "KES",
  "payment_method": "mpesa",
  "created_at": "2026-04-08T22:43:58.620181+03:00",
  "completed_at": null
}

Fields¶

Field	Notes
`status`	Transaction outcome, e.g. `success`; confirm the full set of possible values (`processing`, `failed`, etc.) with Hivemind Payments
`status_description`	Human-readable description of `status`
`transaction_type`	`C2B`, `B2C`, or `B2B`, matching the value sent to Initiate Payment
`transaction_id`	Hivemind Payments' transaction identifier
`merchant_reference`	The `reference` you supplied when calling Initiate Payment — use this to match the callback to your own record
`gateway_reference` / `rail_reference`	Downstream payment-rail identifiers; either may be `null` depending on `payment_method` and how far the transaction progressed
`amount`, `charges`, `currency_code`	Transaction amount, Hivemind Payments' charges, and currency
`is_paid`	Boolean settlement flag — appears alongside `status` and may not always agree with it while a transaction is still `processing`
`payment_method`	e.g. `mpesa`, `airtel`, `tkash`, `bank`, `card`
`created_at` / `completed_at`	`completed_at` was `null` in the captured example even though `status` was `success` — don't assume it's reliably populated on completion without confirming with Hivemind Payments

This matches the Transaction Status Query response fields exactly (minus the {"success", "data"} wrapper), so the same caveats about status/is_paid/completed_at semantics apply here too.

Handling the payload¶

Match the callback to your system's record using merchant_reference.
Treat the callback as the source of truth for final state, but reconcile periodically against Transactions Statement in case a callback is ever missed.
Do not trust the payload contents without first verifying the request's authenticity — see Verifying & Testing Webhooks.