This module allows the admin to view all types of Orders in various states.

Order Types

Order States

While there are several details tracked about an order, it will undergo a series of states. Each state is captured in its history. What each state implies is defined below:
Note: Many of these states may not apply, or apply internally to the system. You can choose to map which of these are significant from a notification or action point of view. So your user interaction status can be a sub-set of these. Internally this is the level of detail the system will maintain for each order.

REQUESTEDOrder was started and has not proceeded since
APPROVEDAn optional state in a workflow, where before it an be PLACED or IN_PROCESS or REMIND_USER_TO_PROCEED it is in an APPROVED state ready to be processed. An alternative state can be ON_HOLD or one of the CANCELLED states, which signal it was rejected.
REMIND USER TO PROCEEDOrder required some admin intervention and the admin now wishes to inform the user to proceed. For example, certain aspects of the payment may not be clear at the time of placing the order. So the admin can specify aditional Shipping rates and direct the user to complete payment and complete the order
FAILED TRANSACTION COMPLETEThe last transaction attempted by the customer failed to complete due to the user abandoning the process
FAILED TRANSACTION ERRORThe last transaction attempted by the customer failed to complete due to some technical failure
IN PROCESSThe order is in process
PLACED AUTOThe order was placed by the customer successfully
PLACED PARTIAL(Optional) If a project recognizes partial state between a placement that started automatically but due to some intervention or other system fault could not complete
PLACED MANUALThe order was placed successfully, but by an administrator
DISPATCHEDThe order has been dispatched to the customer
DELIVEREDThe order has been delivered to the customer
RETURNEDThe order was returned by the customer
CANCELLED USERThe order was cacelled by the customer
CANCELLED ADMINThe order was cancelled by an Admin on the merchant side, irrespective of user getting the order or not. This can be a REJECT in a workflow where for any reason the Admin did not want the order to proceed.
CANCELLED SYSTEMThe order was cancelled by the System or Admin
CLAIM REFUNDThe order has gone into a refund state but not yet been refunded
REFUNDThe order was refunded
DISPUTEThe order is under dispute
CLOSEDThe order was closed
CAPTURED_AUTOThis is an step before {@link #PLACED_AUTO}; where after an online payment some gateways allow you to CAPTURE the payment. This can be followed by a {@link #PLACED_MANUAL} or {@link #PLACED_AUTO}
CAPTURED_MANUALThis is an step before {@link #PLACED_MANUAL}; where after an online payment some gateways allow you to CAPTURE the payment. This can be followed by a {@link #PLACED_MANUAL} or {@link #PLACED_AUTO}
ON_HOLDThe Order is stuck, or waiting for approval or some signal to proceed. IN_PROCESS differs from ON_HOLD in the sense that IN_PROCESS there is progress in the natural course. ON_HOLD explicitly states its not in progress.
READYService based Orders, may need to communicate Ready to deliver State. Pre-Delivery
BACK_ORDERIf an order was requested but was still accepted inspite of zero inventory. Then as a Back Order accept to provide it to the customer.
... one can define additional states custom to a project, if required. However newly defined states and their implications have to be programmed also.

Order Reports

Bulk Actions

Bulk actions on Orders

Some Bulk actions can be performed on orders. While custom actions can be defined, some of the common actions defined are:

Action NameDescription
Unlock All products from OrdersWill dissassociate all products from orders they belong to. this is useful to delete products etc. Note, that for products removed you may not be able to view additional details in the order and it may impact the invoice generation part. One can always re-lock to come back to this state if the product is not deleted permanently).
Remove old requested OrdersA way to clean old stagnant orders in REQUESTED status, which are more than 3 weeks.
Re Lock unfinished OrdersOpposite of UnLock All Products. This allows to re-associate any unlocked products with the order again, if the products still exist within the system.

Order & Customer Details

On clicking on the Order Id of an Order in the order report listing, one can open the order details. Within the order details one can find the following information linked to the order:

Shopping Cart(s)

The shopping cart uses a client side store that synchronizes itself with the server each time an action like Add, Delete etc is performed on it. By default, the synchronization is instant so that we do not commit any wrong information to the customer. For example if a product could not be added to users cart on Server then on the browser also it will report that, to be consistent. However this can be customized, but not recommended. The instant synchronization also allows us to customize logic while customer is adding products to cart. It is also worth mentioning to prevent, users from influencing or hacking the system the Server only relies on the product codes that constitute a cart, it computes the total, discounts etc afresh and does not rely on stale browser cart information that can be tampered with on the interface by hackers.

Life of a Cart

This depends on the type of a Cart. A Shopping cart is only maintained for an active session on a browser window. If you were to close the window the session is lost with the window and so is the cart. On the other hand a cart like a Wish list (if any), can persist for the browser however for a Guest user we anyway do not have a handle so for a Guest user the list may or may not be available, but for a Registered user carts persist. Additionally, to ensure the customer did not hack their cart when they connect to the server the Cart is refreshed by what was last maintained on the server when they login. This feature cannot be available for Guest users.

Life of products within a Cart

The products are maintained within a cart for as long as the Cart is alive, as explained in the previous section. In addition to this, the cart is ONLY cleared if the user made a successful transaction or the user explicitly removed or added to it. The reason for this is simple, that we do not want a person to keep adding the same products to the cart each time they try to make a payment. It is also worth noting that the definition of a successful transaction implies the user came back from the payment gateway after making a successful purchase. In this case the user has no longer use for the products and they are also permanently committed to the user.

Locks on Products - Concurrent Add to Cart Scenario

On high demand products, it may be possible that certain products are limited in stock. This creates a dilemma if a product should be available two multiple parties interested or committed to one. We call the strategy that handles this scenario, a Lock Strategy. While we can customize a Lock strategy, the default behavior is to commit a product to a user for a maximum of 30 minutes from the time the product was added, during that time as far as the inventory is concerned its less by the quantity the first user added, for rest of the world. After 30 minutes another person can also add the product to their cart. The lock strategy does not remove the product from the first user after 30 minutes either but then it's a race condition between the previous and the person currently in possession of the lock. Locks can get complicated and the default scenario is sufficient, however as mentioned customization is possible but at an extra effort.

Relation between Cart, Order, Transaction

One cart results in one order for a session. A Cart *may* result in multiple unsuccessful order attempts that can be captured by the server or ignored (depends on the project). If we want to track abandoned carts, then the server can maintain unsuccessful or REQUESTED orders also.
For an order a person has the option to re-try payment multuple times if they do not succeed. In this case 1 order can result in multiple transactions, if the user opts to Try Again option, on the same order.

Another way understanding the three is:

Transaction States

Once a customer proceeds to payment and initiates a transaction on the Payment Gateway, the following states/steps occur:

  1. REQUEST initiated : Customer made a request from the Browser to the Gateway. At this point there is no confirmation if the customer even landed on the Gateway page.

  2. REQUEST success : Customer made a successful Landing on the Gateway. This state will ensure the website has a Transaction Id, but may or may not generate a Payment Gateway Id.

  3. FAIL / Cancelled : This phase the customer engages with the gateway. The gateway will make a note of the success or failure with its own transaction Id (Gateway Transaction Id) in addition to the Website Order Id and Transaction Id. Some gateways can also track and return the Transaction Id from the issuer like VISA, MASTER CARD or the Bank. (Issuer Transaction Id).
    Cancelled by user:
    Failed due to incorrect user information/credentials supplied by user:
    Multiple fail scenario:

  4. SUCCESS (RESPONSE success) : Customer made a successful payment. This state will ensure the website has a Transaction Id, and will also guarantee an Id on Gateway and Issuers end. When a transaction is successful it means that the money was transferred from the customers card or bank to the gateway. It does not mean that the payment has immediately come into your Bank account. Depending on your arrangement with you Payment Gateway merchant, the merchant may hold the money before releasing it to you. These details have to be known and obtained from the Payment Gateway provider.

Note: Each Payment gateway may differ internally on how they process the transaction with their banks or third party merchants. You are advised to refer to the payment gateway Help or Documentation regarding further details.


Request to Gateway, no Response

Sometimes, a customer may make a purchase and it may not show up successful or completed; more simply put in your the web admin panel may show the Order result (under Transactions) Result as [Request] Successful.
This basically implies the customer made a successful REQUEST to the payment gateway but never returned from it and hence no Response, so we have no idea what happened in this scenario.

The following are possible reasons for such an issue:

What to do?

  1. Check Payment Gateway Merchant panel if the payment was actually made by the customer
  2. If it did, then goto Order Details and mark the Status as PLACED_MANUAL. This will also generate an INVOICE and email it
  3. One can also explicitly send the invoice by clicking Send Invoice
  4. Once you fullfil the order you can close the order
For this reason also, it is recommended that before sending the customer to the payment gateway an email is sent to the user with their order Id. This way if the transaction does not complete, the customer can contact you and know the status or address their concerns and inform you. This is optional and depends from project to project.
If the payment gateway does not send an email, then one must enable the system to atleast send a mail on initiating an Order to the ADMIN. This is because incase the order fails to complete then atleast the admin is aware and can be proactive in checking and following up with the customer.

Sometimes an e-commerce order may not be processed real time and we may require the customer to login later. The default Payment Link is:
https://<your domain>/<your payment page>?oid=<customer order id>&uid=<customer user id>

If the order id (oid) matches the user id (uid), and the status and nature of the order permits later payment, then the link can be used to request the user to pay via the Link. Again exact mechanics around are custom for the application in concern.

Order Process

Order Process

Back to Top