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

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.

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

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

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

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