Orders vs payments
This page explains what orders are and how they are different from payments
This page explains how Orders work and has the following sections:
Orders vs payments
On the Accounts page we saw that payments are linked to Orders. In this page we will explain what Orders are.
Expenses, supplier payments, subscriptions and disbursements are all Orders in Yordex. Orders can have more than one payment. For example, subscriptions or orders with partial payments have more than one payment.
In addition to payment details, orders also contain other information. For example they contain a link to the supplier (trader), approvals, receipts, categorisations and, if provided, line item details
The table below summarises the difference between Orders and payments in Yordex.
Orders | payments | |
---|---|---|
APIs | POST /orders | GET /reports/yordexpay |
Represents | Expenses, subscriptions, supplier payments, disbursements and any other payment type you need | Card payment, bank transfer or card top up |
Contains | Payments, supplier, approvals, payment terms, invoices/receipts, line item details, categorisation and different statuses | Payment details |
As you can see from the table, it is not possible to create a payment directly. All payments are either created by cards or orders. To pay out to someone you can either
- Give them a card and top up the card
- Create an order linked to a card and the order will top up the card
- Create an order that will trigger a bank transfer (same tutorial)
Order lifecycle
An Order has one or multiple Events. Every event represents a payment. The difference between an Event and a payment are:
- Events are created before the payment is made allowing the payment to be pre-approved
- Invoices or receipts are linked to Events, not to payments
Event approval is separate from Order approval. Typically an Order approval indicates that the purchase can be made while the Event approval indicates that the goods or services were delivered so the payment can be made.
Orders and Events therefore each have their own statuses that are separate but linked:
- An Order is only COMPLETED when all Events are COMPLETED
- Only one Event can be 'active' at a time: an event will remain NOT_STARTED until the event before it is COMPLETED
- The Order has to be APPROVED before the first event becomes active. It is however possible to amend an order (temporarily move it back to NOT_APPROVED for editing) when Events are still active
An order lifecycle can be summarised like this:


To illustrate this process, here is a workflow an Order with two Events could go through:
At the start, the statuses will be as follows:
- Order: NOT_APPROVED
- Event 1: NOT_STARTED
- Event 2: NOT_STARTED
Once the order is approved and the first event is for confirmation, the statuses will be as follows:
- Order: APPROVED
- Event 1: FOR_CONFIRMATION
- Event 2: NOT_STARTED
Once the first event is completed and the second event is for confirmation, the statuses will be as follows:
- Order: APPROVED
- Event 1: COMPLETED
- Event 2: FOR_CONFIRMATION
If you amend an order that was already in progress, the statuses will be as follows:
- Order: NOT_APPROVED
- Event 1: COMPLETED
- Event 2: FOR_CONFIRMATION
The order state goes back to NOT_APPROVED and the order has to be approved again, but the event states do not change throughout this process.
Once all events are completed, the statuses will be as follows:
- Order: COMPLETED
- Event 1: COMPLETED
- Event 2: COMPLETED
Updated 3 months ago