Transactions

Money → Transactions is every payment in or out, newest first.

What a status means

This is where most questions start, and several statuses are routinely misread.

Status	What it means	Is it over?
initiated	Recorded, not yet sent to a partner.	No
pending	With the partner, waiting.	No
processing	The partner is working on it.	No
awaiting_action	Waiting on the customer — a prompt on their handset, a card authentication.	No
under_review	Held for a human decision on our side.	No
succeeded	Money collected, or payout delivered.	Yes
failed	Terminal failure.	Yes
cancelled	Stopped before completion.	Yes
expired	The customer did not complete in time.	Yes

Two things to take from that table:

awaiting_action is not a problem. It is the normal state of a mobile money collection between you asking for it and the customer approving on their phone. Most collections pass through it. If your own records show these as failures, whatever reads our API is treating “not yet succeeded” as “no”.

under_review is not a refusal. A risk rule asked for a human look. It will move to a terminal status when somebody makes that decision, and your integration will get a webhook. Do not tell the customer it failed, and do not retry it.

The two amounts, and which one is yours

Every collection shows more than one figure, and picking the wrong one quietly breaks your bookkeeping:

• Amount — what you asked the customer for.
• Customer amount — what the customer was actually charged, which is higher than Amount when the customer bears the fee.
• Merchant amount — what lands in your balance. Amount minus the fee.
• Fee — split into the platform fee and any tax on it, with a bearer saying who paid it.

Reconcile against merchant amount. It is the only one of the four that matches what you will eventually be able to withdraw.

Finding one transaction

Three identifiers point at the same payment, and it is worth knowing which is which when you are on the phone to someone:

Identifier	Who owns it	Use it for
Reference (PSG-…)	Us	Talking to PaySigna support.
Your reference	You	Finding it in your own system. The reference you sent on the API call.
Transaction id (txn_…)	Us	API calls about this transaction.

Search accepts any of them. If a customer is asking about a payment and you have nothing but an amount and a rough time, the date filter plus the amount will usually find it faster than scrolling.

Why a filter asks for dates

The transaction list always applies a date window, and a very wide one is refused. That is not an arbitrary limit: the underlying table is partitioned by date, and a query without a date range would read every partition. The practical effect is that narrowing the dates makes a slow search fast, so narrow them first and add other filters after.

Exporting

Export the filtered view rather than everything — the export honours whatever filters are on screen. For anything you need on a schedule, the API’s GET /v1/transactions is the better tool, because it will not change shape when we redesign this page.

When a customer says they paid and you cannot see it

In this order:

1. Check the environment switch. Test and live are separate lists.
2. Widen the date window — their “this morning” and your timezone may disagree.
3. Search their phone number or your own order reference rather than the amount.
4. If it is genuinely absent, the charge was never created. That is a question for whoever runs your integration, not for us: look for a failed API call at that time.
5. If it is there as awaiting_action or pending, the customer has not finished approving it. If it is expired, they took too long and need to pay again.