diff --git a/doc/api/guides/index.rst b/doc/api/guides/index.rst
index ee2859070..b148c4df6 100644
--- a/doc/api/guides/index.rst
+++ b/doc/api/guides/index.rst
@@ -8,4 +8,5 @@ This part of the documentation contains how-to guides on some special use cases
 .. toctree::
    :maxdepth: 2
 
+   order_lifecycle
    custom_checkout
diff --git a/doc/api/guides/order_lifecycle.rst b/doc/api/guides/order_lifecycle.rst
new file mode 100644
index 000000000..6e48582d6
--- /dev/null
+++ b/doc/api/guides/order_lifecycle.rst
@@ -0,0 +1,56 @@
+Understanding the life cycle of orders
+======================================
+
+When integrating pretix with other systems, it is important that you understand how orders and related objects
+such as order positions, fees, payments, refunds, and invoices work together, in order to react to their changes
+properly and map them to processes in your system.
+
+Order states
+------------
+
+Generally, an order can be in six states. For compatibility reasons, the ``status`` field only allows four values
+and the two remaining states are modeled through the ``require_approval`` field and the number of positions within
+an order. The states and their allowed changes are shown in the following graph:
+
+.. image:: /images/order_states.png
+
+
+Object types
+------------
+
+Order
+    One order represents one purchase. It's the main object you interact with and bundles all the other objects
+    together. Orders can change in many ways during their lifetime, but will never be deleted (unless ``testmode``
+    is set to ``true``).
+
+Order position
+    An order position represents one product contained in the order. Orders can usually have multiple positions.
+    There might be a parent-child relation between order positions if one position is an add-on to another position.
+    Order positions can change in many ways during their lifetime, and can also be removed or added to an order.
+
+Order fees
+    A fee represents a charge that is not related to a product. Examples include shipping fees, service fees, and
+    cancellation fees.
+    Order fees can change in many ways during their lifetime, and can also be removed or added to an order.
+
+Order payment
+    An order payment represents one payment attempt with a specific payment method and amount. An order can have
+    multiple payments attached.
+    Order payments have their own state diagram. Apart from their state and their meta information (e.g. used
+    credit card, …) they usually don't change. They may be added at any time, but will never be deleted.
+
+Order refund
+    An order payment represents one refund attempt with a specific payment method and amount. An order can have
+    multiple refunds attached.
+    Order refunds have their own state diagram. Apart from their state and their meta information (e.g. used
+    credit card, …) they usually don't change. They may be added at any time, but will never be deleted.
+
+Invoice
+    An invoice represents a legal document stating the contents of an order. While the backend technically allows
+    to update an invoice in some situations, invoices are generally considered immutable. Once they are issued,
+    they no longer change. If the order changes substantially (e.g. prices change), an invoice is canceled through
+    creation of a new invoice with the opposite amount, plus the issuance of a new invoice.
+
+Here's an example of how they all play together:
+
+.. image:: /images/order_objects.png
diff --git a/doc/images/order_objects.png b/doc/images/order_objects.png
new file mode 100644
index 000000000..880d0bc77
Binary files /dev/null and b/doc/images/order_objects.png differ
diff --git a/doc/images/order_objects.puml b/doc/images/order_objects.puml
new file mode 100644
index 000000000..1e1641a51
--- /dev/null
+++ b/doc/images/order_objects.puml
@@ -0,0 +1,34 @@
+@startuml
+
+participant User
+collections "OrderPayment\nOrderRefund" as P
+collections "Order\nOrderPosition" as O
+collections "Invoice\nInvoiceLine" as I
+
+User -> O: Order placed (€100)
+rnote over O #6DD96D: Order A1B2C\nstatus = **n**\ntotal = €100
+O -> P: Payment created
+O -> I: Invoice created\n(can also happen later)
+rnote over I #6DD96D: Invoice 00001\n€100
+rnote over P #6DD96D: OrderPayment A1B2C-P-1\nstate = **created**
+P -> User: Payment details (web, email)
+User -> P: Payment performed
+rnote over P #EFF46B: OrderPayment A1B2C-P-1\nstate = **confirmed**
+P -> O: Order marked as paid
+rnote over O #EFF46B: Order A1B2C\nstatus = **p**\ntotal = €100
+User -> O: Data change (e.g. invoice address)
+O -> I: Invoice reissued
+rnote over I #6DD96D: Invoice 00002\n€-100
+rnote over I #6DD96D: Invoice 00003\n€100
+rnote over O #EFF46B: Order A1B2C\nstatus = **p**\ntotal = €100
+User -> O: Order canceled
+rnote over O #EFF46B: Order A1B2C\nstatus = **c**
+O -> I: Invoice canceled
+rnote over I #6DD96D: Invoice 00004\n€-100
+O -> P: Refund started
+rnote over P #6DD96D: OrderRefund\nA1B2C-R-1\nstate = **created**
+P -> User: Money sent
+rnote over P #EFF46B: OrderRefund\nA1B2C-R-1\nstate = **done**
+
+@enduml
+