Payment Tracking

Overview

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.

Transaction table

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.

Proxy fields

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.

How to activate headers setting on the dashboard

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

Header list

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 table transaction

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.

Amount definitions and calculation mechanism

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.

Amount:

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

Settled amount:

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.

Paid 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.

Remaining amount:

|Amount - Settled amount|

Fee:

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.

Refunded amount:

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

Voided 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.

Dashboard charts

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.

Total transactions chart

Represents gross volume and overall success rate across various periods.

Average transaction size chart

Product wise sales chart

Recent orders dynamic report

Payment transaction

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 states

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

States of parent payment transaction

state	state Description	Actor	Note(s)
created	The payment has been created.	Merchant
pending	Waiting for customer action on shared payment.	Customer	Only available with the installed Ottu-plugin , uses the checkout-page.
attempted	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. \	Customer	attempted has different states.
authorized	The customer entered the card details, the amount has been allocated by the bank but not yet deducted.	Customer
paid	The amount has been deducted by the bank.	Customer
failed	The transaction is failed	Customer	It is only applicable for the payment transaction that is attempted once.
canceled	The merchant has canceled the payment, and it can’t proceed afterward.	Merchant
expired	Payment life-time is expired.	Customer
invalided	The payment will not be available any longer, due to: Changing in payment configuration. Changing in currency exchange configuration. Other unforeseen events	Merchant
cod	Cash-on -delivery.	Customer	It is mostly used in food ordering services.

States of child payment transaction

Child state	Parent state	Child state description	Note
paid	authorized	Part of The payment amount will be captured by merchant	A clone of the payment transaction has been created.
refund	authorized	Part of payment amount will be back to customer	There are two refund state Queued refund Rejected refund
refund-queued	authorized	Waiting bank’s approval on payment amount.
refund-rejected	authorized	Payment amount not authorized from the bank.
voided	authorized		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

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 states

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

Payment-attempt state	Description	Mark
pending	Waiting on customer action.
created	The payment attempt is created due to a failed state.	Customers will be redirected to the bank page.
failed	The payment attempt failed, number of attempts based on payment configuration.
canceled	When a customer clicks on the cancel button.
success	Attempts to pay were successful.

Payment transaction state and payment attempt state

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.

Notifications

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
created	Payment transaction has been created
failed	Payment transits to error state and failed state
authorized	Payment transits to authorized state
paid	Payment transits to paid state
canceled	Payment transits to canceled state
expired	Payment transits to expired state
voided	Payment transits to voided state
refunded	Payment transits to refunded state
captured	Payment transits to captured state

Short-URL

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

Payment transaction expiration time

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.