Skip to main content
When a ticket sale completes, the TMT Platform creates an order — a single document that captures the full context of a purchase: which tickets were bought, for which event, by which client, and how the payment was split across one or more payment methods. Each payment method in an order becomes a transaction, and each transaction is tracked both inside the order document and as a standalone record in the orders_transactions collection.

What is an order?

An order is the top-level record of a completed sale. It lives in the orders Firestore collection and is mirrored to the orders PostgreSQL table. An order holds:
  • Amount — the total value of the sale in base currency.
  • Tickets — the list of seat/ticket references included in the sale.
  • Transactions — one entry per payment method used (e.g. cash, card, bank transfer).
  • Client and event context — IDs, names, and office references.
  • Status and payout metadata — whether the order has been fully settled and how revenue was distributed.

What is a transaction?

A transaction is the record of a single payment instrument applied to an order. One order may contain multiple transactions — for example, a split payment using both cash and a bank transfer. Transactions are stored as an embedded array inside the order document, and also written to:
  • orders_transactions in Firestore — for real-time access.
  • custody_accounts/{id}/transactions in Firestore — so the custody balance is automatically updated.
  • orders_transactions in PostgreSQL — for reporting and reconciliation.

How orders trigger transactions

Order creation is a two-step process. The HTTP function order_created writes the initial order document to Firestore. That write triggers the Firestore function order_process, which:
  1. Updates ticket customer metadata.
  2. Calls order_user to register the order under the buyer’s user profile.
  3. Calculates payout distribution (fixed cost, variable cost) against the event’s financial setup.
  4. Writes orders_payout records for each cost entity (TMT or Client).
  5. Calls transactions_generate to create the final transaction records and mark tickets as sold.

Dual-database architecture

Every order write goes to both Firestore and PostgreSQL. Firestore provides real-time subscriptions for point-of-sale UIs. PostgreSQL backs financial reporting, split calculations, and bulk queries.
DataFirestore collectionPostgreSQL table
Ordersordersorders
Transactionsorders_transactionsorders_transactions
Payout recordsorders_payoutorders_payout
Tickets (sold)events/{id}/ticketstickets
User ticket copiesu_users/{uid}/tickets
The orders_payout table tracks revenue distribution between TMT (platform fees) and the Client (event organizer). Each payout record carries a payout_status flag that is flipped by invoice_payout_status once payment is confirmed.

Subsections

Order Lifecycle

All order functions from creation to billing: order_created, order_process, order_update, order_payout, order_user, split_queries, split_payout, invoice_payout_status, and process_order_billing.

Transactions

How transactions are generated and validated: transactions_generate and transactions_validate. Includes the full transaction data structure and payment method variants.

Custody

How the custody_process Firestore trigger keeps custody account balances in sync when transactions are posted.

Build docs developers (and LLMs) love