Payments
This section details the data modelling of payments in Litium Sales area.
Overview of Payments data modeling
Transaction types
TransactionResult
PaymentOverview
- An order may contain multiple payments, represented by Order::OrderPaymentLink collection.
- Each Payment consists of a set of Transaction objects.
- Each transaction has TransactionRow objects.
- Each TransactionRow corresponds to an order row.
- If the transaction is a capture, cancel or refund, the transaction row also corresponds to a shipment row.
Please see all details in a full-size diagram of payments data modeling or click to enlarge the image below.

Transaction::TransactionType attribute identifies the type of the transaction as follows.
1. Init
All payments start with a transaction of type Init. Init transaction contains transaction rows, that corresponds to order rows of the order. The Init transaction is used to initialize the payment providers.
2. Authorize
When a buyer makes a successful purchase at the payment provider, the Payment app informs Litium of the purchase. Litium records an authorization transaction, using the data returned by the payment app. In normal scenarios, this Authorization transaction has the same information as the Init transaction. Authorization transaction has its RelatedTransactionSystemId set to the Init transaction.
3. Capture
Capture transactions happen in two scenarios:
- Shipments: When a shipment is processed, the authorized transactions are captured, resulting in a corresponding Capture transaction for the shipment. RelatedTransactionSystemId points to the Authorization from which the capture is created.
- Bank direct payments: If the buyer paid using a bank direct payment, such as Swish, the money is already captured in the bank. When the payment app notifies Litium of such transactions, Litium automatically creates the capture transaction for the corresponding Authorization transaction. RelatedTransactionSystemId points to the Authorization from which the capture is created.
4. Refund
These transactions happen when processing a return. Its RelatedTransactionSystemId is always a Capture transaction, from which the refund is processed.
5. Cancel
A cancel transaction happens if the order (or part of it) is canceled. When cancelling, a corresponding shipment is also created, to denote that it is a cancellation, and to record which items are actually cancelled. Therefore, the Cancel transaction rows still refer to a shipment row, of a shipment that is cancelled. The RelatedTransactionSystemId points always to an Authorize transaction.
- If an order is paid by a bank direct payment, and later canceled, the payment transaction cannot be canceled. Instead, it should be refunded. In this case, a shipment is created that corresponds to the cancelled items. The shipment would be canceled, but the corresponding transaction is a Refund. Its RelatedTransactionSystemId would be a Capture transaction.
Every transaction starts with an Unknown result. When the transaction is sent to the payment app, it still has an Unknown result. The payment app then notifies Litium of status from the payment provider. It can be
- Pending: Transaction is still in processing, and its result is not known to the Payment provider. The transaction's next state can be Failed, Success, or Denied.
- Success: Transaction succeeded.
- Failed: Transaction has failed and can be re-tried.
- Denied: Transaction is denied, and cannot be re-tried.
Since an order may consist of multiple payments and corresponding transactions, use the PaymentOverriew to get a complete picture of the order's payments. PaymentOverview is constructed as part of the OrderOverview, and you need to use OrderOverviewService to access it.