Skip to main content
A transaction is created for every payment instrument applied to an order. If a buyer pays with two methods (e.g. part cash, part bank transfer), the order contains two transactions and transactions_generate creates two records.

​
Transaction data structure

The fields below are written to orders_transactions in Firestore and the orders_transactions PostgreSQL table.
FieldTypeDescription
amountnumberAmount paid via this payment method in base currency
amount_currencystringCurrency code of the payment ("USD", "VEF")
amount_exchangenumberEquivalent amount in local currency (bolivars)
amount_exchange_ratenumberExchange rate used for conversion
client_idstringID of the event organizer
client_namestringDisplay name of the event organizer
date.createdTimestampTimestamp set by transactions_generate
date.updatedTimestampTimestamp set by transactions_generate
event_idstringFirestore ID of the parent event
event_namestringDisplay name of the event
office_idstringID of the box office
office_namestringDisplay name of the box office
order_idstringFirestore document ID of the parent order
payment_idstringIdentifier for the payment method type
payment_namestringHuman-readable payment method name
payment_dataobjectPayment-method-specific reference data (see below)
statusbooleantrue when the transaction is active/valid
custody_account.idstringID of the custody account that received the funds
custody_account.namestringDisplay name of the custody account
custody_account.account_numberstringAccount number of the custody account
point_sale_tmtbooleantrue if the transaction was made through TMT’s own POS
amount_typestringSet to "payment" by transactions_generate before writing to the custody account sub-collection
order_transaction_idstringThe Firestore document ID assigned to this transaction

​
payment_data variants

The payment_data object shape varies by payment method. Pago Móvil / Mobile payment: 
{
  "bank": "Banco de Venezuela",
  "phone": "+58-412-0000000",
  "reference_number": "123456"
}
Bank transfer: 
{
  "account_number": "0102-0000-00-000000000",
  "bank": "Banco de Venezuela",
  "reference_number": "789012"
}
Digital wallet / Zelle / PayPal: 
{
  "email": "[email protected]",
  "name": "Ana Gomez",
  "phone": "+1-305-0000000"
}
transactions_generate inspects the payment_data object for the presence of email, account_number, or bank to determine which variant to serialize into PostgreSQL.

​
transactions_generate

Creates one orders_transactions document per transaction item, copies each transaction to the corresponding custody account’s sub-collection, and marks all purchased tickets as sold in both Firestore and PostgreSQL. Trigger: POST /transactions_generate (called internally by order_process via Firebase callable)

​
What it does

  1. For each transaction in TransactionData:
    • Generates a new Firestore document ID for the transaction.
    • Sets date.created and date.updated to the current server timestamp.
    • Writes the transaction to orders_transactions/{idtransaction}.
    • Sets amount_type = "payment" and writes the transaction to custody_accounts/{custody_account.id}/transactions/.
    • Appends a row to the orders_transactions PostgreSQL table.
  2. Queries the tickets PostgreSQL table for the current ledger of each purchased ticket.
  3. Appends a { action: "sold" } entry to each ticket’s ledger.
  4. Updates status = false (sold) on each ticket in Firestore (events/{event_id}/tickets/{id}) and PostgreSQL (tickets).
  5. Looks up the buyer’s u_users document by customer_email and copies each purchased ticket document into u_users/{uid}/tickets/{ticket_id}.

​
Request

​
data.TransactionData
array
required
Array of transaction objects built by order_process. Each entry must include amount, client_id, client_name, event_id, event_name, office_id, office_name, order_id, payment_data, payment_id, payment_name, status, custody_account, amount_currency, amount_exchange, amount_exchange_rate, and point_sale_tmt.
​
data.infotickets
array
required
Array of ticket_id strings (in {event_id}-{doc_id} format) for the tickets being purchased.
​
data.event_id
string
required
The event ID — used to locate ticket documents.
​
data.customer_email
string
required
The buyer’s email — used to find their u_users record.
​
data.users_uid
string
required
Initial UID value. Overwritten at runtime with the actual UID found by email lookup.

​
Response

{
  "message": "Pago procesado ",
  "status": 200,
  "data": { "valido": true }
}
​
data.valido
boolean
true when all transactions and ticket updates completed successfully.

​
transactions_validate

Validates a specific payment reference against an existing order and marks the matching transaction as validated (status: true) in Firestore. Trigger: POST /transactions_validate

​
What it does

  1. Reads the order document from orders/{idOrder}.
  2. Iterates the order’s transactions array.
  3. For each transaction, if payment_data matches the supplied payment_data value, sets status: true on that transaction entry.
  4. Writes the updated transactions array back to the order document via a batched Firestore update.
The current implementation hard-codes idOrder and payment_data at the top of the function body. In production, these values must be supplied via req.body.data. Ensure your deployment passes order_id and payment_data in the request payload.

​
Request

​
data.order_id
string
required
The Firestore document ID of the order to validate.
​
data.payment_data
string
required
The payment reference string to match against. The transaction whose payment_data equals this value will have its status set to true.

​
Response

{
  "message": "Order Update ",
  "status": 200,
  "data": { "valido": true }
}

​
Error response

{
  "message": "Orden no Encontrada",
  "status": 400,
  "data": { "valido": false }
}
​
data.valido
boolean
true when validation succeeded. false when the order document was not found.

​
Where transactions are stored

After transactions_generate runs, each transaction exists in three places: 
orders_transactions/
  {transaction_id}          ← primary transaction record

custody_accounts/
  {custody_account_id}/
    transactions/
      {auto_id}             ← copy used to update custody balance

PostgreSQL: orders_transactions
  {transaction_id}          ← used for reporting and reconciliation
The write to custody_accounts/{id}/transactions/ fires the custody_process Firestore trigger, which increments balance_available on the custody account document.

Build docs developers (and LLMs) love

Get started for freeTalk to us