Transactions
The master ledger of every payment the institution initiates or receives, holding STK-push collections, disbursements and inbound transfers as mmm.transaction records. Each row carries the rail, member account, amount, provider reference and lifecycle state. This is the single source of truth reconciliation and support staff return to when tracing a payment.
Workflow
- Open Transactions to list all mobile-money and bank movements.
- Filter by status (pending, confirmed, failed, reversed) or by rail.
- Open a record to inspect the provider reference, callback payload and fee.
- Use the linked member account to confirm who the payment belongs to.
- Export filtered results for settlement or audit follow-up.
Fields reference
Every field on this screen, drawn from the live data model.
| Field | Type | Required | Description |
|---|---|---|---|
Reference / Receiptreference | Text | Yes | Reference / Receipt |
Providerprovider_id | Link → mmm.provider | Yes | Provider |
Directiondirection | Choice: In (C2B / receive), Out (B2C / payout), Reversal | Yes | Direction |
Amountamount | Money | Yes | Amount |
Currencycurrency_id | Link → res.currency | Yes | Currency |
Has Messagehas_message | Yes/No | — | Has Message |
MoMo Accountaccount_id | Link → mmm.account | — | MoMo Account |
Membermember_id | Link → mfi.member | — | Member |
Feefee | Money | — | Fee |
Statusstatus | Choice: Pending, Processing, Success, Failed, Reversed, Idempotency Replay | — | Status |
MSISDNmsisdn | Text | — | MSISDN |
Counterparty Namecounterparty_name | Text | — | Counterparty Name |
Rail-side Referencerail_reference | Text | — | Rail-side Reference |
Checkout Request IDcheckout_request_id | Text | — | Checkout Request ID |
Merchant Request IDmerchant_request_id | Text | — | Merchant Request ID |
Originator Conversation IDoriginator_conversation_id | Text | — | Originator Conversation ID |
Conversation IDconversation_id | Text | — | Conversation ID |
Result Coderesult_code | Text | — | Result Code |
Result Descriptionresult_desc | Text | — | Result Description |
M-Pesa Receipt Numbermpesa_receipt_number | Text | — | M-Pesa Receipt Number |
Last Polledlast_polled_at | Date & time | — | Last Polled |
Idempotency Keyidempotency_key | Text | — | Idempotency Key |
Raw Webhook Payloadraw_payload | Long text | — | Raw Webhook Payload |
Originating Callbackcallback_log_id | Link → mmm.callback.log | — | Originating Callback |
Reconciled Savings Txnreconciled_savings_txn_id | Link → mfi.savings.transaction | — | Reconciled Savings Txn |
Posted Atposted_at | Date & time | — | Posted At |
Companycompany_id | Link → res.company | — | Company |
Actions & buttons
Buttons available on this screen and what they do:
- Mark Success
- Reverse
Notes & rules
- Each transaction stores an idempotency key so duplicate callbacks cannot double-post.
- STK-push collections never store the customer's PIN - the customer authorises on their own handset.
- State transitions are driven by signed provider callbacks, not manual edits.
- Provider reference links the record back to the rail's own statement.
Was this page helpful?