Orders vs payments

This page explains how Orders work and has the following sections:

Orders vs payments
Payment lifecycle
Order lifecycle business perspective
Order lifecycle API perspective

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 /orders PUT /orders/:id	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)

Payment lifecycle

All card payments have the same lifecycle irrespective of the card network (Visa, MasterCard, Amex etc.)

Status	Description
AUTHORIZED	Payments are first authorised. After successful authorisation, the money is ring fenced on the account but not yet taken. The merchant can 'reverse' authorised funds which means the payment won't be made (see below). The cardholder cannot release authorised funds, only the merchant can.
CAPTURED	Merchants have to capture a payment which means they want to go ahead and take the payment. Some payment systems will authorise and capture in a single step which means the payment will never be in the AUTHORIZED status. After the payment is captured, the payment status is CAPTURED.
SETTLED	After capture it takes around 1 or 2 days for the money to leave the account. After the money has left the account the payment status is SETTLED

This is a typical lifecycle for a payment. Alternative lifecycles are possible and include:

Status	Description
REFUNDED	After funds are settled, it is still possible for a cardholder to get back their money. The first step would be for the cardholder to request a refund from the merchant. If the merchant agrees, they can refund the money and the status will be REFUNDED.
DISPUTED	If a merchant refuses to refund but the cardholder believes the payment should not have been made, they can contact Yordex for a chargeback. The network is the ultimate arbiter of whether the chargeback is rewarded or not.
REVERSED	After payment, it’s possible to update the original Authorization or cancel it. If your cardholder placed an order but some items are not in stock then the original amount needs to be lowered. In this case, the merchant can issue a reversal which means the ring-fenced is removed. It can be a partial or full reversal.

Order lifecycle business perspective

Yordex differentiates between payouts and expenses. All of them are orders in our system but in our app we usually call it spend collectively.

	Process	Payment Types
Payouts	Created and approved before they are paid	Card payouts or bank transfer payouts (ACH, SEPA, Faster Payments etc)
Expenses	Paid first and then possibly approved (approval is optional for expenses)	Paid on card

As you will see below, technically both payouts and expenses are the same in our system. The only difference is their lifecycle.

Payouts lifecycle:

Order created
Order approved: equivalent to a PO approval
Order confirmed: equivalent to confirming receipt of goods or services
Payment made
Order completed

A few things to know about the Payouts process:

The invoice can be added to the order at any time, but usually it is done before the order is confirmed. It is possible to not complete the order until the invoice has been provided. In that case it will in a WAITING_FOR_INVOICE status until the invoice has been provided
Payments are only made on the payment due date. The payment due date is normally taken from the invoice or set by the user If neither was provided, it defaults to the date the order was confirmed plus the payment terms, e.g. plus 30 days
Payouts can be recurring, e.g. for online subscriptions. In this case the 'order confirmed' and 'payment made' steps are repeated until the subscription runs out
Payouts can be partially paid. In this case the 'order confirmed' and 'payment made' steps are repeated for the remainder of the payment

Expenses lifecycle:

Card holder makes a payment on card
(Optional) card holder provides receipt and line manager approves
Order completed

A few additional things to know about all spend (both payouts and expenses):

Who needs to approve orders and confirm receipt of goods and services is configurable. Please contact us to set these up
Payouts can have cost allocations which usually mirror what you have in your accounting system. These can be set up in the Settings section of our app

Order lifecycle API perspective

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