Developer Transactions
Find, filter, and interpret the transactions your API integration created, and trace a disputed payment end to end.
The Developer Transactions tab lists transactions created through Seev API products, newest first. It is a focused view for API activity rather than a replacement for your main account activity, and nothing you create in the Dashboard, such as an invoice, payment link, or storefront order, appears here.
Funds from successful API transactions land in your main Seev account, where you withdraw them or move them to another wallet. Settlement is not something you drive from this tab.
Read the transaction list
| Field | Type | Required | Description |
|---|---|---|---|
reference | string | Yes | The Seev payment reference, for example PAY-20260718-f23159df-.... Match this against the reference your own order stored. |
gatewaySessionRef | string | Yes | The gateway session reference. For Checkout API payments it is the same value as reference. |
product | string | Yes | The API product that created the transaction. checkout for Checkout API payments. |
type | string | Yes | The transaction type, payment for a checkout collection. |
amount | number | Yes | The amount in the currency's major unit. The Checkout API takes amounts in the smallest unit, and this field is that value divided by 100, so a session created with amount: 10000 shows here as 100, meaning GHS 100.00. The divisor is fixed at 100 for every currency. Every currency the API accepts divides into hundredths, so that conversion always holds. |
currency | string | Yes | Uppercase currency code, for example GHS. |
status | string | Yes | pending, completed, failed, or cancelled. |
env | string | Yes | sandbox or production. |
checkoutUrl | string | No | The hosted checkout URL issued for the session. |
expiresAt | string | No | When the checkout session stops accepting payment. |
createdAt | string | Yes | When the session was created. |
updatedAt | string | Yes | When the status last changed. Use this to order two events for the same reference. |
Amounts here are in major units while the Checkout API request and response are in the smallest unit. Convert before comparing a row against your stored order total.
Selecting a row opens its detail panel, which adds the customer name, email, and phone reported by the gateway, your own meta object as sent at creation, and the creation and update timestamps.
Filter the list
The environment selector in the developer section decides which set you are looking at. Sandbox and production data never mix, and a sandbox transaction is never evidence that a customer paid.
The period filter is a rolling window measured back from now, not a calendar bucket:
| Value | Type | Required | Description |
|---|---|---|---|
all | string | No | Every transaction. Used when the period is left empty. |
day | string | No | The last 24 hours. |
week | string | No | The last 7 days. |
month | string | No | The last calendar month back from today. |
year | string | No | The last calendar year back from today. |
Anything else is rejected:
{
"error": "invalid period. must be 'all', 'day', 'week', 'month', or 'year'",
"message": "invalid period. must be 'all', 'day', 'week', 'month', or 'year'"
}The status filter is an exact match on the stored status, so completed, pending, failed, and cancelled each return only their own rows and an empty status returns all of them. The overview graph and the failed-transactions section are the same query with these filters applied.
Investigate a payment a customer disputes
- Confirm which environment you are viewing. A production complaint against a sandbox row explains itself.
- Search for the reference your own order recorded. If your order has no reference, the create request never returned, and there may be no transaction to find.
- Open the row and compare amount, currency, product, and timestamps against your order, remembering the major-unit difference.
- Read the current status.
- Line the reference up against your webhook delivery logs and your own server logs to see which side lost the message.
| Status | Cause | What to do |
|---|---|---|
completed | The gateway confirmed payment and SeevPlus recorded it. | Fulfil only after server-side verification or a verified webhook. The dashboard row is for humans, not a fulfilment trigger. |
pending | The session was created and no final result has arrived. The customer may still be paying, or may have abandoned checkout. | Keep the order unpaid and check again. No webhook is emitted while a transaction stays pending, so waiting for a message that never comes is a real failure mode. |
failed | The gateway declined or the payment failed. A payment.failed event was emitted if an endpoint subscribes to it. | Offer the customer a retry path and keep the failed reference for the investigation. |
cancelled | The payment was cancelled. This also emits payment.failed, since there is no separate cancellation event. | Treat it as unpaid. Distinguish it from a decline using the stored status rather than the event name. |
| No row at all | The create request failed before SeevPlus recorded anything, or the recording step errored after the gateway accepted the session. | Check your server logs for the create response. A gateway session can exist without a row here, in which case verify by reference against the Checkout API. |
Do not ask a customer to pay again while the first transaction is still pending. Wait for a final status, or confirm the session has expired, before creating a second one.
Read the API customer rollup
The same transactions are grouped into read-only customer summaries, separated by environment. That view is documented in API Customers.