Payment Tracking

Ottu dashboard is an intuitive workspace composed of a set of tools, to empower all Ottu clients to have a proper payment pipeline, create, monitor, and track payments, the dashboard greets clients with analytical information captured from payment workload(s), to give the client an insight about the payment pipeline and how could proceed with next-login.

All transaction history and details are easily accessible for merchants using Ottu's transaction table, which is provided with each plugin installed. Through the transaction table, users can proceed with payment operations such as void, refund, and capture.

The transaction table is located in the transaction tab under each installed plugin.

Ottu creates a transaction table for each plugin in order to allow merchant(s) to monitor their transactions. Ottu offers an amazing method of adding or removing transaction table’s headers, by using this method, the merchant(s) are empowered to find the required information quickly and easily.

Ottu dashboard > administration panel> plugin config (the plugin of the targeted transaction table) >Tick on (Individual proxy fields enabled)

Ottu dashboard > Required Plugin Tab> Setting > Table headers By dragging the required header (right ⇆ left), the merchant(s) can add or remove the header.

Child transactions are those created by subsequent operations (capture, refund, or void). They should be listed in the transaction table under the main origin payment transaction, which is called parent transaction. The headers of each child payment transaction are inherited from the headers of the parent payment transaction.

Many headers can be added / removed in transaction tables. See proxy fields Amount headers are displayed in different titles based on where the header refers to the payment amount in the process flow.

This is the initial amount at the creation of the transaction.

Is the amount with the same currency of the initiating amount,

  • For editable amount: It is the amount that the customer enters at the checkout page, If the customer pays the full required amount, it will have the same value as the initiating amount.

  • For non-editable amount: The settled amount is the same value as the initiating amount.

It is the amount that is credited to the merchant's bank account.

  • For purchase: It is a settled amount after adding the fee.

  • For authorize: Is the total amount captured by the staff.

Purchase or authorized is determined in payment gateway setting or configuration. See PG configuration.

|Amount - Settled amount|

It represents a markup amount on the initiating amount, which the customer proceeds with.

Depending on the selected merchant(s) currency configuration, which is used by the selected PG, fees may be applied or not to the transactions in the default currency or foreign currency.

The amount, which is sent back to customer's bank account, which is deducted from the paid amount.

It is the full transaction amount, which is credited to the customer's bank account, when the transaction rolling back process gets done. It works only for authorized payment, which is not fully or partially captured.

  • Capture, can capture the entire amount, fee + settled amount.

  • Refund, can only refund the settled amount, that’s without fee.

  • Void, will void the full amount, including the fee.

Merchant(s) easily track and monitor overall transactions and sales progress all in one place, the following snapshots have been taken from the dashboard showing a number of usable charts.

Represents gross volume and overall success rate across various periods.

Payment transaction is a core transactional data which is used by the merchant(s) to create a payment, and to perform certain operations like refund void, cancel .etc. Payment transaction is divided into two types.

Parent payment transaction: Holds the data about the payment.

Child payment transaction: Is created for subsequent operations triggered by the merchant(s).

Payment transactions state are flags, which help merchant(s) to audit-trail the transaction process.


state Description




The payment has been created.



Waiting for customer action on shared payment.


Only available with the installed Ottu-plugin , uses the checkout-page.


It allows a try-again procedure on payment which has a failure state at the customer-end till it gets succeeded/expired.

For the payment which is allowed to be tried for once, it does not have an attempted state, it has either failed state or authorized state. \



has different states.


The customer entered the card details, the amount has been allocated by the bank but not yet deducted.



The amount has been deducted by the bank.



The transaction is failed


It is only applicable for the payment transaction that is attempted once.


The merchant has canceled the payment, and it can’t proceed afterward.



Payment life-time is expired.



The payment will not be available any longer, due to:

  • Changing in payment configuration.

  • Changing in currency exchange configuration.

  • Other unforeseen events



Cash-on -delivery.


It is mostly used in food ordering services.

Child state

Parent state

Child state description




Part of

The payment amount will be captured by merchant

A clone of the payment transaction has been created.



Part of payment amount will be back to customer

There are two refund state

  • Queued refund

  • Rejected refund



Waiting bank’s approval on payment amount.



Payment amount not authorized from the bank.



Void attempts to immediately revert payment.

Voids can only be performed on transactions that have not yet been sent to

the bank could be a single job which can be fired by the end of working hours.

Below figure shows the payment transaction details which is having parent and child state for same payment transaction process. A. The full payment amount. B. Parent state (authorized). C. Child state (paid and refunded).

Payment attempt is the trial that the customer(s) make to proceed the payment when the payment transaction fails, and it is allowed to proceed multiple times.

Payment attempt state represents the payment state at the customer-end.

Payment-attempt state




Waiting on customer action.


The payment attempt is created due to a failed state.

Customers will be redirected to the bank page.


The payment attempt failed, number of attempts based on payment configuration.


When a customer clicks on the cancel button.


Attempts to pay were successful.

Payment transaction allowed to be tried multiple times attempted state for payment transaction canceled or failed state for payment attempt ➡️ attempted state for payment transaction (the payment transaction is ready to be attempted another time and stay having attempted state until it changed to expired or paid).

attempted state for payment transaction success state for payment attempt ➡️ paid or authorized state for payment transaction.

Payment transaction NOT allowed to be tried multiple times

It does not have an attempted state, it has either failed state or authorized state.

Ottu has implemented an event notification system, merchant(s) has the ability to choose the types of the notification event such as (Email, SMS, and WhatsApp).

Notification event

Triggered When


Payment transaction has been created


Payment transits to error state and failed state


Payment transits to authorized state


Payment transits to paid state


Payment transits to canceled state


Payment transits to expired state


Payment transits to voided state


Payment transits to refunded state


Payment transits to captured state

It is the ability to shorten the URL to be sent by SMS in order to reduce SMS consumption. See URL shortener configuration.

The expiration time is the length of time within which a failed transaction can be processed again, and the payment can no longer be processed after the stipulated period has expired. By default, the expiration period is one hour.

Last updated