The smarter way
Search
K

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

Amount:

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.

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

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